ワンクリックで
speq-mission
Create specs/mission.md via interactive interview. Detects brownfield vs greenfield.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Create specs/mission.md via interactive interview. Detects brownfield vs greenfield.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Audit a speq project's health — spec-library structure, feature/decision-log/plan validation, mission-to-spec sync, unrecorded plans, and gitignore hygiene — then guide fixes. Use when the user asks to audit, health-check, doctor, lint, or sanity-check the specs or repo, or after cloning or inheriting a speq project.
Code review tag taxonomy and findings output format — guardrail violations, dead code, obsolete tests, bad comments, optimizations, YAGNI/over-engineering. Triggered by code-reviewer.
Headless follow-up to speq-plan-pr. Continues on a plan's feat/plan-name branch, runs speq-implement, bumps the version, runs the real test suites, records only if green, then pushes and opens/updates a PR. Arg: plan name, PR number, or branch name.
Orchestrate implementation of reviewed plans according to the spec deltas. Arg: <plan-name>.
Headless, non-interactive version of speq-plan. Plans a feature without a live interview, commits the result to a feat/plan-name branch, and opens a PR. If a decision genuinely needs a human, it persists the partial plan and open questions and asks in a PR comment instead of blocking. Arg — plan name, feature intent text, PR number, or branch name.
Adversarial plan-review method and challenge taxonomy — premortem framing, 14-tag/5-axis taxonomy, severity discipline, and findings output format. Triggered by plan-reviewer.
| name | speq-mission |
| description | Create specs/mission.md via interactive interview. Detects brownfield vs greenfield. |
You are creating a project mission file (specs/mission.md) through an interactive interview.
Golden Rule: NEVER assume. ALL content MUST come from user answers or code exploration.
Invoke before starting:
/speq-code-tools — Codebase exploration/speq-ext-research — Tech stack research/speq-cli — Spec structure/speq-writing-guardrails — Prose style for artifacts and GitHub textCheck for .speq/mission-hook.md in the repo root.
Determine project type:
Cargo.toml, package.json, go.mod, etc. exists?
├─ Yes → Brownfield (existing code)
└─ No → Greenfield (new project)
specs/ or similar directory exists?
├─ Yes → Has existing specs (read them)
└─ No → No specs yet
For existing projects, gather context BEFORE interviewing:
| File | Indicates |
|---|---|
Cargo.toml | Rust project → read dependencies |
package.json | Node.js → read dependencies, scripts |
go.mod | Go project → read dependencies |
pyproject.toml / requirements.txt | Python → read dependencies |
pom.xml / build.gradle | Java/Kotlin |
Important: This is an exemplary list. Project may use other languages or frameworks. Project may use several technologies.
Look for existing scripts:
# package.json scripts
# Makefile targets
# Cargo.toml aliases
# pyproject.toml scripts
# List top-level directories
ls -la
# Find main source directories
find . -type d -name "src" -o -name "lib" -o -name "app" | head -20
Check for existing documentation:
README.mddocs/specs/ if anyFor technologies discovered or mentioned:
Use research to inform interview questions and validate user choices.
Conduct a Socratic interview via AskUserQuestion for EVERY section. Never fill in content without asking. Each question should reveal assumptions, surface contradictions, or narrow scope.
For greenfield:
Questions:
- What is the project name?
- In one sentence, what does this system do and why does it exist?
- What problem does this solve?
- Who experiences this problem?
- Why do existing solutions fall short?
For brownfield:
Present discovered information, then ask:
- "I found [X]. Is this accurate? What would you add/change?"
- "The README says [Y]. Is this still the current purpose?"
Questions:
- Who are the primary users of this system?
- What are they trying to achieve?
- What is their typical workflow?
For brownfield: "Based on the code, it seems targeted at [X]. Is this correct?"
Apply User Story Mapping (Patton) — identify activities, then decompose into capabilities:
Questions:
- What are the 3-5 core capabilities this system provides?
- (Describe what it does, not how)
For brownfield: "I found these main modules: [X, Y, Z]. What capabilities do they represent?"
Questions:
- What does this project explicitly NOT do?
- What features might users expect but won't be supported?
Questions:
- Are there domain-specific terms users should understand?
- Any terms used differently than their common meaning?
For brownfield: "I noticed these terms in the code: [X, Y]. What do they mean in this context?"
For greenfield:
Questions:
- What language/runtime?
- What framework (if any)?
- What database (if any)?
- What testing framework?
Use Context7 to research mentioned technologies.
For brownfield:
Present discovered stack:
- "I found: Rust with tokio, clap for CLI, no database. Correct?"
- "Testing appears to use cargo test. Any additional test frameworks?"
For greenfield:
Questions:
- What is the build command?
- What is the test command?
- What is the lint/format command?
- What is the coverage command?
For brownfield:
Present discovered commands:
- "Found in package.json: npm run build, npm test. Are these correct?"
- "No coverage command found. What should it be?"
For greenfield:
Questions:
- What is the planned directory structure?
- What is the purpose of each main directory?
For brownfield:
Present discovered structure and ask for clarification on purpose.
Questions:
- What is the high-level architecture pattern? (layered, hexagonal, event-driven, etc.)
- What are the key components and their responsibilities?
- How does data flow through the system?
Questions:
- Technical constraints? (browser-only, offline-first, etc.)
- Business constraints? (GDPR, multi-tenant, etc.)
- Performance constraints? (response time, memory limits, etc.)
Questions:
- What external services/APIs does this depend on?
- What happens if each dependency is unavailable?
After collecting ALL information:
specs/ directory if neededspecs/mission.md using references/mission-template.md as structurePresent the generated mission.md and ask:
- "Does this accurately capture your project?"
- "Anything to add, change, or remove?"
Iterate until user approves.
Group questions into MECE partitions (max 3-4 per AskUserQuestion call) — each group covers one dimension without overlap:
| Phase | Questions to Group |
|---|---|
| Identity | Name, summary, problem |
| Users | Personas, goals, workflows |
| Capabilities | Core features, out of scope |
| Technical | Stack, commands, structure |
| Constraints | Technical, business, performance |
| Project Complexity | Interview Depth |
|---|---|
| Simple CLI tool | Minimal (skip architecture, external deps) |
| Web application | Standard (all sections) |
| Distributed system | Deep (detailed architecture, failure modes) |
| Wrong | Right |
|---|---|
| "I'll use Jest for testing" | "What testing framework do you want?" |
| "Architecture is MVC" | "What architecture pattern fits best?" |
| "Coverage target is 80%" | "What coverage target do you want?" |