DEV Community: Aishik Yadav

ContextForge: Resurrecting Codebase Blueprints to Slash LLM Token Waste by 90%

Aishik Yadav — Tue, 27 Oct 2026 06:41:01 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 4 — Ghost in the Machine.

👻 The "Ghost in the Machine": When Codebases Haunt the Context Window

Every modern developer working with AI has faced this dilemma:

You want an LLM (Claude 3.5, GPT-4o, Gemini, or a local open-weight model) to fix a bug, review system architecture, or implement a new feature across your codebase.

You have two choices, and both are broken:

Dump the entire codebase into the prompt: You burn through 60,000 to 150,000 tokens in one shot. The model drowns in low-level loop bodies, internal array manipulations, and boilerplate. You hit context limits, pay high token bills, and face the "lost in the middle" problem where models miss critical details hidden in massive dumps.
Manually cherry-pick a few snippets: The model loses the big picture. It hallucinates missing types, invents imaginary function signatures, and violates conventions established elsewhere in your project.

In honor of Hacktoberfest Week 4: "Ghost in the Machine", I wanted to summon the true spirit of a codebase without all the heavy, noisy flesh.

Meet ContextForge ⚡ — an open-source CLI and interactive local web dashboard that strips away implementation clutter, extracts structural AST signatures and type blueprints across multiple languages, budgets tokens against your target model, and formats token-efficient prompt packs that slash token consumption by 70% to 90%.

GitHub Repository: sleepyaishik69/contextforge
License: MIT

⚡ What ContextForge Does

ContextForge bridges the gap between raw codebases and LLM context windows through three core engines:

1. Multi-Language AST Signature Extractor

Instead of feeding an AI 500 lines of implementation logic for a service file, ContextForge parses the code and extracts its structural skeleton:

TypeScript / JavaScript: Exported interfaces, type aliases, classes, method signatures, parameter types, return types, enums, and JSDoc comments.
Python: Classes, methods, functions, type hints, and docstrings.
Go: Structs, interfaces, function signatures, and method receivers.
Rust: Structs, enums, traits, impl blocks, and pub fn signatures.
Java / C#: Classes, interfaces, and public/protected method signatures.

This gives the AI a complete, 100% accurate mental model of your system's contracts and interfaces without reading thousands of lines of internal loops.

2. Intelligent Dynamic Token Budgeting

Different models have different context windows and cost profiles. ContextForge includes built-in presets:

Claude 3.5 Sonnet (200k context / 64k recommended budget)
GPT-4o (128k context / 32k recommended budget)
Gemini 1.5 Pro / Flash (1M context / 128k recommended budget)
Llama 3 / Gemma 2 Local (8k context / 4k budget)
DeepSeek Coder (64k context / 24k budget)

If your codebase exceeds your chosen budget, ContextForge dynamically downsamples non-critical files to AST blueprints while keeping your core entrypoints in full code.

3. Task-Driven Prompt Templates

Context packs aren't just raw code—they are structured prompts with specialized system directives:

🐛 Bug Investigation & Root Cause: Directs the model to check race conditions, null safety, and boundary states.
✨ Feature Implementation Blueprint: Instructs the model to outline touched files and follow existing patterns.
🏗️ Architecture & Data Flow Review: Maps domain entities, lifecycles, and scaling bottlenecks.
🔒 Security & Vulnerability Audit: Audits auth boundaries, input validation, and secret exposure.
🧪 Test Suite Generation: Drafts unit and integration tests covering happy paths and edge cases.

📊 The Math: 91.6% Token Reduction in Practice

Here is a real test running ContextForge against itself:

Metric	Raw Full Codebase	ContextForge Signatures Mode	Savings
Files Scanned	18 files	18 files	Complete Coverage
AST Signatures Extracted	—	73 signatures	Full Architecture
Estimated Tokens	64,700 tokens	5,400 tokens	91.6% reduction
Fit in Local 8k Context?	❌ No (Blows limit 8x)	✅ Yes (Only 67% of 8k)	Instant local inference

By stripping inner loops and keeping types, interfaces, and function signatures, an entire multi-module codebase comfortably fits inside a local Gemma 2 (8k) or Llama 3 context window!

🏗️ Architecture & How It Works

Here is the pipeline that runs when you invoke ContextForge:

[ Codebase Directory ]
          │
          ▼
┌────────────────────────┐
│  scanner/scanner.ts    │ ◄── Respects .gitignore, ignores binary & lockfiles, builds tree
└─────────┬──────────────┘
          │
          ▼
┌────────────────────────┐
│  parser/signature.ts   │ ◄── AST/Regex signature extraction (TS, Python, Go, Rust, Java)
└─────────┬──────────────┘
          │
          ▼
┌────────────────────────┐
│  packer/packer.ts      │ ◄── Allocates token budget, downsamples to signatures, applies template
└─────────┬──────────────┘
          │
     ┌────┴───────────────────────────┐
     ▼                                ▼
┌────────────────────────┐   ┌────────────────────────┐
│  cli.ts                │   │  server/server.ts      │
│  - Terminal summary    │   │  - Glassmorphic UI     │
│  - OS Clipboard (-c)   │   │  - Live token gauges   │
│  - Export Markdown (-o)│   │  - Signature drawer    │
│  - Stream via Ollama   │   │  - Local AI playground │
└────────────────────────┘   └────────────────────────┘

🎨 Two Ways to Use It

1. High-Speed Terminal CLI

# Scan current repository and view metrics
contextforge .

# Generate a bug-hunt pack with a 32k token budget and copy directly to clipboard
contextforge . -t bug -b 32000 -c

# Export architectural blueprints to Markdown
contextforge . -t architecture -m signatures -o architecture-pack.md

2. Glassmorphic Web Dashboard (`--ui`)

Run contextforge --ui to launch an interactive local workspace in your browser (http://localhost:4567):

Visual File Tree: Toggle individual files between Full, Blueprint / Signatures, or Exclude.
AST Signature Inspector: Click the ⚡ badge on any file to open a drawer and inspect parsed methods and types.
Dynamic Context Gauges: Live progress bar showing budget utilization against Claude, GPT-4o, and Gemma.
Local Ollama Studio: Send prompt packs directly to locally running open-weight models with real-time streaming output and tokens/sec metrics.

🔒 Why Open-Source AI Matters Here

When building developer tools that inspect codebases, privacy is non-negotiable:

Zero Intellectual Property Leakage: Feeding company codebases or private repos into third-party cloud APIs poses proprietary risks. With ContextForge and local Ollama inference, not a single line of code ever leaves your laptop.
Cost-Free Scalability: You can generate dozens of context packs and run local queries all day without worrying about API rate limits or surprise bills.
Offline Reliability: Whether you are on an airplane, train, or disconnected from the internet, your local synthesizer and model keep working seamlessly.

🚀 Quickstart: Try It Yourself

1. Prerequisites

Node.js: v18.0.0 or higher (v20+ recommended)
(Optional) Ollama for local AI generation:

  ollama pull gemma2:2b
  ollama serve

2. Clone & Install

git clone https://github.com/sleepyaishik69/contextforge.git
cd contextforge
npm install
npm run build

3. Run It

# Launch the Web Dashboard
npm run ui

# Or generate a prompt pack from terminal:
node dist/cli.js . -t bug -c

🏆 Prize Category

This project is entered into:

Best Use of Gemma ($200 featured category): ContextForge is specifically designed to make complex codebases fit within compact open-weight models like Google's gemma2:2b. By condensing bloated code into high-density AST blueprints, Gemma can understand and reason about entire repositories that would otherwise exceed its context window!

📚 Related Community Reading

Ollama: How to Easily Run LLMs Locally on Your Computer by Richa — a great guide to getting started with local models.
Building Reliable LLM Applications in Python by Puneet — exploring context curation and structured model outputs.

dumper: A Local AI File Organizer That Rewards Your Laziness

Aishik Yadav — Wed, 21 Oct 2026 17:15:22 +0000

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

The Lazy Inspiration: The "Downloads" Graveyard

We all have that one folder. The Downloads folder, the desktop cluttered with Screenshot 2026-10-21.png, assignment_final_v2_really_final.pdf, receipt_182749.pdf, or notes_october.txt.

Every few weeks, we promise ourselves: "Today I'm going to sort this out."
Then we look at 300 unnamed files, realize sorting them by hand will take an hour, and close the folder.

In honor of International Sloth Day and this week’s "Slow and Steady" Hacktoberfest theme, I decided to channel my inner sloth: build something that does the tedious work so I don't have to.

Meet dumper — a background daemon and CLI that watches a drop folder, reads your files locally with an open-source LLM, deduces what each file actually is, renames it into human-readable kebab-case, and files it into tidy category folders.

Zero manual tagging. Zero manual renaming. Just drop and forget.

GitHub Repository: sleepyaishik69/dumper
License: MIT

What I Built

dumper is an autonomous, local-first file organizer built with TypeScript, Node.js, and Ollama.

Instead of writing brittle regex rules or mapping extensions to hardcoded folders (which groups an invoice and an ebook into the same folder just because both are .pdf), dumper actually inspects what is inside the file:

Text & Code (.txt, .md, .ts, .py, .json, etc.): Streams the first 2,500 characters.
PDF Documents (.pdf): Extracts textual content from pages via pdf-parse.
Images & Media (.png, .jpg, .mp4): Extracts metadata, dimensions, and filename semantics.

Then, it queries a locally hosted open-source model (such as gemma2:2b or llama3.2) running on your own machine. The model classifies the content into custom categories (like finance/invoices, college/assignments, development/scripts, notes) and invents a clean, descriptive slug.

Example in Action:

Original Dropped File	Local AI Understanding	Renamed & Moved Destination
`Scan_0042.pdf`	"Utility electricity bill for Sept 2026"	`Organized/Finance/bills/september-2026-electric-bill.pdf`
`Screenshot 2026-10-21.png`	"Figma mockup of login screen"	`Organized/Design/mockups/dark-mode-login-mockup.png`
`hw3_final.py`	"Graph BFS traversal algorithm assignment"	`Organized/College/algorithms/graph-bfs-traversal-hw3.py`
`receipt_78291.pdf`	"Cloud server invoice from AWS"	`Organized/Finance/invoices/aws-cloud-invoice-oct26.pdf`

Architecture & How It Works

Here is the pipeline that runs every time a file is dropped into your dump folder:

[ File Dropped into ~/Dump ]
             │
             ▼
    ┌─────────────────┐
    │   watcher.ts    │  ◄── Chokidar detects write & waits for completion (1.5s debounce)
    └────────┬────────┘
             │
             ▼
    ┌─────────────────┐
    │  extractor.ts   │  ◄── Reads head content, parses PDF text, or inspects media
    └────────┬────────┘
             │
             ▼
    ┌─────────────────┐
    │   analyzer.ts   │  ◄── Injects user categories into prompt -> calls Ollama JSON API
    └────────┬────────┘
             │
             ▼
    ┌─────────────────┐
    │  organizer.ts   │  ◄── Resolves cross-disk moves, slugifies names & handles duplicates
    └────────┬────────┘
             │
             ▼
    ┌─────────────────┐
    │ ui.ts / logger  │  ◄── Renders visual terminal card & records history to ~/.dumper/history.json
    └─────────────────┘

The AI Prompting Mechanism

In src/analyzer.ts, dumper sends a structured request to Ollama with format: "json". It passes the user's configured category definitions directly in the prompt:

{
  "category": "finance",
  "subcategory": "invoices",
  "newFilename": "aws-cloud-hosting-invoice",
  "confidence": "high",
  "reasoning": "Document contains itemized cloud infrastructure charges from Amazon Web Services."
}

If the model is uncertain or the file type is unsupported, dumper gracefully isolates it in an uncategorized/ bucket without interrupting the file watch loop.

Why Open-Source AI Matters Here

File organization is inherently personal and sensitive. Your dump folder contains:

Bank statements and tax forms
Medical records and prescriptions
Proprietary source code and API keys
Personal photos and journal notes

Sending every dropped file to a closed cloud API like OpenAI or Claude creates three huge problems:

Privacy & Security: Cloud providers log API calls and prompts. Feeding them personal invoices or private code is an unnecessary security risk.
Cost: Running a cloud LLM on every single file you download or screenshot quickly turns into a recurring bill.
Reliability & Offline Capability: If you're on a plane or have no internet connection, your file organizer shouldn't stop working.

With open models through Ollama (like Google's Gemma 2 or Meta's Llama 3.2), 100% of the inference happens locally in RAM and GPU. Not a single byte of your files ever leaves your computer.

The Lazy Payoff

How much effort does dumper actually save?

Manual sorting: Finding a downloaded file, opening it to remember what it was, creating a subfolder, renaming it, and moving it takes ~20 to 45 seconds per file.
With dumper: 0 seconds. You download or save files to your ~/Dump directory as usual, and dumper silently organizes them in the background while you grab a coffee or relax.

Over a semester or a few months of development work, that translates to hours of tedious folder maintenance eliminated entirely.

Quickstart: Try It Yourself

1. Prerequisites

Ensure Ollama is installed and running with your choice of model:

# Recommended lightweight model (ideal for Best Use of Gemma):
ollama pull gemma2:2b

# Or Llama 3.2:
ollama pull llama3.2

2. Install & Run

git clone https://github.com/sleepyaishik69/dumper.git
cd dumper
npm install
npm run build

# Run interactive setup wizard
node dist/index.js init

# Start in dry-run mode to see what it would do without moving files:
node dist/index.js start --dry-run

# Or run the live daemon:
node dist/index.js start

3. Check Stats & History

# View recent file moves
node dist/index.js history

# View classification analytics
node dist/index.js stats

Prize Category

This project is entered into:

Best Use of Gemma ($200 featured category): dumper is built from the ground up to pair with gemma2:2b, giving ultra-fast (~300ms) local JSON classification on modest laptop hardware without heating up your machine.

StockSense AI: Building a Retail Analytics Assistant That Shows Its Work

Aishik Yadav — Fri, 16 Oct 2026 12:03:19 +0000

At closing time, a shopkeeper looks at a spreadsheet with hundreds of rows. Sales are recorded. Stock is somewhere between “probably fine” and “we should have ordered this yesterday.” A dashboard can show a total, but it may not explain why a product ranked first, whether a profit number is trustworthy, or what information is missing.

That scenario led me to a question: Could a small retailer get useful answers from sales and stock data without handing the arithmetic to a chatbot?

I built StockSense AI as an open-source retail analytics MVP to explore that question. It combines a conventional analytics backend with an optional local language model. The calculations produce the evidence; the model helps explain it. If the model is unavailable, the core dashboard still works.

Repository: sleepyaishik69/Stock-Sense
Setup and product notes: README
Database schema snapshot: backend/schema.sql
Alembic migrations: backend/migrations
Backend analytics: analytics.py
AI context builder: ai_context.py
API and AI routes: main.py
Dashboard: frontend/app/page.tsx
Synthetic import file for trying the workflow: test_sales_data.csv
Container setup: docker-compose.yml

The question that pushed the AI work forward

These are earlier versions of the Ask StockSense screen. In the first, I asked which product sold the most; the answer said it could not tell, even though the evidence panel showed sales totals. In the second, I asked how to sell more and got broad marketing advice without product-level evidence. Seeing those responses made the gap clear: showing metrics beside an answer is not the same as using those metrics to answer the question.

Earlier iteration: the answer did not identify a best-selling product, despite sales evidence being visible.

Earlier iteration: generic advice did not connect the recommendation to products or measured results.

The design rule: calculate first, explain second

A natural-language answer can sound polished and still be wrong. StockSense keeps business arithmetic in deterministic Python code. The backend calculates totals, comparisons, product rankings, and inventory signals from the selected workspace, store, and date range. Certain questions, including “Which product sold the most units?” and “What were net sales?”, are answered directly from those facts.

For broader questions, StockSense builds a structured, bounded analysis context from the selected period and an equal-length previous period. It includes sales and profit trends, product and category rankings, changes in units, inventory signals, basket patterns, and known data gaps. If Ollama and the configured Gemma model are available, the model uses that context to write an explanation. The model does not get a SQL tool and cannot change inventory or place an order.

The interface labels whether an answer came from core analytics, Gemma, or the core analytics fallback. It also shows the date range and supporting metric, product, and inventory evidence. When the selected period has no relevant data, the app says so instead of inventing a bestseller.

That separation matters: a model can help interpret a result, but it should not quietly become the source of the result.

What is in the app today?

1. A workspace starts empty

A new registration creates a workspace and its first store, but no seeded products or sales. Products, stores, sales, and imports carry workspace scope, and the API applies the authenticated workspace to its queries. Users can register or sign in with an email and password; the API uses a signed HttpOnly session cookie.

This keeps a demo dataset from masquerading as a user’s real business data. The included CSV is an explicit, synthetic test fixture that a developer can import when they want to explore the product.

2. Import existing sales instead of retyping them

The import workflow accepts CSV and Excel files. The preview detects common column aliases, displays a sample, and suggests how source columns map to StockSense fields. Users confirm the import before records are written.

Date, quantity, and unit price are required. Transaction ID, SKU, product name, category, discount, tax, unit cost, and a return indicator are optional. The backend validates dates and numbers, rejects non-positive quantities and duplicate rows, and can import valid rows while recording rejected rows and reasons in an import history. When a SKU is new, the import can create its product record.

That makes data quality visible. A partially successful import is not silently treated as a perfect one: users can inspect rejected rows and should resolve them before trusting the totals.

3. Metrics have explicit definitions

The analytics code uses Python Decimal values and rounds money to cents with half-up rounding. The headline definitions are:

Net sales = gross sales − discounts − refunds. Tax is stored, but excluded from net sales.
Gross profit = net sales − cost of goods sold. It is returned only when every relevant sale line has a unit cost.
Gross margin = gross profit ÷ net sales. It is unavailable when costs are incomplete or net sales are zero.
Transactions count distinct transaction IDs, scoped to a store.
Average transaction value = net sales ÷ transaction count.
Inventory value uses the current product cost and current on-hand count; it is a present-day estimate, not a historical valuation.

These rules help prevent a dashboard from presenting “0” where the honest answer is “unknown.” Missing cost data is particularly important: a product’s current catalog cost cannot retroactively prove what a sale line cost at the time it was sold.

4. Sales and product analysis

The overview includes a selected-period snapshot and an equal-length prior-period comparison. It tracks sales and profit trends at a weekly or monthly grain, ranks products by units, sales, and gross profit, compares product units with the previous period, and groups sales by category.

The dashboard is split into practical views, including Overview, Sales Analytics, Products, Inventory, Finance, Marketing, Ask StockSense, Reports, Imports, and Settings. That lets an owner move from a metric to the records and operational detail behind it.

Reports can be exported as CSV. The goal is not to bury a small business in charts; it is to let someone answer routine questions, see assumptions, and get back to operating the store.

5. Inventory as a sequence of movements

StockSense has an append-only stock movement ledger for opening counts, physical counts, deliveries, damage, and corrections. Each entry records the product, store, workspace, movement type, quantity change, resulting quantity, optional note, actor, and time. Product stock edits also create a movement record. Sales imports do not silently overwrite today’s stock.

This is a deliberate shift from treating stock as one mutable integer. The movement history gives the operator a trail to review when counts change. The ledger only records changes from the point a user starts entering them; it cannot reconstruct stock history that was never captured.

The overview’s Daily Action Center flags unknown stock, low-stock or stockout risk, suggested reorders, and missing product costs. Reorder estimates use selected-period average daily units, lead time, and the configured reorder threshold. They are review prompts: they do not model seasonality, confirmed incoming orders, supplier pack sizes, or demand uncertainty, and they never create a purchase order.

6. Budget and basket signals

The purchase budget planner allocates a stated budget across supported reorder suggestions using current recorded cost and stock. It only includes products with enough information to estimate the cost; it does not contact a supplier or place an order.

The marketing view can surface products that appear together in transaction baskets. It uses support, confidence, and lift, and only works when usable transaction IDs are present. These are descriptive co-purchase patterns. They do not prove that one product causes another to sell or measure a promotion effect. Promotion lift, price elasticity, and customer segmentation are not established by this data model.

7. Optional local Gemma through Ollama

The AI path is optional. StockSense can call a locally running Ollama service configured for gemma2:2b. The dashboard exposes model status; model-backed insight generation has a timeout and bounded concurrency. If Ollama is offline, deterministic analytics, reports, imports, and the rest of the dashboard remain available. Natural-language chat falls back to a labeled summary of calculated facts.

That is useful for local experimentation and keeps the model dependency separate from the data pipeline. It does not mean the complete application has been production-hardened: running a model locally still requires suitable hardware and an operator-managed service.

Stack and architecture

Frontend: Next.js 16, React 19, TypeScript, Tailwind CSS, and Recharts.
API: Python, FastAPI, SQLAlchemy, and Pydantic.
Persistence: SQLite for local development; PostgreSQL in the Docker Compose path.
Schema changes: Alembic migrations. The initial schema and stock-movement migration live in the repository.
Inference: Optional Ollama HTTP calls to Gemma; no model is required for core metrics.

The high-level request path is:

CSV / Excel import
        ↓
Preview → map columns → validate → confirm
        ↓
Workspace-scoped relational records
        ↓
Python Decimal analytics + inventory signals
        ├── Dashboard and CSV reports
        └── Bounded facts context → optional Ollama/Gemma explanation

For SQLite, the API creates an empty schema at startup. PostgreSQL deployments apply the Alembic migration chain. The checked-in schema.sql is a generated SQLite snapshot; migrations are the source of truth for schema evolution.

Run it locally

Clone the repository:

git clone https://github.com/sleepyaishik69/Stock-Sense.git
cd Stock-Sense

Start the API in one terminal:

cd backend
python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt
alembic upgrade head
uvicorn app.main:app --reload --port 8000

Then start the Next.js app in another terminal:

cd frontend
npm install
npm run dev

Open http://localhost:3000, create a workspace, and import your own sales file or the synthetic test CSV. API documentation is available locally at http://localhost:8000/docs.

To try the optional local model, install Ollama and run:

ollama pull gemma2:2b
ollama serve

The API reads OLLAMA_BASE_URL, OLLAMA_MODEL, and OLLAMA_TIMEOUT_SECONDS from configuration. For a PostgreSQL-backed local stack, copy .env.example to .env, replace the development secret, then use docker compose up --build. The optional Ollama service is available through the ai Compose profile.

Limits I want to keep visible

StockSense is an MVP foundation, not a finished SaaS product. The repository’s README lists the current limitations and roadmap. Among the important gaps: PostgreSQL row-level security, workspace roles, password reset, CSRF defenses, rate limiting, supplier records, confirmed purchase orders and partial receiving, historical cost snapshots, seasonality-aware demand, promotion analysis, and browser end-to-end tests are not implemented yet.

The session cookie currently supports local HTTP development; a real deployment needs HTTPS and production cookie settings, secret management, careful database credentials, backups, monitoring, and security review. The Compose credentials are for development. Financial output is operational analysis, not accounting, tax, or professional financial advice.

I think making these limits part of the product story is a strength. A retailer should be able to tell which numbers are observed, which are estimated, and which questions the current data cannot answer.

What I learned building it

The most useful engineering decision was to make the data path explicit before adding natural language. It forced me to define net sales, returns, missing costs, transaction identity, stock history, and the boundary between a measured fact and a plausible explanation.

It also changed how I think about “AI analytics.” The impressive part is not just asking a model to summarize a table. It is preparing the right evidence, preserving metric semantics, showing provenance, and letting the system say “there isn’t enough data.” For inventory, it means recording movements instead of pretending a current count explains the past. For costs, it means making missingness visible instead of filling a gap with a guess.

ChromaWild: A Local Gemma-Powered Color Walk

Aishik Yadav — Sun, 11 Oct 2026 10:45:30 +0000

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

What I built

**
ChromaWild is a color walk and field journal. It gives you a color to look for outdoors, then lets you compare what you found, save field notes, and sketch the observation.

I wanted the prompts to work for the places people actually walk through. That can be a park, a sidewalk, a bus stop, a playground, a building, a piece of public art, a patch of sky, or a plant. It doesn't have to be a wilderness trail.

The color and subject are generated together by Gemma through Ollama. The app asks the model for a fresh, coherent prompt instead of picking a color from a fixed bucket and attaching a preset nature subject.

Demo

There isn't a hosted demo yet. The app runs locally; the repository README has the setup steps: github.com/sleepyaishik69/ChromaWild.

To generate quests locally, install Ollama, run ollama pull gemma2:2b, then start the app with npm run dev.

How it works

The browser handles color matching and keeps field entries, photos, sketches, and progress in its local storage. For a new quest, the Next.js API route asks Ollama for a title, color, subject, and outdoor hint, then checks the returned fields and hex value before using them.

The model prompt includes a broad subject list:

const categories = [
  'plants', 'animals', 'water', 'sky', 'architecture', 'street',
  'transit', 'public art', 'playgrounds', 'outdoor objects',
  'sports', 'food', 'other',
];

The default model is configurable:

model: process.env.OLLAMA_MODEL || 'gemma2:2b',
format: 'json',

Here is the request path:

flowchart LR
  Browser[ChromaWild in browser] -->|request a quest| Next[Next.js API route]
  Next -->|prompt| Ollama[Local Ollama and Gemma]
  Ollama -->|structured color quest| Next
  Next -->|validated quest| Browser
  Browser -->|color comparison and journal| Browser

The implementation is in the Gemma API route. The repo also has setup instructions, contribution and security notes, and a GitHub Actions workflow for linting, type checking, and building.

Why open models matter here

With Ollama, the default color-quest generation runs on the machine hosting the app. I can try a different Ollama model by changing configuration, without tying the core feature to a paid inference API. That makes local experimentation possible and keeps the default quest prompt on the local machine.

There are tradeoffs: users need to install Ollama and download a model, and generation speed depends on their hardware. The hosted-app setup is different: Ollama must be reachable from the server, and this project still needs API protections before a public deployment. Optional Groq evaluation and ElevenLabs speech use external services if configured.

The app's public GitHub repository is up, though I still need to choose a project license. I also want to take ChromaWild on an actual color walk and see which prompts are easy to find in an everyday neighborhood.

Prize category

ChromaWild appears to fit the Best Use of Gemma category because Gemma generates quests in the default setup. If the challenge has a separate category-entry step, I'll select it there.

DEV Community: Aishik Yadav

ContextForge: Resurrecting Codebase Blueprints to Slash LLM Token Waste by 90%

👻 The "Ghost in the Machine": When Codebases Haunt the Context Window

⚡ What ContextForge Does

1. Multi-Language AST Signature Extractor

2. Intelligent Dynamic Token Budgeting

3. Task-Driven Prompt Templates

📊 The Math: 91.6% Token Reduction in Practice

🏗️ Architecture & How It Works

🎨 Two Ways to Use It

1. High-Speed Terminal CLI

2. Glassmorphic Web Dashboard (--ui)

🔒 Why Open-Source AI Matters Here

🚀 Quickstart: Try It Yourself

1. Prerequisites

2. Clone & Install

3. Run It

🏆 Prize Category

📚 Related Community Reading

dumper: A Local AI File Organizer That Rewards Your Laziness

The Lazy Inspiration: The "Downloads" Graveyard

What I Built

Example in Action:

Architecture & How It Works

The AI Prompting Mechanism

Why Open-Source AI Matters Here

The Lazy Payoff

Quickstart: Try It Yourself

1. Prerequisites

2. Install & Run

3. Check Stats & History

Prize Category

Related Community Reading

StockSense AI: Building a Retail Analytics Assistant That Shows Its Work

The question that pushed the AI work forward

The design rule: calculate first, explain second

What is in the app today?

1. A workspace starts empty

2. Import existing sales instead of retyping them

3. Metrics have explicit definitions

4. Sales and product analysis

5. Inventory as a sequence of movements

6. Budget and basket signals

7. Optional local Gemma through Ollama

Stack and architecture

Run it locally

Limits I want to keep visible

What I learned building it

ChromaWild: A Local Gemma-Powered Color Walk

What I built

Demo

How it works

Why open models matter here

Prize category

Related reading

2. Glassmorphic Web Dashboard (`--ui`)