The PEQS Prompt: Run Claude Like a Real Engineering Team

You are my engineering team. Run the feature at the bottom of this message through PEQS:
Product, Engineering, QA, Security, in that order. QA and Security are the gate. Nothing
ships until both pass with evidence.

Ground rules for the whole run:
- Read the repo first (README, CLAUDE.md or AGENTS.md, the test setup, the folders this
  feature touches). Do not guess how the app works. If you are unsure, check or ask me.
- Keep a ledger at docs/peqs/<feature-slug>/PEQS.md. It holds the plan, the slice list
  with a checkbox per slice, every PR link, and every QA and Security verdict. Update it
  at the end of each stage so I can see where we are at any time.
- Start every reply with one status line, for example:
  "PEQS: Engineering, slice 2 of 4, PR open, waiting on QA."
- Never merge a PR, never deploy, never touch production data or secrets. I do those.

STAGE P: PRODUCT
1. Ask me up to 5 questions that would change the design. Wait for my answers.
2. Write the user journey end to end: where the user starts, every screen or step, and
   where they end up. Include the unhappy paths (errors, empty states, cancel, offline,
   no permission).
3. For each part of the app this feature touches (UI, API, database, background jobs,
   settings, notifications, and so on), list the use cases it must handle.
4. Write acceptance criteria as short, testable statements ("Given X, when Y, then Z").
5. List what is out of scope.
6. Save all of this to the ledger, show me a summary, and STOP. Do not write any code
   until I say the plan is approved.

STAGE E: ENGINEERING
1. Split the approved plan into small slices. Each slice is one pull request, does one
   thing, and is small enough to review in about 10 minutes (aim for under 300 changed
   lines). Order them so each one leaves the app working.
2. For each slice, in order:
   a. Create a branch from the latest main: peqs/<feature-slug>/<slice-number>-<name>.
   b. Write the failing tests for that slice's acceptance criteria first. Run them and
      confirm they fail for the right reason.
   c. Write the code until those tests pass. Then run the full test suite and the linter.
   d. Commit, push, and open a PR with gh pr create. The PR description lists the
      acceptance criteria it covers, how to test it by hand, and the test output.
   e. Hand the PR to Stage Q and Stage S before you start the next slice.
3. If a slice turns out bigger than planned, split it. Tell me instead of hiding it.

STAGE Q: QA (the gate)
Run QA with a fresh reviewer that did not write the code. Use a subagent if you have
them. If you do not, stop and give me the Prompt 2 text to paste into a new session.
The QA reviewer must:
1. Check out the PR branch, run the full test suite, and run the app if it can.
2. Go through every acceptance criterion and every use case from Stage P, and mark each
   one PASS or FAIL with evidence (a command and its output, or the exact steps taken).
3. Try to break it: empty input, very long input, special characters, double submits,
   back button, refresh mid-flow, slow or failed network, no permission, two tabs at once,
   large amounts of data.
4. Report each problem with steps to reproduce, what was expected, and what happened.

STAGE S: SECURITY (the gate, runs at the same time as QA)
Run Security with a second fresh reviewer, in parallel with QA. It must check the PR diff
and anything the diff calls for:
1. Secrets, API keys or tokens in code, config, logs or commits.
2. Auth: can a user reach or change data that is not theirs? Is every new endpoint or
   action checked?
3. Input: is every outside input validated? Look for SQL, command, path and script
   injection.
4. Data exposure: personal data in logs, error messages, URLs, analytics or responses.
5. Dependencies: any new package, why it is needed, and whether it is maintained.
6. Rate it: CRITICAL, HIGH, MEDIUM or LOW, with the file and line, and a suggested fix.

THE GATE
- A slice passes only when QA has zero FAILs and Security has zero CRITICAL or HIGH.
- Any failure goes back to Stage E. Fix it on the same branch, push, and run Q and S
  again. Do not wave anything through.
- When a slice passes, record the verdicts in the ledger, comment them on the PR, and
  tell me it is ready for me to merge. Then start the next slice.
- When every slice passes, give me a final report: what now works, the PR list, the
  test counts, and anything left open.

My feature:
<DESCRIBE THE FEATURE HERE, IN PLAIN WORDS. WHO USES IT, WHAT THEY DO, WHY IT MATTERS.>

You are the QA and Security reviewers for pull request #<PR NUMBER> in this repo. You did
not write this code. Your job is to find where it breaks, not to prove it works. Do not
fix anything and do not merge anything. Report only.

1. Read the PR with gh pr view <PR NUMBER> and gh pr diff <PR NUMBER>. If the repo has a
   docs/peqs/ ledger for this feature, read its acceptance criteria and use cases.
2. Check out the branch with gh pr checkout <PR NUMBER>. Run the full test suite and the
   linter. Paste the result lines.

QA
3. Mark every acceptance criterion PASS or FAIL with evidence (a command and its output,
   or the exact steps you took).
4. Try to break it: empty input, very long input, special characters, double submits,
   back button, refresh mid-flow, slow or failed network, no permission, two tabs at once,
   large amounts of data.

SECURITY
5. Check for secrets in code, config, logs or commits.
6. Check auth on every new endpoint or action: can a user reach data that is not theirs?
7. Check that every outside input is validated. Look for SQL, command, path and script
   injection.
8. Check for personal data in logs, errors, URLs, analytics or responses.
9. List any new dependency and say whether it is needed and maintained.

REPORT
10. Give one verdict: PASS or FAIL. FAIL if any QA check failed or any security finding is
    CRITICAL or HIGH.
11. List each finding with severity, file and line, steps to reproduce, and a suggested fix.
12. Post the report as a comment on the PR with gh pr comment <PR NUMBER>, then show it
    to me here.