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.
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.
A direct command skips the review prompt. Inspect the source before running it.
The command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
SKILL.md
Source instructions · Read-only preview
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.
