بنقرة واحدة
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?" |