Jev Kuznetsov
63 lines
2.6 KiB
Markdown
63 lines
2.6 KiB
Markdown
---
|
||
name: wbs
|
||
description: Break down architecture.md into a prioritized feature backlog, skipping already-built features.
|
||
---
|
||
|
||
# Plan
|
||
|
||
Produce or update `docs/feature_backlog.md`.
|
||
|
||
## Process
|
||
|
||
1. Read `docs/architecture.md`. This is the source of truth for what needs to be built.
|
||
2. Scan `docs/features/` for existing feature spec files (pattern: `[0-9][0-9][0-9]-*.md`). These are already built — do not include them in the backlog.
|
||
3. Find the highest `NNN` number across both `docs/features/` files and any existing `docs/feature_backlog.md` entries. New items start from one higher.
|
||
4. Produce `docs/feature_backlog.md` with this structure:
|
||
|
||
```markdown
|
||
# Feature Backlog
|
||
|
||
Completed features are tracked in `docs/features/` and removed from this list.
|
||
|
||
---
|
||
|
||
## NNN — slug-style-title
|
||
|
||
One sentence describing what gets built.
|
||
|
||
## NNN — next-item
|
||
|
||
One sentence. Optionally:
|
||
depends: NNN
|
||
```
|
||
|
||
## What goes on the backlog
|
||
|
||
Cover everything in the architecture that is not yet implemented. Group logically — infrastructure first, then features, then integrations.
|
||
|
||
Do not add items for:
|
||
- Work already represented by a file in `docs/features/`
|
||
- Documentation, comments, or cleanup unless explicitly in the architecture
|
||
- Vague future ideas not grounded in the architecture
|
||
|
||
## Chunk sizing
|
||
|
||
Each backlog item will be handed to a coding agent that writes a spec, implements the code, and commits — all in one automated pass with no human in the loop. Size items accordingly:
|
||
|
||
- **Self-contained**: scope should contain a single functionality that can be implemented and tested.
|
||
- **Scoped**: touches at most 2 modules and adds roughly 50–200 lines of production code
|
||
- **Testable**: success is checkable by running the test suite — no manual inspection required
|
||
|
||
If an architectural feature is large, split it into ordered items (e.g. `data model`, then `API layer`, then `UI`).
|
||
If a feature is trivial (a single function or config value), merge it with a related item.
|
||
|
||
If an item depends on another, note it on a second line as `depends: NNN`.
|
||
|
||
## Rules
|
||
|
||
- Ask only if a trade-off materially changes scope or ordering and cannot be resolved from the architecture.
|
||
- Preserve items already in `docs/feature_backlog.md` that are not yet in `docs/features/` — only add, reorder, or remove items, do not rewrite existing descriptions without good reason.
|
||
- Each item is a `## NNN — slug-style-title` subheading followed by one sentence (and optionally a `depends:` line).
|
||
- Keep descriptions to one sentence — just enough for the coding agent to understand the scope.
|
||
- Do not mark any item as done. Completed work is tracked in `docs/features/`, not here.
|