Explain pr step by step

Skill IcodeNet/agent-skills/skills/explain-pr-step-by-step

Explain a pull request incrementally with concept teaching and confirmation gates between steps. Use when the user asks for a step-by-step PR walkthrough, what changed and why, or asks to pause after each step for deeper understanding.From its SKILL.md

Install

npx -y skills add IcodeNet/agent-skills --skill explain-pr-step-by-step

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.6 KB, 537 tokens by cl100k_base, as published. Nobody here has run it

Explain PR Step by Step

Use this skill to teach a PR in guided, checkpointed steps.

Goal

Produce a clear sequence of changes where each step includes:

what changed,
why it changed,
the concept behind it,
a pause question before moving on.

Required workflow

Collect PR evidence first
- Fetch PR metadata (title, summary/body, commits, files).
- Fetch the full diff and per-file patches if needed.
- Do not infer chronology without checking commit/diff evidence.
Build a teaching sequence
- Group changes into understandable phases, typically:
  1. feature flag/config enablement,
  2. contracts/types,
  3. state domain/data flow,
  4. UI renderer,
  5. runtime registration/wiring,
  6. tests and safety updates.
- Keep each step focused on one core idea.
Deliver one step at a time
- For each step, include:
  - changed files/components,
  - behavioral outcome,
  - concept explanation (for example lifecycle, caching, hydration).
- End each step with an explicit checkpoint question:
  - "Need more detail before we continue to Step N+1?"
Honor drill-down questions immediately
- If user asks "where?", "show example", "what does X mean?", pause progression.
- Provide concrete code references and minimal examples.
- Resume next numbered step only after user confirms.
Use collaborative language
- Prefer "we" and "our" phrasing.
- Avoid over-abstract explanations detached from repo code.

Concept teaching rules

Always link concepts to concrete implementation, deriving examples from the PR's own diff. For example:
- Feature flag -> rollout safety and gating behavior.
- Schema/type change -> contract compatibility between producer and consumer.
- New state field -> data flow and where the source of truth lives.
- Lifecycle/status values -> what each state renders or triggers.
Keep examples small and directly relevant to current files.

Response template per step

Use this structure:

Step N: <short title>
What we changed (files and behavior)
Concept (plain-language explanation)
Why this matters
Checkpoint question ("Need more understanding before Step N+1?")

Quality bar

Steps must be accurate to the diff.
Concepts must be technically correct and simple.
User must control pacing; never dump all steps unless asked.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most explainers skills give in 537 tokens

Counted across 274 of the 289 authors here whose files we hold, read 2026-09-06

Start with an everyday-life analogyin 7 of 274, across 6 files
Use multiple analogies for complex conceptsin 6 of 274, across 5 files
Introduce one simple analogy per explanationin 6 of 274, across 4 files
Reason conversationallyin 5 of 274, across 3 files
Ask reflective questions occasionallyin 5 of 274, across 3 files
Guide the user's thinkingin 5 of 274, across 3 files
End with a reflective promptin 5 of 274, across 3 files
Keep explanations conversationalin 5 of 274, across 4 files
Build the idea step by stepin 5 of 274, across 3 files
Keep the analogy consistent throughoutin 5 of 274, across 3 files
Frame direct answers through reasoningin 5 of 274, across 3 files
Highlight a common mistake or misconceptionin 5 of 274, across 4 files

Said here and by no other author read

Group changes into understandable teaching phases
Keep each step focused on one core idea
Deliver one step at a time
End each step with a checkpoint question
Pause progression on drill-down questions
Resume the next step only after user confirms

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.