| name | feature-dev |
| description | Structured feature development workflow with codebase exploration, architecture tradeoffs, implementation gating, and review Use when this capability is needed. |
| metadata | {"author":"axisrow"} |
Feature Dev Skill
Use this skill when the user wants to build a new feature and would benefit from a deliberate workflow instead of immediate implementation.
Goal
Drive feature work through seven phases:
- Discovery
- Codebase exploration
- Clarifying questions
- Architecture design
- Implementation
- Quality review
- Summary
Operating Rules
- Do not jump straight into code for ambiguous feature work.
- Read the codebase before proposing implementation details.
- Ask clarifying questions after exploration and before architecture selection.
- Present concrete tradeoffs, not abstract options.
- Do not start implementation until the user approves an approach.
- After implementation, run a review pass focused on bugs, regressions, and convention mismatches.
Workflow
1. Discovery
- Restate the feature request in concrete terms.
- If the request is underspecified, ask what problem is being solved, required behavior, constraints, and non-goals.
- Create a task plan that tracks all seven phases.
2. Codebase Exploration
Investigate the codebase from multiple angles. Parallelize local reads and searches when possible.
Cover at least these perspectives:
- Similar or adjacent features
- Relevant architecture layers and extension points
- Existing tests, conventions, and user flows
For each perspective, produce:
- Key files with path references
- Relevant control flow and abstractions
- Constraints that affect implementation
After exploration, read the most important files and summarize patterns that the new feature should follow.
3. Clarifying Questions
Before designing the solution, identify ambiguities such as:
- Edge cases
- Error handling
- Scope boundaries
- Integration points
- Backward compatibility
- Performance or security requirements
Ask the user a concise grouped list of questions and wait for answers. If the user delegates the choice, give a recommendation and get explicit confirmation.
4. Architecture Design
Develop 2-3 implementation approaches with distinct tradeoffs:
- Minimal changes
- Clean architecture
- Pragmatic balance
For each approach, include:
- Files to change or create
- Main abstractions
- Benefits
- Costs and risks
Recommend one approach and explain why it fits this codebase and request. Ask the user which approach to use.
5. Implementation
Do not begin until the user explicitly approves an approach.
When implementing:
- Follow existing project patterns
- Keep changes scoped to the agreed design
- Update the task plan as work progresses
- Add tests when the codebase supports them
6. Quality Review
Review the resulting changes from three lenses:
- Simplicity, DRY, and maintainability
- Bugs, correctness, and regressions
- Project conventions and abstraction fit
Report the highest-signal findings first. If issues exist, ask whether to fix now, defer, or proceed as-is.
7. Summary
Close with:
- What was built
- Key decisions
- Main files changed
- Remaining risks or next steps
Specialist Lenses
Use these role prompts internally when useful:
You do not need separate agents to use this skill. Reuse the lenses as structured thinking modes during exploration, design, and review.
Source: axisrow/tg_content_factory — distributed by TomeVault.
