DEV Community: Saksham Sontakke

My Friend Copy-Pasted Random Commands From the Internet, So I Built an AI Ghost to Save His System

Saksham Sontakke — Wed, 28 Oct 2026 09:17:20 +0000

“Before you hit Enter, let the ghost reveal what lies beneath.”

🔗 Live Demo: https://client-one-rosy-53.vercel.app/

💻 GitHub Repository: https://github.com/CyborgX-hash/terminal-poltergeist

👻 What I Built

Terminal Poltergeist is an AI-powered shell command analysis and developer safety assistant that combines an open-weight language model with a deterministic security rule engine.

Developers frequently copy commands from Stack Overflow, GitHub repositories, documentation, and CI/CD pipelines without fully understanding their consequences. A misplaced flag, an unexpected pipe, or an incorrect filesystem path can turn an ordinary command into a destructive operation.

I wanted to build something that helps developers understand these commands before they run them.

Inspired by the Ghost in the Machine theme, I imagined a spectral guardian living inside the terminal—a ghost that examines unfamiliar commands, uncovers hidden dangers, explains cryptic flags, detects common typos, and suggests safer alternatives.

That idea became Terminal Poltergeist: a haunted command-analysis experience that turns developer uncertainty into understanding.

Its most important rule: submitted commands are NEVER executed. They are treated as untrusted input and analyzed using static parsing, deterministic security checks, and AI inference.

✨ What Can It Do?

👻 1. Haunted Terminal Experience

The interface combines a dark Halloween aesthetic with a retro terminal atmosphere, featuring CRT scanlines, spectral glows, glowing command prompts, subtle animations, and spooky developer-themed commentary.

🔍 2. AI-Powered Command Autopsy

Submit a shell command and receive a detailed breakdown of its behavior, flags, arguments, potential side effects, and possible risks. The AI also suggests safer alternatives when appropriate.

🛡️ 3. Deterministic Security Guardrails

A JavaScript-based rule engine identifies known dangerous command patterns independently of the language model.

When a recognized hazard is detected, the engine enforces an appropriate minimum severity so that a reassuring AI response cannot override a known security risk.

🕸️ 4. Curated Demo Incantations

Explore predefined examples covering:

Fork bombs and recursive deletion.
Dangerous filesystem permissions.
Raw disk writes and formatting operations.
Remote scripts piped directly into a shell.
Common command typos, such as gti instead of git.
Non-existent commands and phantom binaries.

These examples let users explore different scenarios without executing any commands.

🧩 5. Component-Level Breakdown

The analyzer presents command components—including flags, arguments, and pipe operators—in an understandable format, helping developers see how complex commands are constructed.

📜 6. Session History Dashboard

Review previous analyses within an isolated anonymous session, inspect risk levels, and explore the distribution of security findings.

⚙️ How I Built It

Terminal Poltergeist uses a dual-defense architecture that combines open-weight AI with deterministic security rules.

Instead of relying entirely on an AI model, the application combines static command analysis, predefined security rules, and AI-generated explanations to produce a more informative security report.

Architecture Overview

Step	Component	Responsibility
1. User Input	React + Vite Frontend	Accepts a shell command submitted by the user.
2. API Layer	Node.js + Express	Validates requests and coordinates the analysis process.
3. Lexical Analysis	Shell Lexer and Parser	Breaks commands into recognizable components, such as arguments, flags, and operators.
4. Security Analysis	Deterministic JavaScript Rule Engine	Detects known dangerous patterns and enforces appropriate minimum risk severity.
5. AI Analysis	GPT-OSS 20B via Groq	Explains command behavior, contextual risks, potential side effects, and safer alternatives.
6. Result Processing	Guardrail and Result Merger	Combines rule-based findings with AI analysis while enforcing security rules.
7. Report Generation	Unified Security Report	Produces structured findings, risk levels, explanations, and recommendations.
8. Storage and Display	Database Layer + React UI	Persists analysis records where configured and displays results to the user.

🧠 1. Open-Weight AI Inference

I integrated openai/gpt-oss-20b through Groq's hosted inference API.

The model helps explain shell commands in plain language, break down flags and compound operations, identify contextual risks, and suggest safer alternatives. It also adds the project's signature spooky developer commentary.

Using hosted inference allowed me to integrate an open-weight model without hosting model weights or maintaining GPU infrastructure.

🛡️ 2. Deterministic Security Guardrails

Language models can hallucinate, overlook dangerous command patterns, or be influenced by adversarial text embedded in user input. For this reason, I did not rely on AI alone for security decisions.

The deterministic JavaScript rule engine checks for known hazardous patterns, including:

Fork bombs: Recursive shell constructs that can exhaust system resources.
Root filesystem destruction: Dangerous recursive deletion patterns and relevant flags.
Raw disk operations: Potentially destructive writes and filesystem formatting.
Privilege and permission risks: Insecure recursive permission changes and modifications to sensitive system configuration.
Remote code execution patterns: Downloading scripts and immediately piping them into a shell.

When a recognized hazard is detected, the rule engine applies a minimum severity appropriate to that rule. The AI contributes contextual analysis, but it cannot downgrade a known hazard below its enforced severity.

This approach makes the security logic more inspectable, testable, and predictable than relying on an AI-generated risk score alone.

👾 3. Phantom Binary and Typo Detection

Not every failed command is a security threat. A misspelled command typically produces a command-not-found error rather than executing successfully.

Terminal Poltergeist distinguishes likely missing commands from dangerous operations by checking known utilities, common developer tools, and likely command typos.

Examples include:

gti → possible correction: git
sl → possible correction: ls
foobar123 → possible command-not-found result

When the tool identifies a likely missing command, it displays a dedicated COMMAND NOT FOUND status card rather than automatically treating the input as malicious.

These suggestions are advisory and depend on the available command knowledge and analysis context.

🧰 4. Technology Stack

Frontend: React, Vite, Tailwind CSS
Backend: Node.js, Express.js
Database layer: Prisma ORM with PostgreSQL support
AI: GPT-OSS 20B through Groq
Security: Static lexical analysis and deterministic JavaScript rules
Testing: Automated unit and integration tests

The repository is organized as a monorepo, with separate client/ and server/ applications.

🧪 5. Testing and Reliability

The project includes 37 automated unit and integration tests covering lexical parsing, security rules, phantom command detection, and prompt-injection defenses.

The goal is to make the application more than a themed AI wrapper: the core safety checks should be inspectable, testable, and independently maintained.

Most importantly, submitted commands are never executed. They are treated as untrusted input and analyzed as data. The application provides advisory security findings rather than guaranteeing that any command is completely safe.

🌍 Why Open Innovation Matters

Open innovation is especially valuable when building developer-facing security tools.

🔓 1. Model Choice and Reduced Vendor Lock-In

By separating inference from the application logic, the project can be adapted to compatible model providers. This creates a path toward local inference with tools such as Ollama or self-hosted inference servers, subject to model compatibility and available hardware.

🔍 2. Transparent, Inspectable Security Logic

The deterministic rule engine can be reviewed, tested, and extended by contributors. Known dangerous patterns do not have to be entrusted entirely to a black-box language model.

🌱 3. Accessibility for Independent Developers

Hosted open-weight inference lets me experiment with capable models without maintaining GPU infrastructure. A future local-inference option could also make the tool more accessible to developers who prefer to run models on their own hardware.

🔐 4. A Foundation for Privacy-Conscious Tooling

Shell commands can contain internal paths, credentials, and infrastructure details. The application should minimize the information sent to external services, avoid unnecessary retention, and make its processing model clear to users.

The current version uses hosted inference, so AI analysis requires an internet connection and submitted analysis data may be processed by the inference provider. Local inference remains a potential future extension rather than a capability I claim the current deployment already provides.

For me, open innovation is not just about choosing an open-weight model. It is about making the surrounding system adaptable, inspectable, and open to improvement.

👻 The Spirit of the Machine

Every developer knows that moment of hesitation before pressing Enter.

You have copied a command from somewhere on the internet. It looks correct. You think you understand it. But one flag, one path, or one pipe could change everything.

Terminal Poltergeist is built around that moment.

It gives developers a place to pause, investigate, and understand before taking action. The ghost is more than a Halloween character: it represents the hidden behavior inside commands that we often execute without fully understanding.

By combining open-weight AI with deterministic security guardrails, I wanted to make command-line safety more approachable without pretending that AI can guarantee perfect protection.

“The terminal may be mysterious. Your commands shouldn't be.”

🏆 Challenge Tracks

Primary Track: Ghost in the Machine — Hacktoberfest Open-Source AI Challenge
Additional Track: Open-Weight AI Innovation

🔗 Try the Live Application: https://client-one-rosy-53.vercel.app/

💻 Explore the Source Code: https://github.com/CyborgX-hash/terminal-poltergeist

Built with curiosity, open-source AI, and a little bit of digital haunting. 👻

My Friend Copy-Pasted Random Commands From the Internet, So I Built an AI Ghost to Save His System

Saksham Sontakke — Wed, 28 Oct 2026 09:09:49 +0000

Hacktoberfest Open-Source AI Challenge · Week 4: Ghost in the Machine

“Before you hit Enter, let the ghost reveal what lies beneath.”

Live Demo: https://client-one-rosy-53.vercel.app/

GitHub Repository: https://github.com/CyborgX-hash/terminal-poltergeist

👻 What I Built

Terminal Poltergeist is an AI-powered shell command analysis and developer safety assistant that combines an open-weight language model with a deterministic security rule engine.

I wanted to build something that helps developers understand these commands before they run them.

That idea became Terminal Poltergeist: a haunted command-analysis experience that turns developer uncertainty into understanding.

Its most important rule: submitted commands are NEVER executed. They are treated as untrusted input and analyzed using static parsing, deterministic security checks, and AI inference.

✨ What Can It Do?

👻 1. Haunted Terminal Experience

🔍 2. AI-Powered Command Autopsy

🛡️ 3. Deterministic Security Guardrails

A JavaScript-based rule engine identifies known dangerous command patterns independently of the language model.

When a recognized hazard is detected, the engine enforces an appropriate minimum severity so that a reassuring AI response cannot override a known security risk.

🕸️ 4. Curated Demo Incantations

Explore predefined examples covering:

Fork bombs and recursive deletion.
Dangerous filesystem permissions.
Raw disk writes and formatting operations.
Remote scripts piped directly into a shell.
Common command typos, such as gti instead of git.
Non-existent commands and phantom binaries.

These examples let users explore different scenarios without executing any commands.

🧩 5. Component-Level Breakdown

The analyzer presents command components—including flags, arguments, and pipe operators—in an understandable format, helping developers see how complex commands are constructed.

📜 6. Session History Dashboard

Review previous analyses within an isolated anonymous session, inspect risk levels, and explore the distribution of security findings.

⚙️ How I Built It

Terminal Poltergeist uses a dual-defense architecture that combines open-weight AI with deterministic security rules.

Instead of relying entirely on an AI model, the application combines static command analysis, predefined security rules, and AI-generated explanations to produce a more informative security report.

Architecture Overview

Step	Component	Responsibility
1. User Input	React + Vite Frontend	Accepts a shell command submitted by the user.
2. API Layer	Node.js + Express	Validates requests and coordinates the analysis process.
3. Lexical Analysis	Shell Lexer and Parser	Breaks commands into recognizable components, such as arguments, flags, and operators.
4. Security Analysis	Deterministic JavaScript Rule Engine	Detects known dangerous patterns and enforces appropriate minimum risk severity.
5. AI Analysis	GPT-OSS 20B via Groq	Explains command behavior, contextual risks, potential side effects, and safer alternatives.
6. Result Processing	Guardrail and Result Merger	Combines rule-based findings with AI analysis while enforcing security rules.
7. Report Generation	Unified Security Report	Produces structured findings, risk levels, explanations, and recommendations.
8. Storage and Display	Database Layer + React UI	Persists analysis records where configured and displays results to the user.

1. Open-Weight AI Inference

I integrated openai/gpt-oss-20b through Groq's hosted inference API.

Using hosted inference allowed me to integrate an open-weight model without hosting model weights or maintaining GPU infrastructure.

2. Deterministic Security Guardrails

The deterministic JavaScript rule engine checks for known hazardous patterns, including:

Fork bombs: Recursive shell constructs that can exhaust system resources.
Root filesystem destruction: Dangerous recursive deletion patterns and relevant flags.
Raw disk operations: Potentially destructive writes and filesystem formatting.
Privilege and permission risks: Insecure recursive permission changes and modifications to sensitive system configuration.
Remote code execution patterns: Downloading scripts and immediately piping them into a shell.

This approach makes the security logic more inspectable, testable, and predictable than relying on an AI-generated risk score alone.

3. Phantom Binary and Typo Detection

Not every failed command is a security threat. A misspelled command typically produces a command-not-found error rather than executing successfully.

Terminal Poltergeist distinguishes likely missing commands from dangerous operations by checking known utilities, common developer tools, and likely command typos.

Examples include:

gti → possible correction: git
sl → possible correction: ls
foobar123 → possible command-not-found result

When the tool identifies a likely missing command, it displays a dedicated COMMAND NOT FOUND status card rather than automatically treating the input as malicious.

These suggestions are advisory and depend on the available command knowledge and analysis context.

4. Technology Stack

Frontend: React, Vite, Tailwind CSS
Backend: Node.js, Express.js
Database layer: Prisma ORM with PostgreSQL support
AI: GPT-OSS 20B through Groq
Security: Static lexical analysis and deterministic JavaScript rules
Testing: Automated unit and integration tests

The repository is organized as a monorepo, with separate client/ and server/ applications.

5. Testing and Reliability

The project includes 37 automated unit and integration tests covering lexical parsing, security rules, phantom command detection, and prompt-injection defenses.

The goal is to make the application more than a themed AI wrapper: the core safety checks should be inspectable, testable, and independently maintained.

🌍 Why Open Innovation Matters

Open innovation is especially valuable when building developer-facing security tools.

1. Model Choice and Reduced Vendor Lock-In

2. Transparent, Inspectable Security Logic

The deterministic rule engine can be reviewed, tested, and extended by contributors. Known dangerous patterns do not have to be entrusted entirely to a black-box language model.

3. Accessibility for Independent Developers

4. A Foundation for Privacy-Conscious Tooling

For me, open innovation is not just about choosing an open-weight model. It is about making the surrounding system adaptable, inspectable, and open to improvement.

👻 The Spirit of the Machine

Every developer knows that moment of hesitation before pressing Enter.

You have copied a command from somewhere on the internet. It looks correct. You think you understand it. But one flag, one path, or one pipe could change everything.

Terminal Poltergeist is built around that moment.

By combining open-weight AI with deterministic security guardrails, I wanted to make command-line safety more approachable without pretending that AI can guarantee perfect protection.

“The terminal may be mysterious. Your commands shouldn't be.”

🏆 Challenge Tracks

Primary Track: Ghost in the Machine — Hacktoberfest Open-Source AI Challenge
Additional Track: Open-Weight AI Innovation

🔗 Try the Live Application: https://client-one-rosy-53.vercel.app/

💻 Explore the Source Code: https://github.com/CyborgX-hash/terminal-poltergeist

Built with curiosity, open-source AI, and a little bit of digital haunting. 👻

My Friend Kept Forgetting Where He Left Off, So I Built ContextGhost 👻

Saksham Sontakke — Wed, 21 Oct 2026 16:42:35 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Every developer knows the dreaded feeling of returning to an interrupted task: you close your laptop at the end of the day or get pulled into a 2-hour meeting, and when you return, you waste 30 to 45 minutes just reconstructing your mental state:

"Which files was I editing without committing?"
"What was that terminal error stack trace?"
"What experiments did I already try that failed so I don't repeat them?"
"What is my exact next step to resume coding right now?"

To solve this, I built ContextGhost — an open-source, developer work-memory assistant that captures ephemeral, uncommitted developer context and synthesizes it into actionable Resumption Briefings powered by open-weight AI.

Key Capabilities:

Zero-Commit Context Capture: Captures uncommitted Git diffs, scratch notes, terminal logs, and previous failed debugging attempts.
Multi-Layer Secret Redaction: Automatically strips API keys, JWT tokens, AWS/Stripe credentials, and database connection strings into [REDACTED_SECRET] before storage or AI synthesis.
AI-Powered Resumption Briefing: Synthesizes an executive summary, checkable unfinished tasks, exact step-by-step resumption instructions, and a Resumption Readiness Score.
Searchable Work Memory: Fast retrieval across all past debugging sessions and technical notes.
Built-in User Guide & Manual: An interactive, in-app documentation guide explaining every section.

Demo

Live Application: https://context-ghost.vercel.app
In-App User Manual: https://context-ghost.vercel.app/guide

Code

The entire codebase is open-source and organized as a clean monorepo:

CyborgX-hash / ContextGhost

ContextGhost 👻

Forget where you left off. ContextGhost remembers.

ContextGhost is a developer work-memory assistant that helps software engineers resume interrupted work without reconstructing their entire mental context. It captures your active Git state, modified files, terminal errors, test results, and notes, uses a hosted open-weight AI model (via OpenRouter or Groq) or a local Ollama instance to synthesize a grounded session summary, persists relational records in PostgreSQL, and generates actionable "Resume My Work" briefings whenever you return to your codebase.

Built for Hacktoberfest 2026 Week 3 ("Slow and Steady"), ContextGhost demonstrates that open-weight AI models can eliminate mental fatigue and repetitive context-switching without requiring heavy local server installations or proprietary closed APIs.

⚡ The Problem: Context Switching Fatigue

Developers lose up to 40% of their daily productive hours recovering from interruptions:

What was I implementing right before that 2-hour meeting?
Which files did I touch, and why?
…

View on GitHub

Frontend: React, Vite, Tailwind CSS, Lucide Icons (hosted on Vercel)
Backend: Node.js, Express, Prisma ORM, PostgreSQL (hosted on Render & Prisma Accelerate)
AI Engine: Hosted open-weight inference (Groq / OpenRouter) with local offline Ollama fallback

How I Built It

ContextGhost was built around the philosophy that AI should assist developer workflow without demanding proprietary lock-in or heavy infrastructure costs:

Hosted Open-Weight Models:
- Integrated Qwen 3.8 27B hosted on Groq's high-speed LPU infrastructure, delivering ultra-fast (sub-second) structured JSON analysis on a free tier.
- Built a pluggable AI provider architecture (GroqProvider, OpenRouterProvider, and OllamaProvider) via a centralized ProviderFactory.
Offline & Edge Flexibility:
- If a developer is working offline on an airplane, ContextGhost seamlessly falls back to a local Ollama instance (qwen2.5:1.5b) without modifying any application code.
Privacy First by Design:
- Context is sanitized through a deterministic regex-based secret scrubber before it ever reaches the AI engine or PostgreSQL database.
- A live "Inspect Sanitized Payload" modal allows developers to review exactly what will be sent to the model with explicit consent toggles.
Structured JSON Validation & Fallback:
- Implemented a resilient prompt engineering pipeline that forces deterministic JSON schemas (summary, immediateObjective, unfinishedTasks, resumptionSteps).
- If an AI provider experiences rate-limiting or network timeouts, the system gracefully falls back to a structured RAW_SNAPSHOT so developer work is never lost.

Why Does Open Innovation Matter?

Open innovation is the cornerstone of developer tooling:

Developer Trust & Privacy: Proprietary, closed-source models require piping sensitive source code, internal error traces, and architectural thoughts into opaque corporate black boxes. Open-weight models guarantee that developers can inspect, host, and verify exactly where their data goes.
Longevity & Portability: Unlike closed APIs that can deprecate models or change pricing overnight, open-weight models (like Qwen, Llama, and Mistral) can run anywhere — from serverless cloud providers like Groq to an air-gapped local laptop via Ollama.
Hyper-Specialization: Open innovation allowed us to benchmark and switch open-weight models for structured code synthesis without rewriting any backend logic.

The Lazy Payoff

ContextGhost is the ultimate tool for lazy engineering:

No More Re-debugging: Instead of spending 45 minutes on Monday morning trying to remember why a webhook signature failed on Friday, ContextGhost presents an exact 3-step checklist of where you left off.
Effortless Context Dumps: You don't have to write structured documentation. You just paste your raw terminal output and a messy sentence, and the open-weight model turns it into a structured, checkable resumption plan.

Prize Categories

Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
Groq / Open-Weight AI Track

My Friend Was Tired of GitHub Issue Chaos, So I Built an AI to Fix It

Saksham Sontakke — Sun, 18 Oct 2026 12:21:29 +0000

IssuePilot: An Open-Weight AI Copilot to End GitHub Issue Triage Burnout

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Maintainer burnout is a growing problem in open-source software. Popular repositories receive dozens of issues every day: duplicate bug reports, missing reproduction steps, unstructured feature requests, and issues without proper labels. Maintainers end up spending valuable time on repetitive triage instead of building and improving software.

IssuePilot is an AI-powered GitHub Issue Triage and Management platform built around open-weight AI. It acts as an intelligent copilot for open-source maintainers, engineering teams, and SaaS companies, helping them organize incoming issues while keeping humans in control.

What can IssuePilot do?

Intelligent Issue Classification: Categorizes issues as Bugs, Feature Requests, Documentation, Security, or Questions, and recommends priorities ranging from P0 (Blocker) to P3 (Low).
Semantic Duplicate Detection: Uses vector embeddings and cosine similarity to identify potentially duplicate issues, even when they use different terminology.
Human-in-the-Loop Review Queue: Stages suggested labels, priorities, duplicate links, and clarification replies for maintainers to approve or reject before changes are applied to GitHub.
Automatic Upstream Issue Synchronization: Resolves upstream repositories for forks where issues are disabled, allowing contributors to explore and triage real-world upstream issues.
Multi-Repository Management: Connects repositories through a GitHub App and provides a centralized workspace for reviewing issue triage results.

The goal is simple: reduce repetitive work without handing control of a repository to an unpredictable bot.

Who would pay for it?

IssuePilot is designed for open-source foundations, funded projects, enterprise engineering teams, and SaaS startups maintaining public SDKs and APIs.

The planned micro-SaaS model includes:

Free: Individual maintainers managing up to three repositories.
Team — $19–$49/month: Organizations that need multi-repository triage, duplicate detection, SLA tracking, and batch actions.

The business opportunity is to help engineering teams spend less time organizing issues and more time shipping reliable software.

Demo

Live Web Application: https://issue-pilot-ten.vercel.app/
Backend API and Health Check: https://issue-pilot.onrender.com/api/health

Open the web application, sign in with GitHub, and explore connected repositories, AI-generated triage summaries, and the staged action review queue. The backend is hosted on Render, so the first request may take a little longer if the service needs to wake up.

Code

GitHub Repository: https://github.com/CyborgX-hash/Issue-pilot

CyborgX-hash / Issue-pilot

IssuePilot

Less time triaging. More time building.

IssuePilot is a production-minded, AI-powered GitHub issue management platform designed for open-source maintainers and engineering teams. It connects directly with GitHub via a dedicated GitHub App, categorizes incoming issues using open-weight AI (Gemma), detects potential duplicate issues through semantic similarity, and identifies missing bug report information.

Crucially, IssuePilot enforces human-in-the-loop oversight: AI recommendations are staged in an approval queue where maintainers can inspect, edit, approve, or reject changes before any action is committed to GitHub.

Features

GitHub App Integration: Clean authorization and granular installation flow scoping permissions only to selected repositories.
Automated Issue Synchronization: Fetches and caches issues and labels, filtering out pull requests cleanly.
Open-Weight AI Triage
- Classifies issues into BUG, FEATURE_REQUEST, ENHANCEMENT, DOCUMENTATION, QUESTION, or OTHER.
- Recommends issue priority (CRITICAL, HIGH, MEDIUM, LOW) grounded in factual…

View on GitHub

Tech Stack

Frontend: React 18, Vite, Tailwind CSS, Lucide icons
Backend: Node.js, Express.js
Database: PostgreSQL with Prisma ORM
GitHub Integration: GitHub App authentication, Octokit, authenticated webhooks
AI Inference: Groq SDK with Gemma 2
Testing: Vitest integration tests

The project is organized as a full-stack monorepo with separate client/, server/, and docs/ directories.

How I Built It

IssuePilot combines open-weight AI, semantic search, and secure GitHub integration to create a practical developer productivity tool.

1. Open-Weight AI with Gemma 2

The core triage engine uses Gemma 2 (gemma2-9b-it), served through Groq for low-latency inference. The architecture is designed to support compatible local inference deployments through tools such as Ollama or vLLM.

Instead of relying on unstructured AI responses, I used Zod schema validation to enforce structured output containing issue categories, confidence scores, priority recommendations, suggested labels, justifications, and clarification drafts.

Because GitHub issue descriptions are user-generated input, the system also uses prompt-boundary separation and defensive validation to reduce prompt-injection risks.

2. Semantic Duplicate Detection

Keyword matching alone cannot reliably identify duplicates. Two developers might describe the same bug using completely different words.

IssuePilot uses the open-weight all-MiniLM-L6-v2 embedding model to represent issue titles and descriptions as vectors. A cosine-similarity engine compares these representations against existing issues to surface likely duplicates, including reports from closed issues.

This helps maintainers find related reports without manually searching through hundreds of issue descriptions.

3. GitHub App Integration

IssuePilot connects to GitHub through a GitHub App built using Octokit. Authenticated webhooks ingest issue events, while installation-based access supports repository-level integration.

The application uses HMAC-SHA256 webhook signature verification, authenticated API access, and a staged review workflow. AI suggestions are not directly applied to repositories: maintainers must approve proposed actions before the application makes changes through the GitHub REST API.

4. A Human-First Workflow

The most important design decision was to avoid building another bot that automatically posts comments everywhere.

IssuePilot stages proposed actions in a review queue so maintainers can inspect, approve, or reject them. This makes AI useful without removing human judgment from repository management.

5. Testing and Deployment

I used agentic pair-programming workflows to help develop the Prisma schema, implement integration tests, and improve deployment behavior.

The test suite reached 34/34 passing tests during development, covering areas such as webhook signature verification, authorization guards, and duplicate-similarity checks.

The frontend is deployed on Vercel, and the backend is deployed on Render.

Why Does Open Innovation Matter?

Open innovation made IssuePilot possible by giving me access to capable models and tools without requiring a proprietary AI model to be the foundation of the product.

Freedom of deployment: Gemma 2 can be served through an inference provider or a compatible self-hosted setup. Organizations can explore deployment options that fit their infrastructure, cost, and security requirements.

Greater control over sensitive data: Repository issues may contain internal implementation details, stack traces, or vulnerability reports. A self-hosted inference configuration can help organizations keep inference within their own environment, provided the rest of the application and its integrations are configured accordingly.

Lower barriers to experimentation: Open-weight models and open-source embedding tools make it easier to experiment with domain-specific triage, evaluate different inference configurations, and adapt the system to different programming languages and repositories.

Room to improve: The architecture creates opportunities to evaluate model accuracy on real issue datasets and potentially fine-tune models for specialized engineering workflows.

Open innovation is not just about avoiding vendor lock-in. It is about giving developers more control over how AI is deployed, evaluated, and improved.

My Agent Session

I used agentic pair-programming workflows throughout development to accelerate implementation and testing. The workflow helped scaffold the database schema, develop integration tests, refine GitHub authentication and authorization safeguards, and improve the deployment experience.

The objective was to use AI as a development partner while still validating the implementation through tests and real-world repository experiments.

My First User

During development, I tested IssuePilot against real-world upstream repositories, including sktime and aiondemand, to explore the challenges contributors face when working with forks where GitHub issues are disabled.

Feedback from an open-source contributor:

"Usually, when we fork a large repo to contribute, issues are disabled on GitHub by default, so testing triage tools was impossible. IssuePilot's automatic upstream sync pulled in 88 active issues immediately, accurately flagged two duplicates related to token parsing, and proposed the exact bug and backend labels we would have manually tagged."

This experiment reinforced the central idea behind IssuePilot: maintainers need useful, reviewable suggestions rather than autonomous bots that make unapproved changes.

The project is still evolving, and this early feedback provides a useful direction for improving its triage accuracy and workflow.

Prize Categories

I'm submitting IssuePilot for the following categories:

Primary Track: Hacktoberfest Open-Source AI Challenge Week 2 — Side Hustle
Best Use of Open-Weight Models: Gemma 2
Developer Tools / Productivity Micro-SaaS
Open Innovation & Autonomous Agents

Building IssuePilot taught me that useful AI developer tools are not just about generating predictions. They need reliable integrations, structured outputs, security guardrails, and workflows that keep people in control.

If you're maintaining an open-source repository, I'd love for you to try IssuePilot and share your feedback!

Live Demo: https://issue-pilot-ten.vercel.app/

GitHub: https://github.com/CyborgX-hash/Issue-pilot

My Friend Wanted to Start Gardening, So I Built Her an AI Gardening Companion

Saksham Sontakke — Sun, 11 Oct 2026 05:56:07 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

🌱 GrowMate — Your AI Gardening Companion

What I Built

GrowMate is an AI-powered gardening companion designed to help home and balcony gardeners grow healthier plants while spending less time on screens and more time in nature.

Gardening can be challenging for beginners. People often struggle to decide which plants suit their space, understand their plants' needs, or identify potential leaf diseases. GrowMate aims to make these tasks easier through AI-powered guidance and practical outdoor activities.

The project focuses on three main features:

AI Garden Planner: Get personalized plant suggestions and gardening guidance based on your available space, sunlight, and gardening preferences.
Plant Health Scanner: Upload a leaf image to receive AI-assisted plant health classification and guidance on possible next steps.
Touch Grass Mode: Get practical gardening missions that encourage you to step away from your device, interact with your plants, and build a real-world gardening habit.

The idea behind GrowMate is simple: AI should help us experience more of the real world, not keep us trapped in front of a screen.

Instead of endlessly researching gardening online, users can get guidance, put their devices aside, and start caring for their plants.

GrowMate is built for beginners, home gardeners, balcony gardeners, and anyone who wants to develop a greener lifestyle.

Demo

Live Demo: https://growmate-beta.vercel.app/

Explore GrowMate and see how AI can support practical, real-world gardening.

Code

GitHub Repository: https://github.com/CyborgX-hash/Growmate

The project source code is available on GitHub.

How I Built It

I built GrowMate with a focus on combining a modern web application with AI-assisted gardening and practical outdoor activities.

Technology stack:

Frontend: React, Vite, and Tailwind CSS
Backend: Node.js and Express.js
Database: MySQL with Prisma ORM
AI: Open-weight language and computer-vision models for gardening assistance and plant health classification
Deployment: Vercel for the frontend, with backend and AI services configured separately as required

The planned AI components include:

Gemma 3 4B IT for generating gardening guidance, personalized plans, and outdoor missions.
PlantVillage ViT leaf-disease classifier for AI-assisted classification of uploaded plant leaf images.

The goal is to use models with accessible weights and customizable deployment options rather than building the entire experience around a proprietary, closed AI system.

Note: The model names above describe the intended AI components. Confirm which models are actually integrated and responding in the deployed version before publishing this as a description of the finished implementation.

Why Does Open Innovation Matter?

Open innovation matters because gardening assistance should be adaptable, accessible, and transparent.

Using models with accessible weights gives developers more control over how AI features are deployed and customized. It also creates opportunities to experiment with different models, choose infrastructure that fits the project's needs, and improve the application without depending entirely on one proprietary AI provider.

For GrowMate, this approach could make it easier to:

Customize gardening recommendations for different environments and growing conditions.
Replace or upgrade AI models as better options become available.
Keep API credentials and sensitive processing on the server rather than exposing secrets in the frontend.
Experiment with different inference providers and deployment approaches.
Build tools that connect AI assistance with meaningful offline activities.

Open innovation is especially relevant to the Touch Grass challenge because the AI is intended to act as a guide—not as the destination. The real outcome is a person learning about plants, stepping outdoors, and caring for something in the physical world.

My Agent Session

I used an AI-assisted development workflow to help plan and build GrowMate.

Prize Categories

Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass

Built with 🌱 for a greener, more hands-on world.

My Roommate Sends Chaotic Grocery Messages. So I Built an AI for It.

Saksham Sontakke — Mon, 05 Oct 2026 08:15:16 +0000

What I Built

MessyList — Turn chaotic grocery messages into a shopping list

My roommate has a very particular way of asking me to buy groceries.

It's rarely:

"Buy 1 packet of milk, 1 brown bread, and 5kg of atta."

Instead, it looks more like:

"bhai milk le aana"
"bread bhi"
"brown wali"
"eggs bhi khatam hai"
"actually Rahul eggs la raha"
"atta bhi le aa"
"5kg wala"

And somehow, I'm supposed to remember all of that while standing in a grocery store. 😭

So I built MessyList, a personal AI grocery assistant that turns those chaotic conversations into a clean, actionable shopping list.

The idea is simple:

Messy messages → AI understands the context → Clean grocery list

But it isn't just extracting nouns from a message.

MessyList can understand things like:

"bread bhi" → add bread

"brown wali" → understand that it refers to the bread

"get 5kg atta" → understand quantity and unit

"actually Rahul is bringing eggs" → remove eggs from the list

"same milk as last time" → use a saved preference

corrections and conversational context

After the AI interprets the conversation, I can review and edit the result before saving it as a shopping list.

The app also remembers grocery preferences and previous lists, so it can become more useful over time.

I built this specifically around a real, everyday problem rather than trying to make another generic AI chatbot.

Demo

Try MessyList:
https://grocery-ai-indol.vercel.app/

The deployed app includes a demo flow so you can try the idea without having to prepare your own grocery messages.

A typical flow looks like:

Paste the messy messages

bhai milk le aana
bread bhi
brown wali
eggs khatam hai
actually Rahul eggs la raha
atta bhi 5kg wala

MessyList understands them
Review the AI's interpretation
Save the shopping list
Check items off while shopping

The goal was to make the interface simple enough that my roommate could actually use it instead of needing a tutorial.

Code

The complete source code is available on GitHub:

👉 https://github.com/CyborgX-hash/Grocery-ai

The repository contains the frontend, backend, Prisma database layer, AI integration, and demo mode.

How I Built It

The application is built as a full-stack web application.

Tech Stack

React

Node.js

Express.js

Prisma ORM

Database persistence

Open-weight AI / Gemma

Vercel for deployment

The important part of the architecture is the AI parsing layer.

The grocery conversation is sent to the AI with relevant context such as saved grocery preferences and previous purchases.

The model converts the natural language into structured data rather than simply generating a conversational response.

For example:

{
"items": [
{
"name": "Brown Bread",
"quantity": 1,
"unit": "pack",
"status": "active"
},
{
"name": "Eggs",
"status": "cancelled",
"notes": "Rahul is bringing them"
},
{
"name": "Atta",
"quantity": 5,
"unit": "kg",
"status": "active"
}
]
}

The application then validates that response and lets the user review it before saving anything.

I also added a development/demo mode so the application can still demonstrate the complete product flow without exposing or hardcoding AI credentials.

The data layer

I used Prisma ORM to manage the persistent data layer.

The application stores things like:

Grocery lists

Grocery items

Purchase status

Grocery preferences

Previous shopping history

This allows the AI to use relevant personal context instead of treating every grocery request as completely independent.

Why Does Open Innovation Matter?

This is probably the most important part of the project for me.

A grocery list might not sound like sensitive information, but when you start giving an AI access to someone's messages, habits, preferences, purchases, and household information, privacy becomes important.

I wanted the architecture to be built around an open-weight model rather than making the application completely dependent on a closed AI provider.

Using an open model such as Gemma gives the project much more flexibility.

The model can potentially be:

self-hosted

swapped for another open model

adapted for a specific use case

run in a more private environment

changed without rebuilding the entire application around one proprietary API

That matters because the long-term idea behind MessyList isn't just:

"Send my messages to an AI and get a list."

It's:

"Give me a personal AI tool that I can actually control."

For a personal assistant dealing with someone's everyday messages and preferences, that distinction matters.

My Agent Session

I used an AI-assisted development workflow to build and iterate on the application, from the initial architecture and UI through the AI parsing flow and database integration.

Prize Categories

🏆 Best Use of Gemma

MessyList is built around an open-weight AI architecture using Gemma for understanding natural-language grocery conversations and converting them into structured grocery data.

I'm entering the Best Use of Gemma category.

What's Next?

MessyList started with one very specific problem: my roommate's chaotic grocery messages.

But there are a few directions I'd love to take it next:

Voice messages — turn voice notes into shopping lists.

WhatsApp integration — automatically process grocery conversations.

Receipt scanning — update purchase history from receipts.

Budget mode — build a grocery list around a spending limit.

Shared household lists — allow multiple roommates to contribute to the same list.

For now, though, I'm happy that a conversation that normally looks like this:

"milk le aana"
"bread bhi"
"wait don't get eggs"
"actually get eggs"

can become something a little more useful:

☐ Milk
☐ Brown Bread
☐ Atta — 5kg

And hopefully, a little less chaotic. 😄

Thanks for checking out MessyList!