The skills are deliberately named with a number prefix (e.g., 100, 201, 301). This numbering system serves two purposes:
"Use 301 to implement the x feature" or "Run 401 on the changes." The AI will instantly recognize the workflow you want.| Grouping | Meaning |
|---|---|
100 series | Build shared project context: domain, product, architecture, UX, and feature map |
200 series | Define one feature before coding |
300 series | Implement or repair behavior |
400 series | Triage failing tests when the fix path is unclear, or run cleanup-only refinement on an already-changed scope |
Install interactively and choose only the skills you want:
npx skills add ajelinek/SpecFlowInstall the full catalog:
npx skills add ajelinek/SpecFlow --skill '*'Use npx skills add ajelinek/SpecFlow --list if you want to preview the available skills first.
The bundled worker agents in agents/ are optional and installed separately. See
Custom Agents for those install directions.
This page is the inventory and the reference. Use it to understand what each skill does and where it fits in the lifecycle.
100-domain-knowledge optional Research the domain, users, workflows, terminology, regulations, and constraints before planning — including market research and what makes a product unique or its key differentiators — usually through evidence-backed live research.
When to use it: Use it when the product space is unfamiliar, regulated, terminology-heavy, or when project understanding is weak.
101-project-overview optional Define what the product is, who it serves, and why it matters.
When to use it: Use it at the start of a new project after domain research, or when product framing is unclear.
102-system-architecture optional Record the system shape, major components, stack choices, and testing approach.
When to use it: Use it when you need a shared technical baseline before implementation work begins.
103-common-data-model optional Define the conceptual entities, relationships, and business rules in the domain.
When to use it: Use it when the team needs a shared language for data before backend or frontend design.
104-backend-architecture optional Specify API structure, service layering, data access, and backend security patterns.
When to use it: Use it when the backend needs concrete implementation conventions before feature work.
105-frontend-architecture optional Specify component structure, state boundaries, styling rules, and frontend integration patterns.
When to use it: Use it when the frontend needs clear architectural rules before detailed page work.
106-ui-design optional Set the design philosophy, color system, typography, and component visual strategy.
When to use it: Use it when the project needs a design foundation before UX or page-level work.
107-ui-experience optional Define navigation, page inventory, interaction patterns, and UX commitments.
When to use it: Use it when you need a coherent UX model before designing specific pages.
108-ui-page-design optional Design one page in detail with a markdown overview and an HTML mockup used as the primary visual reference.
When to use it: Use it when a specific route from the D07 page inventory needs a detailed layout and interaction reference.
110-feature-overview optional Group the product into capabilities and thin vertical feature slices, with stable feature IDs that later design docs can reference.
When to use it: Use it when the team needs a concise backlog after the main project docs exist.
201-high-level-design core Create a concise feature overview, scope boundary, and user journey for one feature.
When to use it: Use it first when you are starting design work for a specific feature.
202-spec-design core Write Gherkin scenarios with module and lifecycle tagging that describe the feature behavior.
When to use it: Use it after 201 to define what should be tested and built.
203-implementation-design optional Create a repo-grounded, extend-first implementation plan with selectable detail depth before coding.
When to use it: Use it when the team wants a persisted implementation.md plan before coding.
204-feature-validation optional Return a chat-only readiness review across the feature artifacts before coding.
When to use it: Use it after 201, 202, and 203 once implementation.md exists and you want a readiness review before coding.
301-spec-implementation core Implement substantial changes through a tests-first, phase-isolated workflow with internal cleanup and validation.
When to use it: Use it for the main implementation pass when the change is larger than a tiny isolated edit.
302-test-implementation optional Add or repair automated tests for behavior that already exists, with only minimal UI testability hooks if needed.
When to use it: Use it when production behavior is already in place but the automated coverage is weak or missing; route back to 301 if behavior is still missing.
401-cleanup core Run a separate cleanup-only pass on either changed source files or changed test files inside a strict scope.
When to use it: Use it after implementation only when an existing changed set needs a deliberate cleanup pass.
402-test-correction optional Investigate a failing automated test and decide whether the right correction is in the test, in source, or in the intended behavior itself.
When to use it: Use it when a red test needs source-vs-test triage before you decide what to change.
agent-context bonus Refresh root AGENTS.md guidance, with nested overlays only where subtrees materially differ.
When to use it: Use it when repo guidance is missing, stale, or needs local subtree overrides.
deep-research bonus Do multi-source live web research with citations when current external information materially affects the answer.
When to use it: Use it any time web search or web research is needed, especially when freshness matters and a strong answer needs more than a single URL summary.