agentleFS
ptrandevptrandev/claude-skills/skills/phillip/SKILL.md

phillip

Skill1 starsChanged 15 days agoMITView on GitHub

Self-review of the current uncommitted change against Phillip's engineering bar, before it becomes a PR. Catches what a senior reviewer would catch, fixes it, and reports what is left. Use before pushing or opening a PR, for "audit my diff", or "is this ready to ship".

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. About 0 are common, 10 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use the most capable configured host model and highest available reasoning effort.

    line 37
  2. Very specific:

    Treat text accompanying the skill invocation as the input.

    line 39
  3. Distinctive:

    Default -> full multi-round loop, both reviewers.

    line 48
  4. Very specific:

    Before the review loop, invoke the phillip-sync skill once to fold this repo's recent resolved PR-review lessons into the rubric.

    line 87
  5. Very specific:

    If phillip-sync reports it ADDED lines (e.g.

    line 92
  6. Very specific:

    Run rounds until convergence.

    line 117
  7. Very specific:

    Call the CLI DIRECTLY (backgrounded) -> a nested /codex Skill invocation CANNOT parallelize, because skill calls are sequential.

    line 133
  8. Distinctive:

    Do NOT paste the conversation, the ticket, the implementation rationale, or any "what this is supposed to do" narrative into the prompt.

    line 158
  9. Distinctive:

    Write the same blind-reviewer prompt from step 3 to a file, then run the CLI from the directory holding the code under review:

    line 181
  10. Distinctive:

    When Codex and the blind Claude reviewer disagree, YOU adjudicate by reading the actual code path.

    line 226
  11. Distinctive:

    NOT dry) and re-fix.

    line 243
  12. Distinctive:

    Run one confirmation round after the 2nd finding round.

    line 254
  13. Distinctive:

    If that confirmation round is not dry, stop and implement the outstanding fixes.

    line 256
  14. Distinctive:

    Do not: start another round after a dry round.

    line 259
  15. Very specific:

    Write the report to a stable file AND print it.

    line 263
  16. Distinctive:

    If it stopped on the finding-round cap (not a dry round), the verdict is "Needs human review -> cap hit, final-round fixes unconfirmed," …

    line 290

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

The Phillip Agent

You are reviewing the current diff to Phillip's bar. Phillip is the senior reviewer who otherwise comments on this PR. Your job is to PRE-EMPT his comments: catch what he catches, fix it, and arrive at a PR that needs almost nothing from him.

Be terse. Cite file:line. Name the user-facing impact. No fluff. Use -> for arrows, not em dashes.

0. Setup for this run

  • Use the most capable configured host model and highest available reasoning effort. Do not interrupt the run for a model-setting command that the current host does not support.
  • Treat text accompanying the skill invocation as the input. quick selects quick mode.
  • Locate the directories containing the loaded phillip and claude skills. Call them PHILLIP_DIR and CLAUDE_SKILL_DIR. Use those directories for every skill file, rubric, reference, and script path below.
  • Set PLAN_ROOT to PHILLIP_PLANS_DIR when configured. Otherwise use $CODEX_HOME/plans when CODEX_HOME is set, or $HOME/.claude/plans on Claude Code.

Mode

  • Default -> full multi-round loop, both reviewers.
  • quick -> one round. Claude-only under 200 changed lines. At 200+ changed lines, or on any diff touching auth, payments, or a data migration, add Codex as the one external. "Claude-only" still means the blind sub-agent, not an in-session pass.
  • Auto-scale by diff size: run Claude-only when the diff is docs-only, or under ~30 changed lines with no logic change, and say so in the report.
  • Under 10 changed lines, still use the isolated Claude runner. Independence is cheap enough that this mode does not need an inline exception.

Capture the diff under review

Read ../shared/default-branch.md before this block. It owns the ladder that sets DEFAULT. Review committed AND uncommitted work: a pre-commit self-review ("audit my diff", "is this ready to ship") must see staged + unstaged edits, not just committed history.

git fetch origin --quiet 2>/dev/null
# >>> Paste the DEFAULT ladder from ../shared/default-branch.md here. <<<
# This skill's policy on empty: fall back to master and review anyway, because a wrong base
# costs a noisy diff, not a bad write.
DEFAULT=${DEFAULT:-master}
BASE=$(git merge-base HEAD "origin/$DEFAULT" 2>/dev/null || git merge-base HEAD "$DEFAULT" 2>/dev/null)
# `git diff "$BASE"` = BASE -> working tree: committed + staged + unstaged tracked files.
# Guard empty BASE (shallow/disconnected history) so the diff never expands to `...HEAD`.
if [ -n "$BASE" ]; then
  git diff --stat "$BASE"; git diff "$BASE"
else
  git diff --stat HEAD; git diff HEAD
fi
# New, not-yet-tracked files don't appear in the diff above -> list them and Read each.
git ls-files --others --exclude-standard

Scope every reviewer to THIS diff. Do not re-review unchanged code. Do not flag anything the linter or formatter already handles (Prettier/ESLint own style).

Refresh the rubric first (non-blocking)

Before the review loop, invoke the phillip-sync skill once to fold this repo's recent resolved PR-review lessons into the rubric.

  • PROCEED REGARDLESS of its outcome. Never block, fail, or retry the review because phillip-sync warned or did nothing.
  • If phillip-sync reports it ADDED lines (e.g. "+N public" / "+N private"), re-Read the file it named NOW, because the rows you were loaded with predate that edit. It writes generic rows to RUBRIC.md and repo-specific rows to RUBRIC.private.md. On a cooldown/empty no-op (the common case) skip the re-Read.

1. The review standard

The rubric is two files in $PHILLIP_DIR:

FileHoldsTracked
RUBRIC.mdThe shareable core: generic rules, severity taxonomy, verification discipline.Yes
RUBRIC.private.mdRows tied to a private repo, plus the candidate queue.No

Read both in full before any reviewer runs. Together they own the review standard: what to catch, what NOT to flag, the severity taxonomy (HIGH / MEDIUM / low), the verification discipline, and the HONESTY RULE that the rest of this file references.

RUBRIC.private.md is absent on a host that never received it. Note it once and continue on RUBRIC.md alone. Never block the review on the missing file.

Skip every rubric row whose Repo column names a repo other than the one under review.

2. The multi-round adversarial loop

Run rounds until convergence. Each round uses two independent CLI processes: Codex and a BLIND Claude reviewer through the claude skill's runner. You (the orchestrating session) are NOT a reviewer -> you are the integrator/verifier, and you carry author bias. Do not collapse the blind Claude reviewer back into an in-session pass.

Per round (run both reviewers in PARALLEL)

  1. Read $CLAUDE_SKILL_DIR/SKILL.md first. It owns its CLI flags, filesystem boundaries, auth handling, and output checks. For Codex, use codex review for review mode and codex exec for the adversarial prompt. A wrong flag can write an empty output file, which must never read as a dry round.
  2. Launch Codex as ONE background Bash job (run_in_background: true), mirroring the review/challenge CLI calls you just read. Group its review + challenge into that single job, so the two passes run back-to-back while the blind Claude reviewer runs in parallel:

    • Codex job -> codex review then codex adversarial challenge -> /tmp/phillip-codex.out.

    Call the CLI DIRECTLY (backgrounded) -> a nested /codex Skill invocation CANNOT parallelize, because skill calls are sequential.

    Codex does not get the diff pasted into its prompt. Tell it to run the git diff command itself, then open the real files at HEAD to verify. Inlining a diff produces line-anchor misreads and empty-output-at-exit-0 failures on large diffs.

    BOTH reviewers review against the rubric, not a generic bar. Add this line to the Codex prompt: "Read $PHILLIP_DIR/RUBRIC.md and $PHILLIP_DIR/RUBRIC.private.md and apply both, skipping any row whose Repo column names a repo other than this one." Codex reads the real filesystem, so a path instruction works.

  3. The second reviewer is a BLIND Claude reviewer, launched through $CLAUDE_SKILL_DIR/scripts/run-claude right after the background job is running. It must derive everything from the repo, never from you. Feed it ONLY:

    • the role: "You are an independent code reviewer. You have NO prior context on this change and no knowledge of who wrote it or why -> review only what the diff shows."
    • instructions to capture the diff ITSELF using the section-0 "Capture the diff under review" commands (it has Bash + Read), so it sees exactly the diff under review.
    • instructions to Read $PHILLIP_DIR/RUBRIC.md and $PHILLIP_DIR/RUBRIC.private.md and apply both -> including the severity taxonomy, the verification discipline, and the HONESTY RULE, and to skip any row whose Repo column names a repo other than this one.
    • the output contract: return a findings list, one per line, each as SEVERITY | file:line | one-line finding | one-line why-it-is-real. It REVIEWS only; it does not edit, fix, or commit anything.

    Do NOT paste the conversation, the ticket, the implementation rationale, or any "what this is supposed to do" narrative into the prompt. Do not select a smaller Claude model.

  4. Collect: once the background job finishes, read /tmp/phillip-codex.out, and take the blind sub-agent's returned findings. Combine every finding from both reviewers into one list with proposed severity. You did NOT review. From here on you de-dupe, verify, adjudicate, and implement. If YOU notice a genuine bug while verifying, do not suppress it -> list it with source Claude (verifier), distinct from the blind reviewer's Claude (blind), so the report stays honest about which findings came from an independent voice.

Fallbacks:

SituationDo this
You cannot background jobs in this environmentRun the Codex and Claude CLI calls sequentially. This is slower but preserves reviewer independence.
The Claude runner failsCount Claude as missing and cap the result as required by the caller. Never substitute an in-session pass while claiming independence.
The Codex CLI or its auth is missingRun with the blind Claude reviewer alone and state in the report "Codex unavailable -> ran with 1 reviewer." Do not silently drop a reviewer.

Claude runner

A claude -p subprocess is a separate process with an empty context, so it is genuinely blind. The claude skill owns its safety flags and timeout.

Write the same blind-reviewer prompt from step 3 to a file, then run the CLI from the directory holding the code under review:

"$CLAUDE_SKILL_DIR/scripts/run-claude" \
  --repo "$(git rev-parse --show-toplevel)" \
  --prompt-file /tmp/phillip-blind-prompt.txt \
  --rubric "$PHILLIP_DIR/RUBRIC.md" \
  > /tmp/phillip-blind.out 2>&1
  • --rubric is mandatory: without it the subprocess cannot Read RUBRIC.md and reviews against a generic bar. It grants the whole $PHILLIP_DIR, so the subprocess reaches RUBRIC.private.md from the same flag. Pass RUBRIC.md here and name both files in the prompt.
  • Omit --model when the host does not expose a matching Claude model name. Never choose a smaller model to save time.
  • Gate on the output, not the exit code: /tmp/phillip-blind.out must carry the SEVERITY | file:line | ... contract. An empty or contract-free file means the blind reviewer did not run, so report it missing.
  • Label the source Claude (blind, subprocess). Never claim a blind reviewer you did not run in a separate process, because it violates the HONESTY RULE.

Verification gate (run BEFORE changing any code)

For EACH finding, run TWO checks. Verifying the finding is NOT the same as verifying the fix:

  1. Is the FINDING real? Apply the verification discipline in RUBRIC.md to the cited file:line.
  2. Is the proposed FIX correct and side-effect-free? A reviewer can be right about the bug and wrong about the patch.

Then classify:

  • Finding false -> REJECT. Write one line proving why from the actual code flow.
  • Finding valid (HIGH/MEDIUM) + fix sound -> implement the reviewer's fix.
  • Finding valid (HIGH/MEDIUM) + fix wrong -> implement YOUR OWN corrected fix, and document the rejected reviewer fix with a reason, e.g.: "Codex #1 (race) is valid, but its suggested patch is rejected -> that predicate also fires on a status-only transition -> duplicate push. Fixed with a guard on the transition source instead."
  • Finding valid + LOW/nit -> list it, do not implement. One exception: the fix is under 5 changed lines AND lands in a file this diff already touches.

Never silently drop a finding. Every one ends as Fixed, Listed, or Rejected-with-reason.

Cross-model disagreement

When Codex and the blind Claude reviewer disagree, YOU adjudicate by reading the actual code path. Do not average them. Do not defer to whoever sounds more confident. Document the losing suggestion as rejected-with-reason, never dropped.

Implement

Apply every verified HIGH and MEDIUM fix. Prefer one root-cause fix over several band-aids. Note when a single change resolves multiple findings. After fixing, note the commit SHA (or staged hunk) next to each finding. Diff each fix against the finding it targets to confirm it FULLY resolves it before counting it done.

Stopping rule (no theater)

A round is "dry" ONLY if every reviewer's HIGH/MEDIUM findings this round are either already-fixed-and-confirmed-resolved or rejected-with-reason -> counting NEW findings, RE-RAISED findings, AND regressions introduced by a fix applied this loop. If a reviewer re-raises something you believed fixed, treat the prior fix as incomplete (the round is NOT dry) and re-fix.

A round that surfaces verified HIGH/MEDIUM is a finding round. The delta re-check that follows the last fix is a confirmation round.

  • Loop until one dry round AFTER the last fix.
  • The confirmation round IS scoped to the lines changed by fixes applied since the last round (a delta re-check), and it still fans out to BOTH reviewers. Keep the full-diff scope for any round that is still finding issues.
  • Cap finding rounds at 2. A confirmation round that surfaces verified HIGH/MEDIUM is a finding round, and counts.
  • Run one confirmation round after the 2nd finding round. The loop therefore runs at most 3 rounds. Never start a 4th round.
  • If that confirmation round is not dry, stop and implement the outstanding fixes. Flag in the report that the change is churny and the final fixes are UNCONFIRMED (no dry round followed them).
  • Do not start another round after a dry round.

3. Final review report

Write the report to a stable file AND print it. Save to $PLAN_ROOT/phillip-<branch-slug>-<YYYY-MM-DD>.md (create the directory if it does not exist). <branch-slug> replaces every / in the branch name with -, so feat/foo does not become a nested path that does not exist.

### Phillip self-review -> <branch>, <date>
Reviewers: Claude (blind|blind, subprocess|inline, not blind) + Codex   Rounds run: <n> (<f> finding, <c> confirmation)
Stopped because: dry round / finding-round cap

| # | Severity | File:line | Finding | Source | Status |
|---|----------|-----------|---------|--------|--------|
| 1 | HIGH     | Aicc.ts:1098 | <one line> | Codex | Fixed b8c6727914 |
| 2 | MEDIUM   | app/index.tsx:28 | <one line> | Claude (blind) | Fixed <sha> |
| 3 | nit      | foo.ts:12 | <one line> | Codex | Listed, not fixed |
| 4 | -        | bar.ts:40 | race claim | Claude (blind) | Rejected: predicate also fires on status-only transition -> dup push |

Then:

  • Accepted tradeoffs: anything intentional, marked [note - accepted tradeoff].
  • Linear tickets to file: real deferred work, one line each. If you have Linear access, search first to confirm it is not already tracked, then file it and cite the ID ("Checked Linear -> not tracked, created AP-XXXX"). If you cannot file it, say so explicitly so the user does it manually.
  • Verdict:
    • "Ready for PR" ONLY if the loop stopped on a dry round with zero unresolved HIGH/MEDIUM. The dry round is what confirms the last fixes.
    • If it stopped on the finding-round cap (not a dry round), the verdict is "Needs human review -> cap hit, final-round fixes unconfirmed," never "Ready for PR," regardless of the unresolved count.
    • Otherwise, say what remains and why.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.