A Claude Agent Skill that interviews the client before writing a project brief for development. It turns a vague request — "I want an app that…" — into a written brief someone can actually build from: the problem, the goals, what has to work in the first version, what's deliberately out, user stories, requirements, acceptance criteria, and a table of every question still open. Requirements gathering and product discovery, in Claude Code or claude.ai.
The brief contains only what the client actually said or confirmed. Everything else becomes an open question instead of a plausible-looking guess.
A bad brief is not an empty one. A bad brief is full of decisions that nobody in the room actually made — a developer's assumption, an analyst's default, an AI's tidy invention. They read as requirements, nobody challenges them at the start, and three weeks later the wrong thing has been built. The client pays for the rework.
So this skill spends its effort on finding out rather than on writing. The document comes last, and anything unconfirmed is marked as unconfirmed.
| Section | What goes in it |
|---|---|
| Problem | What's wrong, for whom, how it's handled today, what it costs to leave alone |
| Goals | What the client wants to achieve, in their words |
| Priority | What must work in the first version, ranked by the client |
| Non-goals | What's consciously out of scope, and why |
| Users and user stories | By role, including the exception and error cases |
| Requirements | Fixed constraints, stated rules, acceptance criteria, the client's own terms |
| Open questions | Each with who owes the answer and whether it blocks the start of work |
| Assumptions | What the brief treats as true but nobody verified |
Questions come one at a time, in plain language, for 20–40 minutes. Three things make the difference between this and a questionnaire:
- Conflicts get named out loud, while the client can still act on them. "Everything in the first version" and a fixed budget cannot both hold. The skill carries a catalogue of the pairs that come up again and again, says both halves back, and asks which one gives — without picking for the client.
- It knows when an answer isn't an answer. "Sounds good", "something simple", "probably", "about 10,000 users" — each has a specific follow-up, and none of them ends up in the document as a decision.
- It has a short path for people in a hurry. Ten minutes gets exactly three questions and a brief whose gaps are visible, rather than forty minutes of questions the client abandons halfway.
It produces a brief, not a technical specification and not an estimate. No stack, no architecture, no platform choice, no invented metrics, no phases. Those decisions belong to whoever builds the thing — and a brief that pre-empts them hands a contractor requirements the client never set.
As a plugin (Claude Code), through the time2map marketplace:
/plugin marketplace add time2map/skills
/plugin install brief-interview@time2map
As a plain skill: copy skills/brief-interview/ into ~/.claude/skills/ (for yourself) or .claude/skills/ (for a project).
On claude.ai: add the contents of skills/brief-interview/SKILL.md as a skill in your settings.
Describe what you want built, and let the questions come:
I want a mobile app so clients can book my studio themselves instead of DMing me
Or call it by name: /brief-interview.
The interview runs in whatever language you write in; the skill itself is in English.
Alexander Semenov — time2map.com
MIT licensed. If it saves you an argument three weeks into a project, it did its job.