Sheldon Finlay
b3d263258a
- Fix evaluator bypass on last story (moved completion check) - Fix all stale command name references across README, loop.sh, skills, plugin.json - Fix explore evaluator false rejects (.loop/ files are expected) - Fix stderr capture order in headless mode - Fix shell injection risk in hooks.sh python fallback - Remove .DS_Store from tracking - Rewrite README to match current architecture (single entry point, tmux, optional tools) - Add XcodeBuildMCP and iOS simulator MCP to optional tools docs
43 lines
1.7 KiB
Markdown
43 lines
1.7 KiB
Markdown
# Planner Context
|
|
|
|
This file provides additional context for PRD generation.
|
|
|
|
## Story Decomposition Guidelines
|
|
|
|
When breaking a feature into stories, think about:
|
|
|
|
### Independence
|
|
Each story should be independently deployable. After completing story N, the codebase should be in a valid, working state — even if the feature isn't fully built yet.
|
|
|
|
### Context Window Fit
|
|
A story must fit in a single AI context window (~100K tokens). This means:
|
|
- Reading relevant existing code
|
|
- Understanding the task
|
|
- Implementing the change
|
|
- Writing tests
|
|
- Running quality checks
|
|
- Committing
|
|
|
|
Budget roughly:
|
|
- 30% of context for reading/understanding
|
|
- 40% for implementation
|
|
- 20% for testing and quality
|
|
- 10% for bookkeeping (prd.json, progress.md)
|
|
|
|
### Failure Isolation
|
|
If a story fails (evaluator rejects it), the next iteration should be able to retry it cleanly. Stories with too many moving parts are hard to retry because partial state is messy.
|
|
|
|
### Evaluability
|
|
Every story must have criteria the evaluator can independently verify. "The code is clean" is not evaluable. "The function returns 404 when the user doesn't exist" is evaluable.
|
|
|
|
## PRD Anti-Patterns
|
|
|
|
Avoid these common mistakes:
|
|
|
|
- **Stories too large:** "Build the API" — split into individual endpoints
|
|
- **Stories too small:** "Create the file" — combine with meaningful work in that file
|
|
- **Vague criteria:** "Works correctly" — what does correctly mean? Be specific.
|
|
- **Missing dependencies:** Story 5 needs Story 3's database table but doesn't say so
|
|
- **Testing as afterthought:** Tests should be part of each story, not a separate "add tests" story at the end
|
|
- **UI without backend:** A UI story that calls an API that doesn't exist yet
|