Run any Skill in Manus with one click

specflow-init

Stars2

Forks0

UpdatedJuly 10, 2026 at 04:38

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Longhuiberkeley

Longhuiberkeley/specflow

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

More from this repository

same repository

specflow-audit

Longhuiberkeley/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.

2026-07-102

specflow-discover

Longhuiberkeley/specflow

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.

2026-07-102

specflow-plan

Longhuiberkeley/specflow

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.

2026-07-102

specflow-ship

Longhuiberkeley/specflow

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).

2026-07-102

specflow-start

Longhuiberkeley/specflow

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.

2026-07-102

specflow-autoresearch

Longhuiberkeley/specflow

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.

2026-07-102

name

specflow-init

description

Freeform Input Handling

This skill accepts freeform user input alongside the command. Interpret the user's message to determine scope and depth:

No additional context → run the standard workflow (deterministic core only)
A question or concern → run the deterministic core, then address the question directly using the results
A request for depth ("go deep", "be thorough", "all lenses") → run deterministic core + full agent-driven analysis
A specific focus ("focus on REQ-003", "check compliance only") → narrow scope to the request, still run deterministic core first

Always run the deterministic core regardless of input. It costs zero tokens and provides the foundation for any analysis.

SpecFlow Init

Conversational bootstrap for a SpecFlow project.

Workflow

1. Detect or ask about the AI platform

Check the project root for platform detection markers (from platforms.yaml):

Marker	Platform Code	Name
`.claude/`	`claude-code`	Claude Code
`.cursor/`	`cursor`	Cursor
`.windsurf/`	`windsurf`	Windsurf
`.cline/`	`cline`	Cline
`.gemini/`	`gemini`	Gemini CLI
`.opencode/`	`opencode`	OpenCode
`.github/copilot-instructions.md`	`github-copilot`	GitHub Copilot
`.roo/`	`roo`	Roo Code
`.qwen/`	`qwen`	QwenCoder
`.kiro/`	`kiro`	Kiro
`.kilocode/`	`kilocode`	KiloCoder
`.codex/`	`codex`	Codex
`.trae/`	`trae`	Trae
`.junie/`	`junie`	Junie

Scan markers in order. If a marker exists, use that platform code. If multiple markers are found, prefer the first match (table order). specflow init also warns when multiple AI-host platform dirs are detected, since skills are only installed to the one you targeted — run uv run specflow refresh --all-platforms afterward to bring the others current.

If no marker is found, ask:

"Which AI coding assistant are you using?"

Claude Code (Recommended)

Cursor

Windsurf

Cline

Gemini CLI

GitHub Copilot

OpenCode

Roo Code

Kiro

Other

1b. New project, or bringing an existing codebase?

Ask (bounded):

"Is this a NEW project, or are you bringing an EXISTING codebase into SpecFlow?"

New project (Recommended)

Existing codebase

If Existing codebase (brownfield): remember a brownfield flag and prefer the adoption preset (see Step 2) — it installs the /specflow-adopt skill, which inventories your code and backfills an as-built baseline instead of authoring requirements from scratch. Greenfield projects do not need it.

Freeform input: if the user's message already implies an existing codebase ("set up SpecFlow for my project", "add SpecFlow to this repo") and the repo has existing source files, set the brownfield flag without asking.

2. Gather project context

Ask the user:

"What type of project is this?" -- bounded options: Web App, CLI Tool, Library, Firmware/Embedded, Data Pipeline, Mobile, Other
"Do you want to apply an industry standards preset?" -- bounded options: iso26262-demo, default, adoption (existing codebase — installs /specflow-adopt), or None (Recommended)
"Do you want to install optional artifact types (hazard, risk, control)?" -- bounded options: Yes, No (Recommended)
"Which CI provider do you use?" -- bounded options: GitHub Actions (Recommended), GitLab CI, None
"Do you have any specific compliance standard packs you want to install?" -- free text, or None (Recommended)

3. Run the init command

uv run specflow init --platform <platform_code>

Append flags as needed:

--domain <project-type> if a project type was chosen (e.g., --domain embedded, --domain api-service, --domain web-app)
--domain-tags <comma-separated> for domain qualifiers (e.g., --domain-tags real-time,safety-critical)
--preset <preset> if a preset was chosen
--with-types hazard,risk,control if optional artifact types were chosen
--no-ci if no CI provider was requested

This scaffolds .specflow/, _specflow/, config files, schemas, checklists, and installs skill directories for the target platform. When --domain is provided, it also persists the domain classification and attempts to generate project-level best practices (the "process booklet").

4. Verify SpecFlow instruction injection

The specflow init CLI has already injected the SpecFlow instruction block into the platform's instruction file (via scaffold.py). Verify it landed correctly.

4a. Check the injected block

Verify that the target instruction file contains the SpecFlow sentinel marker:

4b. Determine the target instruction file

The specflow init CLI command has already handled instruction injection automatically (via scaffold.py). The instruction file should already contain the SpecFlow block wrapped in  sentinels. Verify it was injected correctly by checking the target file for the sentinel marker.

If the marker is missing (unusual), the target file mapping is:

5. Verify git hook installation

The specflow init command installs a pre-commit hook automatically when .git/ exists. Check the command output for:

+ Installed .git/hooks/pre-commit

If the project has no .git/ directory yet, inform the user they can run uv run specflow hook install after initializing git.

6. Generate CI workflow (if requested)

If a CI provider was specified and the adapters config was generated, the init command may have already created the workflow file. Verify from the output. If not, run:

uv run specflow ci generate

7. Report and recommend next steps

Summarize what was done:

Directories created (.specflow/, _specflow/, platform skills directory)
Configuration files written (config.yaml, state.yaml, adapters.yaml)
Domain classification persisted (if --domain was provided)
Instruction file updated (target file path)
Pre-commit hook installed
CI workflow generated (if applicable)
Packs applied (if any)
Docs knowledge surface recognized (root *.md + docs/); docs: config block written

Then recommend:

If greenfield: "Your project is ready. Run /specflow-discover to start capturing requirements, /specflow-adapter to configure CI or exchange integrations first, or /specflow-doc to cite your spec from existing docs or your README."

If brownfield (adoption preset): "Your project is ready. Run /specflow-adopt to inventory your existing code and backfill an as-built baseline (forward work for new features then resumes through /specflow-discover). Or /specflow-adapter to configure CI."

Upgrade note. After upgrading SpecFlow (uv tool upgrade specflow), remind the user to run uv run specflow refresh — it updates the copied skills, agent-context block, and templates in this repo without a full re-init.

Rules

When offering the user choices for project type, presets, or CI, provide clear, bounded options.
The preset option should default to "None" unless the user indicates a regulated industry.
The CI option should default to "None" unless the user mentions "GitHub" or "GitLab".
Every choice offered to the user includes "(Recommended)" on the suggested default.
Platform detection should be automatic when possible. Only ask when no marker is found.
If the user says "skip" or "move on", accept all defaults and continue without further questions.
Never overwrite existing instruction file content. Only append the SpecFlow block.
The --platform flag must always be passed explicitly to specflow init.
Instruction injection is idempotent: if <!-- SpecFlow section is already present, do nothing.