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.

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