Disambiguate vague build requests through structured questioning. Triggers when user says 'build me X' implying 2+ unresolved dimensions (auth/payments/data/integrations), has new-project or major-feature scope with unresolved decisions, or user says /interrogate. Simple single-page or script requests pass through unchanged.
Instrucciones de origen · Vista previa de solo lectura
name
interrogate
description
Disambiguate vague build requests through structured questioning. Triggers when user says 'build me X' implying 2+ unresolved dimensions (auth/payments/data/integrations), has new-project or major-feature scope with unresolved decisions, or user says /interrogate. Simple single-page or script requests pass through unchanged.
Interrogate Skill
When This Applies
Run this skill when:
User says "build me X" and X implies multiple unresolved domains (e.g., "webstore" = auth + payments + inventory + integrations)
Major feature request has 2+ decision points without clear answers
User runs /interrogate
Skip this skill for: single-page apps ("landing page"), simple scripts ("parse CSV"), obviously-scoped requests ("add a button to do X").
Flow
Ask in batches of 2–3 questions per round. Wait for answers before advancing. For each question, suggest a reasonable default (make your recommendation explicit). If the user defers a domain, accept the deferral and name the default assumption.
Walk domains in order. Stop when all domains are either answered, explicitly deferred with a named default, or marked out-of-scope.
Domains
1. Problem & Users
Who has the problem? (Not "people" — be specific: "solo DevOps engineers shipping Kubernetes," "small e-commerce shops with <$10k/month revenue")
Who pays? (End user, business, admin?)
What's the core loop — the thing done every session?
How painful is the problem today? (Nice-to-have or blocking their work?)
2. Identity & Auth
Do users need to log in?
If yes: Single user, shared team accounts, role-based permissions?
Auth method: Social login (Google/GitHub), email/password, SAML, other?
Existing visual identity to match, or start from scratch?
Mobile-first, desktop-first, or responsive?
Any design system constraints (your company's component library, etc.)?
9. Non-Goals
What does v1 explicitly NOT do? (Clarifying scope boundaries prevents scope creep)
Example: "Not supporting offline mode," "Not handling international shipping," "Not integrating with accounting software"
Output: two files
Once all domains are resolved (or deferred with named defaults), write both files. The split is by rate of change — see docs/CONTEXT-SCHEMA.md. What you learned about the product goes in CONTEXT.md and will still be true next year; what to build first goes in .attacca/focus.md and is stale in a fortnight.
CONTEXT.md (repo root) — stable
# Project Context## Project**What**: [One sentence: what the product does]
**Why**: [The problem and who has it]
**Who pays**: [User, business, subscription model, etc.]
## Stack**Language/Framework**: [Your recommendation or their preference]
**Database**: [Postgres, MongoDB, etc. — or "defer, use starter default"]
**Hosting**: [Vercel, Heroku, AWS, etc.]
**Auth Provider**: [Firebase, Auth0, custom, etc.]
**Payments**: [Stripe, none, other]
## Key Decisions**Decision 1**: [What was decided] | Rejected: [alternatives and why not] | Deferred: [if applicable]
**Decision 2**: [What was decided] | Rejected: [alternatives and why not]
...
Last updated: [Today's date]
Every deferral from the interrogation becomes a Key Decisions bullet with its named default — a deferral is a decision, and the reason it was deferred is exactly what a future session needs. Under ~100 lines; if the spec is large, link docs/spec.md rather than inlining it.
.attacca/focus.md — per-session
# Focus## Current Focus
[The v1 feature set. 3–5 must-haves. Walk the 9 domains to confirm nothing is missing.]
## Next Steps1. [First action for implementation]
2. [Second action]
3. [...]
## Blockers
[Anything unclear or waiting for external input? "None" if clear.]
Last updated: [Today's date]
Create the .attacca/ directory if it doesn't exist. If the project already has a .gitignore ignoring .attacca/ wholesale, narrow it to .attacca/audits/ and .attacca/sbom/ — focus.md must be committed.
Zero-Ambiguity Checklist
Before writing either file, verify:
Problem & Users: Who has it, why, how painful, current workaround
Identity & Auth: Log in? If yes, how? Roles?
Payments: Monetization model and provider (or "free forever")
Data Model: Core entities and retention policy
Integrations: External APIs or none, polling vs webhooks, fallback behavior
Compliance: Regulations, data deletion, audit logs
Design & Brand: Existing brand or from scratch, mobile/desktop/responsive
Non-Goals: What v1 does NOT do
Every item is either answered with a concrete choice, explicitly deferred to a named default (e.g., "use Postgres as default"), or marked out-of-scope (e.g., "mobile is v2").
No silent assumptions. Everything surfaced.
Example
User: "Build me a tool for freelance designers to invoice clients."
Your questions (batch 1):
Who's the user — solo designers or agencies?
How do they invoice today? (Manual spreadsheet, PDF template, existing SaaS?)
User answer: Mostly solo designers using Google Sheets or email PDF.
Your questions (batch 2):
Do they need to log in each time or is this a one-off tool?
Do they need to track payments or just create invoices?
User answer: They'd log in. Yes, track paid/unpaid status.
[Continue until all 9 domains are answered or deferred]
Output: Write CONTEXT.md (project, stack, every decision with its rejected alternative) and .attacca/focus.md (the v1 set, ordered next steps, blockers), then recommend: "Next: run /plan to scope the implementation, or start coding if you're confident in this spec."
Adapted from prd-builder. Focuses on disambiguation only; implementation planning is separate.
