specflow

SCOPE = the whole project. Use for a FULL-PROJECT health review — runs a zero-question deterministic core with optional adversarial wings. Creates AUD and CHL artifacts. Triggers when the user says "audit the project," "health check," "how healthy is the project," "review the whole project," "review overall spec quality," or asks for a comprehensive project-wide assessment. NOT for: single-artifact review (use specflow-artifact-review), reviewing blast radius of recent changes (use specflow-change-impact-review), or quick spot-checks of one file.

Use to start the SpecFlow requirements discovery workflow — the entry point for any new feature, enhancement, or specification task. Triggers when the user wants to start something NEW — "add a feature," "build a NEW [X]," "I want to create [Z]," "we need [capability]," "capture requirements for," or "what should the system do?" Use this FIRST when the idea is new and no REQ exists yet (if REQs are already approved and stories are queued for coding, use specflow-execute). Also triggers for reverse lifecycle: "rethink the requirements," "revise the requirements," "go back to requirements," or when the user wants to revisit specs after planning or executing. This is step 1 of the core lifecycle — use it FIRST for any new feature or change that needs specification, BEFORE specflow-plan and specflow-execute. NOT for: data exploration, data cleaning, researching technologies, prototyping, running experiments, or technical prep work unrelated to requirements authoring.

Use when setting up SpecFlow in a new or existing project for the FIRST TIME. Triggers when the user says "set up SpecFlow," "initialize the project," or "get started with SpecFlow." Conversational bootstrap that scaffolds directories, installs hooks, generates CI workflows, and recommends next steps. NOT for: re-initializing an already-configured project, adding packs to an existing setup (use specflow-adapter), or routine configuration changes.

REQUIRED after discover when REQs are approved. Breaks approved requirements into architecture (ARCH), detailed design (DDD), and stories (STORY). Triggers when the user says "design the architecture," "plan the implementation," "break this down," or when REQs are approved and the user is ready to move forward. Also triggers for reverse lifecycle: "rethink the architecture," "revise the plan," "go back to planning," or when the user wants to revisit architecture after executing. This is step 2 of the core lifecycle — use it BEFORE any implementation begins. NOT for: quick bug fixes (use specflow-execute with lean path), research tasks, or infrastructure setup.

REQUIRED to release a version. Produces a baseline, generates change records (DEC), runs a quick audit, and presents a release summary. Triggers when the user says "release," "ship," "publish v," or asks to tag a version. This is the final step of the core lifecycle — use it when implementation is complete and verified. NOT for: mid-development checkpoints (use specflow-audit or specflow-artifact-review).

Use when unsure which SpecFlow step to run next, or for a quick "where am I / what's next" orientation. Runs `specflow brief --next` for a deterministic next-step recommendation, asks ONE disambiguating question only if intent is ambiguous, and points at the right /specflow-* skill. Triggers on "what should I do," "what's next," "what now," "where do I start," "where are we," "what's the status," "continue," "resume," "remind me where we are," "help me get started," "I'm stuck," "point me in the right direction," or any request that doesn't clearly match a specific lifecycle or review skill. This is the safe default when no other skill clearly fits — prefer routing over guessing. NOT a replacement for the lifecycle skills (discover/plan/execute/ship) or the review skills — it only routes you to the correct one. Prefer this over guessing when the user's intent is vague.

Use when the user wants to run autonomous research loops, set up competitions, review experiment findings, explore competitions, run experiments overnight, set up a benchmark, or promote a deployable finding / productionize a winning experiment back into core requirements. Activates the autoresearch pack's competition-scoped experimentation with knowledge condensation.

Live-operations workflow for the ops pack (RUN + MONITOR). Use when the user deploys or runs something live, monitors a live system's health/metrics, captures ephemeral/live data that won't be reproducible, or investigates drift. Creates a RUN (deployment frozen at deploy-time) and appends MONITOR observations (timestamped metric/signal journal). Triggers on "deploy", "go live", "monitor this run", "capture live odds/data", "is it drifting", "check LIVE health / is the deployed run drifting". NOT for offline experiments (use /specflow-autoresearch EXPT), writing app code (use /specflow-execute STORY), requirements authoring (use /specflow-discover), or a project-wide spec/health audit (use /specflow-audit — "health check" means project health there, not live-system health here).

Use to manage CI workflows, import/export artifacts, configure standards ingestion, or set up team roles and RBAC. Triggers when the user says "set up CI," "configure GitHub Actions for spec validation," "set up team roles / RBAC / CODEOWNERS," "import from DOORS / Polarion / ReqIF," or "export artifacts." Covers adapter configuration, hook management, and CODEOWNERS generation. This is infrastructure/ops configuration — NOT for requirements, architecture, implementation, or review workflows.

Use when the user wants to author a new standards compliance pack — from a PDF file, URL, or pasted text. Triggers when the user says "make a compliance pack from this PDF/URL," or "author a standards pack." Generates a complete pack directory with pack.yaml, standards clauses, and optional schemas. This is a specialized authoring tool — NOT for general SpecFlow usage or project setup.

SCOPE = blast radius of recent changes. Use to review the IMPACT CONE of recent changes — finds unreviewed DEC artifacts, computes blast radius, reviews impact, creates CHL findings. Triggers when the user says "what's the impact of this change," "review recent changes," "change impact," or after a series of commits/PRs. NOT for: full-project audits (use specflow-audit), single-artifact review (use specflow-artifact-review), or reviewing changes that don't have DEC artifacts yet.

SCOPE = the docs/ knowledge surface (README, docs/, adr/, CONTRIBUTING, root markdown). Use to write or revise project documentation, cite spec artifacts from a doc via inline @ID markers (e.g. @ARCH-007, @DEC-018), sync the docs index, and check whether docs still cite current (non-superseded) artifacts. Triggers when the user says "write the docs," "document this," "update the README," "explain the architecture in the docs," "cite the spec from the docs," "link this doc to the spec," "sync the docs index," or "are the docs stale / out of date." NOT for recording a decision (use /specflow-plan → DEC), capturing a requirement (use /specflow-discover → REQ), throwaway research (use a SPIKE), reproducible experiments (use the **autoresearch pack**'s `/specflow-autoresearch EXPT`, if installed), or authoring/reviewing a SpecFlow artifact itself (use create commands or /specflow-artifact-review). Docs are a knowledge SURFACE, not an artifact type — editing a doc never creates a REQ/ARCH/DEC; git history is the ch

Implementation path for planned stories. Orchestrates implementation of approved stories, updates artifact statuses, creates V-model test artifacts (UT/IT/QT), and enforces traceability. Triggers when the user says "implement stories," "execute the plan," "start building," or "run the wave." Also triggers for reverse lifecycle: "rethink the implementation," "this approach isn't working," "go back to architecture," or "go back to requirements." This is step 3 of the core lifecycle. For trivial changes (typos, formatting, dependency updates), the lean path is available — but every code change still traces to a STORY. NOT for: requirements gathering (use specflow-discover), architecture design (use specflow-plan), single-artifact review (use specflow-artifact-review), or research experiments.

Use when bringing an EXISTING codebase into SpecFlow (brownfield adoption) — inventory current code/docs/tests, backfill REQ/ARCH/DDD/DEC describing what already exists (code is linked to ARCH/DDD via output_files globs), cut an as-built baseline, and steer deepening with `specflow adopt status`. STORY is NOT backfilled — it is reserved for forward action. Incremental and resumable for large codebases. NOT for greenfield projects (use /specflow-discover).

SCOPE = one artifact or a small named set. Use to review, validate, or verify SPECIFIC SpecFlow artifacts. Triggers context-specific checks using automated scripts and checklist review. Triggers when the user says "review this REQ," "validate the ARCH," "check this story," or asks about a specific artifact's quality. NOT for: full-project health checks (use specflow-audit), reviewing blast radius of recent DEC changes (use specflow-change-impact-review), or general code review outside SpecFlow artifacts.