1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
#+TITLE: No-Approvals Mode
#+AUTHOR: Craig Jennings & Claude
#+DATE: 2026-05-28
* Overview
A mode Craig switches on to drop the approval gates between work items so a pre-agreed batch of tasks runs straight through without "OK to proceed?" interruptions. The mode stays on until Craig turns it off, until a real question arises, until the queue runs out, or until the conversation moves to an unrelated topic.
The point is throughput on work where the approval has already been earned upfront — a queue of tagged tasks Craig triaged, a "do all the =:quick:solo:= ones" sweep, a multi-step refactor with no design calls left. Approval gates earn their keep when judgment is uncertain. They become friction when the decision is already made.
This is *not* a license to skip the engineering discipline that keeps work shippable. Code review, voice pass, testing, and verification all stay on. The gates this mode turns off are the *interaction* gates: "I drafted a commit message, approve?" / "Plan looks like X, OK to start?" / "Ready to push?"
* When to Use This Workflow
Craig activates the mode with any of:
- "no-approvals mode" / "no approvals" / "no-approval"
- "no need for approval gates"
- "stop asking, just keep going"
- "I'll check back in when you're done or stuck"
- "do all =<selector>= with no-approval" (e.g. "do all =:quick:solo:= tasks with no-approval")
- Queuing several tasks in =todo.org= followed by any phrase above
- Any equivalent phrasing that signals he doesn't want to be re-asked between items
Mode resets when:
- Craig says approvals are back on
- A new top-level user message switches the topic away from the batch (assume the mode is scoped to the work it was invoked for)
- A real question or unknown next step is hit (return control to Craig and exit the batch)
- The session wraps up (mode doesn't persist across wrap-up)
* What's Suspended
The interaction gates that step the workflow back to Craig for an "OK to proceed?" check:
- The commit-message gate in =commits.md= Step 2. Print the final commit message inline, then commit immediately. No "approve / request changes / open in editor" prompt.
- The PR-description gate. Print the final body, then create the PR.
- The PR-review-reply gate. Print the final reply, then post.
- "Ready to start?" / "Plan looks like X, proceed?" gates before implementation work begins.
- "Move on to the next task?" gates between items in a queued batch.
- Per-task summary prompts at the end of each item. Give one short result line and proceed to the next.
* What Stays On
The engineering-discipline gates protect quality, not Craig's interaction time. They remain in force:
- =/review-code= against the staged diff before every commit. Critical and Important findings still block. Minor findings still surface. No "proceed anyway" override unless Craig has given it explicitly for this batch.
- =/voice personal= on every publish artifact (commit messages, PR titles + bodies, PR review comments). The full pattern walk happens. The printed result just doesn't wait for approval.
- The full test suite + lint + compile before commit (per =verification.md=).
- Fetch-and-reconcile in =commits.md= Step 0.
- Session Log updates per =protocols.org=. Every state-mutating turn writes to =.ai/session-context.org= before the closing message. The log is the crash-recovery anchor while Craig is away. Missing entries lose work.
- Subagent review-gate cadence (=subagents.md=). Review each subagent's output before the next dispatch.
- Destructive or irreversible operations per =CLAUDE.md='s "Executing actions with care": force-push, =rm -rf=, dropping a column, dropping a branch, package removal. These need explicit consent regardless of mode. No-approvals is for *interaction* gates, not destructive-action consent.
* Workflow Steps
** 1. Acknowledge the mode
Restate the contract in one sentence so the mode is visible. Name the scope ("no-approvals for the =:quick:solo:= tasks; stays on until done or until I hit a question"). Append a Session Log entry with the trigger phrase and the time.
** 2. Plan the work
Lay out the remaining work as a numbered list. Pick the order yourself; don't ask. Surface the list once so Craig sees what's coming when he checks back in.
** 3. Execute each item
For each item:
- Do the work.
- Update the Session Log per the rules in =protocols.org=.
- Before any commit: run =/review-code= against the staged diff. Surface Critical and Important findings inline; fix them and re-review until clean. Minor findings show but don't block.
- Draft the commit message. Run =/voice personal= (the skill, or walk the patterns inline if unavailable). Print the final message inline before committing so the log shows it.
- Commit and push.
- One-line status between items ("Task X done, on to Y.") so Craig knows what's happening when he checks back in.
** 4. Reach a question or finish
Two exit paths:
*** A. Question for Craig
When you hit a real question, stop. Phrase it with the recommendation as item 1, per =interaction.md='s "Order Options with the Recommendation at Item 1". Surface the question with whatever context Craig needs to decide (what you've finished, what the question is about, what your recommendation is and why, alternatives).
A "real question" does NOT include:
- Routine commit-message wording. Just commit it. The message stays in =git log= and can be edited via interactive rebase if it bothers you.
- Choice of commit decomposition. Use judgment.
- Whether to do something Craig already told you to do.
- Confirmation of obvious next steps.
A "real question" DOES include:
- A destructive operation (=git reset --hard=, force-push, =rm -rf=, dropping a branch).
- An ambiguous requirement where the wrong call wastes meaningful work.
- A surprise in the tree (unexpected WIP, unexplained branch state, a conflict you can't resolve mechanically).
- A judgment Craig has consistently wanted to make himself.
- A finding suggesting the user's stated goal is wrong (e.g. the "fix" reveals the bug is elsewhere).
When breaking out, say so explicitly: "Pausing no-approvals batch — <reason>. Decision needed: <question>."
*** B. Done
When the planned work is finished, post a single summary message: what shipped, what's left for next session (if anything), and a one-line invitation back ("Ready when you are"). Don't auto-wrap-up the session — that's still Craig's call.
* Common Mistakes
1. *Skipping =/review-code=* — the gate is mandatory in this mode, not just protective when uncertain.
2. *Skipping =/voice personal= on commit messages* — same: the rule survives mode changes.
3. *Bundling a "question" with a hidden ask for permission* ("I'm about to do X, is that OK?"). That's an approval gate. Either do X or surface a real question.
4. *Surfacing every minor decision as a question to be safe* — the mode exists because Craig wants velocity; over-surfacing defeats the purpose. Use judgment.
5. *Plowing through a Critical or Important finding* — those still block. The batch pauses, the issue gets fixed, the batch resumes.
6. *Skipping destructive-action consent* — force push, =rm -rf=, dropping production data still need explicit consent. No-approvals doesn't cover these.
7. *Continuing past genuine ambiguity* — if there are two reasonable ways forward, stop and ask. The batch's purpose is to skip *redundant* approvals, not to invent decisions Craig didn't pre-agree to.
8. *Forgetting to surface progress* — Craig still wants the one-line status between items so he knows what's happening.
9. *Forgetting to update the Session Log between items* — the log is the only crash-recovery anchor while Craig is away.
10. *Failing to print the commit message inline before committing* — the print step exists so the log shows exactly what landed without Craig having to read the diff to find out.
11. *Carrying no-approvals across sessions or unrelated user messages* — assume it resets when the work it was scoped for finishes, or when Craig moves to a different topic.
* Exit
This mode applies for the remainder of the session that invoked it. It doesn't persist across wrap-up. The next session starts in normal-gate mode unless Craig invokes no-approvals again.
* Living Document
If a recurring pattern emerges (e.g. Craig wants the one-line status to include the commit SHA, or wants per-task tests skipped because the suite runs once at the end), fold it in. The mode is shaped by use — refine as the dogfooding signal arrives.
* History
Promoted from project-only (=.ai/project-workflows/no-approvals.org= in rulesets, commit =e27bf57= 2026-05-28) to template after pearl independently built its own version (handoff =2026-05-28-0814-from-pearl-no-approvals.org=). The merge took pearl's prominent "What's Suspended" / "What Stays On" split, wider trigger phrases, the mode-resets-on-topic-shift guard, the explicit destructive-action carve-out, and the subagent-review callout. The session-log emphasis, real-question include/exclude lists, and "don't auto-wrap-up" guard came from rulesets.
|
