interview
Skill7 starsChanged 2 months agoMITView on GitHub
Pre-design discovery interview that gathers deep user intent through structured questioning. Produces a discovery brief (discovery.md) consumed by the design skill.
94 other projects use a version of this.
Adopted by
Most recently taken up by
- chrisdesmondSML/chris-skillstheir own version, first seen Nov 8, 2026
- Firzus/agent-skillstheir own version, first seen Nov 8, 2026
- claude-code-hardened/claude-code-hardenedtheir own version, first seen Nov 8, 2026
- MMACABRE/SKILLStheir own version, first seen Nov 8, 2026
- yuri-xyz/skillstheir own version, first seen Nov 8, 2026
- codewhale-hq/codewhale-plugin-marketplacetheir own version, first seen Nov 8, 2026
Used with
Projects with it also use fetch-library-docs, contributor and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Rehan-Ul-HaqSkillfetch-library-docs
Fetches official documentation for external libraries and frameworks (React, Next.js, Prisma, FastAPI, Express, Tailwind, MongoDB, etc.) with 60-90% token savings via content-type filtering. Use this skill when implementing features using library APIs, debugging library-specific errors, troubleshooting configuration issues, installing or setting up frameworks, integrating third-party packages, upgrading between library versions, or looking up correct API patterns and best practices. Triggers automatically during coding work - fetch docs before writing library code to get correct patterns, not after guessing wrong.
Also in 4 projects that use this
NimbleBrainIncSkillcontributor
Get started contributing to NimbleBrain open source — find an integration to build, set up your environment, propose an idea, or check on your work. Use when onboarding as a contributor. Triggers include "I'm a new contributor", "what should I build", "show me open issues", "file an issue".
Also in 3 projects that use this
mjunaidcaSkillbrowsing-with-playwright
Browser automation using Playwright MCP. Navigate websites, fill forms, click elements, take screenshots, and extract data. Use when tasks require web browsing, form submission, web scraping, UI testing, or any browser interaction. NOT when only fetching static content (use curl/wget instead).
Also in 4 projects that use this
qa-amanSkillteach-me
Teach a topic, video, article, codebase change, spec, or transcript until the user demonstrably understands it, using staged instruction, a running checklist doc, and quizzes. Use whenever the user says "teach me", "explain this in detail", "help me understand X", "/teach-me", "walk me through this", "I want to learn X", "understand this deeply", or pastes a YouTube URL, article, paper, PR, or spec and asks to understand it rather than summarize it. Also use when the user wants study notes or raw material from a source they are learning. Do NOT use for a quick factual lookup, a summary request, or when the user just wants the answer.
Also in 8 projects that use this
trebaudSkillfind-unknowns
Workflow for surfacing a task's unknowns before, during, and after implementation — blind spot pass, brainstorm/prototype, interview, references, implementation plan, deviation notes, quiz. Use when starting work in an unfamiliar domain or codebase, when a task feels underspecified, when the user says "find my unknowns", "blindspot pass", "what am I missing", "help me scope this", or when a long task came back wrong.
Also in 3 projects that use this
donatassimkusSkilloffer
Offer design, pricing strategy, and business model architecture. Invoke when asked about making an offer better, pricing a product or service, naming an offer, raising prices, generating fast cash, increasing lifetime value, finding the right customer, qualifying buyers, or designing a business model where customers pay for their own acquisition. Use when someone says their offer isn't converting, they need to charge more, they want to add bonuses or guarantees, or they need a money model for their business.
Also in 3 projects that use this
Other versions94 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 94
- claude-code-best/claude-code★ 23ksame name
- Q00/ouroboros★ 6.3ksame name
- Hisn00w/ASu-skills★ 6.1ksame name
- boshu2/agentops★ 453same name
- genkovich/sdd★ 187same name
- jvm-skills/jvm-skills★ 140same name
- kv0906/pm-kit★ 138same name
- tobieapb/claude-interactive-documentation-workflow★ 105same name
- panaversity/claude-code-skills-lab★ 57same name
- roman01la/skills-agents★ 48same name
84 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
Show its rules and text
We split this skill into the rules it gives an agent
25 rules. 0 are common, 17 are distinctive, and 8 are very specific to this project.
0
Common
Most of the 80 edited versions we read keep these.
17
Distinctive
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
When /coco:phase or /coco:planning-session tactical routes to Standard tier
- Very specific: line 24
Read .coco/config.yaml for project.specs_dir (default: specs).
- Distinctive: line 26
If a feature name or description was provided, use it
- Very specific: line 27
If on a feature/* git branch, extract the feature name
- Distinctive: line 28
If none of the above, ask the user what feature to discuss
- Very specific: line 31
Check if {specs_dir}/{feature-name}/discovery.md already exists:
- Distinctive: line 32
If yes, enter refinement mode (see below)
- Distinctive: line 33
If no, proceed with fresh interview
- Distinctive: line 51
Before asking any questions, analyze the user's initial feature description and any context from the current conversation.
- Distinctive: line 54
Use AskUserQuestion with recommended answers where possible (concrete options help users think faster)
- Distinctive: line 58
After each answer, reassess remaining coverage gaps
- Distinctive: line 59
Stop when all critical categories (Problem, Scope, Functional) are covered, even if other categories have gaps
- Distinctive: line 61
Ask 1-3 questions at a time (not all 10 upfront)
- Distinctive: line 66
Never ask obvious questions -- demonstrate understanding of the domain by making informed assumptions and asking about the non-obvious …
- Distinctive: line 70
After the interview completes (all critical categories covered, user says "done", or 10 questions reached):
- Distinctive: line 72
Create the feature directory if it doesn't exist:
- Distinctive: line 90
When invoked during a planning session (strategic, operational, triage) rather than the standard pre-design flow:
- Very specific: line 100
When discovery.md already exists:
- Distinctive: line 103
Ask the user what has changed or what gaps they want to address
- Very specific: line 108
Update discovery.md in place (preserve existing content, add/modify sections)
- Distinctive: line 113
Keep the interview conversational but structured -- don't make it feel like a form
- Distinctive: line 115
Every answer should move the understanding forward -- don't ask for information you can infer
- Very specific: line 117
Do NOT generate design.md -- that is the design skill
- Very specific: line 118
Do NOT generate tasks.md -- that is the tasks skill
- Distinctive: line 119
Never modify files outside the feature's spec directory
“Common” is measured: kept by at least 6 in 10 of the 80 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Coco Interview Skill
Conduct a structured pre-design interview to gather deep user intent, constraints, and context before generating a feature design. Produces a discovery brief that feeds directly into the design skill.
When to Use
- Pre-design discovery for Standard-tier features (before invoking the
designskill) - Deep-dive during any planning session (strategic, tactical, operational, triage)
- Natural language requests ("interview me about this feature", "let's discuss requirements")
- When
/coco:phaseor/coco:planning-session tacticalroutes to Standard tier
Do NOT use for:
- Trivial-tier features (use
hotfixskill directly) - Light-tier features (skip interview, use
designin light mode) - Features where the user has already provided exhaustive requirements
Setup
- Read
.coco/config.yamlforproject.specs_dir(default:specs). - Determine the feature from conversation context:
- If a feature name or description was provided, use it
- If on a
feature/*git branch, extract the feature name - If none of the above, ask the user what feature to discuss
- Determine the feature directory:
{specs_dir}/{feature-name}/ - Load the discovery template from
.coco/templates/discovery-template.mdif it exists, otherwise use${CLAUDE_PLUGIN_ROOT}/templates/discovery-template.md. - Check if
{specs_dir}/{feature-name}/discovery.mdalready exists:- If yes, enter refinement mode (see below)
- If no, proceed with fresh interview
Execution
Category Progression
The interview covers these categories in order, adapting based on what the user has already provided:
- Problem & Motivation -- What problem does this solve? Who feels the pain? Why now?
- Users & Personas -- Who are the target users? What are their goals and skill levels?
- Scope & Boundaries -- What's explicitly in scope? What's out of scope? MVP vs future?
- Functional Requirements -- What are the core behaviors? What are the key user flows?
- Technical Context -- What existing systems does this interact with? Any constraints?
- UX & Interaction -- What does the user experience look like? Key screens/flows?
- Non-Functional Requirements -- Performance, security, accessibility, scalability?
Question Strategy
Before asking any questions, analyze the user's initial feature description and any context from the current conversation. Determine which categories already have sufficient detail.
Rules:
- Use AskUserQuestion with recommended answers where possible (concrete options help users think faster)
- Skip categories where the initial description already provides sufficient detail
- Maximum 10 questions total across all categories
- Accept "done" or "skip" from the user to terminate early
- After each answer, reassess remaining coverage gaps
- Stop when all critical categories (Problem, Scope, Functional) are covered, even if other categories have gaps
- Prioritize questions by: scope-defining > ambiguity-resolving > nice-to-have
- Ask 1-3 questions at a time (not all 10 upfront)
Question format guidelines:
- Multiple-choice: Provide 2-4 concrete options with a recommended choice. Include descriptions explaining tradeoffs.
- Open-ended: Only when the space of answers is too broad for options. Keep the question specific and bounded.
- Never ask obvious questions -- demonstrate understanding of the domain by making informed assumptions and asking about the non-obvious aspects.
Output
After the interview completes (all critical categories covered, user says "done", or 10 questions reached):
- Create the feature directory if it doesn't exist:
mkdir -p {specs_dir}/{feature-name} - Fill the discovery template with structured findings from the interview.
- Write to
{specs_dir}/{feature-name}/discovery.md. - Report:
- Discovery file path
- Categories covered vs skipped
- Key decisions captured
- Open questions remaining (if any)
- Suggested next step: tell the user to ask Claude to "design this feature" (this triggers the
designskill automatically -- skills are NOT slash commands, so never suggest/coco:design)
Planning Session Context
When invoked during a planning session (strategic, operational, triage) rather than the standard pre-design flow:
- Output the discovery brief inline into session notes instead of (or in addition to) writing
discovery.md - Adapt category progression to the session context:
- Strategic: Focus on Problem & Motivation, Scope & Boundaries, Technical Context
- Operational: Focus on the specific blocker -- narrow to relevant categories only
- Triage: Focus on Problem & Motivation, Scope & Boundaries (enough to score)
Refinement Mode
When discovery.md already exists:
- Load and display a summary of the existing discovery brief
- Ask the user what has changed or what gaps they want to address
- Focus questions on:
- Categories marked with open questions in the existing brief
- New information or changed requirements
- Areas the user specifically wants to revisit
- Update
discovery.mdin place (preserve existing content, add/modify sections) - Append to the Change Log at the bottom:
{date} | Refinement | {summary of changes}
Guidelines
- Keep the interview conversational but structured -- don't make it feel like a form
- Make informed assumptions based on context and industry standards; verify only non-obvious choices
- Every answer should move the understanding forward -- don't ask for information you can infer
- The discovery brief is a living document -- it can be refined as understanding deepens
- Do NOT generate design.md -- that is the
designskill - Do NOT generate tasks.md -- that is the
tasksskill - Never modify files outside the feature's spec directory
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

