feature-development
Feature Development
Implement the next reviewed slice as a small, test-backed increment that can be reviewed and delivered safely.
Context
Feature development is where plans become working behavior. In Prodcraft, it sits between test-first design and formal review: the task is not "write a lot of code," but "land the smallest useful slice that satisfies the current plan and keeps downstream delivery safe."
This skill is especially important when the architecture, contract, and release boundary are already known. It prevents implementation from drifting into hidden scope expansion, accidental product decisions, or broad rewrites disguised as progress.
Inputs
- task-list -- Defines the current slice, scope boundary, and success criteria.
- test-suite -- Gives the executable safety net that the implementation must satisfy.
- architecture-doc -- Provides component boundaries and constraints.
- api-contract -- Protects externally visible behavior when the slice changes a public or inter-service interface.
Process
More from yknothing/prodcraft
system-design
Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.
6ci-cd
Use when a reviewed implementation slice needs an automated build, test, and deployment pipeline, especially when brownfield rollback, release-boundary checks, contract/integration gates, and staged delivery must be explicit before shipping.
6intake
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
6monitoring-observability
Use when a live service or newly delivered release needs actionable telemetry, dashboards, and alerts that expose real user-impactful boundaries, especially when brownfield coexistence rules, unsupported-flow safety, rollback health, or queue/backfill behavior must be visible before incidents escalate.
6incident-response
Use when a live production issue needs coordinated containment, severity triage, stakeholder communication, and evidence capture, especially when a recent release, brownfield coexistence rules, rollback decisions, or unresolved contract boundaries must be handled before root-cause work.
6requirements-engineering
Use when the work is still at the \u201Cwhat should we build\u201D stage and approved discovery inputs or entry-stack outputs must become prioritized requirements and scope boundaries before specification, architecture, planning, or coding. Not for acceptance criteria, spec review, or implementation.
6