Charted Coding is a workflow that turns feature ideas into production code through incremental steps — each backed by a dedicated AI skill. Small steps mean, focused and fast prompts, less review fatigue, less context-switching fatigue, and less token usage.
| Skill | Description |
|---|---|
charted-design | Interviews the user section by section to collaboratively produce design documents. Use when creating a design doc, starting feature design, or when the user invokes the design command. |
charted-review | Reviews a design doc with expert sub-agents |
charted-scaffold | Writes work-in-progress code and tests based on design doc |
charted-red | Writes the next failing test based on provided design doc and existing todo tests |
charted-green | Progressively activates todo tests one at a time, updates implementation code until each passes (verified via Wallaby), then moves to the next—following the design doc as the single source of truth. |
npx skills add marmicode/skillsThe five steps form a linear pipeline. Each step produces an artifact that feeds into the next.
design --> review --> scaffold --> red --> green
Skill:
charted-design
Everything starts with a design document. The AI interviews you section by section — goals, non-goals, desired behavior, architecture (with Mermaid diagrams), testing strategy, and a PR plan — then writes the result to design-docs/. You stay in the driver's seat: every section is drafted, shown to you, and only committed to the document once you approve it.
Why this matters: A design doc forces you to think through the problem before writing code. It captures decisions, constraints, and scope so nothing is lost or assumed. The interview process reduces oversight risk.
Produces: a design document (e.g. design-docs/001-user-auth.md)
Skill:
charted-review
The design doc is sent to expert sub-agents in parallel:
| Expert | Focus |
|---|---|
| Accessibility Expert | WCAG compliance, ARIA, keyboard navigation, screen readers |
| Security Analyst | Input validation, injection, auth gaps, data exposure |
| UX Expert | Interaction patterns, error states, cognitive load |
| XP Coach | Testability, incremental delivery, simplicity, YAGNI |
Their feedback is synthesized into a single review. When experts disagree, a challenge round forces them to defend or revise their positions. Unresolved conflicts are escalated to you for the final call.
Why this matters: You get a multi-perspective review before a single line of code is written, catching accessibility oversights, security gaps, UX pitfalls, and over-engineering early.
Produces: a consolidated review with action items
Skill:
charted-scaffold
The AI reads the (now reviewed) design doc and generates the skeleton of the implementation:
- Classes, components, services, and functions are created but throw
"🚧 work in progress"errors instead of doing real work. - New code is tagged with
@deprecated 🚧 work in progressso it stands out. - No behavior is added or changed — this is pure structure.
- Test files are created with
it.todo(...)stubs whose bodies contain the step-by-step instructions from the design doc's testing strategy, written as comments.
Why this matters: Scaffolding separates where things go from how they work. It lets you review the file structure, naming, and API surface in a focused PR before any logic exists.
Produces: WIP source files + it.todo(...) test files
Skill:
charted-red
Now the TDD cycle begins. The AI picks the next it.todo(...) test, reads the comment instructions inside it, and replaces them with real test code — assertions, setup, teardown — while keeping the test disabled (it.todo).
- Only one test is written at a time.
- The test is implemented but not enabled yet.
- No production code is written or changed.
Why this matters: This is the Red phase of Red-Green-Refactor. You write a test that would fail if it were enabled, precisely defining the next slice of behavior before implementing it.
Produces: a fully implemented (but still .todo) test
Skill:
charted-green
The AI activates the test (converts it.todo(...) to it(...)) and writes just enough production code to make it pass, verified in real time via the Wallaby test runner. Once green, it moves to the next implemented test and repeats.
- One test at a time — no skipping ahead.
- Only code required by the current test is written.
- Empty or comment-only tests are ignored.
Why this matters: This is the Green phase. By implementing the minimum code to satisfy each test, you get a provably correct, incrementally built feature with no dead code.
Produces: passing tests + minimal production code
MIT