0225214b0b
Replaces ambiguous 4-status system with 6 clear stages, one per skill: Planned → Architected → In Progress → In Review → Approved → Deployed - architecture: sets "Architected" (was "In Progress") - frontend + backend: explicitly set "In Progress" with checklist items - qa: sets "In Review" on start, "Approved" on pass (was only "In Review") - general rules + INDEX.md: updated valid statuses and descriptions Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
75 lines
3.9 KiB
Markdown
75 lines
3.9 KiB
Markdown
# General Project Rules
|
|
|
|
## New Project Detection (MANDATORY)
|
|
Before starting ANY work, check if the project has been initialized:
|
|
1. Read `docs/PRD.md` - if it still contains placeholder text like "_Describe what you are building_", the project is NOT initialized
|
|
2. Read `features/INDEX.md` - if the features table is empty, no features have been defined
|
|
|
|
**If the project is not initialized:**
|
|
- Do NOT write any code or create any components
|
|
- Do NOT skip ahead to implementation
|
|
- Instead, tell the user: "This project hasn't been set up yet. Let's start by defining what you want to build. Run `/requirements` with a description of your idea (e.g. `/requirements I want to build a task management app`)."
|
|
- If the user already described their idea in the current message, run `/requirements` automatically with their description
|
|
|
|
**If the project is initialized but the user requests a feature not yet in INDEX.md:**
|
|
- Guide them to run `/requirements` first to create the feature spec before any implementation
|
|
|
|
## Feature Tracking
|
|
- All features are tracked in `features/INDEX.md` - read it before starting any work
|
|
- Feature specs live in `features/PROJ-X-feature-name.md`
|
|
- Feature IDs are sequential: check INDEX.md for the next available number
|
|
- One feature per spec file (Single Responsibility)
|
|
- Never combine multiple independent functionalities in one spec
|
|
|
|
## Git Conventions
|
|
- Commit format: `type(PROJ-X): description`
|
|
- Types: feat, fix, refactor, test, docs, deploy, chore
|
|
- Check existing features before creating new ones: `ls features/ | grep PROJ-`
|
|
- Check existing components before building: `git ls-files src/components/`
|
|
- Check existing APIs before building: `git ls-files src/app/api/`
|
|
|
|
## Human-in-the-Loop
|
|
- Always ask for user approval before finalizing deliverables
|
|
- Present options using clear choices rather than open-ended questions
|
|
- Never proceed to the next workflow phase without user confirmation
|
|
|
|
## Status Updates (MANDATORY - Write-Then-Verify)
|
|
After completing work on any feature, you MUST update tracking files. Follow this exact sequence:
|
|
|
|
1. **Read** the feature spec (`features/PROJ-X-*.md`) and `features/INDEX.md` BEFORE editing
|
|
2. **Write** your changes using the Edit tool — do NOT just describe what you would write
|
|
3. **Re-read** the file AFTER editing to verify the changes are actually present
|
|
4. **If changes are missing**, repeat step 2 — never claim updates were made without verifying
|
|
|
|
**What to update in the feature spec:**
|
|
- Status field in the header (Planned → In Progress → In Review → Deployed)
|
|
- Implementation notes: what was built, what changed, any deviations from the original spec
|
|
- Bug fixes or design changes discovered during implementation
|
|
|
|
**What to update in `features/INDEX.md`:**
|
|
- Feature status column must match the feature spec header
|
|
- Valid statuses: Planned → Architected → In Progress → In Review → Approved → Deployed
|
|
- **Planned**: after `/requirements`
|
|
- **Architected**: after `/architecture`
|
|
- **In Progress**: after `/frontend` or `/backend` starts
|
|
- **In Review**: after `/qa` starts
|
|
- **Approved**: after `/qa` passes (no critical/high bugs)
|
|
- **Deployed**: after `/deploy`
|
|
|
|
**NEVER do this:**
|
|
- Do NOT say "I've updated the feature spec" without actually calling the Edit tool
|
|
- Do NOT summarize changes in chat as a substitute for writing them to the file
|
|
- Do NOT skip updates because "it's obvious" or "minor"
|
|
|
|
## File Handling
|
|
- ALWAYS read a file before modifying it - never assume contents from memory
|
|
- After context compaction, re-read files before continuing work
|
|
- When unsure about current project state, read `features/INDEX.md` first
|
|
- Run `git diff` to verify what has already been changed in this session
|
|
- Never guess at import paths, component names, or API routes - verify by reading
|
|
|
|
## Handoffs Between Skills
|
|
- After completing a skill, suggest the next skill to the user
|
|
- Format: "Next step: Run `/skillname` to [action]"
|
|
- Handoffs are always user-initiated, never automatic
|