46 Claude Code repositories, read and judged.

• The validate-evaluator skill gives a complete procedure for calibrating an LLM judge: split the labels, measure true positive and true negative rates, run the judge once on the test set, and correct the observed pass rate with a stated formula and a bootstrap confidence interval.
• The write-judge-prompt skill specifies a binary judge with four components that writes a critique before its verdict, and says to use several binary judges for severity instead of one Likert scale.
• It says to pin a dated judge model snapshot instead of a floating alias, and to re-validate the judge after any prompt or model change.

• The error-discovery skill is mostly a roughly 70-line specification of a review web app, which is a large context load if you only want the method.
• It says to use Cohen's Kappa only for agreement between two human annotators, not for judge-versus-ground-truth, which disagrees with write-ups that use a Kappa threshold to approve a judge.
• The review loop names the Claude Code Monitor tool, so that part depends on one harness.

• A write-up said the guidance pins gpt-4o-2024-05-13. The current skill only says to use a dated snapshot id and no longer names an OpenAI model. Its other eight steps matched the file line by line.

• security-guidance runs 25 fixed pattern rules after each edit, such as eval(, innerHTML and pickle, with no model call and one warning per file and rule per session. It also does an LLM review of the turn's diff at Stop and on commit and push.
• The marketplace code-review command scores each finding from 0 to 100 with a separate Haiku grader, drops anything below 80, and lists false positives such as problems on lines the user did not change and issues CI will catch.
• security-guidance is configurable: SECURITY_GUIDANCE_DISABLE=1 turns it off, and there are settings for the review model, the number of Stop firings per turn (3) and commit reviews per hour (20).

• security-guidance is a reminder system, not a gate. It has no PreToolUse hook, never denies an edit, and its only block is a Stop-time prompt that wakes the model with findings.
• It is a large plugin of about 9,500 lines. It builds a Python virtual environment with the Agent SDK at session start and sends diffs to a model on every Stop, subagent stop, commit and push.
• The six pr-review-toolkit agents open with an expert persona, four of them inherit the main model so they do not give an independent opinion, and the silent-failure-hunter agent still fails YAML parsing.

• Earlier write-ups said security-guidance has 8 or 9 patterns and runs as a PreToolUse hook. The current plugin (version 2.0.8) has 25 pattern rules and no PreToolUse hook. The PreToolUse version existed from October 2025 to May 2026, and the copy bundled in anthropics/claude-code still describes it.
• A write-up credited the code-review command to a March 2026 edit. That edit belongs to the 109-line copy bundled in anthropics/claude-code. The marketplace copy is a different 92-line workflow, and the Haiku grading rubric is in it.

• The skill-creator skill is a working authoring and evaluation kit: it runs with-skill and baseline runs side by side, grades them, and optimises the skill description on a 60/40 train/test split with 3 runs per query.
• The webapp-testing skill drives a Playwright browser through a server-lifecycle helper script, tells the model to run scripts with --help first rather than reading their source, and uses a look-then-act routine (wait for network idle, inspect, then act).
• The frontend-design skill is 71 lines of rationale, a five-item list of current AI-design tells and a two-pass process (plan tokens, build, then critique a screenshot), with no caps-lock rules.

• The canvas-design skill tells the model to repeat phrases like "meticulously crafted" and fakes a user complaint inside the prompt; treat it as an example of prompt habits to avoid.
• The skill-creator skill is 485 lines; load it only when you are writing a skill.
• The mcp-builder, web-artifacts-builder, theme-factory and brand-guidelines skills are good for their narrow jobs (MCP servers, claude.ai artifacts, slide themes, Anthropic's own brand) but are not general coding-loop tools.

• Earlier write-ups quoted frontend-design as saying "NEVER use generic AI-generated aesthetics" and naming Space Grotesk. The current skill contains neither; that wording survives only as a quoted migration tip elsewhere in the repository.

• no-chained-type-assertions rejects chains of two or more type assertions, and its message tells the author what to do instead: parse untrusted input at its boundary before narrowing it.
• require-safety-comment-for-type-assertion forces a written SAFETY reason next to every non-const cast, which gives a reviewer something to check.
• The install skill tells the agent not to suppress rules, weaken severity, add unsafe casts or launder types to make lint pass, and its update procedure is a reviewed three-way merge that treats local edits as owned policy.

• Some rules are personal taste: no-shape-in-symbol-names bans the substring "shape" in local names, and require-readable-spacing is a fixed whitespace policy. Disable them first.
• The rules are syntactic and do not use the TypeScript type checker, so keep tsc checks alongside them. Pin oxlint and @oxlint/plugins to the same exact version (1.78.0 at this commit).

• The self-preference index is the judge's own-family win rate minus what the other judges award the same responses, which separates real quality from family bias.
• Every pair is judged in both orders, so position bias is measured and not left as a confound. The pilot found the first-shown response won 63.1% of the time and win rate tracked length at +0.98.
• Model calls are cached by content, so a rerun reproduces the same numbers.

• The pilot is small: 24 open-ended prose prompts, no human ground truth and single-letter verdicts. The author notes the result may differ on verifiable tasks.
• Its published Haiku 4.5 result (+0.144, with the model unable to recognise its own text) is against Sonnet 4.6 candidates. No Claude 5-generation model appears anywhere.

• The pilot is cited as showing Haiku 4.5 favours its own family by +0.14 with self-recognition at zero. The result files confirm both numbers; they also show Sonnet 4.6 at +0.137, GPT-4o at +0.210 and GPT-4o-mini at +0.071.

• The grilling skill, reached through grill-me or grill-with-docs, interviews you on a design tree. Each round asks the whole open frontier of questions with a recommended answer for each, and it ends when nothing is left silently assumed.
• The diagnosing-bugs skill makes building a feedback loop the first phase, and that phase is complete only when you can name a command you have already run that fails.
• The tdd skill is 38 lines. It requires tests only at seams you have confirmed, names tautological and implementation-coupled tests as anti-patterns, and puts refactoring in the review stage. The to-tickets skill turns a spec into vertical-slice tickets with blocking edges.

• Many of the 37 skills are personal workflow and are not in the plugin, such as teach, wayfinder, the writing skills and the misc scripts. Install selectively.
• The improve-codebase-architecture skill produces a styled HTML report with badges and diagrams, which is more ceremony than the decision it supports needs.
• The git-guardrails-claude-code skill, a hook that blocks dangerous git commands by pattern, was moved to misc by the author and overlaps native permissions.

• Earlier write-ups called the tdd skill a strict red-green-refactor gate. Version 1.1.0 dropped the workflow, the per-cycle checklist and the refactor stage, so it is now three one-line rules.
• Earlier write-ups used the names diagnose and to-issues. Those are now diagnosing-bugs and to-tickets, and the old names no longer exist.

We ran grilling, grill-me and diagnosing-bugs unmodified, and adapted tdd and to-tickets, inside a larger bundle that also included a Codex review script and a skill-evaluation hook; against stock Claude Code on 69 build tasks with Claude Opus 5.5 the bundle showed no harm (-0.4 points), no measurable gain and about 25% higher estimated cost, and no individual effect can be attributed to any one skill.

• The search-conversations subagent is a clean model: pinned to Haiku, given only Read and the two MCP tools, with a fixed output contract of up to 1,000 words plus every source and its line range.
• The skill's "Don't search first" list (current code, the current conversation, before understanding the question) and its history triggers ("last time", "we discussed") are a usable routing rule.
• EPISODIC_MEMORY_DISABLE_AUTO_SYNC=1 turns off the hook so you can run the sync on a schedule instead.

• The skill description says "You MUST invoke this skill before saying 'I don't know,' guessing, or treating any topic as new", which fires on every uncertain question. Remove it and keep the routing rules.
• Summaries are generated by a Claude call on every sync (Haiku by default), a standing cost.
• A hook that launches claude re-fires SessionStart; the repository documents a recursion that spawned hundreds of processes and fixed it with a guard variable. Any hook of yours that shells out to claude needs the same.

• The skill says it "Saves 50-100x context" against loading raw conversations. The repository contains no measurement behind that figure.

• The wrapper only ever runs codex review. Every other flag, including any write-capable option, exits with code 64, and exit codes 3 (no Codex installed) and 4 (not in a git repository) let the caller fall back.
• Since version 1.1.0 (August 2026) it also pins -c sandbox_mode="read-only" -c approval_policy="never", because filtering flags alone was not read-only when the user's Codex config allowed workspace writes.
• The skill treats Codex output as untrusted input: the calling agent verifies each finding, drops what it can disprove, and keeps one outside voice per design.

• The skill file is bilingual (English and Japanese) and links to design records that are not in the repository, so adapt it rather than copy it.
• It needs a recent Codex CLI (0.142 or later), and the review path does not pass the flags that ignore a user-level rules file, so such rules are still read.
• A bare word that does not start with a dash is treated as a custom review prompt, so exec becomes the prompt text rather than a subcommand.

• The wrapper has been described as a roughly 40-line script. It is 133 lines, about half of them comments and argument parsing.
• Version 1.0.0 (July 2026) was not read-only in practice on a machine whose Codex config set workspace-write. Pin version 1.1.0 or later.

Its scripts were part of our full setup, which we measured as a bundle against stock Claude Code on 69 build tasks with Claude Opus 5.5: no harm (-0.4 points), no measurable gain, about 25% higher estimated cost, and no effect attributable to any one component.

• The measurement probe runs claude -p with --output-format stream-json, one turn, only the Skill tool allowed and a 20-second kill, then detects activation by finding a tool_use call named Skill in the stream. That is an artifact the model cannot narrate its way past.
• The test sets include prompts that need no skill and score them as true or false negatives, so a hook that fires on everything is caught.
• The hook is 35 lines. Its commitment step, where the model names each skill and says whether to use it, also cut false activations in the author's hard set.

• The hook text is a mandatory three-step sequence in capitals ("MANDATORY", "CRITICAL: You MUST") injected on every prompt, which adds tokens to every turn.
• The llm-eval variant calls a second model (Claude 3.5 Haiku, not the 4.5 the write-ups implied) from inside the hook, and the author's own numbers show it worse than the forced hook on false activations.
• The repository's own settings wire a one-line instruction hook, not the forced-evaluation hook, and the results files record no model.

• The author reports 100% skill activation with the hook against 55% without. The results files show 22 of 22 against 11 or 12 of 22, but no model is recorded, so the "Sonnet 4.5" attribution cannot be checked from the repository.
• The harness never counts a correct abstention as correct, so the headline 75% on the hard set is really 18 of 19 on prompts that need a skill, with 5 of 5 no-skill prompts handled correctly.

In our test the hook raised correct skill activation from 62% to 93% on 41 prompts (+30.5 points, 95% CI 17.1 to 43.9), cost ×1.88 output tokens per prompt, and loaded extra skills on 14 of the 41 prompts; a reworded version inside our setup gave +21.2 points at an interim look.

• Then steps must describe an outcome that can be observed and checked from the scenario text, not "it works".
• Scenarios state the starting condition ("the user is signed in with role Editor") instead of a click-by-click path, which leaves implementation choices to the coding agent.
• Example data should be concrete and realistic, not foo, bar or lorem ipsum. The end-of-file checklist is written for both humans and LLMs, so one list serves review and generation.

• The file has 28 MUST and MUST NOT statements, which suits a format specification but is not a pattern to copy into a general instruction file.
• The README offers pasting the whole file into a chat window as one option; pointing a skill or subagent at the file is the better route.

• The author's blog says unguided AI-written Gherkin drifts into vague Then steps. The repository contains no measurement of this; it is an assertion.

• The consensus tool consults each model separately. Each model sees only the proposal and files, never the other models' answers, and the calling agent writes its own neutral analysis first and then synthesizes.
• Its neutral stance says that balanced means being truthful about the weight of evidence, and that a 90/10 case should not be presented as 50/50.
• Its reply format ends with a confidence score of X/10 with what drives it and what is uncertain, which is cheap to copy into any reviewer's output.

• The stance text is written in a compensatory style: 13 all-caps imperatives in the tool and 3 in the prompt, with headers such as "MUST OVERRIDE STANCE". The ideas hold up; the wording does not need to be copied.
• The prompt opens with flattery ("The questioner values your expertise immensely") and caps each reply at 850 tokens for transport reasons, which would limit a review.
• The tool describes itself as "structured debate", but it runs blinded parallel opinions with no debate rounds.

• A write-up listed an issue about stance steering (#162) as open. It was closed in August 2025, and the code contains the blinding that addresses it.
• The clone is the last GitHub release (version 9.8.2, December 2025). The package index is at 11.1.0, so the files we read may have changed.

• The check command has a four-value exit contract: 0 all pass, 1 any failure, 2 no state recorded, 3 any sensor below its threshold. A hook can branch on status rather than parse prose.
• A "below threshold" status is separate from "failed", so a gate can tell worse-than-target from broken.
• The default parser accepts any tool that prints one JSON object (success, summary, score, findings) and ignores surrounding text, so ad-hoc scripts become sensors without a custom parser.

• The background control service uses a Unix socket and is tested only on macOS, and the repository carries duplicated tool configuration in two places.
• The author's own modularity review describes structural debt, so borrow the contract and the data shape, not the code.

• Earlier write-ups gave the check exit codes as 0/1/2. The code returns 3 when a sensor is below threshold, and the README still lists only 0/1/2, so a hook must treat 3 as not passing.

• The review output keeps severity (P0 to P3) separate from an autofix class and an owner. The autofix class is described as information, not a check that permits or blocks, and when reviewers disagree the more cautious class wins.
• A finding cannot score 75 or above unless the reviewer quotes the line that motivated it. A Python script enforces the quote check, the deduplication and the promotion rule, so they do not depend on the model following prose.
• The ce-compound skill admits a lesson only if a future engineer would repeat the mistake without it, writes one lesson per run, and checks the lesson's paths and claims against the repository before saving it.

• The code review is a 40-line spine that loads about 20 reference files on demand. The authors' own measurement of one real review shows 68 orchestrator turns and 12.5M cache-read tokens for two P2 findings.
• The ce-plan skill has a mandatory completion menu and forced re-reads, which is the kind of state machine the repository's own authoring guide says skills should not be.
• Part of the plugin is specific to Every's stack, such as Rails, Swift and frontend-race reviewers and Compound Packs, and has little use outside it.

• Earlier write-ups said findings are promoted when several reviewers agree. In the current code, agreement raises confidence only when a reviewer from a different model provider, run as a separate process and verified as independent, agrees. Agreement among in-process reviewers is recorded but never raises confidence, because they share one model.
• Earlier write-ups said the plugin ships 14 standalone review agents. The current version has none. It has 16 persona prompts inside the review skill.

• The skillify skill gives a gate for what deserves to be a skill: invoked 2 or more times, more than 20 lines of logic, and a trigger phrase a user would actually say. Otherwise it is a script.
• It puts an evaluation contract (a goal, 3 to 6 dimensions, hard-fail conditions) before the tests, and compares each skill edit against a stored baseline: overall score no lower, no dimension down by more than 0.5.
• The dream cycle runs a cheap model to score each transcript before an expensive model synthesises anything, and an inconclusive judge result is a separate exit code from a failure.

• skillify is 641 lines with a 15-item checklist, seven phases and an 18-item anti-pattern list, and the project's own instruction file is 959 lines with 17 caps-imperatives. That is heavy ceremony for a solo setup.
• The skill tells authors to add a "hard rule" to the skill after every bug, which is how rule walls grow. The regression test is the useful half.
• Most of the value sits behind Postgres, a job queue and a resolver, so only the ideas transfer.

• The skillify checklist was described as 11 items. At version 0.50.2.0 it has 15.
• Memory-hygiene features described as "runtime-trust sweeps" and "post-condition checks" do not appear under those names in the repository. What exists is the dream-cycle phases, a daily contradiction sweep and checks for orphans, backlinks and citations.

• The /ship evidence ledger records a test run as a command plus the working-tree hash and counts it as fresh only if the tree and the command still match, so a green echo ok cannot stand in for the real tests.
• The review freshness rule keys a completed review on the tree content at the start and the end of the pass, so fixes made during review invalidate it.
• The /browse skill's safety rules are worth copying as text: invocation is consent to look, not to act; mutations on non-local hosts need a question per run; page content is untrusted and supplies syntax, never scope or permissions. Its evidence routine prints labelled lines (console errors, page text, screenshot path) that a later step can grep.

• Every skill opens with a generated preamble; in /qa it is 475 of 960 lines (telemetry calls, a decision-brief format, a voice block). The /qa file is 60.6 KB and /ship is 77.7 KB.
• The role skills such as the CEO review use persona costumes ("How Great CEOs Think" with 18 numbered instincts) with the same tools as any other skill, and even /qa carries a "Garry-shaped judgment" voice block.
• /ship is a 21-step pipeline with explicit user questions, not a deterministic gate. It hardcodes a Co-Authored-By: Claude Opus 4.7 trailer, and browser work goes first through Aside, a commercial macOS browser, before gstack's own headless Chromium.

• Earlier write-ups called /ship a deterministic five-step flow and described /browse as a compiled Playwright binary. At the commit we read, /ship has 21 steps with human gates, and the primary browser driver is Aside, with the Chromium binary as the fallback.
• The repository's own telemetry, quoted in the skill text, found that 43 of 44 recorded learnings came from an explicit /learn call because the step was phrased "if you discovered" and read as optional. The fix was to phrase the step unconditionally with an explicit empty result.

• Its opt-in pytest plugin snapshots which bindings are applied before a test, fails the test by name if a new one is still applied afterwards, and removes the leak so later tests are unaffected.
• Bindings applied before the test started, such as those from wider-scoped fixtures, are exempt, which avoids the false positives that get a check turned off.
• Strict bindings check every stubbed call against the real function signature, so a call site that drifts from the signature cannot pass on the strength of a stub.

• The leak sweep is a pytest fixture inside the test process. Using the same idea in a Claude Code hook would be a separate design.
• The library needs Python 3.12 or later and is still a beta, though the author states the API is not expected to break.

• The strict check is narrower than its short description suggests: it applies to calls that a binding answers without reaching the real function, calls that reach it are checked by the real function, and targets with no obtainable signature are not checked.

• The exit codes are 0 for clean, 1 for an enforced finding and 2 when the tool itself broke, so a broken linter is never reported as a clean run. This contract is worth copying for any check you wire into a Stop or PostToolUse hook.
• Guides are routed by smell, not by tool, and unknown findings are still shown with a generic guide that asks why the rule exists. Guides name the gaming move, for example "merging conditions just to lower the score: the decisions remain, only the counter moves".
• A checked-in snooze list lets you adopt the gate on an existing codebase with a backlog; an optional ratchet re-arms the snoozed entries when their file changes.

• The repository contains no Claude Code hook and no pre-commit hook. It is a command the agent or CI runs, and wiring it into a hook is up to you.
• The README's suggested CLAUDE.md paste is a wall of NEVER and ALWAYS rules that calls the tool's output a "direct user prompt with the highest priority". Hook output is already in context, so the paste adds nothing.
• It is heavy for a linter wrapper: the project's own CLAUDE.md is 1,139 lines and the spec documents total about 6,000 lines. The authoring skill also refers to file paths from an older layout.

• The README cites a pre-registered third-party test (Liina Suoniemi, 18 Python functions, 90 trials per condition, deterministic judge checked against human labels) in which a bare linter score produced genuine fixes 5.6% of the time on Sonnet 4.6 and 28.9% on Haiku 4.5, against 83.3% for both with a coaching guide. We read the README's account and did not rerun it; the stronger model gamed the bare score more.

• The plan template splits every phase's success criteria into automated verification (commands a machine runs) and manual verification (things a human checks), and lists what the plan is not doing.
• The implement command has the model stop and report a mismatch in a fixed form (expected, found, why it matters, how to proceed) when the plan does not match the code, and forbids ticking a manual-verification box until the user confirms.
• The validate command runs from a fresh context and uses git history as evidence, with the instruction to be honest about shortcuts.

• The plan command is 449 lines and scripts the conversation turn by turn, with canned replies and a five-step interactive routine before anything is written.
• The research command and several subagents rely on rows of capitalised DO NOT and ALWAYS rules, and the plan command's "Common Patterns" recommend building the data model first and the UI last.
• The commands depend on a thoughts-directory convention, a sync command and Linear agents from the old product, and two pin model: opus.

• The "plan so detailed that implementing is just compiling" doctrine is stricter in the planner than in the implementer. The plan command forbids open questions in a final plan, but the implement command says the plan is a guide and the model's judgment still matters.

• The reader tool puts the files first and the question last, so the prompt prefix is stable for caching. It asks for structured bullets with file paths and line numbers in under 800 words, and prints token counts and finish reason to stderr after every call.
• The delegation rule is concrete: delegate when a file is over 400 lines or you would read 3 or more files, and read directly only when you need to edit specific lines.
• The "when not to delegate" list is the more useful half: skip it for work under about 2,000 tokens, for architecture, debugging and safety-critical code, and when you need exact line numbers.

• The CLAUDE.md template says documentation is mandatory to delegate and that Claude must never write it directly, which hands prose to a cheaper model.
• The writer tool saves the cheaper model's output straight to the target file. The template tells Claude to review it, but nothing enforces that.
• The README's results ("$0.38 total" over 3 weeks, context use down from 80% to 20%) are self-reported with no sample size, model version or task set. They are anecdote.

• The post's "about 1/100th the cost" has no baseline in the repository. The README gives only a per-call cost of about $0.02 and the 3-week total.

• The coverage rule is simple: allow an edit when the target path equals, or sits under, a file declared by a worklist item with status proposed or applied; otherwise deny.
• State-file writes must bump a version integer by exactly one, which gives optimistic concurrency without hashes. Status changes go through a server call and not a file edit.
• The override is a timed record with explicit paths and a one-hour expiry, or the exact phrase "just do it". The guard denies on unparsable input and on panics, and its deny messages name the token that classified a command as a write.

• The product is far larger than a solo setup needs: forge-signature gates, a Codex adapter and a 2,470-line conventions document injected as agent instructions.
• Nothing is small or self-contained enough to copy; the policy is compiled code, and the worklist and authorization files are gitignored.

• Earlier write-ups said the guard rejects edits not covered by an "approved" worklist item. Coverage keys on item status proposed or applied, so the files of a proposed but unapproved item are already covered. Whether to require approval is an open issue in the repository.
• Earlier write-ups described Python hook adapters regenerated at build time. They no longer exist; hooks call the Rust bram-guard binary directly.

• The command line takes one positional stage name plus all, puts --limit on the cheap first stage and --model on the paid analysis stage, so you can test on 5 items, swap in a cheaper model, then run the full set.
• Each stage skips an item whose output already exists, and a clean command with a stage option redoes downstream work, so the pipeline can be re-run without a job queue.
• It keeps one directory per article with the prompt, the response and the parsed grades side by side, which makes intermediate results easy to inspect.

• The code is specific to Hacker News and to the OpenAI Responses API (default model gpt-5.1), so it is a pattern to copy, not code to reuse.
• The --limit flag only applies to the fetch stage. Later stages are limited because they process whatever fetch wrote.

• The parse-acceptance oracle runs SQLite's own upstream test files as a source of 395,694 statements, discards their expected results, and compares the real sqlite3_prepare_v2 verdict with syntaqlite's on every statement. Disagreements fall into a named matrix: both accept, both reject, false positive, gap.
• Both oracles use a one-way ratchet per category over deduplicated mismatches, so a shift between categories counts as a regression even when the total is flat. Each run also writes a ranked triage file that the agent can work through from the top.
• The token-preservation oracle formats a corpus and compares token streams before and after, normalising keyword case and comparing everything else exactly. Its wider sweep over about 78,000 statements is opt-in and not ratcheted, because it differs per machine.

• The differential oracle checks whether both parsers accept or reject a statement, not whether they return the same results; the upstream expected values are thrown away.
• The repository holds about twenty design-plan documents, which is a lot of planning ceremony; the agent guide itself is 326 lines with no caps-lock rules and is a good example of an architecture-and-commands file.
• The code is specific to SQL parsing. The reusable part is the five-step shape: borrow an input corpus, compare against a reference implementation, classify disagreements, ratchet per category, emit a work queue.

• Earlier write-ups said that if SQLite rejects a statement, syntaqlite must reject it. Gaps in that direction are baselined and ratcheted rather than required to be zero; 560 remain at the commit we read, along with 231 false positives.
• Agreement between the two parsers at that commit is 99.80% over 395,694 statements on Linux (99.79% on macOS), slightly above the 99.7% quoted earlier. The "78,554 of 78,555" token-preservation figure comes from a pull request description and is not stored in the repository.

• Approved Scenarios keeps input and expected output as fixture files in a domain format. A runner regenerates them, so review is a diff of fixtures and not of assertion code.
• Overnight Batch says no issue is ready for unattended delivery without a deterministic acceptance gate, and batch-planning ten issues surfaces shared groundwork once.
• Habit Hooks pair a deterministic detector with a prompt that says what to do and can be snoozed. Slice for Review splits a large delivery into stacked pull requests of about 200 lines, structural changes apart from behavioural ones.

• No document carries a measurement, transcript or before-and-after number. The house style is assertion only.
• The Reminders pattern injects a reminder on every prompt, and the Habit Hooks page uses an emoji pair marked CRITICAL to make hook output read as user input. Current Claude Code already delivers hook output that way.

• The Reminders page says hook-injected reminders are "~95% more reliable". The figure has no source anywhere in the repository.

• The classifier labels each step by what the command literally is, using rules over the action text and the last 2,000 characters of the output, so the labels are reproducible. The written spec lists 35 base intents with their patterns.
• A sequence layer separates verification after an edit from re-running the same command or re-running with no edit, and marks the first all-pass and the wasted steps after the work is done. This gives a verify-steps-per-edit measure.
• The repository pairs runs on the same instance and counts only tasks where both runs submitted, to avoid composition bias in comparisons.

• The classifier is written for SWE-Agent trajectories (str_replace_editor, submit) and is 1,147 lines; using it on Claude Code transcripts means re-implementing the rules against Claude Code's tool names.
• About 9,000 lines of the repository are scripts that build HTML pages. The reusable part is the classifier and its spec.
• The data covers Sonnet 4.5, GPT-5 and some later models, so its cost and step ratios describe those models and that harness, not current ones.

• The repository's audit finds that verification grows to 37-49% of steps in the last quarter of Claude trajectories, and that about 19.4% of late-phase "verify" steps are writing throwaway test scripts rather than running checks. We read the audit's numbers and did not reproduce them.
• The repository's head-to-head on 23 tasks that both models resolved reports Claude at 6.0 times the mean cost, 3.2 times the output tokens and 1.3 times the steps of GPT-5. The sample is small and dates from October 2025.

• The spec and plan reviewer prompts are 49 lines each with no capitalised rules. They say to flag only issues that would cause real problems and to approve unless there are serious gaps, and they mark recommendations as advisory so they do not block approval.
• The repository includes a dated experiment on instruction phrasing, run on Opus 4.8 with 5 repetitions per phrasing in June 2026. Prohibitions on how to compose output did worse than a positive recipe, and appending caveats to a winning recipe degraded it.
• In the same experiment, current Opus produced no plan placeholders in 40 of 40 runs, with or without the banned-patterns list.

• The SessionStart hook injects the mandate ("even a 1% chance a skill might apply… you ABSOLUTELY MUST invoke the skill") inside an EXTREMELY_IMPORTANT tag on every startup, clear and compact.
• Several skills open with an "Iron Law" in capitals and carry Excuse/Reality tables, and the persuasion notes cite imperative language as the intended mechanism. The authors' own placeholder experiment suggests current models do not need it.
• The spec, plan and subagent pipeline was made mandatory in version 5.0.0 and only partly walked back in 6.3.0 with a classifier that scales ceremony to the task.

• The release notes claim version 6 is "roughly twice as fast" with "almost 50% fewer tokens", with no model named. Elsewhere this is reported as about 60% fewer tokens.
• The gates were described as asserted, not measured. The release notes report that deleting the test-first rationale prose dropped compliance from 8/10 to 5/10, so some of that prose does work under pressure.

• The preserving-productive-tensions skill says to keep two valid options open when the choice depends on deployment context, and to force a decision when a choice is a one-way door or when keeping both adds complexity without value.
• It includes a short template for recording an unresolved decision: the two options, what each optimizes for, the trade-off, when each is best, how to preserve both, and what would trigger a resolution.

• Four skills (test-driven development, systematic debugging, verification before completion, and the skill-writing guide) contain an "Iron Law" block, and the using-skills skill is a mandatory check-for-skills gate injected at session start.
• The meta group is 1,724 lines about maintaining the skills wiki itself, which is of little use to a solo setup.
• The repository is archived, so it will not change. Newer additions such as design-for-isolation and file-size-awareness are only in obra/superpowers.

• Earlier write-ups said the architecture group held more skills that could not be listed. The directory contains one skill and an attribution file, and its history shows it never held more.
• The one architecture skill is derived from the ambiguity-guardian agent in Microsoft's Amplifier project, as the repository's own attribution file says.

• The skill states its reference's cost up front (about 12,000 tokens) and says to read the full text only when writing or editing prose.
• When context is tight, the skill says to write the draft first, then hand the draft and the full text to a subagent for copyediting and take back the revision.
• The 18-rule index (active voice, positive form, concrete language, omit needless words, emphatic words at the end) works as a short checklist for docs and commit messages without loading the long text.

• The description says to apply the rules to "any prose humans will read", which matches almost every turn if the skill is routed automatically. Narrow the trigger to documentation, README, commit and PR text, or user-facing copy.
• Eleven generated manifests for other agent tools surround one 62-line skill, which is packaging you can ignore.

• The adversarial review prompt sets a clear stance ("break confidence in the change, not validate it"), requires every finding to be defensible from repository context, and prefers one strong finding over several weak ones.
• The review output schema has a verdict of approve or needs-attention, with severity, file, line range, confidence from 0 to 1 and a recommendation per finding.
• Read-only is set by the plugin runtime as thread parameters (sandbox: read-only, approvalPolicy: never), not by anything the model writes. The Stop gate prompt tells the reviewer to verify claimed edits from repository state before blocking.

• The codex-rescue subagent is marked to run proactively when Claude is stuck and defaults to a write-capable Codex run. Remove it if you install the plugin for reviews.
• The Stop gate blocks on any non-ok outcome, including timeouts and parse failures, with a 15-minute limit per stop. The README warns it can create a long loop and drain usage limits.

• An earlier write-up said /codex:review is read-only by design but not enforced. It is enforced by the plugin's runtime thread parameters, and the review starts through the Codex app-server protocol and not a shell command the model builds.

• The shared voice file defines three confidence tags: certain (direct evidence in a file, command, doc or test), speculating (name the inference path) and don't know ("never launder a guess as analysis"). It also says to track contradictions in the dialogue instead of making the user the consistency check, and to agree when the evidence supports agreement.
• The pasteurize debugging skill says to build a reliable feedback loop before forming a hypothesis, with a concrete bar for the loop (same result each run, one command, exact symptom, under 30 seconds). It stops after three failed fix attempts without a new hypothesis, and treats a missing or mocked test seam as an architectural finding.
• Reviewer prompts are told to report everything and let a cheaper verifier filter afterwards, and the routing policy says not to delegate verification of your own work.

• Three skills use "Iron Law" blocks with red-flag lists and rationalisation tables, a mandate style inherited from the superpowers project.
• The spec skill's full tier is heavy ceremony: a 17-box coherence checklist, a fresh-context taste test bound to a hash, and a gate graph. The hard-cheese skill adds a judge that scores whether you can explain the diff, which costs human time.
• The routing table pins reviewer to Opus, coder to Sonnet and verifier to Haiku across three agent tools. That suits its author but is tied to the model generation, and the cheese router dispatches autonomously by default.

• Earlier write-ups called the confidence vocabulary, the feedback-loop-first rule, the SOLO-taxonomy check in hard-cheese and the two-key approval handshake unverified. All four exist in the shipped skills as described.
• The repository labels its own numbers honestly: the debugging skill's fan-out constants are described as reasoned by a reviewer with "no run history", and the judge's pass threshold of 3 out of 5 is a configuration default, not a measured cut.

• The design skill gives a brand-swap test (if swapping your brand name for a competitor's still works, the design is too generic), a "controlled imperfection" rule against perfect symmetry, and a personality table that sets density, warmth and boldness by product type.
• The planning-products skill sorts decisions into Type 1 (one-way door, full discovery) and Type 2 (two-way door, ship and learn). Its assumptions log lists the evidence, confidence and how to validate each assumption, and a low-confidence Type 1 assumption blocks the spec.
• Its experience-definition template lists six journey moments (entry, first impression, core action, feedback, recovery, return) and requires naming the trade-off when two qualities conflict.

• Several skills carry a one-line guard that repository-local rules take precedence over the skill. Copying that line into your own skills is cheap, but the plugin as a whole duplicates native subagents.
• The design skill has long lists of "Never" rules with no reason given for each item.
• The writer skill ships nine personas and strategy-writer four, which earlier write-ups called costumes. We enumerated them but did not read them.

• Earlier write-ups said the assumptions log, Type 1 and 2 gating, experience template, brand-swap test and "controlled imperfection" were not in the repository. All of them are in the current version and have been since March 2026. The earlier check used an out-of-date mirror of one file.

• Two subagents pass bulk context through handoff files on disk and each returns only a three-line summary, which keeps the main session's context small.
• A five-field brief (mode, task, files, tests, done-when) is enough to start a subagent. The driver's reply ends in DONE or BLOCKED: reason with the test output pasted in, which gives a checkable completion signal plus evidence.
• Having one agent write the tests and another write the implementation, without sight of each other's work, decorrelates test authorship.

• The separation is enforced only by prose such as "NEVER write or modify tests". Both agents have identical tools, so nothing stops the driver from editing tests. A tool restriction in the agent definition, or a PreToolUse rule on the tests directory, would enforce it.
• The driver definition is a rule wall ("Do NOT add features", "Tests MUST stay green", "Run tests after EVERY change"), and both agents say "Use PROACTIVELY" in the description.
• The orchestration skill mandates a fixed red, green, review, refactor cycle with gate lines, which hard-codes a test-driven sequence into the loop.

• The changelog is the primary source for when a Claude Code feature or setting appeared; it is more reliable than community summaries of version history.
• The bundled code-review command sets a reviewer bar of high-signal issues only (compile failures, definite wrong results, quotable CLAUDE.md violations) and tells the model not to flag anything it is not certain about.
• The bundled code-review command re-checks each flagged issue with validation subagents and posts only the ones that survive.

• The bundled plugins lag the copies in the official plugin marketplace: security-guidance here is v2.0.0 against v2.0.8 there, so install from the marketplace.
• All six pr-review-toolkit agents have frontmatter that fails YAML parsing, because unquoted example dialogue sits in the description field. They are also older persona-style agent files.
• This repository and the marketplace ship two different code-review commands under the same name (109 lines with Opus bug agents and validation subagents here, 92 lines with a Haiku 0-100 scoring pass there), and both differ from the built-in /code-review.

• Earlier write-ups dated the /simplify to /code-review rename at 2.1.146. The changelog puts it at 2.1.147, and also confirms the worktree hook events (2.1.50), /goal (2.1.139) and claude plugin eval (2.1.269).
• A claim that auto mode arrived in 2.1.178 is not supported by the changelog: that version's entries are about permission syntax and auto-mode classifier fixes.

• The review-pr command is 20 lines: it fans out to all five reviewers, tells each to report only noteworthy feedback, then has the orchestrator filter again before posting, with inline comments for specific issues and top-level comments for general ones.
• All five reviewers declare a read-only tool list (Glob, Grep, Read, WebFetch and similar, with no Edit, Write or Bash), so a reviewer subagent cannot change the tree.

• Each reviewer opens with a persona line such as "You are an elite security code reviewer". The five differ by checklist, not by what they can see: all get the same code and the same tools.
• The checklists are generic (OWASP list, SOLID, testing pyramid) and overlap the official code-review plugin. Only three TypeScript house rules are specific to this repository.
• Running five parallel reviewers on every pull request of a small Action repository costs more compute than a single fresh-context reviewer would.

• An earlier assumption was that these agents are internal development reviewers of little general use. Reading all five confirmed it: they are generic lens-split reviewers with no repository-specific logic beyond the TypeScript style rules.

• The Outcomes notebook gives a usable checklist for grader rubrics: checkable criteria, evidence required before a pass, describe the goal and not the steps, and a list of what the grader should ignore.
• The scheduled reviewer notebook separates two session designs: resume the session for sweeps, start fresh for each gate so old opinions do not steer the verdict. It also uses a closed set of verdicts and a JSON schema for findings.
• The coordinator notebook states its caveats plainly: compare team and solo runs at the same verification standard, splitting work into more narrow briefs raised the bill, and a cheap reader may summarize away what mattered.

• The coordinator notebook stores no cell outputs, so no run data in the repository backs its figures.
• The content moderation guide is a 240 KB notebook; the useful idea (a model compiles a policy into rules once, then a rule engine gives verdicts with no model call) fits in a paragraph.

• The coordinator notebook was widely cited as "2.5× cheaper and 3× faster". Anthropic removed those figures on 28 August 2026 (PR #851); the notebook now states only that 84-98% of the team's input tokens were billed at the worker rate, from the authors' own runs with Fable 5 as coordinator and Sonnet 5 as workers.
• A secondary write-up said the cookbook shows you "barely lose anything on benchmarks". The notebook makes no benchmark-quality claim; it measures cost and wall-clock on one 20-fact coverage task and says discovery-style questions narrow the gap.

• The write-spec skill's scope test is useful on its own: a requirement is P0 only if cutting it means the feature no longer solves the core problem, and any scope addition must come with a removal or a longer timeline.
• The code-review skill ends with a three-valued verdict (Approve, Request Changes, Needs Discussion) and a "What Looks Good" section before it, instead of a numeric score.
• The tech-debt skill is 32 lines and scores items with Priority = (Impact + Risk) x (6 - Effort), a fixed formula the model cannot argue around.

• write-spec is 250 lines because it says things twice: the PRD structure appears in two sections and MoSCoW restates P0/P1/P2. A trimmed version would be about 120 lines.
• Cowork-specific material, such as ~~source control connector placeholders and a STANDALONE/SUPERCHARGED ASCII box, means nothing in Claude Code and should be stripped before reuse.
• The skills are generic templates with no hooks, scripts or agents, so they work as a baseline to compare against more than as a setup to install.

• A code-review standard quoted as "approve a change when it definitely improves overall code health, even if it isn't perfect" does not appear in this repository's code-review skill or in its earlier revisions. The wording is from Google's engineering practices.
• The product-management skill was reported as feature-spec. That name existed until March 2026, when the /write-spec command and the skill were merged into write-spec.

• The loop uses one script and two prompts: a planning prompt that writes a prioritised plan and no code, and a build prompt that takes the top item, tests, commits and pushes. Each iteration starts with fresh context and the plan file on disk is the memory.
• The prompts say to search the codebase before assuming something is not implemented, and to keep the agent-instructions file operational only because a bloated one pollutes every later iteration.
• The spec-writing prompt separates what to verify (acceptance criteria as observable outcomes) from how to build it, which is left to the agent.

• The script is built around --dangerously-skip-permissions and pins --model opus; the README says a sandbox becomes the only security boundary, and asking for approval on every tool call would break the loop.
• The build prompt ends with a run of rules numbered 99999 and up, and both prompts ask for hundreds of parallel Sonnet subagents and "ultrathink". These are prompt ceremony from older models.
• The prompts name specific models ("Opus 4.6") even though the README describes the pattern as tool-agnostic.

• The ghuntley/how-to-ralph-wiggum repository is sometimes described as the source. Both READMEs open with Clayton Farr's text, and the ghuntley files are identical or older, so this repository is the upstream.

• The keynote lays out four planning phases: product requirements, system architecture, program design (types, signatures, layout and call stacks), then vertical slices. It argues each program-design choice is otherwise made implicitly in code review, at the most expensive time.
• It argues that models write horizontal plans (migrations, then service, API, frontend), and recommends starting in the middle with an API contract and mock data and delivering 1 to 3 small slices at a time.
• It gives a triage rule: about 40% of tasks are one-shot, medium tasks need one plan document, and only large tasks need every phase.

• The text is vested: it pitches the author's product, and the productivity figures it relays are correlation, as the author says.
• The SlopCodeBench results are single runs on a small subset, and the author says some differences are not significant.
• The essays are long (the keynote is 705 lines), so read the phases section rather than the whole post.

• The keynote says there are no good benchmarks for how well a model keeps a codebase maintainable. The author's later posts try to measure it. On SlopCodeBench with a prompt that only asks for a solution, Opus 5 passed 4 of 17 strict checkpoints (24%) and Fable 5 and GPT-5.6 Sol each passed 10 of 30 (33.3%).
• Earlier write-ups placed the research, plan, implement commands and the keynote in one repository. The commands are in humanlayer/humanlayer, and the keynote is at the root of this repository.

• The verifier-subagent skill (30 lines) says a fresh-context verifier should get the spec and the output, never the maker's reasoning, and gives a five-field handoff brief: goal, inputs, checkable definition of done, constraints, where to write.
• The scope-fence skill (28 lines) has the model decide first whether a message is a question or a change request. "Prod latency doubled after the deploy, what's going on?" gets a diagnosis, not an executed rollback.
• The lesson-memory skill says to delete a lesson proven wrong and to quarantine any lesson that reads as an instruction instead of a description of past behaviour.

• Most of the repository is a security vertical (SOC triage, scanners, a scope gate) with little use for web or CLI work, and claims about model behaviour are the author's day-one observations.
• The skills README concedes that most are standing behavioural rules a model will not reliably invoke on its own, and suggests pasting them into the project instruction file.

• The root README says "ten" skills. The plugin and the skills README list 11, because a scope-gate skill was added in the latest commit.

• The sandbox guide lists four layers for reading untrusted repositories: a container, bubblewrap with read-only binds and no network, seccomp syscall filtering, and PID, network and mount namespaces.
• It warns that without a bearer secret on the sandbox's HTTP port, anyone who can reach the port can clone repositories, execute tools and delete data, which applies to any local helper service.
• The built-in judge scores answers on completeness, evidence, sourcing and reasoning.

• The sandbox needs Docker with gVisor on Linux and a separate worker service. That is infrastructure for reading untrusted repositories at scale, not for a solo developer's own project.
• The docs lag the code in places: the layer table still says Podman or Docker after Podman support was dropped.

• Write-ups describe it as an npm package. It is published through JSR.

• codex review takes --uncommitted, --base <branch>, --commit <sha>, --title (only with --commit) and an optional custom prompt. The argument parser rejects a scope flag combined with a custom prompt.
• A -c key=value override beats the user's config.toml, but -s, --yolo and the forced approval_policy = never in headless mode beat -c. To get a read-only review regardless of the user's config, pass -s read-only before the review subcommand.
• The -m model flag is a root option, so codex -m <model> review ... works and codex review -m ... does not. A value that starts with a hyphen after -m is rejected by the parser.

• Codex has no dedicated exit codes for review: errors exit 1, parser errors exit 2 and success is 0. Any other code comes from a wrapper.
• That a review does not write is a property of the review task, not a command-line guard, so a wrapper should set the sandbox itself.
• The --full-auto flag and the codex mcp-server subcommand no longer exist, so tools that still pass them will fail.

• Earlier write-ups called --full-auto and codex mcp-server deprecated. At the commit we read (between releases 0.154.0 and 0.155.0-alpha) they are removed.

• The shrink analysis edits prompts by one rule: "say it once, positively, no examples". It collapsed 11 "don't" bullets in the doing-tasks section into one positive line.
• The cross-model capture shows Sonnet 5 and Haiku 4.5 receiving the same 2,094-word prompt while Opus 4.8 gets 383 words and Fable 5 gets 901. The author warns that self-reports undercount and only a captured request is trustworthy.
• The repository's honesty bar is worth copying: raw logs are never edited, n is stated for every cell, and null results are filed like wins.

• The comparison runs are n=1 per cell by a single author with costs at list rates, and the author warns not to quote June and July numbers together after seeing Opus score about 12% in June and 57% in July on one audit.
• The bug-hunt results moved to a separate repository in September 2026, so the table cited elsewhere is no longer in this one and is out of date.

• The shrink is quoted as "80% smaller". The author's table gives 81% with the memory block removed, 73% with it excluded from both sides and 69% with it loaded on both sides, and calls about 70% the defensible headline.

• The hook wiring uses ${CLAUDE_PLUGIN_ROOT} in the command path, a portable template for any plugin that ships a hook.
• The nopeek plugin has a PreToolUse hook that redacts Bash output; it was not reviewed in depth but is a pointer if you want that.

• The hook is an always-on all-caps mandatory sequence, which is heavier than most current models need.
• The README advertises "84% activation hooks", a figure from a synthetic Haiku 4.5 run, without saying which model it came from.

• The README's 84% activation figure carries no model line; the repository contains no measurement rig, which lives in a separate repository (spences10/svelte-claude-skills).

Not measured here. The hook text is identical to the one in spences10/svelte-claude-skills, where we measured correct skill activation rising from 62% to 93% on 41 prompts (+30.5 points, 95% CI 17.1 to 43.9) at ×1.88 output tokens per prompt, with extra skills loaded on 14 of the 41 prompts.

• The rule against destructive git commands (git reset --hard, rm, and git checkout or git restore to an older commit without explicit written instruction) is better enforced as a deny rule or a PreToolUse Bash hook than as prose.
• Setting GIT_EDITOR=: and GIT_SEQUENCE_EDITOR=: during a rebase stops git from opening an editor the agent cannot use.

• The rules about coordinating with other agents assume agents can talk to each other, which they cannot without extra setup, so they do little in a solo setup.
• The "ABSOLUTELY NEVER ... catastrophic" wording is prose that the model can argue with, and the file itself exempts Cursor and Codex Web, so the rules were tied to specific tools.
• The advice to double-check git status before every commit is obsolete for current models.

• Runtime is test time times files times mutants, so 1 minute across 10 files with 100 mutants each is 16 hours. The docs say to run it overnight, not in CI after every push.
• When a mutant that replaces code with a throw survives, it skips the less severe mutants for that line, since the line is untested anyway.
• TypeScript is a first-class language, with its own grammar and JS, JSX, TS and TSX dialects.

• There is no Python support. The supported languages are C++, DAML, Go, JavaScript/TypeScript, Rust, Solidity and Move.
• The only skill it ships is a 528-line contributor workflow for adding a language to the tool, with duplicated sections. It is not a usage skill, though it refers to one that does not exist.
• Installers cover Linux x86_64 and macOS aarch64 only; Windows is unsupported.

• Write-ups said mewt supports TypeScript but not Python. The source confirms both halves.
• Other write-ups limited it to Go and Rust. At version 4.0.0 it covers seven language families, including JavaScript and TypeScript since its earliest releases.

• The loop runs Claude with --dangerously-skip-permissions and pins --model opus; the README says a sandbox becomes the only security boundary.
• The build prompt ends in a numbered tail of rules written as 99999... priorities, and the planning prompt leans on subagent counts and "Ultrathink" nudges.

• Write-ups describe this repository as Huntley's one-line while loop. That one-liner is from his blog, not this repository; the repository ships a 69-line loop script and prompts taken from Farr's playbook.

• Write-ups listed claude-opus-4-6 as the model it uses. That name appears in no revision we examined; the only model pin at the latest commit is --model opus in an optional second-opinion script.