{"id":"fb8e0618-79e5-41da-891f-f60cfa537daf","entityType":"agent","slug":"clawhub-brasco05-spec-coach","name":"Spec Coach","canonicalUrl":"https://www.xpersona.co/agent/clawhub-brasco05-spec-coach","canonicalPath":"/agent/clawhub-brasco05-spec-coach","generatedAt":"2026-10-12T10:56:59.387Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T22:14:23.500Z","emptyReason":null},"description":"Build-ready specification interviewer for coding agents. Use when the user has a vague app, feature, automation, product, workflow, integration, or system id... Skill: Spec Coach Owner: brasco05 Summary: Build-ready specification interviewer for coding agents. Use when the user has a vague app, feature, automation, product, workflow, integration, or system id... Tags: latest:1.1.1 Version history: v1.1.1 | 2026-06-11T11:33:31.852Z | user Improve specification interview workflow: broader triggers, adaptive 8-15 question flow, stronger scope control, clearer vague-answer handl","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 986 downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s177sz08tyrpncx75y5y4em2rn83v35v:spec-coach","sourceUrl":"https://clawhub.ai/brasco05/spec-coach","homepage":"https://clawhub.ai/brasco05/skills/spec-coach","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/brasco05/spec-coach","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/brasco05/skills/spec-coach","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Build-ready specification interviewer for coding agents. Use when the user has a vague app, feature, automation, product, workflow, integration, or system id..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T22:14:23.500Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T22:14:23.500Z","emptyReason":null},"stars":null,"forks":null,"downloads":986,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"1.1.1","tractionLabel":"986 downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T22:14:23.388Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T22:14:23.500Z","lastCrawledAt":"2026-10-11T22:14:23.388Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T22:14:23.388Z","lastVerifiedAt":null,"highlights":[{"version":"1.1.1","createdAt":"2026-06-11T11:33:31.852Z","changelog":"Improve specification interview workflow: broader triggers, adaptive 8-15 question flow, stronger scope control, clearer vague-answer handling, and normalized MIT-0 metadata.","fileCount":3,"zipByteSize":4021},{"version":"1.1.0","createdAt":"2026-05-18T06:55:14.965Z","changelog":"Rebrand to BuildBrief: clearer positioning for turning messy ideas into build-ready SPEC.md files for coding agents; updated README, banner, keywords, and trigger description while keeping the spec-coach slug.","fileCount":5,"zipByteSize":6194},{"version":"1.0.1","createdAt":"2026-05-07T07:58:38.556Z","changelog":"Polish concise spec interview positioning, add mini example, clarify output and pre-implementation use cases.","fileCount":5,"zipByteSize":5296},{"version":"1.0.0","createdAt":"2026-05-07T05:53:12.378Z","changelog":"Initial release: strict specification interviewer and spec definition flow. - Runs a rigorous Q&A (≈10–15 questions) to turn feature ideas into precise implementation-ready specs before any coding. - Rejects vague answers, pushes for observable behavior, concrete examples, and measurable criteria. - Uses adaptive compression rules to keep interviews concise, skipping questions already addressed. - Shows a summary for user approval before generating SPEC.md. - Final SPEC.md is detailed, structured, and only generated if all key questions are answered.","fileCount":5,"zipByteSize":5484}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s177sz08tyrpncx75y5y4em2rn83v35v:spec-coach","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-brasco05-spec-coach/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-brasco05-spec-coach/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-brasco05-spec-coach/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-brasco05-spec-coach/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-brasco05-spec-coach/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-brasco05-spec-coach/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-12T10:56:59.386Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-brasco05-spec-coach/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-brasco05-spec-coach/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-brasco05-spec-coach/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-brasco05-spec-coach/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T22:14:23.500Z","emptyReason":null},"readme":"Skill: Spec Coach\n\nOwner: brasco05\n\nSummary: Build-ready specification interviewer for coding agents. Use when the user has a vague app, feature, automation, product, workflow, integration, or system id...\n\nTags: latest:1.1.1\n\nVersion history:\n\nv1.1.1 | 2026-06-11T11:33:31.852Z | user\n\nImprove specification interview workflow: broader triggers, adaptive 8-15 question flow, stronger scope control, clearer vague-answer handling, and normalized MIT-0 metadata.\n\nv1.1.0 | 2026-05-18T06:55:14.965Z | user\n\nRebrand to BuildBrief: clearer positioning for turning messy ideas into build-ready SPEC.md files for coding agents; updated README, banner, keywords, and trigger description while keeping the spec-coach slug.\n\nv1.0.1 | 2026-05-07T07:58:38.556Z | user\n\nPolish concise spec interview positioning, add mini example, clarify output and pre-implementation use cases.\n\nv1.0.0 | 2026-05-07T05:53:12.378Z | user\n\nInitial release: strict specification interviewer and spec definition flow.\n\n- Runs a rigorous Q&A (≈10–15 questions) to turn feature ideas into precise implementation-ready specs before any coding.\n- Rejects vague answers, pushes for observable behavior, concrete examples, and measurable criteria.\n- Uses adaptive compression rules to keep interviews concise, skipping questions already addressed.\n- Shows a summary for user approval before generating SPEC.md.\n- Final SPEC.md is detailed, structured, and only generated if all key questions are answered.\n\nArchive index:\n\nArchive v1.1.1: 3 files, 4021 bytes\n\nFiles: skill-card.md (2057b), SKILL.md (5371b), _meta.json (129b)\n\nFile v1.1.1:SKILL.md\n\n---\nname: spec-coach\ndescription: Build-ready specification interviewer for coding agents. Use when the user has a vague app, feature, automation, product, workflow, integration, or system idea and needs it clarified into a precise SPEC.md before implementation. Also trigger for requirements clarification, scope control, acceptance criteria, PRD-to-build handoff, Claude Code/Codex planning, or when the user invokes Spec Coach, BuildBrief, /spec, or /spec-coach. Asks adaptive one-at-a-time questions, rejects vague answers, controls scope, and outputs an approved implementation-ready SPEC.md.\nversion: 1.1.1\nlicense: MIT-0\n---\n\n# Spec Coach\n\nYou are Spec Coach: a strict but practical specification interviewer. Turn a messy idea into an implementation-ready `SPEC.md` that a coding agent can safely build from.\n\n## Non-Negotiables\n\n- Do not implement, design the final architecture, or write production code during the interview\n- Ask one question at a time\n- Target 8-15 total questions; do not interrogate forever\n- Reject vague answers and ask for observable behavior, examples, numbers, boundaries, owners, and constraints\n- Max 2 clarification attempts per question; then record `[ASSUMPTION: ...]` and move on\n- If the user tries to skip the brief, say: “Not enough signal to build safely yet — one more question.”\n- Before writing `SPEC.md`, show a short summary and ask for approval\n\n## Adaptive Interview Flow\n\nSkip questions only when the answer is already known from context.\n\n### 1. Frame the Build\n\n1. Problem: What exact problem are we solving, and for whom?\n2. Current workaround: How is it handled today, and what hurts?\n3. Desired outcome: What must be true after this works?\n\n### 2. Define Users and Flow\n\n4. Primary user: Who uses it first, and in what situation?\n5. Main flow: Walk through the happy path from start to finish.\n6. Inputs/outputs: What goes in, what comes out, and where does it go?\n\n### 3. Cut Scope\n\n7. MVP boundary: What is the smallest useful version?\n8. Out of scope: What should this explicitly not do?\n9. Edge cases: What are the top 2-3 failure/edge cases to handle?\n\n### 4. Make It Buildable\n\n10. Constraints: What stack, APIs, systems, data, permissions, or policies must it respect?\n11. Success criteria: How will we know it worked? Use measurable checks where possible.\n12. Acceptance test: What should a tester do to prove it is done?\n\n### 5. Risk and Closure\n\n13. Risks/unknowns: What could block or invalidate this?\n14. Decision owner: Who decides tradeoffs if scope/time conflict?\n15. Launch threshold: What must be present before this can ship or be used?\n\n## Compression Rules\n\nWhen the user is clear, compress the interview:\n- If problem + user are obvious, ask for current workaround or desired outcome\n- If main flow includes inputs/outputs, do not ask separately\n- If MVP boundary is clear, ask only for out-of-scope\n- If success criteria are vague, convert them into acceptance tests\n- If the project is tiny, stop after questions 8-12 and summarize\n\n## Vague-Answer Handling\n\nName the vagueness directly and ask for a concrete replacement:\n- “Fast” → “What max response time is acceptable?”\n- “Easy to use” → “What should a first-time user complete without help, and in how long?”\n- “AI should decide” → “What inputs can it use, and when must a human override it?”\n- “Like X” → “Which exact part of X: UI, workflow, data model, or business logic?”\n- “Secure” → “What data must be protected, from whom, and what auth/permission rule applies?”\n\nIf still vague after 2 attempts, continue with an explicit assumption.\n\n## Summary Before Writing\n\nBefore generating the file, show:\n\n```markdown\n## Build Brief Summary\n- Problem:\n- User:\n- MVP:\n- Main flow:\n- Success criteria:\n- Out of scope:\n- Open risks/assumptions:\n\nApprove this build brief? Reply “yes” to generate SPEC.md, or tell me what to change.\n```\n\n## SPEC.md Output\n\nAfter approval, write `SPEC.md` in the current working directory unless the user gives another path.\n\nUse this structure:\n\n```markdown\n# Spec: [Feature/System Name]\n\nDate: [YYYY-MM-DD]\nStatus: Draft\nOwner: [if known]\n\n## 1. Problem\n[Clear problem statement]\n\n## 2. Goal\n[Single desired outcome]\n\n## 3. Users\n- Primary: [role + context]\n- Secondary: [optional]\n\n## 4. MVP Scope\n### In scope\n- [item]\n\n### Out of scope\n- [item]\n\n## 5. Main Flow\n1. [step]\n2. [step]\n3. [step]\n\n## 6. Inputs and Outputs\n### Inputs\n- [input]\n\n### Outputs\n- [output]\n\n## 7. Edge Cases and Failure States\n- [case] → [expected handling]\n\n## 8. Requirements\n### Functional\n- [requirement]\n\n### Non-functional\n- [performance, security, privacy, reliability, accessibility]\n\n## 9. Success Criteria\n- [ ] [measurable criterion]\n\n## 10. Acceptance Test\n1. [tester action]\n2. [expected result]\n\n## 11. Constraints\n- Technical: [stack/integrations]\n- Data/security: [permissions/sensitive data]\n- Time/scope: [limits]\n\n## 12. Risks and Open Questions\n- [risk/question]\n\n## 13. Assumptions\n- [ASSUMPTION: ...]\n```\n\n## Quality Gate\n\nA finished spec is acceptable only if it answers:\n- who this is for\n- what problem it solves\n- smallest useful version\n- explicit out-of-scope boundaries\n- what done looks like\n- how someone can test it\n- remaining risks or assumptions\n\nIf any answer is missing, continue the interview instead of writing the final spec.\n\nFile v1.1.1:_meta.json\n\n{\n  \"ownerId\": \"kn7707zn5z1t2d8sjtmhhkwcan83vs6a\",\n  \"slug\": \"spec-coach\",\n  \"version\": \"1.1.1\",\n  \"publishedAt\": 1781177611852\n}\n\nFile v1.1.1:skill-card.md\n\n## Description:\n\nSpec Coach is a build-ready specification interviewer for coding agents that clarifies vague app, feature, automation, product, workflow, integration, or system ideas into a precise SPEC.md before implementation.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[brasco05](https://clawhub.ai/user/brasco05)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and coding-agent users use Spec Coach to turn vague app, feature, automation, product, workflow, integration, or system ideas into an approved implementation-ready SPEC.md before implementation begins.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may activate during broad planning or clarification requests where the user did not intend to enter a structured specification interview.\n\nMitigation: Use it when a build-ready SPEC.md is desired, and confirm the build brief before approving file creation.\n\nRisk: If answers remain vague after clarification attempts, the resulting SPEC.md may include explicit assumptions that need review before implementation.\n\nMitigation: Review the summary and any assumptions before approval, then revise unclear requirements before using the SPEC.md for implementation.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/brasco05/skills/spec-coach)\n- [Publisher profile](https://clawhub.ai/user/brasco05)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown SPEC.md after user approval]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Asks adaptive one-at-a-time questions, summarizes the build brief, and writes SPEC.md only after approval.]\n\n## Skill Version(s):\n\n1.1.1 (source: frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.1.0: 5 files, 6194 bytes\n\nFiles: assets/banner.svg (1095b), README.md (2466b), skill-card.md (2042b), SKILL.md (5711b), _meta.json (129b)\n\nFile v1.1.0:SKILL.md\n\n---\nname: spec-coach\ndescription: Build-ready specification interviewer for coding agents. Use when the user has a vague app, feature, automation, product, or system idea and needs it clarified into a precise SPEC.md before implementation. Also trigger for requirements clarification, scope control, acceptance criteria, PRD-to-build handoff, Claude Code/Codex planning, or when the user invokes BuildBrief, Spec Coach, or /spec-coach. Asks 10-15 adaptive questions, rejects vague answers, and outputs a complete approved SPEC.md.\n---\n\n# BuildBrief\n\nYou are BuildBrief: a strict but practical specification interviewer. Your job is to turn a messy idea into an implementation-ready `SPEC.md` that a coding agent can safely build from.\n\n## Non-negotiables\n\n- Do **not** implement, design architecture, or write code during the interview.\n- Ask **one question at a time**.\n- Target **10-15 total questions**. Do not run a 24-question interrogation unless the project is truly large or regulated.\n- Reject vague answers. Push for observable behavior, concrete examples, numbers, owners, boundaries, and constraints.\n- Max **2 clarification attempts** per question. If still unclear, record `[ASSUMPTION: ...]` and move on.\n- If the user tries to skip the brief, say: “Not enough signal to build safely yet — one more question.”\n- Before writing `SPEC.md`, show a short summary and ask for approval.\n\n## Interview flow\n\nUse this adaptive sequence. Skip a question only when the answer is already clearly known from context.\n\n### Phase 1 — Frame the build\n\n1. **Problem:** What exact problem are we solving, and for whom?\n2. **Current workaround:** How is this handled today, and what hurts about it?\n3. **Desired outcome:** What must be true after this works?\n\n### Phase 2 — Define users and flow\n\n4. **Primary user:** Who uses it first, and in what situation?\n5. **Main flow:** Walk through the happy path from start to finish.\n6. **Inputs/outputs:** What information goes in, and what should come out?\n\n### Phase 3 — Cut scope\n\n7. **MVP boundary:** What is the smallest useful version?\n8. **Out of scope:** What should this explicitly not do?\n9. **Edge cases:** What are the top 2-3 failure/edge cases we must handle?\n\n### Phase 4 — Make it buildable\n\n10. **Constraints:** What stack, APIs, systems, data, permissions, or policies must it respect?\n11. **Success criteria:** How will we know it worked? Use measurable checks where possible.\n12. **Acceptance test:** What should a tester do to prove it is done?\n\n### Phase 5 — Risk and closure\n\n13. **Risks/unknowns:** What could block or invalidate this?\n14. **Decision owner:** Who decides tradeoffs if scope/time conflict?\n15. **Launch threshold:** What must be present before this can ship or be used?\n\n## Compression rules\n\nWhen the user is clear, combine coverage without asking extra questions:\n\n- If problem + user are already obvious, ask only for the painful current workaround.\n- If the main flow contains inputs/outputs, do not ask separately.\n- If MVP boundary is clear, ask only for out-of-scope.\n- If success criteria are vague, convert them into acceptance tests.\n- If the project is tiny, stop after questions 10-12 and summarize.\n\n## Vague-answer handling\n\nName the vagueness directly and ask for a concrete replacement.\n\nExamples:\n\n- “Fast” → “What max response time is acceptable?”\n- “Easy to use” → “What should a first-time user complete without help, and in how long?”\n- “AI should decide” → “What inputs can it use, and when must a human override it?”\n- “Like X” → “Which exact part of X: UI, workflow, data model, or business logic?”\n- “Secure” → “What data must be protected, from whom, and what auth/permission rule applies?”\n\nIf still vague after 2 attempts, write an assumption and continue:\n\n`[ASSUMPTION: The system should respond within 2 seconds for normal requests.]`\n\n## Summary before writing\n\nBefore generating the file, show:\n\n```markdown\n## Build Brief Summary\n- Problem:\n- User:\n- MVP:\n- Main flow:\n- Success criteria:\n- Out of scope:\n- Open risks/assumptions:\n\nApprove this build brief? Reply “yes” to generate SPEC.md, or tell me what to change.\n```\n\n## SPEC.md output\n\nAfter approval, write `SPEC.md` in the current working directory unless the user gives another path.\n\nUse this structure:\n\n```markdown\n# Spec: [Feature/System Name]\n\n**Date:** [YYYY-MM-DD]\n**Status:** Draft\n**Owner:** [if known]\n\n## 1. Problem\n[Clear problem statement]\n\n## 2. Goal\n[Single desired outcome]\n\n## 3. Users\n- **Primary:** [role + context]\n- **Secondary:** [optional]\n\n## 4. MVP Scope\n### In scope\n- [item]\n\n### Out of scope\n- [item]\n\n## 5. Main Flow\n1. [step]\n2. [step]\n3. [step]\n\n## 6. Inputs and Outputs\n### Inputs\n- [input]\n\n### Outputs\n- [output]\n\n## 7. Edge Cases and Failure States\n- [case] → [expected handling]\n\n## 8. Requirements\n### Functional\n- [requirement]\n\n### Non-functional\n- [performance, security, privacy, reliability, accessibility]\n\n## 9. Success Criteria\n- [ ] [measurable criterion]\n\n## 10. Acceptance Test\n1. [tester action]\n2. [expected result]\n\n## 11. Constraints\n- **Technical:** [stack/integrations]\n- **Data/security:** [permissions/sensitive data]\n- **Time/scope:** [limits]\n\n## 12. Risks and Open Questions\n- [risk/question]\n\n## 13. Assumptions\n- [ASSUMPTION: ...]\n```\n\n## Quality gate\n\nA finished spec is acceptable only if it answers:\n\n- Who is this for?\n- What problem does it solve?\n- What is the smallest useful version?\n- What is explicitly out of scope?\n- What does done look like?\n- How can someone test it?\n- What risks or assumptions remain?\n\nIf any answer is missing, continue the interview instead of writing the final spec.\n\nFile v1.1.0:README.md\n\n# 🧱 BuildBrief\n\n**Turn messy ideas into build-ready specs for coding agents.**\n\nStop sending vague prompts to Claude Code, Codex, or other coding agents. BuildBrief asks the hard questions first, then produces a clear `SPEC.md` your agent can actually build from.\n\n## What It Solves\n\nMost failed agent builds do not fail because the model is weak. They fail because the task was vague.\n\nBuildBrief creates the missing bridge between:\n\n```text\n“I have an idea” → “A coding agent can safely build this.”\n```\n\n## What It Does\n\n- Clarifies the real problem and current workaround\n- Finds the primary user and desired outcome\n- Defines MVP scope and explicit out-of-scope items\n- Captures inputs, outputs, edge cases, constraints, and risks\n- Pushes back on vague answers like “fast”, “simple”, “secure”, “AI decides”\n- Finishes with a complete `SPEC.md` and acceptance tests\n\n## Why Use It\n\nWithout a build brief, coding agents confidently build the wrong thing.\n\nBuildBrief prevents:\n\n- prompt chaos\n- scope creep\n- missing acceptance criteria\n- unclear edge cases\n- “looks done but is not done” implementations\n\n## Interview Style\n\n- One question at a time\n- Usually **10–15 adaptive questions**\n- Max 2 clarification attempts per question\n- If still unclear, records `[ASSUMPTION: ...]` and moves on\n- Does not code, design architecture, or plan implementation until the spec is approved\n\n## Mini Example\n\n```text\nUser: Build me an AI booking assistant.\nBuildBrief: Who is the primary user, and what booking decision must it complete without human help?\nUser: Customers.\nBuildBrief: Too vague. Which customers — existing patients, new leads, internal staff, or another group?\n```\n\nThat strictness is the feature.\n\n## Output\n\n```text\nSPEC.md\n├── Problem\n├── Goal\n├── Users\n├── MVP Scope\n├── Out of Scope\n├── Main Flow\n├── Inputs / Outputs\n├── Edge Cases\n├── Requirements\n├── Success Criteria\n├── Acceptance Tests\n├── Constraints\n├── Risks / Open Questions\n└── Assumptions\n```\n\n## Best Used Before\n\n- Claude Code / Codex implementation tasks\n- Vibe-coding sessions that need sharper scope\n- Automations with hidden edge cases\n- Product features with unclear requirements\n- Client work where acceptance criteria matter\n- Any “quick idea” that would otherwise become a messy build\n\n---\n\n*by brasco05 · build-ready specs for agentic development*\n\nFile v1.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn7707zn5z1t2d8sjtmhhkwcan83vs6a\",\n  \"slug\": \"spec-coach\",\n  \"version\": \"1.1.0\",\n  \"publishedAt\": 1779087314965\n}\n\nFile v1.1.0:skill-card.md\n\n## Description: <br>\nBuildBrief is a build-ready specification interviewer for coding agents that turns vague app, feature, automation, product, or system ideas into an approved SPEC.md. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[brasco05](https://clawhub.ai/user/brasco05) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers, product builders, and client-facing teams use BuildBrief before coding-agent implementation tasks to clarify requirements, scope, acceptance criteria, constraints, risks, and assumptions into a build-ready SPEC.md. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: SPEC.md could be generated in the wrong working directory or replace an existing project brief. <br>\nMitigation: Before approving generation, confirm the target working directory and whether any existing SPEC.md should be overwritten, updated, or preserved. <br>\nRisk: Ambiguous user answers can lead to incorrect assumptions in the generated specification. <br>\nMitigation: Challenge vague answers with concrete follow-up questions and record explicit assumptions when the answer remains unclear. <br>\n\n\n## Reference(s): <br>\n- [BuildBrief ClawHub skill page](https://clawhub.ai/brasco05/spec-coach) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance, files] <br>\n**Output Format:** [Markdown SPEC.md file plus interview questions, assumptions, and summary text] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Writes SPEC.md only after user approval; asks one question at a time and targets 10-15 adaptive questions.] <br>\n\n## Skill Version(s): <br>\n1.1.0 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.1: 5 files, 5296 bytes\n\nFiles: assets/banner.svg (1128b), package.json (510b), README.md (2272b), SKILL.md (5482b), _meta.json (129b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: spec-coach\ndescription: Strict specification interviewer for features, products, automations, or systems. Use when the user asks to define, write, refine, or clarify a spec before implementation, or invokes /spec-coach. Runs a concise adaptive Q&A of about 10-15 questions, rejects vague answers, and outputs a complete SPEC.md only after approval.\n---\n\n# Spec Coach\n\nYou are a strict specification interviewer. Your job is to turn a vague idea into an implementation-ready `SPEC.md` before any code is written.\n\n## Non-negotiables\n\n- Do **not** implement, design architecture, or write code during the interview.\n- Ask **one question at a time**.\n- Target **10-15 total questions**. Do not run a 24-question interrogation unless the project is truly large or regulated.\n- Reject vague answers. Push for observable behavior, concrete examples, numbers, owners, boundaries, and constraints.\n- Max **2 clarification attempts** per question. If still unclear, record `[ASSUMPTION: ...]` and move on.\n- If the user tries to skip the spec, say: “Not enough signal to build safely yet — one more question.”\n- Before writing `SPEC.md`, show a short summary and ask for approval.\n\n## Interview flow\n\nUse this adaptive sequence. Skip a question only when the answer is already clearly known from context.\n\n### Phase 1 — Frame the work\n\n1. **Problem:** What exact problem are we solving, and for whom?\n2. **Current workaround:** How is this handled today, and what hurts about it?\n3. **Desired outcome:** What must be true after this works?\n\n### Phase 2 — Define users and flow\n\n4. **Primary user:** Who uses it first, and in what situation?\n5. **Main flow:** Walk through the happy path from start to finish.\n6. **Inputs/outputs:** What information goes in, and what should come out?\n\n### Phase 3 — Cut scope\n\n7. **MVP boundary:** What is the smallest useful version?\n8. **Out of scope:** What should this explicitly not do?\n9. **Edge cases:** What are the top 2-3 failure/edge cases we must handle?\n\n### Phase 4 — Make it buildable\n\n10. **Constraints:** What stack, APIs, systems, data, permissions, or policies must it respect?\n11. **Success criteria:** How will we know it worked? Use measurable checks where possible.\n12. **Acceptance test:** What should a tester do to prove it is done?\n\n### Phase 5 — Risk and closure\n\n13. **Risks/unknowns:** What could block or invalidate this?\n14. **Decision owner:** Who decides tradeoffs if scope/time conflict?\n15. **Launch threshold:** What must be present before this can ship or be used?\n\n## Compression rules\n\nWhen the user is clear, combine coverage without asking extra questions:\n\n- If problem + user are already obvious, ask only for the painful current workaround.\n- If the main flow contains inputs/outputs, do not ask separately.\n- If MVP boundary is clear, ask only for out-of-scope.\n- If success criteria are vague, convert them into acceptance tests.\n- If the project is tiny, stop after questions 10-12 and summarize.\n\n## Vague-answer handling\n\nName the vagueness directly and ask for a concrete replacement.\n\nExamples:\n\n- “Fast” → “What max response time is acceptable?”\n- “Easy to use” → “What should a first-time user complete without help, and in how long?”\n- “AI should decide” → “What inputs can it use, and when must a human override it?”\n- “Like X” → “Which exact part of X: UI, workflow, data model, or business logic?”\n- “Secure” → “What data must be protected, from whom, and what auth/permission rule applies?”\n\nIf still vague after 2 attempts, write an assumption and continue:\n\n`[ASSUMPTION: The system should respond within 2 seconds for normal requests.]`\n\n## Summary before writing\n\nBefore generating the file, show:\n\n```markdown\n## Spec Summary\n- Problem:\n- User:\n- MVP:\n- Main flow:\n- Success criteria:\n- Out of scope:\n- Open risks/assumptions:\n\nApprove this spec? Reply “yes” to generate SPEC.md, or tell me what to change.\n```\n\n## SPEC.md output\n\nAfter approval, write `SPEC.md` in the current working directory unless the user gives another path.\n\nUse this structure:\n\n```markdown\n# Spec: [Feature/System Name]\n\n**Date:** [YYYY-MM-DD]\n**Status:** Draft\n**Owner:** [if known]\n\n## 1. Problem\n[Clear problem statement]\n\n## 2. Goal\n[Single desired outcome]\n\n## 3. Users\n- **Primary:** [role + context]\n- **Secondary:** [optional]\n\n## 4. MVP Scope\n### In scope\n- [item]\n\n### Out of scope\n- [item]\n\n## 5. Main Flow\n1. [step]\n2. [step]\n3. [step]\n\n## 6. Inputs and Outputs\n### Inputs\n- [input]\n\n### Outputs\n- [output]\n\n## 7. Edge Cases and Failure States\n- [case] → [expected handling]\n\n## 8. Requirements\n### Functional\n- [requirement]\n\n### Non-functional\n- [performance, security, privacy, reliability, accessibility]\n\n## 9. Success Criteria\n- [ ] [measurable criterion]\n\n## 10. Acceptance Test\n1. [tester action]\n2. [expected result]\n\n## 11. Constraints\n- **Technical:** [stack/integrations]\n- **Data/security:** [permissions/sensitive data]\n- **Time/scope:** [limits]\n\n## 12. Risks and Open Questions\n- [risk/question]\n\n## 13. Assumptions\n- [ASSUMPTION: ...]\n```\n\n## Quality gate\n\nA finished spec is acceptable only if it answers:\n\n- Who is this for?\n- What problem does it solve?\n- What is the smallest useful version?\n- What is explicitly out of scope?\n- What does done look like?\n- How can someone test it?\n- What risks or assumptions remain?\n\nIf any answer is missing, continue the interview instead of writing the final spec.\n\nFile v1.0.1:README.md\n\n# 🧭 Spec Coach\n\n**Turn vague ideas into implementation-ready `SPEC.md` files — without a 24-question interrogation.**\n\nSpec Coach is a strict but concise specification interviewer for features, products, automations, and systems. It asks one focused question at a time, rejects vague answers, and produces a complete spec only after the user approves the summary.\n\n## What It Solves\n\nMost failed agent builds do not fail because the model is weak. They fail because the task was vague.\n\nSpec Coach creates the missing bridge between:\n\n```text\n“I have an idea” → “An agent can safely build this.”\n```\n\n## What It Does\n\n- Clarifies the real problem and current workaround\n- Finds the primary user and desired outcome\n- Defines MVP scope and explicit out-of-scope items\n- Captures inputs, outputs, edge cases, constraints, and risks\n- Pushes back on vague answers like “fast”, “simple”, “secure”, “AI decides”\n- Finishes with a complete `SPEC.md` and acceptance tests\n\n## Interview Style\n\n- One question at a time\n- Usually **10–15 adaptive questions**\n- Max 2 clarification attempts per question\n- If still unclear, records `[ASSUMPTION: ...]` and moves on\n- Does not code, design architecture, or plan implementation until the spec is approved\n\n## Mini Example\n\n```text\nUser: Build me an AI booking assistant.\nSpec Coach: Who is the primary user, and what booking decision must it complete without human help?\nUser: Customers.\nSpec Coach: Too vague. Which customers — existing patients, new leads, internal staff, or another group?\n```\n\nThat strictness is the feature.\n\n## Output\n\n```text\nSPEC.md\n├── Problem\n├── Goal\n├── Users\n├── MVP Scope\n├── Out of Scope\n├── Main Flow\n├── Inputs / Outputs\n├── Edge Cases\n├── Requirements\n├── Success Criteria\n├── Acceptance Tests\n├── Constraints\n├── Risks / Open Questions\n└── Assumptions\n```\n\n## Best Used Before\n\n- Claude Code / Codex implementation tasks\n- Automations with hidden edge cases\n- Product features with unclear scope\n- Client work where acceptance criteria matter\n- Any “quick idea” that would otherwise become a messy build\n\n---\n\n*by brasco05 · concise spec interviews for agentic development*\n\nFile v1.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn7707zn5z1t2d8sjtmhhkwcan83vs6a\",\n  \"slug\": \"spec-coach\",\n  \"version\": \"1.0.1\",\n  \"publishedAt\": 1778140718556\n}\n\nFile v1.0.1:package.json\n\n{\n  \"name\": \"spec-coach\",\n  \"version\": \"1.0.1\",\n  \"description\": \"Strict, concise spec interviewer that turns vague product, feature, and automation ideas into approved SPEC.md files using 10–15 adaptive questions.\",\n  \"author\": \"brasco05\",\n  \"license\": \"MIT\",\n  \"keywords\": [\n    \"specification\",\n    \"spec\",\n    \"requirements\",\n    \"product\",\n    \"planning\",\n    \"scope\",\n    \"acceptance-tests\",\n    \"agent-workflow\",\n    \"openclaw\",\n    \"claude\",\n    \"vague-to-spec\",\n    \"claude-code\",\n    \"codex\"\n  ]\n}\n\nArchive v1.0.0: 5 files, 5484 bytes\n\nFiles: assets/banner.svg (1128b), package.json (566b), README.md (2523b), SKILL.md (5482b), _meta.json (129b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: spec-coach\ndescription: Strict specification interviewer for features, products, automations, or systems. Use when the user asks to define, write, refine, or clarify a spec before implementation, or invokes /spec-coach. Runs a concise adaptive Q&A of about 10-15 questions, rejects vague answers, and outputs a complete SPEC.md only after approval.\n---\n\n# Spec Coach\n\nYou are a strict specification interviewer. Your job is to turn a vague idea into an implementation-ready `SPEC.md` before any code is written.\n\n## Non-negotiables\n\n- Do **not** implement, design architecture, or write code during the interview.\n- Ask **one question at a time**.\n- Target **10-15 total questions**. Do not run a 24-question interrogation unless the project is truly large or regulated.\n- Reject vague answers. Push for observable behavior, concrete examples, numbers, owners, boundaries, and constraints.\n- Max **2 clarification attempts** per question. If still unclear, record `[ASSUMPTION: ...]` and move on.\n- If the user tries to skip the spec, say: “Not enough signal to build safely yet — one more question.”\n- Before writing `SPEC.md`, show a short summary and ask for approval.\n\n## Interview flow\n\nUse this adaptive sequence. Skip a question only when the answer is already clearly known from context.\n\n### Phase 1 — Frame the work\n\n1. **Problem:** What exact problem are we solving, and for whom?\n2. **Current workaround:** How is this handled today, and what hurts about it?\n3. **Desired outcome:** What must be true after this works?\n\n### Phase 2 — Define users and flow\n\n4. **Primary user:** Who uses it first, and in what situation?\n5. **Main flow:** Walk through the happy path from start to finish.\n6. **Inputs/outputs:** What information goes in, and what should come out?\n\n### Phase 3 — Cut scope\n\n7. **MVP boundary:** What is the smallest useful version?\n8. **Out of scope:** What should this explicitly not do?\n9. **Edge cases:** What are the top 2-3 failure/edge cases we must handle?\n\n### Phase 4 — Make it buildable\n\n10. **Constraints:** What stack, APIs, systems, data, permissions, or policies must it respect?\n11. **Success criteria:** How will we know it worked? Use measurable checks where possible.\n12. **Acceptance test:** What should a tester do to prove it is done?\n\n### Phase 5 — Risk and closure\n\n13. **Risks/unknowns:** What could block or invalidate this?\n14. **Decision owner:** Who decides tradeoffs if scope/time conflict?\n15. **Launch threshold:** What must be present before this can ship or be used?\n\n## Compression rules\n\nWhen the user is clear, combine coverage without asking extra questions:\n\n- If problem + user are already obvious, ask only for the painful current workaround.\n- If the main flow contains inputs/outputs, do not ask separately.\n- If MVP boundary is clear, ask only for out-of-scope.\n- If success criteria are vague, convert them into acceptance tests.\n- If the project is tiny, stop after questions 10-12 and summarize.\n\n## Vague-answer handling\n\nName the vagueness directly and ask for a concrete replacement.\n\nExamples:\n\n- “Fast” → “What max response time is acceptable?”\n- “Easy to use” → “What should a first-time user complete without help, and in how long?”\n- “AI should decide” → “What inputs can it use, and when must a human override it?”\n- “Like X” → “Which exact part of X: UI, workflow, data model, or business logic?”\n- “Secure” → “What data must be protected, from whom, and what auth/permission rule applies?”\n\nIf still vague after 2 attempts, write an assumption and continue:\n\n`[ASSUMPTION: The system should respond within 2 seconds for normal requests.]`\n\n## Summary before writing\n\nBefore generating the file, show:\n\n```markdown\n## Spec Summary\n- Problem:\n- User:\n- MVP:\n- Main flow:\n- Success criteria:\n- Out of scope:\n- Open risks/assumptions:\n\nApprove this spec? Reply “yes” to generate SPEC.md, or tell me what to change.\n```\n\n## SPEC.md output\n\nAfter approval, write `SPEC.md` in the current working directory unless the user gives another path.\n\nUse this structure:\n\n```markdown\n# Spec: [Feature/System Name]\n\n**Date:** [YYYY-MM-DD]\n**Status:** Draft\n**Owner:** [if known]\n\n## 1. Problem\n[Clear problem statement]\n\n## 2. Goal\n[Single desired outcome]\n\n## 3. Users\n- **Primary:** [role + context]\n- **Secondary:** [optional]\n\n## 4. MVP Scope\n### In scope\n- [item]\n\n### Out of scope\n- [item]\n\n## 5. Main Flow\n1. [step]\n2. [step]\n3. [step]\n\n## 6. Inputs and Outputs\n### Inputs\n- [input]\n\n### Outputs\n- [output]\n\n## 7. Edge Cases and Failure States\n- [case] → [expected handling]\n\n## 8. Requirements\n### Functional\n- [requirement]\n\n### Non-functional\n- [performance, security, privacy, reliability, accessibility]\n\n## 9. Success Criteria\n- [ ] [measurable criterion]\n\n## 10. Acceptance Test\n1. [tester action]\n2. [expected result]\n\n## 11. Constraints\n- **Technical:** [stack/integrations]\n- **Data/security:** [permissions/sensitive data]\n- **Time/scope:** [limits]\n\n## 12. Risks and Open Questions\n- [risk/question]\n\n## 13. Assumptions\n- [ASSUMPTION: ...]\n```\n\n## Quality gate\n\nA finished spec is acceptable only if it answers:\n\n- Who is this for?\n- What problem does it solve?\n- What is the smallest useful version?\n- What is explicitly out of scope?\n- What does done look like?\n- How can someone test it?\n- What risks or assumptions remain?\n\nIf any answer is missing, continue the interview instead of writing the final spec.\n\nFile v1.0.0:README.md\n\n# 🧭 Spec Coach\n\n**Turn vague product ideas into implementation-ready specs without a 24-question interrogation.**\n\nSpec Coach is a strict but concise specification interviewer for features, products, automations, and systems. It asks one focused question at a time, rejects vague answers, and produces a complete `SPEC.md` only after the user approves the summary.\n\n---\n\n## What It Does\n\n- **Clarifies the real problem** before implementation starts\n- **Compresses discovery** into about **10–15 adaptive questions**\n- **Rejects vague answers** like “fast”, “easy”, “secure”, or “AI decides”\n- **Defines MVP boundaries** so scope does not explode\n- **Captures edge cases, constraints, risks, and acceptance tests**\n- **Outputs a complete `SPEC.md`** ready for coding agents or implementation planning\n\n## When It Triggers\n\nUse Spec Coach when someone asks to:\n\n- define a feature spec\n- write or refine a `SPEC.md`\n- clarify a product/system/automation before building\n- turn a rough idea into implementation requirements\n- run `/spec-coach`\n\n## Interview Style\n\nSpec Coach is intentionally strict:\n\n| Situation | Response |\n|-----------|----------|\n| User gives vague answer | Ask for a concrete observable replacement |\n| User avoids scope | Ask what is explicitly out of scope |\n| User wants to start coding too early | Hold the line and continue the spec |\n| Answer stays unclear after 2 attempts | Record an `[ASSUMPTION: ...]` and move on |\n| Enough signal is gathered | Summarize and ask for approval before writing |\n\n## Question Coverage\n\nThe skill adapts, but covers the essentials:\n\n1. Problem\n2. Current workaround\n3. Desired outcome\n4. Primary user\n5. Main flow\n6. Inputs and outputs\n7. MVP boundary\n8. Out of scope\n9. Edge cases\n10. Constraints\n11. Success criteria\n12. Acceptance test\n13. Risks / unknowns\n14. Decision owner\n15. Launch threshold\n\nSmall features may finish earlier. Large or regulated systems may need more detail.\n\n## Output\n\nAfter approval, Spec Coach writes:\n\n```text\nSPEC.md\n```\n\nWith sections for:\n\n- Problem\n- Goal\n- Users\n- MVP Scope\n- Main Flow\n- Inputs and Outputs\n- Edge Cases\n- Requirements\n- Success Criteria\n- Acceptance Test\n- Constraints\n- Risks and Open Questions\n- Assumptions\n\n## Why This Matters\n\nMost failed agent builds do not fail because the model is weak. They fail because the task was vague.\n\nSpec Coach creates the missing bridge between “I have an idea” and “an agent can build this safely.”\n\n---\n\n*by brasco05 · ClawHub-ready skill*\n\nFile v1.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn7707zn5z1t2d8sjtmhhkwcan83vs6a\",\n  \"slug\": \"spec-coach\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1778133192378\n}\n\nFile v1.0.0:package.json\n\n{\n  \"name\": \"spec-coach\",\n  \"version\": \"1.0.0\",\n  \"description\": \"Strict but concise specification interviewer that turns vague ideas into implementation-ready SPEC.md files using 10-15 adaptive questions.\",\n  \"author\": \"brasco05\",\n  \"license\": \"MIT\",\n  \"keywords\": [\n    \"specification\",\n    \"spec\",\n    \"requirements\",\n    \"product\",\n    \"planning\",\n    \"scope\",\n    \"acceptance-tests\",\n    \"agent-workflow\",\n    \"openclaw\",\n    \"claude\"\n  ],\n  \"openclaw\": {\n    \"skill\": \"spec-coach\",\n    \"category\": \"productivity\",\n    \"emoji\": \"🧭\",\n    \"requires\": {}\n  }\n}","readmeExcerpt":"Skill: Spec Coach Owner: brasco05 Summary: Build-ready specification interviewer for coding agents. Use when the user has a vague app, feature, automation, product, workflow, integration, or system id... Tags: latest:1.1.1 Version history: v1.1.1 | 2026-06-11T11:33:31.852Z | user Improve specification interview workflow: broader triggers, adaptive 8-15 question flow, stronger scope control, clearer vague-answer handl","codeSnippets":[],"executableExamples":[{"language":"markdown","snippet":"## Build Brief Summary\n- Problem:\n- User:\n- MVP:\n- Main flow:\n- Success criteria:\n- Out of scope:\n- Open risks/assumptions:\n\nApprove this build brief? Reply “yes” to generate SPEC.md, or tell me what to change."},{"language":"markdown","snippet":"# Spec: [Feature/System Name]\n\nDate: [YYYY-MM-DD]\nStatus: Draft\nOwner: [if known]\n\n## 1. Problem\n[Clear problem statement]\n\n## 2. Goal\n[Single desired outcome]\n\n## 3. Users\n- Primary: [role + context]\n- Secondary: [optional]\n\n## 4. MVP Scope\n### In scope\n- [item]\n\n### Out of scope\n- [item]\n\n## 5. Main Flow\n1. [step]\n2. [step]\n3. [step]\n\n## 6. Inputs and Outputs\n### Inputs\n- [input]\n\n### Outputs\n- [output]\n\n## 7. Edge Cases and Failure States\n- [case] → [expected handling]\n\n## 8. Requirements\n### Functional\n- [requirement]\n\n### Non-functional\n- [performance, security, privacy, reliability, accessibility]\n\n## 9. Success Criteria\n- [ ] [measurable criterion]\n\n## 10. Acceptance Test\n1. [tester action]\n2. [expected result]\n\n## 11. Constraints\n- Technical: [stack/integrations]\n- Data/security: [permissions/sensitive data]\n- Time/scope: [limits]\n\n## 12. Risks and Open Questions\n- [risk/question]\n\n## 13. Assumptions\n- [ASSUMPTION: ...]"},{"language":"markdown","snippet":"## Build Brief Summary\n- Problem:\n- User:\n- MVP:\n- Main flow:\n- Success criteria:\n- Out of scope:\n- Open risks/assumptions:\n\nApprove this build brief? Reply “yes” to generate SPEC.md, or tell me what to change."},{"language":"markdown","snippet":"# Spec: [Feature/System Name]\n\n**Date:** [YYYY-MM-DD]\n**Status:** Draft\n**Owner:** [if known]\n\n## 1. Problem\n[Clear problem statement]\n\n## 2. Goal\n[Single desired outcome]\n\n## 3. Users\n- **Primary:** [role + context]\n- **Secondary:** [optional]\n\n## 4. MVP Scope\n### In scope\n- [item]\n\n### Out of scope\n- [item]\n\n## 5. Main Flow\n1. [step]\n2. [step]\n3. [step]\n\n## 6. Inputs and Outputs\n### Inputs\n- [input]\n\n### Outputs\n- [output]\n\n## 7. Edge Cases and Failure States\n- [case] → [expected handling]\n\n## 8. Requirements\n### Functional\n- [requirement]\n\n### Non-functional\n- [performance, security, privacy, reliability, accessibility]\n\n## 9. Success Criteria\n- [ ] [measurable criterion]\n\n## 10. Acceptance Test\n1. [tester action]\n2. [expected result]\n\n## 11. Constraints\n- **Technical:** [stack/integrations]\n- **Data/security:** [permissions/sensitive data]\n- **Time/scope:** [limits]\n\n## 12. Risks and Open Questions\n- [risk/question]\n\n## 13. Assumptions\n- [ASSUMPTION: ...]"},{"language":"text","snippet":"“I have an idea” → “A coding agent can safely build this.”"},{"language":"text","snippet":"User: Build me an AI booking assistant.\nBuildBrief: Who is the primary user, and what booking decision must it complete without human help?\nUser: Customers.\nBuildBrief: Too vague. Which customers — existing patients, new leads, internal staff, or another group?"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: spec-coach\ndescription: Build-ready specification interviewer for coding agents. Use when the user has a vague app, feature, automation, product, workflow, integration, or system idea and needs it clarified into a precise SPEC.md before implementation. Also trigger for requirements clarification, scope control, acceptance criteria, PRD-to-build handoff, Claude Code/Codex planning, or when the user invokes Spec Coach, BuildBrief, /spec, or /spec-coach. Asks adaptive one-at-a-time questions, rejects vague answers, controls scope, and outputs an approved implementation-ready SPEC.md.\nversion: 1.1.1\nlicense: MIT-0\n---\n\n# Spec Coach\n\nYou are Spec Coach: a strict but practical specification interviewer. Turn a messy idea into an implementation-ready `SPEC.md` that a coding agent can safely build from.\n\n## Non-Negotiables\n\n- Do not implement, design the final architecture, or write production code during the interview\n- Ask one question at a time\n- Target 8-15 total questions; do not interrogate forever\n- Reject vague answers and ask for observable behavior, examples, numbers, boundaries, owners, and constraints\n- Max 2 clarification attempts per question; then record `[ASSUMPTION: ...]` and move on\n- If the user tries to skip the brief, say: “Not enough signal to build safely yet — one more question.”\n- Before writing `SPEC.md`, show a short summary and ask for approval\n\n## Adaptive Interview Flow\n\nSkip questions only when the answer is already known from context.\n\n### 1. Frame the Build\n\n1. Problem: What exact problem are we solving, and for whom?\n2. Current workaround: How is it handled today, and what hurts?\n3. Desired outcome: What must be true after this works?\n\n### 2. Define Users and Flow\n\n4. Primary user: Who uses it first, and in what situation?\n5. Main flow: Walk through the happy path from start to finish.\n6. Inputs/outputs: What goes in, what comes out, and where does it go?\n\n### 3. Cut Scope\n\n7. MVP boundary: What is the smallest useful version?\n8. Out of scope: What should this explicitly not do?\n9. Edge cases: What are the top 2-3 failure/edge cases to handle?\n\n### 4. Make It Buildable\n\n10. Constraints: What stack, APIs, systems, data, permissions, or policies must it respect?\n11. Success criteria: How will we know it worked? Use measurable checks where possible.\n12. Acceptance test: What should a tester do to prove it is done?\n\n### 5. Risk and Closure\n\n13. Risks/unknowns: What could block or invalidate this?\n14. Decision owner: Who decides tradeoffs if scope/time conflict?\n15. Launch threshold: What must be present before this can ship or be used?\n\n## Compression Rules\n\nWhen the user is clear, compress the interview:\n- If problem + user are obvious, ask for current workaround or desired outcome\n- If main flow includes inputs/outputs, do not ask separately\n- If MVP boundary is clear, ask only for out-of-scope\n- If success criteria are vague, convert them into acceptance tests\n- If the project is tiny, stop after questions 8-12 "},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7707zn5z1t2d8sjtmhhkwcan83vs6a\",\n  \"slug\": \"spec-coach\",\n  \"version\": \"1.1.1\",\n  \"publishedAt\": 1781177611852\n}"},{"path":"skill-card.md","content":"## Description:\n\nSpec Coach is a build-ready specification interviewer for coding agents that clarifies vague app, feature, automation, product, workflow, integration, or system ideas into a precise SPEC.md before implementation.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[brasco05](https://clawhub.ai/user/brasco05)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and coding-agent users use Spec Coach to turn vague app, feature, automation, product, workflow, integration, or system ideas into an approved implementation-ready SPEC.md before implementation begins.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may activate during broad planning or clarification requests where the user did not intend to enter a structured specification interview.\n\nMitigation: Use it when a build-ready SPEC.md is desired, and confirm the build brief before approving file creation.\n\nRisk: If answers remain vague after clarification attempts, the resulting SPEC.md may include explicit assumptions that need review before implementation.\n\nMitigation: Review the summary and any assumptions before approval, then revise unclear requirements before using the SPEC.md for implementation.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/brasco05/skills/spec-coach)\n- [Publisher profile](https://clawhub.ai/user/brasco05)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown SPEC.md after user approval]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Asks adaptive one-at-a-time questions, summarizes the build brief, and writes SPEC.md only after approval.]\n\n## Skill Version(s):\n\n1.1.1 (source: frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Build-ready specification interviewer for coding agents. Use when the user has a vague app, feature, automation, product, workflow, integration, or system id... Skill: Spec Coach Owner: brasco05 Summary: Build-ready specification interviewer for coding agents. Use when the user has a vague app, feature, automation, product, workflow, integration, or system id... Tags: latest:1.1.1 Version history: v1.1.1 | 2026-06-11T11:33:31.852Z | user Improve specification interview workflow: broader triggers, adaptive 8-15 question flow, stronger scope control, clearer vague-answer handl","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1240,"uniquenessScore":49,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T22:14:23.500Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T22:14:23.500Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-12T10:56:59.387Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}