Open Source

aSPARK turns Claude Code from a coding tool into a tool with a process: a product team of Product Owner, Designer, Engineering Manager, Reviewer, QA Tester, and Release Manager. Every feature runs through the SPARK loop and has to pass each gate before it moves on.

Decisions do not vanish into the chat log — they land in the project as artifacts: spec.md, plan.md, review.md, qa.md. Stable IDs for user stories, acceptance criteria, and non-functional requirements keep every phase traceable. QA is not claimed, it is run in a real browser.

1. S Specify Sharpen the idea, settle user stories and acceptance criteria
2. P Plan Decide the architecture, break the work down
3. A Act Build the increment strictly to plan
4. R Review Code review and QA in a real browser
5. K Keep Release, document, and record the learnings

/plugin marketplace add a-lottes/aSPARK
/plugin install aspark@aspark

aspark-graph reads one repository — its source code and its aSPARK delivery trail under .spark/ with specs, plans, reviews, and QA reports — and builds a single queryable graph, served over a CLI and an MCP server. It answers two questions without grepping: which code implements this user story, and which stories sit in the blast radius of a change?

The graph is deterministic — tree-sitter plus declared artifact links, no LLM and no network — so two builds of an unchanged repo produce byte-identical results. And it is deliberately disposable: a rebuildable read model, never a source of truth.

pip install aspark-graph
claude mcp add aspark-graph -- uvx aspark-graph serve

aSPARK-policy turns architecture guidelines, secure coding standards, naming conventions, and review checklists into a machine-readable policy layer. Markdown files explain the standards, a policy.yaml activates them, and every aSPARK agent consumes the same policy — no duplicated prompts, no custom agent modifications.

A policy is not a package you install, it is a repository you mount: your organization keeps its standards in its own repo, and each project pulls it in as a Git submodule at .spark/policy. Where it stands today: a documented format, a tested JSON Schema, an installable Python package, and eight catalog packs. Enforcement via CLI and the Facilitator binding is still ahead — the project is in early development.

Tokibot is a small e-paper device whose mood reflects what your coding agents are doing. It tracks several sessions at once, shows the one that needs you most, and counts what is working, waiting, or done. With Claude Code it also shows your 5-hour and 7-day budget.

It runs its own slim Buildroot image with a read-only root filesystem. Only metadata leaves your computer; prompts, code, and replies never do. An optional relay lets cloud agents reach the device over any Wi-Fi. Tokibot is still in development.

BRASS-01 is a home-built mini retro console on an ESP32-S3, with its own game engine (SteamCore) and its own games. The graphics are deliberately monochrome orange on black and run at a low virtual resolution, scaled by whole numbers onto the display. The goal is not to emulate old consoles but a platform that could have existed in a steampunk 1983. The first game is Galactic Invasion.

Every feature was built with aSPARK: 13 features, each with its spec, plan, review, QA and release under .spark/ — the complete, publicly readable delivery trail of a real project. Because the console has no browser surface, QA runs by a substitute method declared in the constitution: host unit tests, framebuffer dumps and serial transcripts.

Most Eleventy starters treat multilingual as a lookup table for button labels — that is the easy part. The hard part is what happens when a reader switches language on an arbitrary page: a tag page, page 4 of the blog, your privacy notice. eleventy-rosetta answers that everywhere, with translated routes (/de/impressum/, /en/legal/, and /fr/mentions-legales/ are the same page), translated tags, and a language switcher that disables itself rather than linking a 404.

German, English, and French out of the box, custom CSS with no framework, and no external services at runtime: full-text search via Pagefind is built at deploy time, responsive images in AVIF and WebP at build time. The package comes in two halves — the plugin stays upgradable through npm, while eleventy-rosetta init copies layouts, CSS, demo content, and config into your project once and then gets out of the way. Adding a language means adding a directory under _data/i18n/, not editing a registry. The theme grew out of the code behind this site.

npx eleventy-rosetta init
npm install && npm start