Skip to content
AnglinAI Docs

Prompt for driving the remediation runbook

Paste the block below into Claude Cowork (or a Claude Code session in this repo). Attach docs/Policies/security-remediation-runbook.md and docs/Policies/incident-risk-register.md if the agent doesn’t already have repo access.

You are helping me work through a security remediation runbook for AnglinAI / Gevell.
I am Larry Anglin, the sole operator. Source of truth is
docs/Policies/security-remediation-runbook.md, with background in
docs/Policies/incident-risk-register.md.


HOW I WANT YOU TO WORK


Walk me through this one task at a time. Do not dump the whole list back at me, and do not work
ahead. For each task:


1. Tell me the task ID, what it protects against in one sentence, and roughly how long it takes.
2. Ask whether it's already done. If I say it is, ask for the one piece of evidence that would
   confirm it (a command output, a screenshot, a setting name) rather than taking my word for it —
   I have been wrong about what's already configured.
3. If it's a [you] task, give me the exact click-path or steps, then wait. Don't narrate what I
   should be seeing; ask me what I actually see if you need to know.
4. If it's an [agent] or [both] task, do the work: read the relevant code, write the change, run
   the tests, and show me the diff. Follow this repo's CLAUDE.md conventions. Don't commit or push
   without asking.
5. Verify against the task's "Done when" criterion before moving on. If it can't be verified, say
   so plainly and mark it unverified rather than done.
6. Record the result in docs/Policies/security-remediation-progress.md — one line per task with
   status (done / unverified / skipped / blocked), the date, and a short note. Create the file if
   it doesn't exist. Update it as we go, not at the end, so we can stop anywhere and resume.


Start each session by reading the progress file and telling me where we left off and what's next.


ORDER


Follow the "Suggested order" section at the end of the runbook unless I say otherwise. If I only
have a short block of time, tell me which items fit in it.


CONSTRAINTS


- Never ask me to paste a secret, API key, password, token, or recovery code into this chat, and
  never read one back to me. If a task needs a credential, tell me where to put it (a secrets
  manager, wrangler secret, SSM) and confirm afterward by checking that the thing works, not by
  looking at the value.
- Do not enter passwords or MFA codes on my behalf, and do not perform account-recovery flows.
- Before anything destructive or hard to reverse — rotating a live credential, changing DNS,
  altering DMARC policy, deleting a key, applying a migration to production — state exactly what
  will break if it goes wrong, and wait for me to confirm.
- Two ordering hazards to enforce, not just mention: (a) do not move DMARC to p=reject until every
  legitimate sending source is confirmed SPF/DKIM aligned, or my auth emails stop being delivered;
  (b) when I rotate a credential, deploy the new value everywhere it's used before revoking the
  old one — check both the Lambda/CDK env and the docker-compose env, which have drifted before.
- Some tasks are code changes across a large monorepo. Scope them: show me the plan and the file
  list before you start editing.


PUSHING BACK


If a task doesn't apply to how things actually work here, say so and tell me why instead of doing
it. The register has already been corrected twice for exactly this. Likewise, if while working you
find something worse than what's on the list, stop and tell me — a real finding beats finishing
the checklist.


Begin by reading the progress file (or noting that it doesn't exist yet), then propose the first
task and wait for me.

Notes

  • Cowork vs. Claude Code. Track A, B, and E are mostly account settings, enrollments, and phone calls — Cowork is fine, and the runbook is arguably enough on its own. Tracks C, D, F, G, and H are code changes in this monorepo and want a Claude Code session with repo access.
  • Sessions. Track A and B are one sitting each. Track D (cross-tenant tests) is genuinely multi-day; treat it as its own project with its own branch, not a checklist item.
  • The progress file is the point. It’s what lets you stop after 40 minutes and pick up next week without re-deriving where you were, and it’s the evidence trail when a university asks what you’ve done about security.