mirror of
https://github.com/duthaho/claudekit.git
synced 2026-06-11 04:34:56 +03:00
4.1 KiB
4.1 KiB
name, argument-hint, user-invocable, description
| name | argument-hint | user-invocable | description |
|---|---|---|---|
| feature-workflow | [feature description or issue] | true | Use when implementing a complete feature end-to-end — from requirements analysis through planning, implementation, testing, and review. Trigger for keywords like "feature", "implement", "build", "add functionality", "end-to-end", or any task that spans planning through delivery. Also activate when the user provides a feature description, issue reference, or requirement spec that needs a structured development workflow. |
Feature Workflow
When to Use
- Implementing a complete feature from requirements to delivery
- When given a feature description, issue number, or requirement spec
- Multi-phase work that needs planning, implementation, testing, and review
- Any task that benefits from a structured development workflow
When NOT to Use
- Simple bug fixes — use
systematic-debugging - Pure refactoring — use
refactoring - Writing tests for existing code — use
testing - Already have a plan to execute — use
executing-plans
Workflow Phases
Phase 1: Understanding
- Parse the feature request thoroughly
- Identify acceptance criteria
- List assumptions that need validation
- Clarify ambiguous requirements with the user
Phase 2: Planning
- Explore codebase for related implementations and patterns
- Identify integration points and dependencies
- Decompose into atomic, verifiable tasks
- Order tasks by dependencies
- Track all tasks with TodoWrite
- (Optional, recommended for non-trivial features) Run
autoplanon the resulting plan to pressure-test strategy, architecture, design, and DX before Phase 4 (Implementation)
Phase 3: Research (if needed)
If the feature involves unfamiliar technology:
- Research best practices and patterns
- Find examples in the codebase or documentation
- Identify potential pitfalls
Phase 4: Implementation
For each task:
- Write failing test first (TDD)
- Implement minimally to pass the test
- Refactor if needed
- Mark task complete immediately
Phase 5: Testing
- Run full test suite — no regressions
- Verify coverage — should not decrease
- Test edge cases and error scenarios
# Python
pytest -v --cov=src
# TypeScript
pnpm test
Phase 6: Review
Self-review checklist:
- Code follows project conventions
- No security vulnerabilities
- Error handling is complete
- Tests are passing
- No debug statements or TODOs
Phase 7: Completion
- Verify all tasks complete
- Stage appropriate files
- Generate commit message
- Create PR if requested
Output Format
## Feature Implementation Complete
### Feature
[Feature description]
### Changes Made
- `path/to/file.ts` — [What was added/modified]
- `path/to/file.test.ts` — [Tests added]
### Tests
- [x] Unit tests passing
- [x] Integration tests passing
- [x] Coverage: XX%
### Ready for Review
Best Practices
- Break down aggressively — smaller tasks are easier to verify and commit.
- Test first — every task starts with a failing test.
- Commit incrementally — commit after each task, not at the end.
- Clarify before building — ambiguous requirements lead to rework.
- Check existing patterns — follow conventions already in the codebase.
Common Pitfalls
- Starting without understanding — jumping to code before clarifying requirements.
- Monolithic implementation — implementing everything in one pass without incremental verification.
- Ignoring existing patterns — building something inconsistent with the rest of the codebase.
- Skipping tests — "I'll add tests later" means no tests.
Related Skills
brainstorming— Use before this skill when requirements are unclear or need explorationwriting-plans— Use for detailed task breakdown when the feature is complextest-driven-development— The TDD discipline applied during Phase 4git-workflows— Committing and shipping the completed featurerequesting-code-review— Getting feedback before merging