← fstackCONTENT HISTORY

Update to fstack

Snapshot Sep 30, 2026 · 23:16 UTC · version 1.1.2

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Prepare PRs for review by cleaning noisy history, improving PR descriptions, and adding reviewer guidance without changing code behavior. Use for \"make this easy to review\", \"tidy this PR\", \"clean up commits\", or \"annotate the diff\".",
  "included_files": [],
  "name": "make-pr-easy-to-review",
  "skill_md_contents": "---\r\nname: make-pr-easy-to-review\r\ndescription: Prepare PRs for review by cleaning noisy history, improving PR descriptions, and adding reviewer guidance without changing code behavior. Use for \"make this easy to review\", \"tidy this PR\", \"clean up commits\", or \"annotate the diff\".\r\nmenu-description: clean noisy history and improve PR description before review\r\n---\r\n\r\n# Make PR Easy to Review\r\n\r\nPrepare a PR so a reviewer can quickly understand the intent, important files, and risk. The default goal is reviewability without behavior changes.\r\n\r\n## Workflow\r\n\r\n1. Resolve the target PR from the user-provided URL or current branch.\r\n2. Inspect commits, diff size, changed paths, generated files, and PR description.\r\n3. Identify reviewability issues: noisy commits, stale description, unrelated changes, mixed mechanical and logic changes, missing tests, or unclear reviewer entry points.\r\n4. Propose a plan before rewriting history or force-pushing.\r\n5. Apply safe improvements, then verify the tree or diff still matches the intended code.\r\n\r\n## History Cleanup\r\n\r\nOnly rewrite history when the user asks for it or agrees to the plan. Before rewriting:\r\n\r\n```bash\r\ngh pr view <PR> --json title,headRefName,baseRefName,state,commits\r\ngit fetch origin <headRefName> <baseRefName>\r\nORIGINAL_TREE=$(git rev-parse origin/<headRefName>^{tree})\r\n```\r\n\r\nGood commit groupings usually follow dependency order:\r\n\r\n1. Schema/storage or generated API definitions.\r\n2. Core logic.\r\n3. Wiring and integration.\r\n4. UI or surface behavior.\r\n5. Tests.\r\n\r\nAfter rewriting, verify content identity:\r\n\r\n```bash\r\necho \"Original tree: $ORIGINAL_TREE\"\r\necho \"Current tree:  $(git rev-parse HEAD^{tree})\"\r\ngit diff origin/<headRefName> --stat\r\n```\r\n\r\nDo not push if the tree changed unintentionally.\r\n\r\n## Reviewer Guidance\r\n\r\nWhen code behavior should stay untouched, prefer PR description and review notes:\r\n\r\n- Add a TL;DR that matches the actual diff.\r\n- Separate core files from generated or mechanical files.\r\n- Call out risky behavior changes, migration order, rollout plan, and test coverage.\r\n- Link issue trackers, dashboards, or design docs when they explain intent.\r\n\r\n## Guardrails\r\n\r\n- Never hide meaningful behavior changes inside \"cleanup\".\r\n- Do not bypass hooks unless the user explicitly asks.\r\n- If the PR is too large to make reviewable with notes, recommend splitting instead of polishing around the problem.\r\n"
}

SHA-256 of public snapshot: 9993a33666c2b9289c25771cdbc19b2c10667e9611b7880667f05866bd42dd69