/craft-prompt

name: craft-prompt
description: Advanced surface, separate from Foreman's core roadmap job — a standalone prompt builder for work that has no roadmap entry behind it. Guides you through assembling a self-contained spawned-session prompt following Foreman's template — asks which optional sections to include, gathers required info via AskUserQuestion, assembles the XML, then runs it here as one or several tracked tasks, hands it to a background Agent, or copies it to the clipboard.
when_to_use: Trigger only on an explicit request to build or refine a standalone prompt — "craft a prompt", "build a prompt", "write me a prompt", "refine this prompt", "foreman prompt", or invokes /foreman:craft-prompt. An ordinary work request is not one of those: wanting something built, tracked, or handed to a background agent is roadmap work — it goes to the `foreman` entrance, which picks or adds the entry and builds the handoff itself.
argument-hint: "<brief task description — optional seed>"
allowed-tools: AskUserQuestion, TaskCreate, TaskUpdate, Agent, Read, Write, Bash, PowerShell

foreman:craft-prompt — interactive prompt builder

Advanced tool, separate from Foreman's core job. Ordinary work goes through the `foreman` entrance, which builds its own handoff out of the roadmap entry. This skill is for the case with no roadmap entry behind it: a standalone prompt, asked for explicitly. The spawned session has zero memory of this conversation — every field must be filled so it can act cold.

If args were provided, treat them as the task description seed and skip asking for it in Call 1.

---

Call 1 — task type, optional sections, starting point, and flavor

Ask these four questions together:

**Q1** — "What task should the spawned session perform?" Options: `Implement a feature`, `Fix a bug`, `Investigate / research`, `Refactor code`

**Q2** — "Which optional sections do you want in the prompt?" (multiSelect: true) Options:

• `Tone` — override the default (minimal/professional, silent-by-default — see the template; projects opt out entirely via `omitSections: ["tone"]`)
• `Example` — a before/after or input→output snippet (good for fixes and transformations)
• `Constraints` — hard limits on files or interfaces the agent must NOT touch
• `Background context` — architectural decisions, patterns, or environment details

**Q3** — "How well do you know this part of the code?" Options:

• `I know it well` — I can name what should change and what must not.
• `I know the goal, not the code` — I know what I want; this area's shape

is new to me.

• `This area is new to me` — I could not yet say what a good answer looks

like here.

**Q4** — "Is this prompt a Workflow `agent(prompt, {schema})` stage?" Options:

• `No` — an ordinary prompt.
• `Yes` — prompt plus a JSON Schema the tool layer enforces (mechanically

omits `Tone` and replaces the default output format with a fixed enforcement sentence — see the template)

Q4 is a flavor, not an optional section: it changes how every block is rendered rather than adding one. `Yes` overrides a `Tone` selected in Q2.

Record which optional sections were selected.

Q2 asks what the user *wants* in the prompt, not what's *true* about the code — no amount of upfront code investigation answers it, so don't skip it even when you've already grounded every fact the prompt will state. Investigation and section selection are orthogonal: being confident about the code is not the same as knowing which sections the user wants included.

Q3 is a starting-point line, not a section: it changes what the assembled prompt says, never which blocks it carries. There is no new judgment field — every answer below lands in `judgment.context` or `judgment.steps`, which the assemble step already carries.

• `I know it well` — nothing is added.
• `I know the goal, not the code` — add one `judgment.context` line:

"Starting point: the user knows the goal but not this area's code, so the file list and steps below are a best guess at its shape, not a survey of it."

• `This area is new to me` — say in one line that a blind spot pass here is

cheaper than a wrong prompt, and offer to run one in this session before crafting. A cold session cannot teach an absent user, so the pass belongs here, not in the prompt. If the user takes it, its answers feed Call 2's files and steps and Call 4's background context, and Q3 is re-read as `I know the goal, not the code`. If the user declines, add the context line above plus one first `judgment.steps` bullet: "Before making changes, do a blind spot pass on this area: name the unknown unknowns — the questions this task should have answered, what good looks like here, prior work already done, and the potholes — and report them. Then proceed with the conservative reading."

Word that bullet with **name** and **report**, never "explain your reasoning": the gate warns on a prompt that asks the destination to echo its reasoning, and the warning is real — it can trigger a refusal on a Fable-class model.

---

Ground the file options (one Explore pass, before Call 2)

Call 2's Q3 is the one answer that has to produce a real path, and a hand-typed path pointing at the wrong file is exactly the failure `truth_grounding` spends the destination's tokens rescuing. Ground the question instead of asking it cold: dispatch **one** `Explore` agent now, before Call 2, and turn what it finds into the options.

Give it Call 1's request verbatim and ask for four things back:

• up to three candidate file lines, each `path — the symbols that matter`
• the project's test command, written the way it would actually be typed
• one file that already does something similar, for the `Pattern:` line
• one way this project can be *driven or looked at*, when it has one — a

skill under `.claude/skills/`, a script, a fixture harness. It has to clear three bars, all of them: it runs unattended, it exits on its own, and it does not rewrite the thing it