Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
cameroncooke avatar

Pr Learning

  • 1 installs
  • 44 repo stars
  • Updated July 10, 2026
  • cameroncooke/cameroncooke-skills

pr-learning is a skill that mines PR review feedback into ranked candidate rules and codifies approved ones into AGENTS.md or CLAUDE.md.

About

pr-learning is a skill that mines pull-request review feedback to extract repeatable rules and learnings. It collects review artifacts with gh, scores acceptance versus dispute, clusters patterns, and presents ranked candidates for the user to approve. Developers use it to turn recurring review feedback into durable guidance in AGENTS.md or CLAUDE.md. It dedupes against existing entries and records provenance so the same lesson is not re-added.

  • Mines PR review feedback into repeatable rules and learnings
  • Scores acceptance vs dispute and clusters repeated patterns
  • Codifies approved items into AGENTS.md or CLAUDE.md with provenance and dedupe

Pr Learning by the numbers

  • 1 all-time installs (skills.sh)
  • Ranked #982 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
  • Data as of Jul 28, 2026 (Skillselion catalog sync)
At a glance

pr-learning capabilities & compatibility

Capabilities
review mining · rule extraction · feedback clustering
Works with
github
Use cases
code review
From the docs

What pr-learning says it does

You are a Staff Engineer turning PR feedback into durable team guidance.
SKILL.md
Collect PR review artifacts (comments, threads, replies, commit context) using `gh`.
SKILL.md
**Never write AGENTS.md/CLAUDE.md before user selection.**
SKILL.md
npx skills add https://github.com/cameroncooke/cameroncooke-skills --skill pr-learning

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1
repo stars44
Last updatedJuly 10, 2026
Repositorycameroncooke/cameroncooke-skills

What it does

Extract repeatable rules from PR review feedback and codify approved ones into AGENTS.md or CLAUDE.md with provenance and dedupe.

Who is it for?

Turning recurring pull-request review feedback into durable, deduplicated team guidance.

Skip if: Promoting one-off, file-specific, or disputed feedback into strict rules.

When should I use this skill?

When mining PR review feedback to extract repeatable rules and codify approved items into AGENTS.md or CLAUDE.md.

What you get

Approved, deduplicated rules and learnings written into AGENTS.md or CLAUDE.md with provenance markers.

  • Ranked candidate rules and learnings
  • Codified AGENTS.md/CLAUDE.md entries with provenance

By the numbers

  • Default scope collects up to 200 PRs all-time (--since-days 0)

Files

SKILL.mdMarkdownGitHub ↗

PR Learning (Continuous Improvement from Review Feedback)

Your role

You are a Staff Engineer turning PR feedback into durable team guidance.

You are not summarizing PRs. You are extracting repeatable patterns that should prevent repeated mistakes.

What this skill does

1. Collect PR review artifacts (comments, threads, replies, commit context) using gh. 2. Normalize feedback into observations. 3. Score acceptance/dispute confidence. 4. Cluster repeated patterns. 5. Propose candidate Rules (strict) and Learnings (soft). 6. Ask the user to choose all, none, or selected IDs. 7. Codify approved candidates in project/user AGENTS.md or CLAUDE.md with provenance markers. 8. Persist dedupe state so the same lesson is not re-added.

Preconditions

  • gh is installed and authenticated (gh auth status).
  • python3 is available.
  • Run scripts from the target repository root.

Defaults and scope

  • Default repository: current repo from gh repo view.
  • Override repository: pass --repo owner/repo.
  • Default PR search: PRs involving the authenticated user (involves:<login>) across open + closed states.
  • Default window: all-time by default (--since-days 0) and max 200 PRs unless overridden.

Safety invariants

1. Never write AGENTS.md/CLAUDE.md before user selection. 2. Always show candidate list with evidence first. 3. Dedupe against existing codified items and stored keys before proposing writes (semantic + fuzzy keys). 4. If feedback is disputed and not clearly resolved, do not promote to strict rule. 5. Bias scope to project unless genericity and repetition are clearly strong. 6. Scripts provide deterministic pre-ranking only; the agent performs final candidate selection with reasoning.

Workflow

Step 1: Collect feedback artifacts

python3 pr-learning/scripts/collect_feedback.py --since-days 0 --limit 200

--since-days 0 means no date filtering (historical backfill mode).

If collection reports truncation due pagination, either narrow your query or explicitly accept partial data with --allow-truncated.

If discovery returns suspiciously few PRs, stop and widen discovery before candidate generation.

Useful flags:

python3 pr-learning/scripts/collect_feedback.py \
  --repo owner/repo \
  --since-days 120 \
  --limit 300 \
  --out .pr-learning/raw/feedback.json

Step 2: Build observations and ranked candidates

python3 pr-learning/scripts/build_candidates.py \
  --input .pr-learning/raw/feedback.json \
  --output-dir .pr-learning/analysis

If input is intentionally partial, add --allow-truncated-input.

Outputs:

  • .pr-learning/analysis/observations.json
  • .pr-learning/analysis/candidates.json
  • .pr-learning/analysis/duplicates.json
  • .pr-learning/analysis/report.md

Step 3: Agent shortlist (required before asking user)

Before showing options to the user, the agent must review candidates.json and classify every candidate as:

  • KEEP (plausibly reusable guidance)
  • REJECT (local/one-off/noise)

Only present KEEP candidates to the user. Never ask the user to choose from obvious REJECT items.

For each shortlisted (KEEP) candidate, include:

  • ID + type/scope suggestion + confidence
  • Proposed text (exact bullet that would be written)
  • Why it passed shortlist (1 sentence)
  • Evidence summary + source URLs + relevant thread/code context

Also include a brief filtered summary, e.g.:

  • "Filtered out 4 candidates as one-off/local feedback (rename/move/nit/file-specific)."

Then ask:

  • all
  • none
  • C001,C004,C007 (specific IDs)

Optional: ask if the user wants wording edits before codification.

Step 4: Codify approved items

Dry-run preview (default):

python3 pr-learning/scripts/codify_learnings.py \
  --candidates .pr-learning/analysis/candidates.json \
  --select C001,C004

Write changes:

python3 pr-learning/scripts/codify_learnings.py \
  --candidates .pr-learning/analysis/candidates.json \
  --select all \
  --write \
  --yes

Acceptance/dispute model

Each observation gets an explainable acceptance score.

Positive signals:

  • Reviewer positive follow-up/approval after feedback.
  • Thread resolved.
  • Author acknowledgement (e.g. "fixed", "addressed").
  • Follow-up commit after comment.

Negative signals:

  • Explicit dispute/won't-fix language.
  • Unresolved request-change patterns that merged without clear follow-up.

If dispute is explicit and no later positive reviewer signal exists, treat as disputed.

Selection rubric (default: reject)

The script output is a candidate pool, not final decisions. The agent should only present candidates to the user when they are likely reusable guidance.

Hard reject candidates when any apply:

  • Pure one-off/local comments (rename this variable, move this helper, file-specific nit)
  • Disputed feedback with no later confirmation
  • Non-actionable phrasing
  • Guidance tied to a single line/object with no forward scope
  • Change request that only affects naming/layout without durable policy value
  • Business-logic-specific feedback that only applies to one endpoint/feature/path and does not generalize

Accept as project-scope when all apply:

  • Accepted signal is meaningful (not disputed)
  • Actionable phrasing exists
  • Likely reusable in other areas of the codebase
  • Reads as a future rule, not as a PR-specific observation
  • Not tightly coupled to one piece of business logic

Accept as user-scope only when clearly generic and broadly reusable across repositories.

Positive examples:

  • "Prefer explicit errors over silent fallback behavior"
  • "Use camelCase for TypeScript identifiers"

Reject examples:

  • "skillLabel is identical to skillDirName"
  • "rename foo to bar"
  • "move this helper"
  • "this variable name is redundant in this file"
  • "swap this function call order in this one code path"
  • "for this endpoint, apply business rule X before Y"

Scope decision

  • Project scope if feedback references project APIs, modules, paths, architecture, or local process.
  • User scope only if pattern is generic, repeated, and accepted across multiple PRs/reviewers.

Target file precedence

Project scope: 1. ./AGENTS.md (if exists) 2. ./CLAUDE.md (if AGENTS missing) 3. else create ./AGENTS.md

User scope (Codex): 1. ~/.codex/AGENTS.md 2. ~/.codex/CLAUDE.md 3. else create ~/.codex/AGENTS.md

User scope (Claude mode): same precedence under ~/.claude/.

Dedupe and provenance

Dedupe uses three layers: 1. Source IDs (exact comment/thread duplicates). 2. Semantic key (normalized principle hash). 3. Fuzzy key (simhash on normalized tokens).

Codified bullets include machine-readable provenance comments:

- Prefer ?? over || for default values unless falsy values are intentionally treated as empty.
  <!-- pr-learning:v=1 type=rule scope=project key=... sim=... sources=PR#12,PR#44 confidence=0.88 -->

Output contract

At the end, report:

1. Repo + query used. 2. PRs scanned and feedback artifacts parsed. 3. Candidate count by type (rule, learning). 4. Selected IDs and skipped duplicates. 5. Exact write targets. 6. Inserted bullet text.

References

  • pr-learning/references/SCORING.md
  • pr-learning/references/SCOPE_RULES.md
  • pr-learning/references/DEDUPE.md
  • pr-learning/assets/candidate.schema.json
  • pr-learning/assets/store.schema.json

Notes

  • codify_learnings.py --write requires --yes.
  • --tool codex|claude controls user-level store and write targets.

Related skills

FAQ

Does pr-learning write files automatically?

No. It never writes AGENTS.md or CLAUDE.md before the user selects candidates, and shows the candidate list with evidence first.

How does it avoid re-adding the same lesson?

It dedupes against existing codified items and stored keys using semantic and fuzzy matching before proposing writes.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.