# Marmicode Skills
A collection of AI agent skills to fix trust issues.
| Skill | Description |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| [Charted Coding](#charted-coding) | A workflow that turns feature ideas into production code through incremental steps — design, review, scaffold, red, green. |
| [`angular-testing`](#angular-testing) | Writes, fixes and reviews Angular tests following the Pragmatic Angular Testing approach. |
## Installation
```sh
npx skills add marmicode/skills
```
To install a single skill:
```sh
npx skills add marmicode/skills --skill angular-testing
```
## Angular Testing
> Skill: `angular-testing`
Writes, fixes and reviews Angular tests following the **Pragmatic Angular Testing** approach:
- **Fakes over mocks**: real collaborators by default, and fakes of the adapters you own (e.g. HTTP repositories) instead of `vi.mock()` or spies stubbing return values.
- **The widest narrow test**: tests as wide as possible while staying fast, isolated, and easy to reason about.
- **Through the DOM**: components are tested the way users interact with them, rather than through `fixture.componentInstance`.
- **Signals, guards, routing and timers**: dedicated guidance for each.
It targets **Vitest** (Browser Mode preferred, jsdom and happy-dom supported) and also applies to Jest, Jasmine/Karma and Angular Testing Library projects — including migrating them to Vitest. It is not meant for Playwright or Cypress end-to-end tests.
It plays well with the Charted Coding workflow: `charted-red` and `charted-green` drive the red/green cycle while `angular-testing` shapes the content of the tests.
## Charted Coding
**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.
<div align="center">
<a href="https://www.youtube.com/watch?v=8z9tUsSoros">
<img src="assets/charted-coding-thumbnail.jpg" alt="TDD with an AI Agent — Whisking Raw Ideas into Tidy Code" width="600">
</a>
</div>
<table>
<thead>
<tr><th width="200">Skill</th><th>Description</th></tr>
</thead>
<tbody>
<tr><td><a href="#1-design"><code>charted-design</code></a></td><td>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.</td></tr>
<tr><td><a href="#2-review"><code>charted-review</code></a></td><td>Reviews a design doc with expert sub-agents</td></tr>
<tr><td><a href="#3-scaffold"><code>charted-scaffold</code></a></td><td>Writes work-in-progress code and tests based on design doc</td></tr>
<tr><td><a href="#4-red"><code>charted-red</code></a></td><td>Writes the next failing test based on provided design doc and existing todo tests</td></tr>
<tr><td><a href="#5-green"><code>charted-green</code></a></td><td>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.</td></tr>
<tr><td><a href="#continue"><code>charted-continue</code></a></td><td>Sometimes, you will forget where you left off. This skill figure it out.</td></tr>
</tbody>
</table>
### The Charted Coding Steps
The five steps form a linear pipeline. Each step produces an artifact that feeds into the next.
```
design --> review --> scaffold --> red --> green
```
#### 1. Design
> 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`)
#### 2. Review
> 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
#### 3. Scaffold
> 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 progress` so 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
#### 4. Red
> 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
#### 5. Green
> 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
### Resuming a PR
> Skill: `charted-continue`
When you pick up work after a break — or just want an Agent to figure out the next step — **charted-continue** reads the design doc and inspects PR state, then invokes exactly one downstream skill:
| Condition | Skill invoked |
| -------------------------------- | ------------------ |
| Scaffolding not done | `charted-scaffold` |
| Next 🚧 test not implemented | `charted-red` |
| Next 🚧 test already implemented | `charted-green` |
It locates the PR section in the design doc, checks whether WIP files and `it.todo(...)` stubs exist, finds the first pending test (still marked 🚧), and classifies whether that test has real code or only design-doc comments. One skill per run — no skipping ahead.
**Why this matters:** You don't have to remember where you left off. The skill resumes at scaffold, red, or green automatically.
**Produces:** delegates to the appropriate downstream skill (one step per invocation)
## License
MIT
