intent

Intent: Capture an Idea as an Artifact

Goal: Turn an idea, a ticket, or an incident finding into a committed .temper/specs/{slug}/intent.md with Status: draft — and stop there. This is the entry point for work that isn't ready to build yet: the originator (who may not be the implementer, or an engineer at all) describes the problem in their own words; the committed draft is what a product owner reviews and what /temper later picks up.

/temper's own Intent stage (also when /temper:plan starts the run) still creates intent.md when none exists — this command exists for the capture-now-build-later split, so the idea's author, timestamp, and revision history live in version control from the moment it's real. A draft captured here is exactly what the pipeline's Intent gate later presents for acceptance.

Usage

/temper:intent "handlers spend a third of call time on status-only queries"
/temper:intent "JIRA-4521"      # fetch the ticket, capture it as intent
/temper:intent                  # no argument — interview from scratch

Execution

Enforcement marker. Look at your system prompt for a line that starts with Temper enforcement:. With no such line, make the first sentence of your first reply in this conversation exactly "Temper enforcement is off here (no mods support); continuing with prompt based phases." With the line Temper enforcement: off (UI only), the Temper mod is loaded and the user turned enforcement off: make that first sentence exactly "Temper enforcement is off (turned off by the user); continuing with prompt based phases." instead. Then carry on as written below. Never treat either case as an error and do not mention it again. With Temper enforcement: active, say nothing about it. You state this once, in this conversation: a stage subprocess never has that line in its system prompt, so its brief says nothing about enforcement.

1. Understand the problem, not the solution. Read $ARGUMENTS (tell a ticket key such as JIRA-123, a GitHub issue such as #123 and free text apart). Fetch every source the request links (ticket, MR/PR, doc) read-only and record each under ### Context Sources (consulted: / unavailable: / none:). Then interview with the full question bank — current vs desired behavior, scope and non-goals, acceptance, post-release outcome, blocking vs deferred decisions — and always ask who reviews the intent (the **Reviewer:** header: a name, not a role). Two probes are mandatory: "what business outcome or risk does each criterion address?" (the Why: line) and "who acts on the result, and what happens next?" (the Target Users action chain). Ask only where the uncertainty changes the outcome — no fixed round count, one question at a time, via AskUserQuestion. No formal language is required of the originator; producing structure is your job, not theirs. Write every answer into ### Decisions immediately, as {question} -> {answer} ({who decided}, {date}). Never write card data or personal data into the intent — reference the ticket instead. When a ticket key is linked, prefix the slug with the key as typed ({KEY}-{slug}, for example PROJ-123-login). A slug is letters (either case), digits, '.', '_' or '-', starts with a letter or digit, and has no '..' or '/': /temper later passes it to state init, which refuses anything else. Soft source words: never turn a source "should" or "may" into "must" silently. Ask the originator whether the source means required or optional and record the answer in ### Decisions. With no answer yet, keep the source wording (marked (source: …)) and add a Blocking Open Question.