feat(re-anchor): add sweep-all-disciplines posture-batch runbook#1050
Conversation
Add a composed runbook that batches the discipline correctors into a single re-anchor pass: it fans out a conversation-inheriting fork subagent per in-scope corrector for an audit-only walk, then applies the corrections once on the main thread in a fixed rank order (use-your-skills first, tighten-your-output last). At session start it reports a cheap posture digest instead, loading no corrector bodies. It is a declared second species, not a corrector, and records its split of the shared loop as a declared delta. Membership and order live in each corrector's own colocated frontmatter metadata (re-anchor-batch tier + re-anchor-batch-rank), so the runbook globs and reads rather than naming members; a userConfig overlay (batch_exclude/promote/demote) adjusts membership without a PR. Also fixes the README scrutinize-dont-coast table/detail drift and bumps re-anchor to 0.6.0. Refs #1041 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 3m 10s —— View job PR Review: feat(re-anchor): add sweep-all-disciplines posture-batch runbookTasks
Overall AssessmentThis is a well-designed, thoroughly-documented addition. The declared-second-species framing is architecturally sound, the colocated-metadata approach avoids the hand-maintained-list drift problem neatly, and the fork/main-thread split for audit vs. correction is the right call. A few ambiguities in Findings1. Step-3 correction mechanism is underspecified (correctness concern)
This tells the main thread when to apply corrections but not how. An agent following this instruction might correct from the findings ledger alone (i.e., from memory of what the audit found), rather than re-loading each corrector's Suggested addition after "correct forward each finding": "Load that corrector's 2.
|
|
Claude finished @kyle-sexton's task in 1m 53s —— View job Security Review — PR #1050Tasks
This PR adds a posture-batch runbook skill ( No CRITICAL or IMPORTANT security findings. SUGGESTION — userConfig values substituted raw into LLM instruction contentConfidence: LOW Lines 110–112 of These three user-controlled strings are substituted verbatim into skill instruction content before it is interpreted by the model. A value containing embedded instructions (e.g., The blast radius is narrow: The low confidence reflects that the threat model for a personal Claude Code plugin config does not include a meaningful adversary. It is worth noting as a defence-in-depth concern if the platform ever allows project-level No other injection surfaces, secret handling, permission escalation, path traversal, GitHub Actions patterns, or supply-chain risks were identified in the changed files. |
Sync the root README plugin catalog with the re-anchor manifest description via scripts/generate-catalog.mjs (plugin-gate parity). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 3m 0s —— View job PR Review: feat(re-anchor): add sweep-all-disciplines posture-batch runbookTasks
Latest commit (b53110a) — catalog sync onlyThe push that triggered this review contains one change: a root Overall AssessmentThe architecture is sound. Declared second species, colocated tier metadata, fork-for-audit / main-thread-for-correction, no drift-prone member list — all of these are the right calls. The findings below are continuation from the 91a0a83 review; none have been addressed in b53110a. Findings (ranked most-severe first)1. Step-3 mechanism is underspecified — an agent could correct from memory alone
This tells the main thread when to correct but not how. An agent following this literally might apply corrections directly from the findings ledger (the fork's output), rather than reloading each corrector's Suggested text after "correct forward each finding on the main thread now —": 2. userConfig overlay conflict cases have no defined precedenceThree edge cases have no specified resolution:
Without rules here, these produce invisible misbehavior. Suggested one-liner precedence: "exclude wins over promote/demote; promote/demote applied only to the tiers they make sense for; mismatched overlays are reported, not silently ignored." 3. Glob self-inclusion: the runbook is a sibling directory and has no
|
|
Claude finished @kyle-sexton's task in 2m 5s —— View job Security Review — PR #1050Tasks
This PR adds Changed file types: LLM instruction documents (Markdown), eval JSON, and a plugin manifest. No executable code, no shell scripts, no GitHub Actions modifications. No CRITICAL or IMPORTANT security findings. SUGGESTION — userConfig strings substituted verbatim into LLM instruction contentConfidence: LOW
These three In today's platform model, Worth noting as a defense-in-depth concern if the platform later supports org-level Areas with no findings
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b53110a009
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The correction step walks in-scope members by ascending re-anchor-batch-rank; never-tier correctors carry no rank and are already excluded at membership resolution. State that explicitly so the rank sort never meets an absent rank. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 3m 52s —— View job PR Review: feat(re-anchor): add sweep-all-disciplines posture-batch runbookTasks
Latest commit (4512013) — addresses finding #6 from prior reviewsThe change explicitly states that -3. **Correct once, in rank order.** Walk the members by ascending
- `re-anchor-batch-rank` and correct forward each finding on the main thread
- now — the shared loop's step 3, batched.
+3. **Correct once, in rank order.** Walk the in-scope members — the core and
+ situational correctors that ran (never-tier carries no rank and was already
+ excluded at membership resolution) — by ascending `re-anchor-batch-rank`,This closes the null-rank ambiguity that previous reviews flagged. Finding #6: fixed. Codex P1 finding — factually incorrect, but surfaces a real gapCodex flagged
However, Codex was directionally right that there's a problem — just not this one. See finding #1 below. New finding: fork mode is opt-in and experimental — not documented in SKILL.md
The docs confirm the mechanism is correct, but also state:
Without Suggested addition to the Gotchas section:
Still-open findings from prior reviews (none addressed since 91a0a83)Step-3 mechanism underspecified — agent could correct from memory alone
The SKILL.md tells the main thread when to correct but not how. An agent could apply corrections directly from the findings ledger rather than reloading each corrector's userConfig overlay conflict cases have no defined precedenceThree edge cases are unspecified: same name in both Glob self-inclusion: the runbook has no
|
|
Claude finished @kyle-sexton's task in 1m 38s —— View job Security Review — PR #1050 (latest commit: 4512013)Tasks
Latest commit (4512013)This commit makes one change to No new security findings introduced by this commit. Full PR security assessment (all 20 changed files)Changed file types: LLM instruction documents (Markdown), one eval JSON, one plugin manifest JSON. No executable code, no shell scripts, no GitHub Actions modifications. No CRITICAL or IMPORTANT security findings. SUGGESTION — userConfig strings substituted verbatim into LLM instruction contentSeverity: SUGGESTION | Confidence: LOW
These three In the current platform trust model, Worth noting as a defence-in-depth concern if the platform later supports org-level or administrator-managed This finding is unchanged from the previous two security review passes on this PR (17:46 and 17:50 UTC). Areas with no findings
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4512013e2f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Batched step 3 now states that a load-bearing correction whose suspected drift source is the main context still escalates to a fresh-context (non-fork) re-derivation per the shared method's Non-negotiable — the batch orchestrates the correction on the main thread but does not waive that escalation (the fork audit inherits context on purpose, as step 2 is a same-context self-audit). Adds a Gotcha that Agent-tool forks run at the parent model over the full transcript, so the never tier and situational relevance-gating keep the fan-out small. Addresses independent-review IMPORTANT + fork-cost suggestion. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 3m 44s —— View job PR Review: feat(re-anchor): add sweep-all-disciplines posture-batch runbookTasks
Latest commit (b5088ee) — two targeted fixesThis commit makes two additions to 1. Fresh-context escalation preservation in step 3 (lines 91–97):
This is architecturally correct and well-motivated. Verified against 2. Fork cost Gotcha (lines 148–152):
Accurate and actionable. The note that "keeping the Still-open findings (none addressed since 4512013)The following findings from prior reviews remain unaddressed. Ranked most-severe first. 1. Step-3 mechanism underspecified — agent could correct from memory alone
The main thread is told when to apply step 3 but not how: whether it re-loads each corrector's 2. Fork mode is experimental and opt-in — not documented as a prerequisite
Per the live sub-agents docs: "Letting Claude itself spawn forks is experimental and may change in future releases" and "To control fork mode regardless of the staged rollout, set Without that variable set (or a server-side rollout covering the consumer's environment), the fork dispatch silently fails — the audit fan-out produces no ledgers and the batch produces no corrections, with no error surfaced to the user. The new Gotcha in b5088ee addresses fork cost, not fork availability. A prerequisite note in the Gotchas section — e.g., "Fork dispatch is experimental; set 3. userConfig overlay conflict cases have no defined precedenceThree edge cases remain unspecified:
All three produce invisible misbehavior without a stated rule. Suggested one-liner: "exclude wins over promote/demote; promote/demote apply only to the tiers they make sense for; mismatched overlays are reported, not silently ignored." 4. Unsubstituted
|
|
Claude finished @kyle-sexton's task in 1m 45s —— View job Security Review — PR #1050 (latest commit: b5088ee)Tasks
Latest commit (b5088ee)This commit modifies only
Both additions are LLM instruction prose — no executable code, no new external calls, no new injection surface. No new security findings introduced by this commit. Full PR security assessment (all 20 changed files, latest HEAD: b5088ee)Changed file types: LLM instruction documents (Markdown), eval JSON, plugin manifest JSON, documentation. No executable code, no shell scripts, no GitHub Actions modifications. No CRITICAL or IMPORTANT security findings. SUGGESTION — userConfig strings substituted verbatim into LLM instruction contentSeverity: SUGGESTION | Confidence: LOW
These three In the current platform trust model, Worth noting as a defence-in-depth concern if the platform later supports org-level or administrator-managed This finding is unchanged from the three prior security review passes on this PR (17:46, 17:50, and 18:05 UTC). Areas with no findings
Note: The Codex P2 finding (unsubstituted |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b5088eeded
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Codex review: (1) fork-spawning is a rollout-gated capability
(CLAUDE_CODE_FORK_SUBAGENT); where it is off, a `fork` request degrades to a
fresh general-purpose subagent that cannot see the conversation — so the batch
now reports it cannot run the inheriting audit rather than auditing blind. The
`subagent_type: "fork"` mechanism itself is correct per the official
sub-agents docs. (2) An unset userConfig option does not reliably substitute
to empty — the literal ${user_config.*} token can survive on zero-config or
headless installs; treat a surviving literal placeholder as unset so it is
never parsed as a corrector name.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 3m 16s —— View job PR Review: feat(re-anchor): add sweep-all-disciplines posture-batch runbookTasks
Latest commit (ee4ecb3) — two targeted fixesThis commit addresses two open findings: 1. Fork-mode gating — previously reviewers flagged that fork-spawning being experimental ( 2. Unsubstituted userConfig tokens (Codex P2) — the prior text said the overlay values are "empty when unset," which is incorrect for zero-config, headless, or pre-configure installs where Findings status — full PR view
Open findings1. Step-3 mechanism underspecified — agent could correct from memory alone
The main thread is told when to apply step 3 but not how. An agent executing step 3 from the findings ledger alone skips each corrector's discipline-specific resolution rules — the resolution ladder, escalation conditions, and correction vocabulary live in each corrector's own SKILL.md, not in the ledger the fork returned. Suggested addition after "the shared loop's step 3, batched": 3. userConfig overlay conflict cases have no defined precedenceThree edge cases remain unspecified:
Without a precedence rule, all three produce invisible misbehavior. A one-liner: "exclude wins over promote/demote; promote/demote apply only to the tiers they make sense for; mismatched overlays are reported, not silently ignored." 5. Glob self-inclusion — no skip rule for entries with no
|
|
Claude finished @kyle-sexton's task in 1m 20s —— View job Security Review — PR #1050 (latest commit: ee4ecb3)Tasks
Latest commit (ee4ecb3) — two targeted security/correctness fixesThis commit modifies only
Full PR security assessment (all 20 changed files, HEAD: ee4ecb3)Changed file types: LLM instruction documents (Markdown), eval JSON, plugin manifest JSON, documentation. No executable code, no shell scripts, no GitHub Actions modifications. No CRITICAL or IMPORTANT security findings. SUGGESTION — userConfig strings substituted verbatim into LLM instruction contentSeverity: SUGGESTION | Confidence: LOW
These three In the current platform trust model, Worth noting as a defence-in-depth concern if the platform later supports org-level or administrator-managed This finding is unchanged from the four prior security review passes on this PR. The new unset-placeholder guard in this commit narrows the practical surface by ensuring literal tokens are never parsed as corrector names, but does not address the general substitution path. Areas with no findings
|
The plugin gains its first userConfig surface (the sweep-all-disciplines batch
overlay), so the setup contract wants a discoverable setup skill. Per the
userConfig-only carve-out it is check-only: /re-anchor:setup check reports the
effective overlay (excluded/promoted/demoted correctors, validated against the
installed correctors), treats an unexpanded ${user_config.*} token as unset,
notes the fork-mode prerequisite, and routes reconfiguration to the native
/plugin configure re-anchor flow. It writes no config. README Configuration
and CHANGELOG updated.
Addresses Codex P2 (setup check for batch userConfig).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 2m 46s —— View job PR Review: feat(re-anchor): add sweep-all-disciplines posture-batch runbookTasks
Latest commit (bf80d45) — setup skill added for batch userConfigThis commit adds The setup skill is well-formed and correctly satisfies the check-only carve-out from
Specific verifications:
Evals: 3 evals covering check output, unexpanded token, and name validation — adequate for the three distinct behaviors. One minor gap: no eval specifically exercises the fork-prerequisite INFO (step 5). Not blocking. Finding N: FIXED. ✓ One minor gap in the setup skill itselfThe step validates Findings status — full PR view
Still-open findings1. Step-3 mechanism underspecified — agent could correct from memory alone
This is the most persistent finding across five review rounds. The SKILL.md tells the main thread when to apply step 3 but not how: whether it re-loads each corrector's Suggested addition after "the shared loop's step 3, batched": 3. userConfig overlay conflict precedence partially addressed but sweep runtime still unspecified
The setup skill (step 4) now validates and reports conflicts before the batch runs — that's the right discoverability path. But the sweep skill itself still doesn't say what to do at runtime when the user proceeds with a contradictory overlay (e.g., same name in both 5. Glob self-inclusion — no skip rule for entries with no
|
|
Claude finished @kyle-sexton's task in 1m 23s —— View job Security Review — PR #1050 (latest commit: bf80d45)Tasks
Latest commit (bf80d45)This commit adds No CRITICAL or IMPORTANT security findings. SUGGESTION — userConfig strings substituted verbatim into LLM instruction content (second substitution site)Severity: SUGGESTION | Confidence: LOW The same three The skill's own unexpanded-token guard (lines 37–40: treat a surviving literal Positive security controls in this commit
Full PR security assessment across all 6 commitsNo CRITICAL or IMPORTANT security findings across any commit in this PR. The one SUGGESTION (LOW confidence) — |
|
🔒 babysit-prs lane claiming this PR for on-branch fix work this cycle (amendment-round: 16, safe tier). Will fix clear branch-owned findings and push; will not resolve threads or merge (safe tier). |
|
Safe-tier babysit pass — classification of the open findings on this review (validated against head
Reacted 👀 (acknowledged, deferred to author — no fix this pass). Security review (latest-commit SUGGESTION, LOW confidence — Status: green (all required checks pass; |
…derivability rubric+evals (#1058) ## Summary The `audit-derivability` spot-test protocol told the auditor to avoid `context: fork` "because a fork inherits this context's contaminated history." That inverts the mechanism and conflates two distinct things: - **Skill-level `context: fork`** (a SKILL.md frontmatter setting) starts BLANK — it does not inherit the invoking conversation. - **Agent-tool `fork` subagent type** (`subagent_type: "fork"`) DOES inherit the parent conversation (and its model), so it is the mechanism that carries the contamination. The stated *reason* was inverted; the *recommendation* (delegate the spot-test to a fresh-context, non-fork subagent) was and remains correct. ## Fix Re-point the contamination risk to the Agent-tool `fork` subagent type, and add a tight clause distinguishing it from skill-level `context: fork`, in all three sites where the inverted claim appeared: - `plugins/docs-hygiene/skills/audit-derivability/SKILL.md` (spot-test bullet) - `plugins/docs-hygiene/skills/audit-derivability/context/rubric.md` (spot-test protocol, step 1) - `plugins/docs-hygiene/skills/audit-derivability/evals/evals.json` (eval id 7: `expected_output` + one expectation) The issue named only the rubric and evals; a sweep of the skill surfaced the same inverted claim in `SKILL.md`, which is fixed here too so the correction is complete rather than half-applied. Includes a patch version bump (`0.8.4` → `0.8.5`) and a matching CHANGELOG entry. ## Verification Confirmed the distinction against the official docs (fetched, not recited): - Skills — https://code.claude.com/docs/en/skills, "Run skills in a subagent": *"Add `context: fork` to your frontmatter when you want a skill to run in isolation. The skill content becomes the prompt that drives the subagent. **It won't have access to your conversation history.**"* - Sub-agents — https://code.claude.com/docs/en/sub-agents, "What loads at startup": *"Each subagent starts with a fresh, isolated context window… The exception is a fork, which inherits the parent conversation instead of starting fresh."* And "Fork the current conversation": *"A fork is a subagent that inherits the entire conversation so far instead of starting fresh… a fork sees the same system prompt, tools, model, and message history as the main session."* Claude spawns one "by requesting the `fork` subagent type explicitly." `docs/PLUGIN-PHILOSOPHY.md`'s fresh-eyes section already carries the correct Agent-tool fork wording and was used as the phrasing model; it is intentionally not edited. `evals.json` re-validated as well-formed JSON after the edit. Closes #1053 ## Related - #1053 — the issue this fixes. - #1050 — the re-anchor `sweep-all-disciplines` PR whose independent review verified the fork-mechanism claims against the official docs and surfaced this contradiction. - #1062 — deferred follow-up (SUGGESTION, non-blocking): SKILL.md Hard Rules line 111 could use an inline clarification too. --- Authored by Claude Code (Claude Opus 4.8). Session: https://claude.ai/code/session_01Mu8bLN896ia5AeWmGPqAUv Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Closes #1041.
What
Adds a posture-batch runbook to the
re-anchorplugin — a higher-orderskill that composes the discipline correctors into one re-anchor pass, instead
of hand-pasting a long list of
/re-anchor:*invocations. It is a declaredsecond species: not a corrector, carries zero discipline text, pure router.
Name
sweep-all-disciplines— confirmed by Kyle from a blind 3-lens namingpass (shortlist:
sweep-all-disciplines(chosen),run-every-corrector,ground-every-discipline,set-the-posture).How it works
tool
subagent_type: "fork"— inherits history, required to audit it)per in-scope corrector, audit-only (shared-loop steps 1-2, no writes), one
SKILL.mdeach, returns a findings ledger.order:
use-your-skillsfirst → evidence → structural →mind-your-maxims→
tighten-your-outputlast. A load-bearing correction whose drift source isthe main context still escalates to a fresh-context (non-fork) re-derivation
per the engine doc's Non-negotiable.
in its own frontmatter (
metadata.re-anchor-batch= core/situational/neverre-anchor-batch-rank). The runbook globs and reads; it never namesmembers. 4 core / 7 situational / 3 never.
silent.
batch_exclude/batch_promote/batch_demote)— the plugin's first
userConfigsurface.load.
recorded in the skill. Member human-gates and the outward-artifact carve-out
survive batching.
scrutinize-dont-coasttable/detail drift (13 listed vs 14shipped). Bumps
re-anchorto 0.6.0.Verification
userConfigschema (plugins-reference),metadata:frontmatter (skills),fork context/model inheritance (sub-agents).
skill-quality:checkPASS on all 15 re-anchor skills (0 errors/warnings);markdownlint clean;
claude plugin validatepasses; internal doc linkresolves; all CI checks green.
CRITICAL. Its one IMPORTANT (fresh-context escalation must survive batching)
and the fork-cost caveat are applied in the latest commit. The Claude
review-bot's clarity finding (never-tier excluded before the rank-walk) is
also applied; the security bot's sole note was LOW / no-action; Codex clean.
Classification decisions (documented; reviewer-endorsed)
scrutinize-dont-coast→neveron architectural grounds: its auditneeds a non-fork fresh context and it stops to remediate with the user
— incompatible with the autonomous fork fan-out. A second "never" class
beyond the
-deepcost class. (Alternative if ever wanted:situationalwith a special non-fork dispatch path.)
userConfig(comma-separatednames), not the
multiple: truearray — array-into-skill-contentsubstitution is undocumented, and substitution is the overlay's only
consumption path.
Related
adversarial-review decision log (repository-external working notes for the
repeated-prompts-to-skills effort).
PRs and do not depend on this one.
rubric conflates Agent-tool fork with skill-level
context: fork; this PR'susage is correct per official docs.
🤖 Generated with Claude Code