Skip to content
SpecFlow SpecFlow
🚧 This documentation is a draft and is currently under review. 🚧

FAQ

Is this heavyweight?

No. The main delivery path is 201 → 202 → 301. Use 401 only when you want a separate cleanup-only pass on an already-changed scope.

Do I need all the workflows?

No. Start with 201 → 202 → 301 for feature delivery and add the rest only when they solve a real problem.

Do I need the 100-series first?

Not always, but it helps more often than teams expect. Use the 100-series when the project still needs domain, product, architecture, UX, or feature-set definition before feature delivery starts. That applies to new projects and to existing projects where understanding is still weak. If that context already exists, many teams can begin with 201.

What is with the numbers?

The numbers make the catalog easy to scan, search, and reference in prompts.

  • Start with the 100 series for project and planning context.
  • Follow the 200 series for feature design.
  • Use the 300 series to implement the change.
  • Use the 400 series for red-test triage when the fix path is unclear and for cleanup-only refinement.

That means you can write short prompts like “follow 201 to build the feature set” or “follow 301 to implement this change” without needing to remember the full skill names.

How is this different from plain prompting?

It breaks the work into feature intent, expected behavior, implementation, and cleanup.

Does skills.sh install the worker agents too?

No. skills.sh installs the SpecFlow skills only. The bundled worker agents are an optional separate install step.

When should I use 302 instead of 301?

Use 302 when production behavior already exists and the missing work is test coverage. If the behavior is missing or disagrees with the scenarios, switch back to 301 or correct the spec first.

Why is 401 separate from 301?

Because 301 already includes internal test-cleanup and production-cleanup phases. 401 exists for the times you want an extra cleanup-only pass on an existing changed set, with a strict source-versus-test boundary.

When should I use 402 instead of 302?

Use 402 when the starting point is a failing test and you still need to determine whether the defect is in the test, in production code, or in the intended behavior. Use 302 when production behavior is already believed to be correct and the missing work is simply automated test coverage or a bounded test-side repair.

Can I skip 201 and go straight to 202?

You can, but 201 keeps the feature scope clear.