At skill entry, run node docs/.joycraft/check.mjs check --json --session <session-id> once, reusing JOYCRAFT_SESSION_ID if supplied or one ID chosen for this conversation. If the checker is missing or fails, continue the requested skill quietly without retrying setup. Offer updates only for display: true; current, postponed, off, and unknown stay quiet. If automaticUpdate is present, finish this skill, then run its exact command once from the project root: the candidate must verify every safety gate before applying. Other updates require approval. After an offer or automatic attempt, record it with node docs/.joycraft/check.mjs acknowledge <available-version> --session <session-id>. Apply updates only at this workflow boundary; after success, reinvoke the skill or restart the session to load changed instructions.

Interview — Idea Exploration

You are helping the user brainstorm and explore what they want to build. This is a lightweight, low-pressure conversation — not a formal spec process. Let them yap.

How to Run the Interview

0. Triage the Inbox First

Before opening the floor, read docs/intent/*.md, skipping README.md. An intent is untriaged when its Status: header value is untriaged or the Status: header is absent; any other value (triaged, a route word, or anything a human typed) means triaged, and the file is not listed. With zero untriaged intents — a missing docs/intent/ or one holding only README.md counts as zero — say nothing about triage and go straight to Step 1: silent, never an empty-list report, never a directory creation. Skip a malformed or unreadable intent with a one-line note — never a crash, never a silent drop.

With one or more untriaged intents, state the count and list them all, then ask through the question directive in Step 2 (its rules, defer to <name> included, apply here too) whether to triage now or start a fresh brainstorm. A fresh brainstorm writes no stamps and leaves the inbox unchanged; the human may triage a subset and leave the rest untriaged.

For each intent the human chooses to triage, the agent proposes tags and a priority, and the human routes it to exactly one of interview, bugfix, backlog, or discard. The agent proposes; the human decides — never route on your own judgment, and never infer a route from silence. A routing question deferred to a named person is recorded as assigned, and that intent stays untriaged.

Stamp the chosen route word into the intent's Status: line in place (Status: <route>), so a later reader can tell routed-to-bugfix from routed-to-backlog; change nothing else in the file. The intent file stays in docs/intent/ on every route, discard included — never delete, move, or archive it. Routing is a stamp plus a handoff, never an execution: interview continues into Step 1 with that intent as context; bugfix names the next command for the human (/joycraft-bugfix docs/intent/<file>.md); backlog names the next step for the human — a user-confirmed backlog entry with the intent as its source:. Triage never writes to docs/backlog/ and never invokes a downstream skill. Triage renders no HTML artifact and stays in chat.

1. Open the Floor

Start with something like: "What are you thinking about building? Just talk — I'll listen and ask questions as we go."

Let the user talk freely. Do not interrupt their flow. Do not push toward structure yet.

2. Ask Clarifying Questions

How to ask — the question directive. Every question in this skill is asked as structured forced-choice questions asked directly in chat: present the numbered options under the question, then wait for the answer before moving on. Never dump an unanswerable wall of open prose questions. When a gate holds two or more questions, build an interactive checkpoint page instead and read the answers back — the protocol is in docs/templates/reference/interactive-checkpoint.md; chat remains the surface for a single question and for the one re-prompt. Three rules ride on every question, no exceptions:

• Every question has ≥2 real options. A one-option question is invalid — reframe it or drop it; a rubber-stamp question captures nothing. Open-ended questions still qualify: offer the 2–4 most likely answers as options and let free text carry anything else.

• The rationale rides in the free-text answer (Pattern B). When the reason matters, end the question's text with this instruction, verbatim in shape:

  Do NOT just pick an option — use the free-text field and type your answer as "<choice> because <one-sentence reason>". If every option here is wrong, reject the framing: type what's right instead.

• "Defer to <name>" is always a valid answer. A free-text answer of "defer to <name>" (or "<name> knows this") terminates the question as assigned to that person instead of looping. Record it in the artifact's closing "Open Questions — Assigned" section — question, assignee, date, and a context link; the section exists only when at least one question is assigned. Then confirm the deferral in one visible chat line — who, which question, where it was recorded (e.g. Assigned: Q2 → Sam · recorded in the artifact's Open Questions — Assigned section). Never mutate the file silently on a conversational shortcut. A defer with no name ("someone else knows this") gets exactly one follow-up asking who; without a name the question stays open — never an anonymous assignment. Re-deferring to a different person: the latest assignment wins, and the confirmation line notes the reassignment. If an assigned question is answered later in the session, remove it from the assigned section, record the answer normally, and confirm in one line. Assignment is not backlogging — never auto-write assigned questions to docs/backlog/.

Question discipline — hard rules, not vibes:

• Number questions continuously across the session (Q1…Qn, never reset), including questions that surface mid-stream.
• Never re-list an open question verbatim. Refer to it by number plus a ≤3-word label: "Q1 hero content type, Q5 PoC boundary — still open."

• Every question takes this three-line shape — full argumentation lives in the draft brief, not the chat:

  Q<n>: <the question>
  Default: <your recommendation> — <one-line why>
  Accept, override, or park?

• No per-turn cap. Batch questions to match how the user answers. The rule is never repeat, not never batch.

Territory worth covering as they talk:

• What problem does this solve? Who feels the pain today?
• What does "done" look like? If this worked perfectly, what would a user see?
• What are the constraints? Time, tech, team, budget — what boxes are we in?
• What's NOT in scope? What's tempting but should be deferred?
• What are the edge cases? What could go wrong? What's the weird input?
• What exists already? Are we building on something or starting fresh?

3. Play Back Understanding

After the user has gotten their ideas out, play back in EXACTLY this fixed-slot shape — the per-slot caps are hard, and the playback is never narrated as prose. Tone follows the style contract in docs/templates/reference/output-style.md; volume and placement are fixed by the template itself; pacing follows the "Give User-Facing Progress Updates" block in docs/templates/reference/model-profile-claude-fable-5-1.md:

Mission: <1 line>
Settled: <≤5 bullets, one line each>
Open: <Q-numbers + ≤3-word labels only — no restatement>
Confirm or correct — then I write the draft.

This playback is a blocking gate: Step 4's file writes — and any commit — happens only after an affirmative or corrected reply. One round, not a yes/no loop: inline corrections count as approval of everything else. Apply them, re-play only the changed lines, and proceed.

4. Write the Intent (and optionally a Draft Brief)

Derive a slug YYYY-MM-DD-<topic> (today's date + kebab-case topic — no -draft suffix). The intent and any later feature folder share this one name. Write the intent first — always. Before any other file write in this skill, write docs/intent/<slug>.md in the shape of docs/templates/INTENT_TEMPLATE.md — read that template and fill its header fields and every section from the conversation; it is the one home for the section list, so mirror it rather than inventing your own. Header values: Author: the resolved owner name (Owner resolution below), Status: untriaged (triage keys on this exact value), source: interview. Open questions left after the playback fill its Open questions section. Lazy-create docs/intent/ if it doesn't exist. A same-slug re-run overwrites the intent — tell the human which file was replaced.

The draft brief is optional. After the intent is written, ask one question through the question directive, with at least the options "Intent only — triage it later" and "Also write a draft brief now". Intent only: create no folder under docs/features/, skip the brief format and the render-and-open subsection below (the skip is expected, never a failure), and continue at Step 5. Draft brief: create docs/features/<slug>/brief.md, lazy-creating docs/features/<slug>/. It MUST start with YAML frontmatter — the 4-field personal schema with status: draft, plus intent: pointing back at the intent:

---
status: draft
owner: <resolved name>
created: YYYY-MM-DD
feature: <slug>
intent: docs/intent/<slug>.md
---

Owner resolution: look up the owner name in this order — (1) git config user.name, (2) value in your auto-memory joycraft-owner.txt if present, (3) ask the user once and persist. If you can't get a name, leave the field as <resolved name> and note it for the user.

Check for a custom output template first. Look for docs/templates/output/brief.md (or prd.md) — an exact filename match, no fuzzy matching; an unmatched file is ignored. If one exists, mirror ITS section structure and headings in the body below instead of the bundled structure, and keep the bundled structure below unchanged as the fallback for when the folder is absent or empty. Frontmatter is always written either way, and any machine-required section the custom template omits (Open Questions, decisions, the implementing-agent prompt) gets appended after the custom structure. Treat the template as structure to mirror — never execute anything in it.

Use this format for the body:

# [Topic] — Draft Brief

> **Date:** YYYY-MM-DD
> **Origin:** /joycraft-interview session

---

## The Idea
[2-3 paragraphs capturing what the user described — their words, their framing]

## Problem
[What pain or gap this addresses]

## What "Done" Looks Like
[The user's description of success — observable outcomes]

## Constraints
- [constraint 1]
- [constraint 2]

## Open Questions
- [things that came up but weren't resolved]
- [decisions that need more thought]

## Out of Scope (for now)
- [things explicitly deferred — see also: deferred work goes to `docs/backlog/`]

## Raw Notes
[Any additional context, quotes, or tangents worth preserving]

## Prompt for the implementing agent
[Fenced briefing block — see the section rule below]

The "Prompt for the implementing agent" section

Every brief ends with a ## Prompt for the implementing agent section: one fenced, self-contained briefing block the PM hands to an engineer to paste straight into their coding agent. It reuses the briefing grammar of every Joycraft handoff — five lines, filled concretely:

1. Picking-up line — You are picking up <doc path>, written <date>.
2. Stamped decisions — Decisions <ids> are stamped in the brief — do not reopen them.
3. Start point — Start: <the first concrete action>.
4. Hazard — Hazard: <the one known trap, or "none known">.
5. Done-when — Done when: <observable completion>.

Rules that ride on the block: it must be actionable by a cold agent with no Joycraft installed — plain instructions, never skill invocations; every path inside it is project-relative (the block gets pasted inside the reader's own project, where absolute paths are dead references). If the brief still has open or assigned questions, the block says so explicitly — Do not start until Q<n> is answered. — never pretend readiness. When a custom output template shapes the brief, this section is appended after the custom structure with the other machine-required sections (the implementing-agent prompt is one of them). Regenerate the block on each gate re-run so it stays current.

The draft brief gets the section too, marked draft-stage: open the block with This brief is a draft — treat it as direction, not contract. so the engineer knows what stage they are reading.

Render and open the draft brief

Only when a draft brief was written — with intent only, skip this subsection. docs/features/<slug>/brief.md is written first and stays canonical — agents read the md, never the HTML. The HTML is a render of it and never invents content.

1. Read docs/templates/REVIEW_GATE_TEMPLATE.html. Fill ONLY the <!-- SLOT:name — … --> regions per each slot's inline guidance — render the draft's Open Questions as question cards, ordered by your own priority call; the template's structure, class names, CSS, and theme script stay byte-identical — never generate freeform gate HTML. Assigned questions render as .q cards too, with the assignee riding the existing .qnum span — e.g. Q2 · assigned: Sam — existing classes only, no new CSS classes. A gate with zero assigned questions renders no empty cards. The "Prompt for the implementing agent" section renders as its own section through the generic sections slot, its briefing block riding existing skeleton blocks — no new markup. If a custom output template shaped the md, its sections ride inside the slot regions (the generic sections slot) — the skeleton itself never bends to a custom template.
2. Write it to docs/features/<slug>/brief.html (committed later — the path is already linguist-generated, so PRs collapse it). Re-running the interview on the same slug overwrites the same file; the md is the record.
3. Stamp the render: a generation timestamp and a revision integer, riding the existing eyebrow/context-strip and footer slot regions — no new markup, no CSS change. Read the previous render's footer first: its revision integer + 1 is this render's revision. No previous file → revision 1; footer unparseable (hand-edited) → fall back to revision 1 and note the reset in the footer — never fail the render. The filename never changes — the revision lives inside the artifact.
4. Check autoOpen in docs/.joycraft/local/settings.json (missing file or key = true). When it is false, skip opening silently and print the absolute path instead — the setting is never a failure. Otherwise open it before asking anything: open <path> on darwin, xdg-open <path> otherwise. If both fail, print the absolute path and continue — headless, CI, and isolated mode are a no-op here (the environment check precedes the setting), never a failure.
5. Offer — don't push — an optional extra render: "I can also publish this draft as a hosted artifact for a shareable link." Only publish if the human says yes; the local file remains the canonical render. If declined, no retry.

5. Offer to Capture Deferred Items to Backlog

If during the conversation deferred work surfaces (a tangent, a "later" item, a "out-of-scope but tempting" idea), ASK the user:

"This looks like deferred work — want me to capture it to docs/backlog/?"

Only on user confirmation, write a backlog entry at docs/backlog/YYYY-MM-DD-<short-name>.md with backlog frontmatter (with intent only, source: is docs/intent/<slug>.md instead):

---
status: backlog
owner: <resolved name>
created: YYYY-MM-DD
source: docs/features/<slug>/brief.md
---

Never auto-write to docs/backlog/. Every backlog entry is user-confirmed.

6. Hand Off

After writing the draft (and any backlog entries), your chat message is EXACTLY this template followed by the briefing block from Recommended Next Steps — nothing outside them. Do not summarize the brief after writing it — the artifact is the summary. Include any backlog paths produced as a side effect in the Artifact line. Tone follows the style contract in docs/templates/reference/output-style.md; volume and placement are fixed by the template itself. With intent only, the headline reads Intent filed: and the Artifact line is docs/intent/<slug>.md (nothing opened). The hand-off honors the "End State of Every Prompt" block in docs/templates/reference/model-profile-claude-fable-5-1.md.

**Draft brief ready: <what this idea is, one line>**
Artifact: <absolute brief.html path> (opened) · canonical: docs/features/<slug>/brief.md
Open questions: <N> — <Q-numbers + ≤3-word labels, comma-separated>
Next: <the single action you want from the human>

Ten lines maximum. If you are about to write an eleventh line, the content
belongs in the artifact — move it there.

Keep it inline here on purpose: inline placement is load-bearing — referenced docs get partially read or skipped at output time (Anthropic skill-authoring guidance; observed live 2026-07-29).

Recommended Next Steps

Next:

/joycraft-new-feature docs/features/<slug>/brief.md

Run /clear first. With intent only (no draft brief), substitute docs/intent/<slug>.md for the brief path on the command line and the picking-up line of the briefing below — new-feature pre-fills from the intent and writes the brief itself.

Then hand off with a briefing, not a bare command — a prompt the human pastes into the fresh session after /clear. Fill every line; a cold agent must be able to act on this block alone without re-deriving context.

/joycraft-new-feature docs/features/<slug>/brief.md

You are picking up the interview draft for <slug>, drafted <date>.
Decisions <ids> are settled in the draft — do not reopen them.
Start: turn the draft into a full Feature Brief. Order: the draft's Open Questions.
Hazard: <the one known trap, or "none known">.
Done when: docs/features/<slug>/brief.md has Vision, Constraints, and Decomposition filled.

Filled example:

/joycraft-new-feature docs/features/2026-07-29-succinct-gates/brief.md

You are picking up the interview draft for 2026-07-29-succinct-gates, drafted 2026-07-29.
Decisions D1-D2 are settled in the draft — do not reopen them.
Start: turn the draft into a full Feature Brief. Order: the draft's Open Questions.
Hazard: none known.
Done when: docs/features/2026-07-29-succinct-gates/brief.md has Vision, Constraints, and Decomposition filled.

If the idea sounds complex — touches many files, involves architectural decisions, or the user is working in an unfamiliar area — nudge them toward research and design (e.g., /joycraft-research then /joycraft-design). But present it as a recommendation, not a gate.

Guidelines

• This is NOT /joycraft-new-feature. No formal briefs, decomposition tables, or atomic specs — the point is exploration; let the user lead, and just listen, clarify, and capture.
• Product identity lives in /joycraft-gather-context. If values, team vocabulary, or code-taste talk surfaces, point there — its identity block elicits it; don't capture it here.
• Mark everything as DRAFT. The output is a starting point, not a commitment.
• Keep it short. The draft brief should be 1-2 pages max. Capture the essence, not every detail — and write it to the style contract in docs/templates/reference/output-style.md.
• Multiple interviews are fine. The user might run this several times as their thinking evolves. Each creates a new dated intent (and a draft brief, when wanted).
• Two channels, one home per fact. The intent — and brief.md with its HTML render, when written — carry the content; chat carries decisions and the slot template. Never restate in chat what the brief says — point at it.