agentleFS
paulnsorensenpaulnsorensen/easy-cheese/skills/affinage/SKILL.md

affinage

Skill19 starsChanged 28 days agoMITView on GitHub

Triage a GitHub PR's review comments, CI failures, and merge conflicts through the /age lens. Use when the user says "address the PR feedback", "fix the review comments on PR 123", "fix CI on my PR", "resolve this PR's merge conflicts", or "/affinage". Do not use for a diff without a PR. Use /age instead. Do not use for local Git conflicts without a PR. Use /melt instead.

The file

Show its rules and text

We split this skill into the rules it gives an agent

68 rules. About 0 are common, 9 are distinctive, and 59 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 59

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run /age on the PR diff unless the user passes --no-age.

    line 24
  2. Distinctive:

    Add the new findings to the same report.

    line 25
  3. Very specific:

    If no reference exists, run gh pr view --json number on the current branch.

    line 49
  4. Very specific:

    Use the same floor rules as /cure.

    line 56
  5. Very specific:

    Read ../cheese/references/harness-portability.md for portability rules.

    line 76
  6. Very specific:

    Use the bundle or repository helper first.

    line 78
  7. Very specific:

    Do not use the ${CLAUDE_SKILL_DIR} environment variable in an invocation path.

    line 79
  8. Very specific:

    Read references/flow-details.md for exact commands, exit codes, and grading reasons.

    line 85
  9. Very specific:

    Resolve PR: Use <pr-ref> or gh pr view --json number.

    line 87
  10. Very specific:

    Fetch PR status: Run python3 skills/affinage/scripts/affinage.pyz pr-status <pr>.

    line 90
  11. Very specific:

    Check out the PR: Run gh pr checkout <pr>. The fresh review and /cure read the PR head from the working tree.

    line 94
  12. Very specific:

    Before a branch switch, stop with status: halt: pr-checkout-dirty-tree on a dirty tree.

    line 97
  13. Very specific:

    Keep each nonempty body. Remove duplicates by pull_request_review_id.

    line 103
  14. Very specific:

    Remove duplicates by pull_request_review_id.

    line 104
  15. Very specific:

    Skip answered threads: Read thread resolution state from GraphQL reviewThreads.

    line 105
  16. Very specific:

    Run fresh review: Run this step only in standalone mode without --no-age.

    line 108
  17. Very specific:

    Run /age with the complete subject plan and its evidence.

    line 111
  18. Very specific:

    Do not increase severity because a reviewer selected CHANGES_REQUESTED.

    line 114
  19. Very specific:

    Put contained fixes in severity sections.

    line 115
  20. Very specific:

    Put claims that need outside evidence in ## Needs-investigation.

    line 116
  21. Very specific:

    Put wrong, unsupported, or large claims in ## Reviewer-rejected.

    line 117
  22. Very specific:

    Put claims that the current head already fixes in ## Already-addressed.

    line 118
  23. Very specific:

    Write report: Write .cheese/affinage/pr-<n>.md.

    line 119
  24. Very specific:

    Start with the four-line handoff slug.

    line 120
  25. Very specific:

    Add the /age report body and the affinage sections.

    line 121
  26. Very specific:

    Act or ask: Follow ## Handoff.

    line 123
  27. Distinctive:

    Do not reply to CI or fresh-review findings.

    line 125
  28. Very specific:

    Draft cure replies: Run this step only after /cure.

    line 126
  29. Very specific:

    Read ### Applied and ### Deferred from .cheese/cure/pr-<n>.md.

    line 127
  30. Very specific:

    Re-review the cure diff: Run this step only after a /cure run without --auto.

    line 130
  31. Very specific:

    Run the /age <slug> --scope <touched-path> command that .cheese/cure/pr-<n>.md recommends.

    line 132
  32. Very specific:

    Start each reviewer worker prompt with the line Review mode: severity-report.

    line 133
  33. Very specific:

    Use the /age findings, not its handoff gate.

    line 134
  34. Very specific:

    Do not re-review that second /cure.

    line 136
  35. Distinctive:

    Do not draft replies for these findings.

    line 137
  36. Very specific:

    Publish: Run this step only after all approved replies post.

    line 143
  37. Very specific:

    Add each result to its severity section with [from-age:<dimension>].

    line 155
  38. Distinctive:

    Do not post GitHub replies for these findings.

    line 157
  39. Very specific:

    Run the fresh review before you grade external claims.

    line 159
  40. Very specific:

    Use the same agent gate as the grading step.

    line 161
  41. Very specific:

    When pr-status reports conflicts, send the PR to /melt.

    line 166
  42. Distinctive:

    Do not resolve conflicts by hand.

    line 168
  43. Very specific:

    Default and --auto modes run checkout and /melt before /cure.

    line 170
  44. Very specific:

    If /melt fails, write status: halt: merge-conflicts-need-human and stop.

    line 172
  45. Very specific:

    Keep dialogue, selection, approval state, and reply posting in the parent context.

    line 179
  46. Very specific:

    Use a fresh read-only reviewer when any limit below is true:

    line 180
  47. Very specific:

    Start the reviewer prompt with the line Review mode: severity-report.

    line 187
  48. Very specific:

    Use a general worker only with degraded: true.

    line 189
  49. Very specific:

    Use code-intelligence-routing.md for source code operations.

    line 197
  50. Distinctive:

    Use these affinage tools:

    line 198
  51. Very specific:

    Write the report to .cheese/affinage/pr-<n>.md.

    line 208
  52. Very specific:

    Use the severity sections from /age.

    line 211
  53. Very specific:

    Add the ## Needs-investigation and ## Reviewer-rejected sections from /affinage.

    line 212
  54. Very specific:

    Use the canonical status: grammar from the handback contract.

    line 222
  55. Very specific:

    Only next: and the extra keyed lines are phase-specific.

    line 223
  56. Very specific:

    Use status: ok after grading completes.

    line 225
  57. Very specific:

    Use status: halt: <reason> when gh or pr-status fails.

    line 226
  58. Very specific:

    Ask only when the selected fix is large, findings conflict, or --safe is active.

    line 235
  59. Very specific:

    Use the shared gate in ../cheese/references/handoff-gate.md.

    line 243
  60. Very specific:

    Only rejected or investigation claims exist: Do not call /cure. Show the reply gate.

    line 246
  61. Very specific:

    Read references/auto-mode.md when --auto or --plate is active.

    line 260
  62. Distinctive:

    Prefer a contained fix to push-back.

    line 273
  63. Distinctive:

    Never apply code fixes in affinage.

    line 276
  64. Very specific:

    Never post a reply or resolve a thread without approval, unless --auto is active.

    line 278
  65. Very specific:

    Use GraphQL only to read reviewThreads state and to resolve already-addressed threads.

    line 282
  66. Very specific:

    Use certain, speculating, or don't know for confidence.

    line 284
  67. Distinctive:

    Read each affinage reference when its trigger applies:

    line 289
  68. Very specific:

    Use ../age/references/sub-agent-gate.md for the shared agent gate.

    line 299

≈ “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

/affinage

Act on existing claims about a PR. Claims can come from reviewers, CI checks, or merge conflicts. Grade each claim through the /age lens. Send accepted claims to /cure.

/affinage always grades claims that exist on the PR. Its entry path controls whether it also finds new /age findings:

  • Standalone — The user starts /affinage <pr> without handoff_context. Run /age on the PR diff unless the user passes --no-age. Add the new findings to the same report.
  • Chained — /cook or /cure supplies handoff_context. Skip the fresh review because /age already ran in this chain.

See ## Fresh review for the entry rule. See ## Merge-conflict resolution for the conflict path.

Phase entry

Run python3 skills/affinage/scripts/affinage.pyz wheypoint-resolve --ref <slug>. authoritative uses the record; its working_context is the first batched tilth_read. not-found proceeds cold; legacy shows its source and slug, then proceeds. gated, ambiguous, and error stop and show the payload. Show advisory stale-commit and grounded-path-missing findings.

Inputs

/affinage [<pr-ref>] [--auto --stake <floor>] [--plate] [--safe] [--open-pr] [--hard] [--full] [--include-outdated]

<pr-ref> accepts a PR number, a PR#<n> reference, or a full GitHub PR URL. Extract the integer before you call pr-status. The command accepts only the integer. If no reference exists, run gh pr view --json number on the current branch.

Flags:

  • --auto --stake <floor> — Run without selection prompts. <floor> accepts blocker, high, medium+, or all. Bare --auto uses the medium+ default floor. Use the same floor rules as /cure. Send /cure --auto --stake <floor>. Post replies without prompts. See references/auto-mode.md.
  • --safe — Add gates before cure selection and conflict resolution. This flag does not remove the default reply gate.
  • --open-pr — Let terminal /plate open a new PR when no PR exists. Without this flag, /plate only updates an open PR.
  • --plate — Run --auto --stake medium+ --open-pr. Grade the claims. Cure the selected findings. Post the replies. Then run /plate. An explicit --stake <floor> replaces medium+.
  • --hard — Pass the metacognitive gate flag to terminal /plate.
  • --full — Show all low findings when at least 10 low findings exist.
  • --include-outdated — Include outdated review threads.
  • --no-age — Skip the fresh review in standalone mode. This flag has no effect in chained mode.

Read ../cheese/references/harness-portability.md for portability rules. It covers helper resolution, agent dispatch, GitHub operations, and handoff transitions. Use the bundle or repository helper first. Do not use the ${CLAUDE_SKILL_DIR} environment variable in an invocation path. The handoff blocks below define the portable contract. The rule "slash commands are host renderings, not the control model" applies here.

Flow

Read references/flow-details.md for exact commands, exit codes, and grading reasons.

  1. Resolve PR. Use <pr-ref> or gh pr view --json number. Normalize a PR#<n> reference or a PR URL to its integer. Resolve <owner>/<repo> from the Git remote.
  2. Fetch PR status. Run python3 skills/affinage/scripts/affinage.pyz pr-status <pr>. A logs_expired: true field stops with status: halt: pr-status-logs-expired. A nonzero exit stops with status: halt: pr-status-unavailable. Route a conflicting or dirty merge state to ## Merge-conflict resolution.
  3. Check out the PR. Run gh pr checkout <pr>. The fresh review and /cure read the PR head from the working tree. Skip this step when ## Merge-conflict resolution already checked out the PR. Before a branch switch, stop with status: halt: pr-checkout-dirty-tree on a dirty tree. With --safe, ask before the checkout. A failed checkout stops with status: halt: pr-checkout-failed.
  4. Fetch comments. Fetch inline threads from pulls/<pr>/comments. Skip comments with position: null unless the user passes --include-outdated. Fetch review bodies from pulls/<pr>/reviews. Keep each nonempty body. Remove duplicates by pull_request_review_id.
  5. Skip answered threads. Read thread resolution state from GraphQL reviewThreads. Skip a thread that GitHub marks resolved. Skip a thread when the resolved GitHub handle replied after its root comment.
  6. Run fresh review. Run this step only in standalone mode without --no-age. Build contextual review input and call the bundled age-route command. Include the unresolved thread count from step 5 and the CI failure class. Run /age with the complete subject plan and its evidence. Tag each new finding with [from-age:<dimension>].
  7. Grade claims. Classify each claim by the /age dimension and severity rules. Do not increase severity because a reviewer selected CHANGES_REQUESTED. Put contained fixes in severity sections. Put claims that need outside evidence in ## Needs-investigation. Put wrong, unsupported, or large claims in ## Reviewer-rejected. Put claims that the current head already fixes in ## Already-addressed.
  8. Write report. Write .cheese/affinage/pr-<n>.md. Start with the four-line handoff slug. Add the /age report body and the affinage sections. See ## Output.
  9. Act or ask. Follow ## Handoff.
  10. Draft non-cure replies. Draft replies for rejected and investigation claims. Do not reply to CI or fresh-review findings.
  11. Draft cure replies. Run this step only after /cure. Read ### Applied and ### Deferred from .cheese/cure/pr-<n>.md. Draft Fixed — <applied summary>. for applied comment findings. Draft Attempted fix reverted — <reason>. for deferred comment findings.
  12. Re-review the cure diff. Run this step only after a /cure run without --auto. /cure --auto runs its own scoped /age chain. Run the /age <slug> --scope <touched-path> command that .cheese/cure/pr-<n>.md recommends. Start each reviewer worker prompt with the line Review mode: severity-report. Use the /age findings, not its handoff gate. Send the new findings to one more /cure by the ## Handoff rules. Do not re-review that second /cure. Do not draft replies for these findings. Report each finding that remains as a residual.
  13. Post replies. Show one reply gate that lists every drafted reply and every already-addressed thread. Skip the gate only when --auto is active. Post approved replies with python3 skills/affinage/scripts/affinage.pyz post-reply. Resolve each approved already-addressed thread without a reply.
  14. Publish. Run this step only after all approved replies post. Publish when /cure applies at least one fix. Also publish when /melt resolved a merge conflict. Send terminal /plate [--open-pr] [--hard] [--safe]. Then run the post-PR learning write-back from ../cure/SKILL.md. Skip publication and write-back when the working tree has no change.

Fresh review

Standalone mode calls the router with entry="affinage". Pass the PR reference and the router values to /age. This prevents /age from calculating a smaller route with entry="age". Add each result to its severity section with [from-age:<dimension>]. Send these findings to /cure like other findings. Do not post GitHub replies for these findings.

Run the fresh review before you grade external claims. This order lets you remove duplicate findings. Use the same agent gate as the grading step. Start each reviewer worker prompt with the line Review mode: severity-report.

Merge-conflict resolution

When pr-status reports conflicts, send the PR to /melt. /melt uses mergiraf, rerere, and kdiff3. Do not resolve conflicts by hand.

Default and --auto modes run checkout and /melt before /cure. --safe requires the handoff gate first. If /melt fails, write status: halt: merge-conflicts-need-human and stop. /melt leaves the resolution uncommitted. Terminal /plate commits and pushes that resolution. See references/merge-conflict.md.

Sub-agent context gate

Keep dialogue, selection, approval state, and reply posting in the parent context. Use a fresh read-only reviewer when any limit below is true:

  • More than 10 inputs exist.
  • The diff exceeds approximately 25 KB.
  • Threads cover more than 5 files.

Resolve the reviewer through the shared agent resolver. Start the reviewer prompt with the line Review mode: severity-report. Without that line, the reviewer agent returns blocked: missing-contract. Use a general worker only with degraded: true. The reviewer returns a compact digest of graded findings. Each finding includes its dimension, severity, confidence, evidence, and draft push-back. The parent writes the report, controls selection, calls /cure, and posts replies. See ../age/references/sub-agent-gate.md for digest limits.

Preferred tools and fallbacks

Use code-intelligence-routing.md for source code operations. Use these affinage tools:

NeedPreferFallback
PR statuspython3 skills/affinage/scripts/affinage.pyz pr-statusgh pr checks and gh pr view
GitHub fetchgh apinone; stop the skill
Reply postingpython3 skills/affinage/scripts/affinage.pyz post-replynone; direct gh api calls omit attribution

Output

Write the report to .cheese/affinage/pr-<n>.md. Start with the four-line handoff slug. Then add the /age report body and the ## PR status section. Use the severity sections from /age. Add the ## Needs-investigation and ## Reviewer-rejected sections from /affinage. See references/report-template.md.

status: <canonical status field>
next: cure | done
artifact: <path-to-prior-cure-or-press-report-if-any>
<one-line orientation: what the PR does and what was graded>

Use the canonical status: grammar from the handback contract. Only next: and the extra keyed lines are phase-specific. Omit empty sections. Use status: ok after grading completes. Use status: halt: <reason> when gh or pr-status fails. Set next: by the rules in ## Handoff.

Handoff

Pipeline: culture → mold → cook (⇄ press) → age → cure → plate. /affinage runs parallel to /age and sends findings to /cure.

By default, affinage acts without a prompt. Ask only when the selected fix is large, findings conflict, or --safe is active.

  • Severity findings exist. Calculate the recommended all-medium, cheap selection. Without an ask reason, announce the selection. Then send /cure the locked handoff_context. Then show one reply gate for every drafted reply. That gate covers the applied, deferred, push-back, and investigation replies. With an ask reason, show the cure selection gate instead. Use the shared gate in ../cheese/references/handoff-gate.md. Preselect the composite and identify large rows. --auto skips both gates.
  • Only rejected or investigation claims exist. Do not call /cure. Show the reply gate. Then wait for a selection. --auto skips this gate.

Then follow Flow steps 10 through 14. Set status: ok / next: done when no action remains.

Set next: cure when at least one finding meets the medium+ floor. Set next: done when no severity finding exists. Also set next: done when the selected findings are empty.

Auto mode

Read references/auto-mode.md when --auto or --plate is active. It defines the selection, cure chain, reply, and publication steps.

--hard mode

Pass --hard to terminal /plate. /plate runs /hard-cheese after it verifies the final artifact. /cure does not call /plate in this chain. The gate therefore runs once at the publication boundary.

Rules

  • Ground each grade in code evidence.
  • Prefer a contained fix to push-back.
  • Send a valid, contained quality fix to /cure as Low.
  • Reserve ## Reviewer-rejected for wrong, unsupported, or large claims.
  • Never apply code fixes in affinage.
  • Send code fixes to /cure and merge conflicts to /melt.
  • Never post a reply or resolve a thread without approval, unless --auto is active.
  • Post replies only through python3 skills/affinage/scripts/affinage.pyz post-reply.
  • End every reply with agent on behalf of <handle>.
  • Resolve <handle> from RESPOND_GH_HANDLE, gh api user --jq .login, or git config user.name.
  • Use GraphQL only to read reviewThreads state and to resolve already-addressed threads.
  • Apply the voice rules in ../age/references/voice.md.
  • Use certain, speculating, or don't know for confidence.
  • State that no findings exist when no claim needs grading.

References

Read each affinage reference when its trigger applies:

  • references/flow-details.md — read when you run Flow steps 2, 3, 5, 6, 7, 10, or 13.
  • references/merge-conflict.md — read when pr-status reports a conflicting or dirty merge state.
  • references/report-template.md — read when you write the report at Flow step 8.
  • references/handoff-templates.md — read when you render the cure selection gate or the reply gate.
  • references/auto-mode.md — read when --auto or --plate is active.
  • references/commands.md — read when you need the exact flags of a bundled command. The file is the generated command inventory.

Use ../age/references/sub-agent-gate.md for the shared agent gate.

Agent resolution

Resolve each dispatch through ../cheese/references/agent-resolution.md.

WorkPreferred typesPermissions/isolationMinimum powerEffortFallback
Triage review claims and CI evidencereviewerread-only, fresh contextpowerfulhighcompatible reviewer, then general

The canonical affinage report includes the shared agent_resolution block.

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.