Agent skill
feature-file
Manage features.yml for tracking requirements and progress; use proactively ONLY when features.yml already exists, or invoke manually to create one; complements TodoWrite for persistent project state.
Install this agent skill to your Project
npx add-skill https://github.com/Chemiseblanc/ai/tree/main/plugins/cascade-development/skills/feature-file
SKILL.md
Feature File Management
Manage features.yml - a waterfall-style planning document combining structured requirements tracking with incremental development.
Quick Reference
feature: "Feature Name"
phase: Requirements | Design | Implementation | Testing | Complete
version: 1
changelog: |
## [1]
### Added
- Initial feature
decisions:
- Decision rationale
known-issues:
- Known bug or limitation
requirements:
req-id:
description: "When X, the system SHALL Y"
status: Not-Started | In-Progress | Needs-Work | Complete
tested-by: [test-id]
test-cases:
test-id:
name: "test_function_name"
file: "tests/test_file.py"
description: "Given X, when Y, then Z"
passing: true | false
type: unit | [integration, rainy-day] # optional, string or list
---
# Next feature...
See references/schema.md for complete field documentation.
Proactive Usage
This skill should be used automatically when features.yml exists.
Before Starting Implementation
- Check if
features.ymlexists in project root - If missing: do not use this skill proactively (stop here)
- Plan the work in features.yml before writing code:
- Add/update the feature with all requirements extracted from the user's request
- Add anticipated test cases to
test-cases(withpassing: false) - Document design decisions in
decisionsif non-trivial choices are involved
- Set the first requirement to
status: In-Progress
During Implementation
- Update
statustoCompleteas requirements are finished - Add test cases to
test-caseswhen writing tests - Update
passingfield after running tests - Add discovered issues to
known-issues
After Completing Work
- Verify all implemented requirements are marked
Complete - Run
./scripts/feature-status.py --validateto check consistency - Commit features.yml changes with the implementation
Relationship with TodoWrite
| Tool | Purpose | Persistence |
|---|---|---|
| TodoWrite | Immediate session actions | Ephemeral |
| features.yml | Requirements and progress | Persistent (in repo) |
Use both: TodoWrite for what to do now, features.yml for durable project state.
Phase Transitions
| From | To | Conditions |
|---|---|---|
| Requirements | Design | All requirements have descriptions |
| Design | Implementation | decisions field exists (use [] if none needed) |
| Implementation | Testing | All requirements In-Progress or Complete |
| Testing | Complete | All requirements Complete AND all tests passing: true |
Scripts validate these rules and report errors.
Workflows
Agent Workflow (Condensed)
ls features.yml→ exists? Read it : Create it- Plan first: Add feature, requirements, test-cases, decisions
- Set first requirement
status: In-Progress - Implement, then set
status: Complete - Run tests, update
passingstatus ./scripts/feature-status.py --validate- Commit with implementation changes
Creating a New Feature File
- Create
features.ymlwith first feature:yamlfeature: "Feature Name" phase: Requirements version: 1 changelog: | ## [1] ### Added - Initial planning requirements: req-1: description: "Requirement description using EARS syntax" status: Not-Started - Run
./scripts/feature-status.pyto validate structure
Minimal start (for quick bootstrapping during implementation):
feature: "Feature Name"
phase: Implementation
version: 1
changelog: |
## [1]
### Added
- Initial implementation
requirements:
req-1:
description: "Requirement from user request"
status: In-Progress
Building from Existing Codebase
- Identify logical feature boundaries in the code
- For each feature:
- Create feature document, set
phasebased on current maturity - Extract requirements from code behavior, comments, documentation
- Discover existing tests and add to
test-cases - Link tests to requirements via
tested-by - Set
statusbased on implementation state and test coverage
- Create feature document, set
- Run
./scripts/feature-status.py --validateto check consistency - Run
./scripts/extract-work.pyto see gaps
Development Workflow (Incremental Progress)
Work on ONE requirement at a time:
- Run
./scripts/extract-work.pyto see incomplete requirements - Pick highest priority requirement, update
status: In-Progress - Implement the requirement
- Write/update tests, add to
test-caseswithpassing: false - Run tests, update
passing: truewhen passing - Update requirement
status: Complete - Run
./scripts/feature-status.pyto check phase advancement eligibility - Repeat
Version Management
- Run
./scripts/check-version.pyto check for needed bumps - If bump recommended:
- Increment
versionfield - Add new changelog section:
yaml
changelog: | ## [2] ### Added - New capability ## [1] ... - Commit the update
- Increment
Scripts
All scripts read from features.yml in current directory. Scripts are executable and use inline dependencies via uv run --script.
feature-status.py
Overview of all features with progress and test status (with breakdown by type if defined).
./scripts/feature-status.py # Plain text output
./scripts/feature-status.py --format markdown # Markdown table
./scripts/feature-status.py --validate # Exit 1 if validation errors
extract-work.py
List requirements needing work (status != Complete).
./scripts/extract-work.py # All incomplete
./scripts/extract-work.py --phase Implementation
./scripts/extract-work.py --status In-Progress
./scripts/extract-work.py --format markdown
extract-issues.py
List known issues across all features.
./scripts/extract-issues.py
./scripts/extract-issues.py --format json
check-version.py
Check git history to see if versions need bumping.
./scripts/check-version.py
Compares when feature sections were last modified vs when version was last set.
Best Practices
- One requirement at a time: Complete and verify before starting next
- Update status immediately: Keep file in sync with actual state
- Document decisions: Capture rationale in
decisionsbefore implementation - Track known issues: Document bugs and limitations in
known-issues - Bump version on requirement changes: Any add, modify, or remove
- Use EARS syntax for requirements: "When X, the system SHALL Y"
- Use Given/When/Then for test descriptions
Change Management
All requirement changes require a version bump. This ensures traceability and clear history.
Adding Requirements to Existing Feature
- Add requirement with
status: Not-Started - Increment
versionfield - Add changelog entry under
### Added - If feature is past Design phase, consider whether new requirement needs design review
Modifying Existing Requirements
- Document rationale for the change
- Update requirement
description - Update
status:- If was
Complete: set toNeeds-Work - Otherwise: keep current status
- If was
- Review affected test cases in
tested-by- update or mark as needing revision - Increment
versionfield - Add changelog entry under
### Changed
Deprecating/Removing Requirements
- Document rationale
- Either:
- Remove requirement entirely, OR
- Move to
known-issuesas historical note (e.g., "req-x removed: no longer needed")
- Remove or update associated test cases
- Increment
versionfield - Add changelog entry under
### Removed
Version Bump Triggers
Always bump version when:
- Adding, modifying, or removing requirements
- Shipping a milestone
- Significant scope changes
- Phase transitions to
Complete
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
waterfall-development
Enforces strict waterfall development workflow with phase gates. Use when (1) features.yml exists in project root, (2) user asks to implement/develop/build a feature, (3) user explicitly requests waterfall workflow. Creates features.yml if missing when invoked.
git-commit
Guide for breaking changes into logical, atomic commits using interactive staging. Use when committing changes that span multiple concerns, when needing to stage parts of files (hunks), when asked to create well-organized commit history, or when changes should be split into multiple commits.
software-architecture
Document software architecture using ARCHITECTURE.md and docs/*.md files with Mermaid diagrams. Use proactively when ARCHITECTURE.md exists in project root, or invoke to create initial architecture documentation. Covers system design, data flows, component relationships, and code organization with references to key entry points and abstractions.
commit-message
Format git commit messages combining Conventional Commits summary lines with Linux kernel-style bodies. Use when writing, reviewing, or formatting commit messages.
structured-logging
Guide for writing effective log messages using wide events / canonical log lines. Use when writing logging code, adding instrumentation, improving observability, or reviewing log statements. Teaches high-cardinality, high-dimensionality structured logging that enables debugging.
tlaplus-modeling
Model and reason about concurrent or distributed systems with TLA+ and PlusCal. Use when: designing multithreaded or distributed behavior before code exists, deriving invariants from an informal design, writing TLA+ specs, creating PlusCal algorithms, model checking with TLC, organizing multi-module specifications, debugging verification failures, or reducing state space. Covers informal concurrency design, MCP tool usage, PlusCal preferred syntax (call/await over goto), TLA+ module organization, and state-space optimization.
Didn't find tool you were looking for?