# Prompt shapes

Skeletons for the prompts HQ writes most. Every one is issued complete, in a code block, labeled for its surface. Fill the brackets, never leave them. Every prompt opens with the chat name, the repo, "read only what you need, no whole-repo loads," and the commit gate, and closes with "Completed / Still needed block and a handoff note."

## Common header

```
Chat: <Client> · <Task> M/D. Repo: <your repo URL>, <branch>. Read only what you need, no whole-repo loads. Do not commit or push until I approve the deliverable in this chat.

Context: <two to five sentences: who asked, what was decided and where (call, chat, task tracker), what is due and when, who is out>.
```

If no repo is involved: "A repo is attached only because this interface requires one. Do not read from it or write to it."

If the work may touch a blocked domain: "If <domain> is blocked from this session, stop and tell me; I will attach the files."

## 1. Read-only context brief

Use when you are dropped into an engagement or need to know what the record holds before you engage.

```
Do not build anything.
1. Repo shape: root files, every project folder, key apps, analyses headers. One line each.
2. Read <the two documents that define scope>. Summarize scope, workstreams, milestones, dates, owners in ten lines.
3. Call recordings: every <client> call by date, title, attendees. Read the two most recent in full. Note every open commitment and who owes it.
4. Task tracker: the <client> list and chat. Open tasks, owners, due dates, last five messages.
5. Search repo, call recordings, and the task tracker for "<term>" and "<term>." Report what exists and what does not.
6. One-screen brief: the engagement today, people on every side, delivered, in flight, owed and by whom, what the record says about my role. Save as docs/context-brief-YYYY-MM-DD.md on branch claude/context-brief, no PR.
7. Numbered list, five lines at most, of what the record cannot answer and only <person> can. Label it "For <person>, [chat tool]."
```

## 2. Build with approval gate

Use for any client-facing or public-facing page, portal, deck, or doc.

```
Do this:
1. <read the inputs>
2. <build step>
Show me before anything is committed: <screenshot of the page / the full text / the rendered route at 1920x1080>. I approve or change it here.
After my approval: build and lint clean, push to branch claude/<task>, open a PR into <default branch> in your team's format with Completed / Still needed (<list the known Still needed items>). Do not merge. Confirm whether your deploy target picks the merge up automatically or needs a manual redeploy. Draft a two-line task-tracker comment for the <client> task with the PR link and equivalent-work figure. I post it.
```

## 3. Two-phase plan then build

Use when the target is uncertain (a generalization, anything that could collide with existing work).

```
Phase 1, plan only, stop and wait for my yes:
1. Read one existing example of the pattern end to end so the new work matches conventions.
2. Locate <the thing being generalized>. List every hardcode.
3. Check for anything already in the repo or in open PRs that overlaps. If it exists, stop and ask before writing anything.
4. Proposed layout on one screen. Keep phase 1 to one screen.

Phase 2, after my yes, switch to <your build-tier model>:
5. Branch claude/<task> from <default>. Build.
6. Run the existing suites plus any you add. Green before you open anything.
7. PR in your team's format. Do not merge.
8. Two-line task-tracker comment for <the right internal list>.
```

## 4. Rebase or conflict cleanup

```
State: <which PRs merged, which show conflicts, which are your reviewer's and which are yours>.
Do this, in order, one PR at a time:
1. #<n>. Rebase onto <default>. Show me each conflict and how you resolved it before pushing. After the rebase, check for duplicate imports or switch cases git did not flag, and for renames that lived only in merge commits. Run every suite and the check scripts. Green, then force-push with --force-with-lease.
2. #<m>. First tell me who opened it and what it changes. Then the same.
3. Report the merge order that now works, one line per PR.
4. Two-line task-tracker comment with the PR links.
```

For a PR that belongs to someone else: push only if they reported the conflict, with --force-with-lease, and your reply to them says what changed.

## 5. Rollback to a known version

```
Phase 1, plan only:
1. Find <person>'s last commit before this week's PRs. List every commit since, one line each, classed as content, data, or fix.
2. Diff current <file> against that commit. List what was added.
3. Identify the fix to keep exactly (files and lines).
4. Find every place <the removed thing> touches: slides, imports, generated files, scripts, routes. Say what leaves and what stays as data.
5. Propose the new home for <the moved thing>, checking existing patterns in the app first.
6. One-screen plan: rolls back, kept, moves, risks.
Phase 2 on <your build-tier model> after my yes. Before you push: show me <the list of what remains>, the diff against the baseline (must be only the kept fix), and a screenshot of <the new route>.
```

## 6. Verification pass (a browser-capable session)

Use when a coding session produced a draft from indexed text and the real sources are on a blocked domain.

```
<Task> verification pass. The draft below came from a session that could not open <domain>; section 1 is verified, sections 2 through 4 need checking against the real documents. Do not redo the work, verify it and finish it.

===== DRAFT START =====
<paste the full draft>
===== DRAFT END =====

Do this:
1. Open <the live page> in the browser. Confirm the catalog, fill missing URLs, note anything on the page not in the draft.
2. Open and read <the documents> in full, tables and figures included. Correct the draft where the indexed text was wrong.
3. Reread the recommendation against what you saw. Keep it or change it, and say which.
4. Strip every "unverified" marker you have verified.
5. Save as <filename>. Give me the file, no attaching. Two-line task-tracker comment to post. One-paragraph summary I can read in under a minute.
```

## 7. Plan reconciliation

Use when an older plan may have been overtaken by the repo.

```
Read the plan from <branch or doc>. List its units. For each, check current <default> plus open PRs and classify: built (where), partly built (what is missing), superseded (what replaced it and why the plan's version should not be built), still net new. Note where the plan's assumptions are now wrong. Write docs/<plan>-reconciliation-YYYY-MM-DD.md: one-screen status table (unit, status, evidence link, what remains), then decisions only <person> can make. No recommendations on build order. Do not open a PR.
```

## 8. Assessment for ops (Claude versus not-Claude)

Use when a colleague asks whether something should be an automation, a Claude skill, or a scheduled job.

```
Inventory the shape, not the contents. Propose the destination convention. Evaluate the options against your existing stack (<list>): what each handles, how it deals with <the hard object type>, monthly cost at your volume, setup effort and who does it, who maintains it day to day given <access constraint>, failure mode and who notices. Recommend one. If the answer is not Claude, say so plainly. Write the findings as <path> under two screens. Draft a message for <colleague>, five lines at most, labeled "For <colleague>, [chat tool]": recommendation, owner, cost, next step, and that <approver> gets a look before anything is built.
```

## 9. Update to the reviewer

```
Yes, all of them plus <repo>. Here is where it all sits.

**<Client>**
<two to four sentences with every link>

**<Repo>**
<what is open, what they merge, what is running>

**From you**
- <ask>: <where they answer it, as a link or "reply here">
- <ask>: <link>
```

## 10. Short thread reply

Two to four lines, the fact and the link, no preamble. Example: "Rolled back to your last version plus the fix we agreed on, the extra feature moved to its own page behind the password we discussed. PR to merge: <link>"

## 11. Stop message

When a session is burning context on plumbing:

```
Stop. Do not attach anything. Paste <what it has> as plain text here, marked as unverified where you could not open the source. I am moving <the rest> to a surface that can <do the blocked thing>.
```

## 12. Pause message

When a task pauses across days:

```
Pausing until <day>. Before you stop: <one to four settled decisions as instructions>. Write a handoff note so a fresh chat can run steps <n> through <m>: what is approved, what is in the scratchpad, what is committed, the QC findings so far.
```