agentleFS
Sign inStart free
bordenetbordenet/superpowers-plus/skills/engineering/feature-development/skill.md

feature-development

Skill8 starsChanged 6 months agoMITView on GitHub

Orchestrate new feature development. Route bug fixes, bounded process corrections, skill edits, promotions, and status work to their specific workflows instead of imposing the full feature ceremony.

9 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use for a new feature or when the user explicitly requests this full workflow.

    line 31
  2. Distinctive:

    Do not apply it merely because a file will change.

    line 32
  3. Very specific:

    Use brainstorming for unresolved product/design choices and its Clear path for a fully specified request.

    line 40
  4. Very specific:

    Use the active repository's review routing (tools/review.sh in superpowers-plus) for the final changed paths and the applicable independent …

    line 50
  5. Very specific:

    Use the active repository's authoritative runner and evidence policy.

    line 63

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
skill.md

Feature Development

Wrong skill? Bug fix or process defect -> systematic-debugging and, for a failed control, durable-correction. Skill edits -> llm-skill-review. Promotion/history sync -> branch-flow-gate. Status -> session-status.

Scope

Use for a new feature or when the user explicitly requests this full workflow. Do not apply it merely because a file will change. A bounded repair, skill edit, configuration correction, promotion, or status request is not automatically a new feature. Its specific workflow still supplies required safety and review.

Workflow

  1. Establish the user's outcome, existing behavior, constraints and acceptance criteria. Read the relevant implementation before asking for missing facts.
  2. Use brainstorming for unresolved product/design choices and its Clear path for a fully specified request. Use debate only for a material choice between significant approaches. Do not invent options or approval rounds for a settled design. Use think-twice when stuck or when a real blind spot needs isolation.
  3. Plan proportionately: a short checklist for a bounded feature; a durable plan for work that actually spans phases. Do not create global TODO work merely to satisfy a second orchestration skill.
  4. Implement with focused regression coverage. Every required test runs through its authoritative runner. Equivalent content/context reuses successful evidence or waits for the active producer; changed inputs invalidate affected coverage.
  5. Use the active repository's review routing (tools/review.sh in superpowers-plus) for the final changed paths and the applicable independent review. One clean review is sufficient. Material findings or later relevant changes require delta review; never demand two rounds just to count two.
  6. Complete required lint/build/test, IP, authorization and integration checks. Consume existing valid results; do not restart them for each phase, message, commit, PR or history-only merge. Do not bypass a real missing requirement.
  7. Ship within the user's approved scope. Follow required forge/deployment checks, verify the requested outcome, disclose limitations, then stop. Unrelated health checks are not new acceptance criteria.

Enforcement and evidence

Use the active repository's authoritative runner and evidence policy. In superpowers-plus, tools/test-all.sh and its CI own receipts and single-flight execution; do not assume those paths exist in another project. Review clearance remains governed by native content-scoped sentinel consumers. Skills coordinate these mechanisms; they do not mint PASS, parse imagined formats, or launch raw duplicate suites when the authoritative runner reports reuse/wait.

Failure cases

FailureCorrect response
Full feature chain fires for a bounded repairUse the specific repair/review workflow
Another phase asks for the same testReuse or wait on the equivalent producer
Required inputs or execution context changedValidate the changed inputs once
Clean review followed by an arbitrary second reviewStop; only a material delta justifies re-review
Missing proof or an untrusted producerTreat as unresolved; never claim PASS
Acceptance met, more unrelated checks appearDisclose their scope without extending the task

Companion skills

  • brainstorming: resolve real design uncertainty
  • systematic-debugging: investigate and repair a defect
  • durable-correction: replace a failed control
  • plan-and-execute: execute a genuinely phased plan
  • verification-before-completion: tie final claims to actual evidence

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free