[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C45X0Z4VVEWC04CM2EMCXC":3,"skill-same:01M6C45X0Z4VVEWC04CM2EMCXC":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6C45X0Z4VVEWC04CM2EMCXC","post-pr-review",null,"Post-merge checklist for archiving, documentation, versioning, and release tagging. Use when completing post-merge cleanup, archiving tracking files, updating docs, or running the pre-merge strategic assessment (Step 6). DO NOT USE FOR: pre-PR readiness checks (use verification-before-completion) or processing GitHub review comments (use code-review-intake).","Grimblaz\u002Fagent-orchestra","Grimblaz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F74755849?v=4","01M6C430M9XZDHGHPWQVTQ3KMA","01M6C430RJY3MMX0QAZ3X8DR3Y",3,"MIT","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fpost-pr-review\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"post pr review","pr review","pr","review","code","updating docs","use","versioning","orchestrate","intake","verification","code-review","release","run","cleanup","assessment","documentation","merge","workflow","github","2026-11-10 10:12:30",false,"---\nname: post-pr-review\ndescription: \"Post-merge checklist for archiving, documentation, versioning, and release tagging. Use when completing post-merge cleanup, archiving tracking files, updating docs, or running the pre-merge strategic assessment (Step 6). DO NOT USE FOR: pre-PR readiness checks (use verification-before-completion) or processing GitHub review comments (use code-review-intake).\"\nprovides: post-pr\nsuggested-next-step: Run \u002Forchestrate {ISSUE} or follow post-pr-review skill workflow\n---\n\n# Post-PR Review\n\n## When to Use\n\nExecute this workflow **after**:\n\n- Pull Request has been reviewed\n- All feedback has been addressed\n- PR has been merged to the main branch\n- CI\u002FCD pipeline has completed successfully\n\nOr use the strategic assessment section only (Step 6) **before merging** to evaluate design alignment and long-term implications before approving a PR.\n\n**Step 9 (Close-Out Record) is not gated on a merged PR.** It fires whenever an issue that was opened for work is about to be closed, including an issue closed without a pull request. Do not read the merged-PR trigger above as a reason to skip it.\n\n**And on a run that will open a pull request, the record is owed earlier than this document is read at all** — before the PR-creation action, stated on the brief that run is dispatched against (`skills\u002Fplan-authoring\u002FSKILL.md` § The close-out obligation on an affirmation-record issue). Step 9 owns the record's shape at both moments; it is not the only place the obligation is stated, and by the time a reader arrives here through the post-merge trigger above, moment 1 has already passed.\n\nBe clear about who reaches it on that path, because no dispatcher does: the post-merge checklist is invoked by Code-Conductor's cleanup path, which presupposes a PR. For a PR-less close the reader is the **conversation closing the issue**, routed here by `skills\u002Fopen-for-work\u002FSKILL.md` § Resuming an issue already opened for work (`complete` state). That is a documented reader, not an automated one — nothing fires Step 9 on its own, so an issue closed by hand outside any conversation will not get a close-out record unless someone runs this step deliberately.\n\n> **Note for plugin-only users**: Step 6 (Strategic Assessment) is available without cloning — it's pure analysis using GitHub tools.\n\n## Purpose\n\nThis document provides a standardized checklist for agents to follow after a Pull Request has been reviewed, approved, and merged. These steps ensure proper cleanup, documentation, and project maintenance.\n\n## Standard Post-Merge Checklist\n\n### 1. Archive Tracking Files\n\n**Action**: Move completed tracking files into the local archive. These directories are gitignored — they stay on your machine only.\n\n```powershell\n# Preferred: use the cleanup script (handles archival, branch deletion, git sync).\n# The script is shipped with the agent-orchestra plugin\u002Fclone and self-resolves its paths.\npwsh \"skills\u002Fsession-startup\u002Fscripts\u002Fpost-merge-cleanup.ps1\" -IssueNumber {ID} -FeatureBranch feature\u002Fissue-{ID}-description\n# Optional: also pass sibling worktrees or orphan branches for composite cleanup (see session-startup SKILL.md § Permission allowlist):\n# pwsh \"skills\u002Fsession-startup\u002Fscripts\u002Fpost-merge-cleanup.ps1\" -IssueNumber {ID} -FeatureBranch feature\u002Fissue-{ID}-description -OrphanBranches @('claude\u002Fold-branch') -SiblingWorktrees @('path\u002Fto\u002Fworktree')\n\n# Or manual archive only (PowerShell):\n$archivePath = Join-Path \".copilot-tracking-archive\" (Get-Date -Format 'yyyy') (Get-Date -Format 'MM') \"issue-{ID}\"\nNew-Item -Path $archivePath -ItemType Directory -Force\nGet-ChildItem .copilot-tracking -Recurse -File |\n    Where-Object { (Get-Content $_.FullName -Raw) -match 'issue_id:\\s*{ID}' } |\n    ForEach-Object { Move-Item -LiteralPath $_.FullName -Destination $archivePath }\n```\n\n**Note**: Both `.copilot-tracking\u002F` and `.copilot-tracking-archive\u002F` are gitignored. These files are agent scaffolding — the durable record lives in GitHub issues, PRs, commits, and `Documents\u002FDesign\u002F`. Do not commit tracking files.\n\n**Verify**:\n\n- Files moved to `.copilot-tracking-archive\u002F{year}\u002F{month}\u002Fissue-{ID}\u002F`\n- No tracking files remain in `.copilot-tracking\u002Fresearch\u002F` for this issue\n\n> **Automation**: The plugin's `SessionStart` hook detects stale tracking files, sibling worktrees, and orphan branches and prompts you at the start of your next conversation — cleanup requires one confirmation and runs as a single composite `pwsh ...post-merge-cleanup.ps1 ...` invocation (no per-branch permission prompts). You can also run the script directly: `pwsh \"skills\u002Fsession-startup\u002Fscripts\u002Fpost-merge-cleanup.ps1\" -IssueNumber {ID} -FeatureBranch feature\u002Fissue-{ID}-description` (script path is relative to the agent-orchestra plugin or repo clone). See the `### Permission allowlist (recommended)` subsection in `skills\u002Fsession-startup\u002FSKILL.md` for opt-in allowlist entries that suppress the single prompt.\n\n### 2. Update Documentation\n\n**Action**: Ensure all relevant documentation reflects the changes.\n\n**Common Documentation to Review**:\n\n- [ ] README.md - Updated if features\u002Fsetup changed\n- [ ] CHANGELOG.md - Entry added for this change\n- [ ] API documentation - Updated if interfaces changed\n- [ ] Architecture docs - Updated if structure changed\n- [ ] User guides - Updated if user-facing changes\n- [ ] Configuration examples - Updated if settings changed\n\n**Guidelines**:\n\n- Be specific about what changed\n- Include version numbers where applicable\n- Link to related issues or PRs\n- Update any diagrams or visual documentation\n\n### 3. Version Badge Updates (If Applicable)\n\n**Action**: Use the bump-version script to update version strings consistently across all files in one invocation:\n\n```powershell\npwsh .github\u002Fscripts\u002Fbump-version.ps1 -Version X.Y.Z -DryRun  # preview first\npwsh .github\u002Fscripts\u002Fbump-version.ps1 -Version X.Y.Z           # apply\n```\n\nThe script updates `plugin.json`, `.claude-plugin\u002Fplugin.json`, `.claude-plugin\u002Fmarketplace.json` (2 occurrences), `.github\u002Fplugin\u002Fmarketplace.json` (2 occurrences), and `README.md` (badge line) — 7 occurrences across 5 files. It validates pre-bump consistency and exits with an error if any file has drifted.\n\n**Plugin-only users** (scripts not distributed via plugin): If you're using this workflow as a plugin install without cloning, use targeted `replace_string_in_file` edits for each file individually, then commit and push.\n\n**WRONG** (do not use):\n\n```text\n# mcp_github_create_or_update_file with partial file content\n# This tool REPLACES the entire file. Only use it for net-new files.\n# Using it with partial content silently truncates the rest of the file.\n```\n\n**Rule**: `mcp_github_create_or_update_file` is only safe for **new files**. For any edit to an existing file, use the bump script (cloned repo) or `replace_string_in_file` + `git commit` + `git push` (plugin-only).\n\n### 4. Tag Releases (If Applicable)\n\n**Action**: Create version tags for significant releases.\n\n**When to Tag**:\n\n- Feature releases (minor version bump)\n- Bug fix collections (patch version bump)\n- Breaking changes (major version bump)\n- Milestone completions\n\n**Semantic Versioning**:\n\n- `MAJOR.MINOR.PATCH` (e.g., `v1.2.3`)\n- **MAJOR**: Breaking changes\n- **MINOR**: New features (backward compatible)\n- **PATCH**: Bug fixes (backward compatible)\n\n**Process**:\n\n```bash\n# Example commands (adapt to your project)\ngit tag -a v1.2.0 -m \"Release version 1.2.0: Added feature X\"\ngit push origin v1.2.0\n```\n\n**Release Notes**:\n\n- Summarize changes from CHANGELOG\n- Highlight breaking changes\n- Include upgrade instructions if needed\n\n### 5. Clean Up Branches\n\n**Action**: Remove merged feature branches.\n\n```bash\n# Delete local branch\ngit branch -d feature\u002Fissue-{ID}-description\n\n# Delete remote branch (if not auto-deleted by PR merge)\ngit push origin --delete feature\u002Fissue-{ID}-description\n```\n\n**Note**: Some projects auto-delete branches on PR merge. Verify your project settings.\n\n> **Automation**: Branch deletion is also handled by `skills\u002Fsession-startup\u002Fscripts\u002Fpost-merge-cleanup.ps1` when invoked via the \"Session Startup Check\" cleanup flow (see Section 1 above).\n\n### 6. Strategic Assessment (Pre-Merge)\n\n**Action**: Before approving a PR, evaluate strategic alignment on three dimensions.\n\n**Design Alignment**:\n\n- Does the implementation match the design doc (`Documents\u002FDesign\u002F{domain}.md`)?\n- Are any design decisions reversed or partially implemented?\n- If the design doc doesn't exist yet, does the implementation align with the issue's stated goals?\n\n**Roadmap Integration**:\n\n- Does this change fit the project's stated direction?\n- Any unintended coupling introduced that will constrain future work?\n- Are there deprecations triggered or migration concerns created?\n\n**Long-Term Implications**:\n\n- Tech debt introduced — is it tracked (labeled issue or comment)?\n- Are there performance, scale, or maintenance concerns not covered in tests?\n- Would this pass the \"6-month-later developer\" readability test?\n\n**Output**: Emit one of:\n\n- `✅ Strategic assessment: aligned` — no concerns\n- `⚠️ Strategic assessment: concerns noted` — list specific items; may block PR\n- `⏭️ Strategic assessment: skipped — {reason}` — e.g., documentation-only change\n\n### 7. Update Project Tracking\n\n**Action**: Close related issues. The portfolio tracker issue updates automatically.\n\nThe derived portfolio tracker (`Documents\u002FPlanning\u002Fsequence.yaml` + `render-portfolio.yml` workflow) re-renders the control-tower issue after every merge to `main` — no manual board update is required. The board model (ranked-umbrella zones, derived Triage) is documented in [Documents\u002FDesign\u002Fcontrol-tower-v2.md](..\u002F..\u002FDocuments\u002FDesign\u002Fcontrol-tower-v2.md).\n\n**Manual fallback** (if the workflow did not run or needs a forced refresh):\n\n```powershell\n# Guard: skip silently in consumer repos that lack the renderer\nif ((Test-Path 'Documents\u002FPlanning\u002Fsequence.yaml') -and (Test-Path '.github\u002Fscripts\u002Frender-portfolio.ps1')) {\n    pwsh .github\u002Fscripts\u002Frender-portfolio.ps1\n}\n```\n\n> **Consumer repos**: if `Documents\u002FPlanning\u002Fsequence.yaml` or `.github\u002Fscripts\u002Frender-portfolio.ps1` is absent, this step is a no-op — skip silently.\n\n**Verification**:\n\n- [ ] Related issues closed or updated\n- [ ] Control-tower issue reflects current state (auto-rendered or manual fallback run)\n\n### 8. Notify Stakeholders (If Applicable)\n\n**Action**: Communicate completion to relevant parties.\n\n**Notification Scenarios**:\n\n- Feature releases → Announce to users\u002Fteam\n- Breaking changes → Alert dependent teams\n- Bug fixes → Notify affected users\n- Security patches → Follow security disclosure process\n\n**Communication Channels** (adapt to your project):\n\n- GitHub issue comments\n- Team chat channels\n- Email notifications\n- Release announcements\n- Documentation updates\n\n### 9. Close-Out Record (Issues Opened For Work)\n\n**Applies to**: an issue that was **opened for work** through the open-for-work entrance — one carrying an affirmation record. **Does not apply otherwise.** An ordinary pull-request close on an issue that never ran that flow has no close-out record to write and no re-route count to report; check for the affirmation record first, and when there is none, skip this step and say so rather than manufacturing an empty record.\n\n**How to check** — run the lookup in `skills\u002Fopen-for-work\u002FSKILL.md` § Resuming an issue already opened for work. That section is the only place both recognised record forms are defined, and it is the instruction here, not an inference: read the issue's comments through `gh api repos\u002F{owner}\u002F{repo}\u002Fissues\u002F{ID}\u002Fcomments --paginate` (never `gh issue view --json comments`, which carries no `updated_at`), accept either the registered marker form or the interim practiced form's exact first line, and discard any record edited after creation. **Zero lawful records → skip this step.**\n\n**Action**: write one close-out comment on the issue, carrying three things.\n\n**Its first line is exactly** `**Close-out record - issue {ID}**` (bold, ASCII only — a plain hyphen, deliberately no em dash given this repository's console-encoding history; `{ID}` is the issue number). This is identification, not decoration: the record is amendable in place (`skills\u002Fplan-authoring\u002FSKILL.md` § The close-out obligation on an affirmation-record issue), and a later run cannot amend a comment it cannot pick out. Recognise a record by that line. **This is a first-line convention, not a marker family** — no marker, no `persist-marker.ps1` write path, and deliberately so, since a new family is machinery this work declined.\n\n**An amendment says it is one.** *When* a run amends is not decided here — that trigger has one home, `skills\u002Freview-judgment\u002FSKILL.md` § Close-Out Record Amendment, which fires at each judge pass's own emission on every lane that runs a judge. This step owns only the shape below. A run amending an existing record appends a dated line naming itself and what changed — *\"Amended {date} by the run for PR #{N}: {what changed}.\"* — rather than silently rewriting. **When the amending run has no pull request**, which the amendment trigger's ordinary route makes reachable, name the run instead of inventing a number: *\"Amended {date} by the {lane} run on issue #{ID}: {what changed}.\"* Do not omit the identification and do not fabricate a `#{N}`; a record is recognised as amended by this line's shape, so an off-template line reads as original text. The record is a public artifact whose first writer is often a person, not this run, and an unannounced in-place rewrite of someone else's comment leaves a reader unable to tell an amendment from the original. When the comment's author is not the amending run, say so in that line.\n\n**Render marker-like text inert.** Item 1 folds in finding text, including findings derived from external reviewers, and this repository's findings routinely name marker families. A literal HTML-comment marker in the record is live to the raw-text scanners that read real comments, so strip the delimiters when quoting one (`skills\u002Fsession-memory-contract\u002Freferences\u002Fhandoff-markers.md` § Writing about markers safely). Backticks do not neutralise it.\n\nThe three things:\n\n1. **One line per sustained finding** — where it was introduced, where it was catchable, where it was caught. This is the phase-containment ledger's own grain, and this step **does not emit ledger blocks**: the emission mechanics belong to `Documents\u002FDesign\u002Fphase-containment-ledger.md` and the plan-surface ledger those blocks already live on. Point at that ledger and summarise from it; do not re-emit it here.\n\n   **When no ledger exists** — reachable on a PR-less close, and on a novel-arm parent closed after its chunks carried their own reviews — say exactly that: *\"No phase-containment ledger was produced for this issue; no sustained findings to summarise.\"* Do not invent a ledger reference, and do not silently omit the item. An absent ledger is a fact about the issue, not a gap in the record.\n\n   **Not-yet is a different state from absent, and at moment 1 it is the normal one.** A record written before the PR-creation action necessarily predates its own review, so no ledger exists *yet* — and the sentence above would be a false claim about the issue rather than a true one. Say instead: *\"No phase-containment ledger exists yet; this record is provisional and is amended once review completes.\"* Reserve the absent form for a close where no ledger will ever be produced.\n2. **A dead-premises note** — which filed premises beat 1's grounding falsified and amended in place, so the next reader does not resurrect them.\n3. **The beat-2 re-route count** — how many times the escape hatch re-ran the routing. Zero is the common case and is reportable. **The count is what the run observed, not an arithmetic on comment counts.** Records-minus-one is a cross-check that legitimately disagrees in three directions: a record voided by a later edit still evidences a re-route that happened, a re-affirmation with an unchanged what-statement can append nothing at all, and a retried write can append twice for one re-route. Report the observed count, note how many affirmation records the issue carries and how many are lawful, and when those disagree say so and why.\n\n**When to write it — two moments, and the second is not a fallback for the first.**\n\n1. **Before the PR-creation action**, on a run that will open a pull request. That run meets this obligation earlier than this step: it is stated on the brief the run is dispatched against, at `skills\u002Fplan-authoring\u002FSKILL.md` § The close-out obligation on an affirmation-record issue. This step owns the record's shape; that section owns when the obligation is read.\n2. **Before the close** (`## Completion` below), **whenever moment 1 did not already produce the record on this issue**. Keyed on whether the record exists, **not** on whether a pull request exists. An issue closed by hand **without a pull request** is the obvious instance; it is not the only one. An issue also closes on a **closing keyword in a pull request belonging to a different issue** — a designed parent auto-closed by one of its own chunk PRs is exactly that, and moment 1 never fired for it, because the parent has no brief and the chunk that closed it owes no record of its own. A backstop keyed on PR-absence would miss that population while reading as complete.\n\n**Why it binds: the run ends at the close.** Afterwards there is no conversation left to write anything — which is how two of the six issues that owed a record got none at all.\n\n**It is not, as this step used to say, that a closed issue cannot be found.** That reason was false at the grain this step itself reads: the lookup above is number-keyed and state-blind, so a record written a minute *after* the close sits on the issue exactly as reachably as one written a minute before.\n\n**The limit that does hold — do not over-read the correction into \"ordering never matters.\"** A closed issue stays reachable by a number-keyed read and **ages out of time-windowed sweeps**: this repository's portfolio render and its rolling-history ledger both scan closed issues through a `closed:>=` \u002F `closed:>` search window. A late record is not lost, but it can fall outside a sweep that goes looking for it by date.\n\n## Validation Checklist\n\nBefore considering work fully complete, verify:\n\n- [ ] Close-out record written (issues opened for work only — Step 9; skip with a stated reason when the issue carries no affirmation record)\n- [ ] No test failure in main branch that this work introduced, measured against a named baseline commit; any failure already present at that baseline is named and routed rather than carried silently (`skills\u002Fverification-before-completion\u002FSKILL.md` § The Completion Account)\n- [ ] No merge conflicts or issues\n- [ ] Tracking files moved to `.copilot-tracking-archive\u002F{year}\u002F{month}\u002Fissue-{ID}\u002F` (local only — do not commit)\n- [ ] Documentation is current and accurate\n- [ ] Version badge updated (if version bumped) via bump script (`pwsh .github\u002Fscripts\u002Fbump-version.ps1 -Version X.Y.Z`); plugin-only installs: `replace_string_in_file` + git — not GitHub file API\n- [ ] Release tagged (if applicable) via `git tag` + `git push origin \u003Ctag>`\n- [ ] GitHub release created with release notes\n- [ ] Branches cleaned up\n- [ ] Project tracking updated\n- [ ] Stakeholders notified (if needed)\n- [ ] Working tree clean: `git status` shows no untracked or modified files\n\n## Project-Specific Customization\n\n**[CUSTOMIZE]** Add project-specific steps:\n\n- Deployment procedures\n- Database migration verification\n- Cache invalidation\n- CDN purging\n- Monitoring setup\n- Alert configuration\n- Dependency updates\n- Security scans\n- Performance benchmarks\n\n## Emergency Rollback\n\nIf critical issues are discovered post-merge:\n\n1. **Immediate**: Revert the merge commit\n2. **Communication**: Alert team and stakeholders\n3. **Investigation**: Identify root cause\n4. **Resolution**: Create hotfix PR\n5. **Documentation**: Record incident and resolution\n\n```bash\n# Revert merge commit\ngit revert -m 1 \u003Cmerge-commit-hash>\ngit push origin main\n```\n\n## Completion\n\nOnce all checklist items are verified:\n\n- Write the close-out record if the issue was opened for work (Step 9) — this happens **before** the close, not after, and on a run that opened a pull request it was already owed **before the PR-creation action**; if it is not there by now, it is late, so write it and say so\n- Mark the original issue as closed\n- Remove any temporary resources\n- Archive any temporary documentation\n- Verify control-tower issue updated (auto-rendered by workflow after merge)\n\nThe work is now fully complete and properly documented.\n\n## Structured Outcome Contract\n\nWhen invoked from Code-Conductor's post-merge cleanup path, this skill returns a structured outcome hashtable with the following shape:\n\n```powershell\n@{\n    archive    = 'passed' | 'failed' | 'skipped'\n    docs       = 'passed' | 'failed' | 'skipped'\n    version    = 'passed' | 'failed' | 'skipped'\n    releaseTag = 'passed' | 'failed' | 'skipped'\n}\n```\n\n**Per-key outcome determination**:\n\n- `archive`: `passed` when tracking files were moved\u002Farchived and `git status` is clean; `failed` when archiving was attempted but incomplete; `skipped` when no tracking files existed.\n- `docs`: `passed` when README, CLAUDE.md, or ROADMAP edits land or explicit skip rationale is documented; `failed` when documentation is known to be out of date; `skipped` when no documentation scope applied.\n- `version`: `passed` when plugin manifest version bumps are verified (`bump-version.ps1` completed or version is already correct); `failed` when manifests are out of sync; `skipped` when no version-bump scope applied.\n- `releaseTag`: `passed` when the release tag exists on the merged commit or explicit skip rationale exists; `failed` when the tag was expected but is absent; `skipped` when no release-tag scope applied.\n\nCode-Conductor passes this hashtable to `Build-PostPrCreditRow -ChecklistOutcomes @{...}` to emit the `post-pr` credit row into the PR-body pipeline-metrics block.\n\n**Step 9 (close-out record) is deliberately not a key here.** The contract's four keys are the ones `Build-PostPrCreditRow` consumes; adding a fifth would change a shape Code-Conductor already reads. The close-out record is an issue comment written at Step 9, and its absence on an issue that was opened for work is a checklist miss rather than a credit-row outcome.\n\n## Gotchas\n\n| Trigger                                                                    | Gotcha                                                                                 | Fix                                                                                    |\n| -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |\n| `git status` shows `.copilot-tracking\u002F` files as untracked                 | These are gitignored local scaffolding, not team artifacts                             | Never `git add` them; use GitHub issues and `Documents\u002FDesign\u002F` for durable records    |\n| Updating an existing file using `mcp_github_create_or_update_file`         | Tool replaces the entire file; partial content silently truncates to just the new text | Use `replace_string_in_file` + `git commit` + `git push` for existing files            |\n| Restoring a file from git history using `Set-Content` or `Out-File`        | PowerShell may add BOM or CRLF causing noisy diffs                                     | Use `git restore --source=\u003Csha> \u003Cfile>` instead                                        |\n| Looking for the `Documents\u002FDesign\u002F` file before the PR is merged           | The file is created by Code-Conductor in the PR diff, not in the repo pre-merge        | Check the PR diff, not the repo, for the design doc                                    |\n| Version bump using `mcp_github_create_or_update_file` with partial content | Tool replaces entire file; version bump deletes all other content                      | Use `pwsh .github\u002Fscripts\u002Fbump-version.ps1 -Version X.Y.Z` or `replace_string_in_file` |\n| \"PR merged — done\" without running the cleanup checklist                   | Stale branches persist; related issues stay open; version history unclear              | Run the full post-merge checklist (Steps 1–5) before declaring done                    |\n| Skipping the pre-merge strategic assessment (Step 6 \u002F SAR)                 | Missing the window to catch low-quality patterns before they set precedent             | Complete Step 6 SAR before committing to merge on any >Medium impact PR                |\n| Archiving tracking files before committing documentation                   | PR created without updated design docs and changelog                                   | Follow checklist order: documentation first, then archive                              |\n\n## Frame Ports Filled By This Skill\n\n| Port | Work adapter | Explicit-skip adapter |\n| --- | --- | --- |\n| `post-pr` | This `SKILL.md` frontmatter declares `provides: post-pr` | [adapters\u002Fpost-pr-explicit-skip-adapter.md](adapters\u002Fpost-pr-explicit-skip-adapter.md) |\n","# Post-PR Review\n\n## When to Use\n\nExecute this workflow **after**:\n\n- Pull Request has been reviewed\n- All feedback has been addressed\n- PR has been merged to the main branch\n- CI\u002FCD pipeline has completed successfully\n\nOr use the strategic assessment section only (Step 6) **before merging** to evaluate design alignment and long-term implications before approving a PR.\n\n**Step 9 (Close-Out Record) is not gated on a merged PR.** It fires whenever an issue that was opened for work is about to be closed, including an issue closed without a pull request. Do not read the merged-PR trigger above as a reason to skip it.\n\n**And on a run that will open a pull request, the record is owed earlier than this document is read at all** — before the PR-creation action, stated on the brief that run is dispatched against (`skills\u002Fplan-authoring\u002FSKILL.md` § The close-out obligation on an affirmation-record issue). Step 9 owns the record's shape at both moments; it is not the only place the obligation is stated, and by the time a reader arrives here through the post-merge trigger above, moment 1 has already passed.\n\nBe clear about who reaches it on that path, because no dispatcher does: the post-merge checklist is invoked by Code-Conductor's cleanup path, which presupposes a PR. For a PR-less close the reader is the **conversation closing the issue**, routed here by `skills\u002Fopen-for-work\u002FSKILL.md` § Resuming an issue already opened for work (`complete` state). That is a documented reader, not an automated one — nothing fires Step 9 on its own, so an issue closed by hand outside any conversation will not get a close-out record unless someone runs this step deliberately.\n\n> **Note for plugin-only users**: Step 6 (Strategic Assessment) is available without cloning — it's pure analysis using GitHub tools.\n\n## Purpose\n\nThis document provides a standardized checklist for agents to follow after a Pull Request has been reviewed, approved, and merged. These steps ensure proper cleanup, documentation, and project maintenance.\n\n## Standard Post-Merge Checklist\n\n### 1. Archive Tracking Files\n\n**Action**: Move completed tracking files into the local archive. These directories are gitignored — they stay on your machine only.\n\n```powershell\n# Preferred: use the cleanup script (handles archival, branch deletion, git sync).\n# The script is shipped with the agent-orchestra plugin\u002Fclone and self-resolves its paths.\npwsh \"skills\u002Fsession-startup\u002Fscripts\u002Fpost-merge-cleanup.ps1\" -IssueNumber {ID} -FeatureBranch feature\u002Fissue-{ID}-description\n# Optional: also pass sibling worktrees or orphan branches for composite cleanup (see session-startup SKILL.md § Permission allowlist):\n# pwsh \"skills\u002Fsession-startup\u002Fscripts\u002Fpost-merge-cleanup.ps1\" -IssueNumber {ID} -FeatureBranch feature\u002Fissue-{ID}-description -OrphanBranches @('claude\u002Fold-branch') -SiblingWorktrees @('path\u002Fto\u002Fworktree')\n\n# Or manual archive only (PowerShell):\n$archivePath = Join-Path \".copilot-tracking-archive\" (Get-Date -Format 'yyyy') (Get-Date -Format 'MM') \"issue-{ID}\"\nNew-Item -Path $archivePath -ItemType Directory -Force\nGet-ChildItem .copilot-tracking -Recurse -File |\n    Where-Object { (Get-Content $_.FullName -Raw) -match 'issue_id:\\s*{ID}' } |\n    ForEach-Object { Move-Item -LiteralPath $_.FullName -Destination $archivePath }\n```\n\n**Note**: Both `.copilot-tracking\u002F` and `.copilot-tracking-archive\u002F` are gitignored. These files are agent scaffolding — the durable record lives in GitHub issues, PRs, commits, and `Documents\u002FDesign\u002F`. Do not commit tracking files.\n\n**Verify**:\n\n- Files moved to `.copilot-tracking-archive\u002F{year}\u002F{month}\u002Fissue-{ID}\u002F`\n- No tracking files remain in `.copilot-tracking\u002Fresearch\u002F` for this issue\n\n> **Automation**: The plugin's `SessionStart` hook detects stale tracking files, sibling worktrees, and orphan branches and prompts you at the start of your next conversation — cleanup requires one confirmation and runs as a single composite `pwsh ...post-merge-cleanup.ps1 ...` invocation (no per-branch permission prompts). You can also run the script directly: `pwsh \"skills\u002Fsession-startup\u002Fscripts\u002Fpost-merge-cleanup.ps1\" -IssueNumber {ID} -FeatureBranch feature\u002Fissue-{ID}-description` (script path is relative to the agent-orchestra plugin or repo clone). See the `### Permission allowlist (recommended)` subsection in `skills\u002Fsession-startup\u002FSKILL.md` for opt-in allowlist entries that suppress the single prompt.\n\n### 2. Update Documentation\n\n**Action**: Ensure all relevant documentation reflects the changes.\n\n**Common Documentation to Review**:\n\n- [ ] README.md - Updated if features\u002Fsetup changed\n- [ ] CHANGELOG.md - Entry added for this change\n- [ ] API documentation - Updated if interfaces changed\n- [ ] Architecture docs - Updated if structure changed\n- [ ] User guides - Updated if user-facing changes\n- [ ] Configuration examples - Updated if settings changed\n\n**Guidelines**:\n\n- Be specific about what changed\n- Include version numbers where applicable\n- Link to related issues or PRs\n- Update any diagrams or visual documentation\n\n### 3. Version Badge Updates (If Applicable)\n\n**Action**: Use the bump-version script to update version strings consistently across all files in one invocation:\n\n```powershell\npwsh .github\u002Fscripts\u002Fbump-version.ps1 -Version X.Y.Z -DryRun  # preview first\npwsh .github\u002Fscripts\u002Fbump-version.ps1 -Version X.Y.Z           # apply\n```\n\nThe script updates `plugin.json`, `.claude-plugin\u002Fplugin.json`, `.claude-plugin\u002Fmarketplace.json` (2 occurrences), `.github\u002Fplugin\u002Fmarketplace.json` (2 occurrences), and `README.md` (badge line) — 7 occurrences across 5 files. It validates pre-bump consistency and exits with an error if any file has drifted.\n\n**Plugin-only users** (scripts not distributed via plugin): If you're using this workflow as a plugin install without cloning, use targeted `replace_string_in_file` edits for each file individually, then commit and push.\n\n**WRONG** (do not use):\n\n```text\n# mcp_github_create_or_update_file with partial file content\n# This tool REPLACES the entire file. Only use it for net-new files.\n# Using it with partial content silently truncates the rest of the file.\n```\n\n**Rule**: `mcp_github_create_or_update_file` is only safe for **new files**. For any edit to an existing file, use the bump script (cloned repo) or `replace_string_in_file` + `git commit` + `git push` (plugin-only).\n\n### 4. Tag Releases (If Applicable)\n\n**Action**: Create version tags for significant releases.\n\n**When to Tag**:\n\n- Feature releases (minor version bump)\n- Bug fix collections (patch version bump)\n- Breaking changes (major version bump)\n- Milestone completions\n\n**Semantic Versioning**:\n\n- `MAJOR.MINOR.PATCH` (e.g., `v1.2.3`)\n- **MAJOR**: Breaking changes\n- **MINOR**: New features (backward compatible)\n- **PATCH**: Bug fixes (backward compatible)\n\n**Process**:\n\n```bash\n# Example commands (adapt to your project)\ngit tag -a v1.2.0 -m \"Release version 1.2.0: Added feature X\"\ngit push origin v1.2.0\n```\n\n**Release Notes**:\n\n- Summarize changes from CHANGELOG\n- Highlight breaking changes\n- Include upgrade instructions if needed\n\n### 5. Clean Up Branches\n\n**Action**: Remove merged feature branches.\n\n```bash\n# Delete local branch\ngit branch -d feature\u002Fissue-{ID}-description\n\n# Delete remote branch (if not auto-deleted by PR merge)\ngit push origin --delete feature\u002Fissue-{ID}-description\n```\n\n**Note**: Some projects auto-delete branches on PR merge. Verify your project settings.\n\n> **Automation**: Branch deletion is also handled by `skills\u002Fsession-startup\u002Fscripts\u002Fpost-merge-cleanup.ps1` when invoked via the \"Session Startup Check\" cleanup flow (see Section 1 above).\n\n### 6. Strategic Assessment (Pre-Merge)\n\n**Action**: Before approving a PR, evaluate strategic alignment on three dimensions.\n\n**Design Alignment**:\n\n- Does the implementation match the design doc (`Documents\u002FDesign\u002F{domain}.md`)?\n- Are any design decisions reversed or partially implemented?\n- If the design doc doesn't exist yet, does the implementation align with the issue's stated goals?\n\n**Roadmap Integration**:\n\n- Does this change fit the project's stated direction?\n- Any unintended coupling introduced that will constrain future work?\n- Are there deprecations triggered or migration concerns created?\n\n**Long-Term Implications**:\n\n- Tech debt introduced — is it tracked (labeled issue or comment)?\n- Are there performance, scale, or maintenance concerns not covered in tests?\n- Would this pass the \"6-month-later developer\" readability test?\n\n**Output**: Emit one of:\n\n- `✅ Strategic assessment: aligned` — no concerns\n- `⚠️ Strategic assessment: concerns noted` — list specific items; may block PR\n- `⏭️ Strategic assessment: skipped — {reason}` — e.g., documentation-only change\n\n### 7. Update Project Tracking\n\n**Action**: Close related issues. The portfolio tracker issue updates automatically.\n\nThe derived portfolio tracker (`Documents\u002FPlanning\u002Fsequence.yaml` + `render-portfolio.yml` workflow) re-renders the control-tower issue after every merge to `main` — no manual board update is required. The board model (ranked-umbrella zones, derived Triage) is documented in [Documents\u002FDesign\u002Fcontrol-tower-v2.md](..\u002F..\u002FDocuments\u002FDesign\u002Fcontrol-tower-v2.md).\n\n**Manual fallback** (if the workflow did not run or needs a forced refresh):\n\n```powershell\n# Guard: skip silently in consumer repos that lack the renderer\nif ((Test-Path 'Documents\u002FPlanning\u002Fsequence.yaml') -and (Test-Path '.github\u002Fscripts\u002Frender-portfolio.ps1')) {\n    pwsh .github\u002Fscripts\u002Frender-portfolio.ps1\n}\n```\n\n> **Consumer repos**: if `Documents\u002FPlanning\u002Fsequence.yaml` or `.github\u002Fscripts\u002Frender-portfolio.ps1` is absent, this step is a no-op — skip silently.\n\n**Verification**:\n\n- [ ] Related issues closed or updated\n- [ ] Control-tower issue reflects current state (auto-rendered or manual fallback run)\n\n### 8. Notify Stakeholders (If Applicable)\n\n**Action**: Communicate completion to relevant parties.\n\n**Notification Scenarios**:\n\n- Feature releases → Announce to users\u002Fteam\n- Breaking changes → Alert dependent teams\n- Bug fixes → Notify affected users\n- Security patches → Follow security disclosure process\n\n**Communication Channels** (adapt to your project):\n\n- GitHub issue comments\n- Team chat channels\n- Email notifications\n- Release announcements\n- Documentation updates\n\n### 9. Close-Out Record (Issues Opened For Work)\n\n**Applies to**: an issue that was **opened for work** through the open-for-work entrance — one carrying an affirmation record. **Does not apply otherwise.** An ordinary pull-request close on an issue that never ran that flow has no close-out record to write and no re-route count to report; check for the affirmation record first, and when there is none, skip this step and say so rather than manufacturing an empty record.\n\n**How to check** — run the lookup in `skills\u002Fopen-for-work\u002FSKILL.md` § Resuming an issue already opened for work. That section is the only place both recognised record forms are defined, and it is the instruction here, not an inference: read the issue's comments through `gh api repos\u002F{owner}\u002F{repo}\u002Fissues\u002F{ID}\u002Fcomments --paginate` (never `gh issue view --json comments`, which carries no `updated_at`), accept either the registered marker form or the interim practiced form's exact first line, and discard any record edited after creation. **Zero lawful records → skip this step.**\n\n**Action**: write one close-out comment on the issue, carrying three things.\n\n**Its first line is exactly** `**Close-out record - issue {ID}**` (bold, ASCII only — a plain hyphen, deliberately no em dash given this repository's console-encoding history; `{ID}` is the issue number). This is identification, not decoration: the record is amendable in place (`skills\u002Fplan-authoring\u002FSKILL.md` § The close-out obligation on an affirmation-record issue), and a later run cannot amend a comment it cannot pick out. Recognise a record by that line. **This is a first-line convention, not a marker family** — no marker, no `persist-marker.ps1` write path, and deliberately so, since a new family is machinery this work declined.\n\n**An amendment says it is one.** *When* a run amends is not decided here — that trigger has one home, `skills\u002Freview-judgment\u002FSKILL.md` § Close-Out Record Amendment, which fires at each judge pass's own emission on every lane that runs a judge. This step owns only the shape below. A run amending an existing record appends a dated line naming itself and what changed — *\"Amended {date} by the run for PR #{N}: {what changed}.\"* — rather than silently rewriting. **When the amending run has no pull request**, which the amendment trigger's ordinary route makes reachable, name the run instead of inventing a number: *\"Amended {date} by the {lane} run on issue #{ID}: {what changed}.\"* Do not omit the identification and do not fabricate a `#{N}`; a record is recognised as amended by this line's shape, so an off-template line reads as original text. The record is a public artifact whose first writer is often a person, not this run, and an unannounced in-place rewrite of someone else's comment leaves a reader unable to tell an amendment from the original. When the comment's author is not the amending run, say so in that line.\n\n**Render marker-like text inert.** Item 1 folds in finding text, including findings derived from external reviewers, and this repository's findings routinely name marker families. A literal HTML-comment marker in the record is live to the raw-text scanners that read real comments, so strip the delimiters when quoting one (`skills\u002Fsession-memory-contract\u002Freferences\u002Fhandoff-markers.md` § Writing about markers safely). Backticks do not neutralise it.\n\nThe three things:\n\n1. **One line per sustained finding** — where it was introduced, where it was catchable, where it was caught. This is the phase-containment ledger's own grain, and this step **does not emit ledger blocks**: the emission mechanics belong to `Documents\u002FDesign\u002Fphase-containment-ledger.md` and the plan-surface ledger those blocks already live on. Point at that ledger and summarise from it; do not re-emit it here.\n\n   **When no ledger exists** — reachable on a PR-less close, and on a novel-arm parent closed after its chunks carried their own reviews — say exactly that: *\"No phase-containment ledger was produced for this issue; no sustained findings to summarise.\"* Do not invent a ledger reference, and do not silently omit the item. An absent ledger is a fact about the issue, not a gap in the record.\n\n   **Not-yet is a different state from absent, and at moment 1 it is the normal one.** A record written before the PR-creation action necessarily predates its own review, so no ledger exists *yet* — and the sentence above would be a false claim about the issue rather than a true one. Say instead: *\"No phase-containment ledger exists yet; this record is provisional and is amended once review completes.\"* Reserve the absent form for a close where no ledger will ever be produced.\n2. **A dead-premises note** — which filed premises beat 1's grounding falsified and amended in place, so the next reader does not resurrect them.\n3. **The beat-2 re-route count** — how many times the escape hatch re-ran the routing. Zero is the common case and is reportable. **The count is what the run observed, not an arithmetic on comment counts.** Records-minus-one is a cross-check that legitimately disagrees in three directions: a record voided by a later edit still evidences a re-route that happened, a re-affirmation with an unchanged what-statement can append nothing at all, and a retried write can append twice for one re-route. Report the observed count, note how many affirmation records the issue carries and how many are lawful, and when those disagree say so and why.\n\n**When to write it — two moments, and the second is not a fallback for the first.**\n\n1. **Before the PR-creation action**, on a run that will open a pull request. That run meets this obligation earlier than this step: it is stated on the brief the run is dispatched against, at `skills\u002Fplan-authoring\u002FSKILL.md` § The close-out obligation on an affirmation-record issue. This step owns the record's shape; that section owns when the obligation is read.\n2. **Before the close** (`## Completion` below), **whenever moment 1 did not already produce the record on this issue**. Keyed on whether the record exists, **not** on whether a pull request exists. An issue closed by hand **without a pull request** is the obvious instance; it is not the only one. An issue also closes on a **closing keyword in a pull request belonging to a different issue** — a designed parent auto-closed by one of its own chunk PRs is exactly that, and moment 1 never fired for it, because the parent has no brief and the chunk that closed it owes no record of its own. A backstop keyed on PR-absence would miss that population while reading as complete.\n\n**Why it binds: the run ends at the close.** Afterwards there is no conversation left to write anything — which is how two of the six issues that owed a record got none at all.\n\n**It is not, as this step used to say, that a closed issue cannot be found.** That reason was false at the grain this step itself reads: the lookup above is number-keyed and state-blind, so a record written a minute *after* the close sits on the issue exactly as reachably as one written a minute before.\n\n**The limit that does hold — do not over-read the correction into \"ordering never matters.\"** A closed issue stays reachable by a number-keyed read and **ages out of time-windowed sweeps**: this repository's portfolio render and its rolling-history ledger both scan closed issues through a `closed:>=` \u002F `closed:>` search window. A late record is not lost, but it can fall outside a sweep that goes looking for it by date.\n\n## Validation Checklist\n\nBefore considering work fully complete, verify:\n\n- [ ] Close-out record written (issues opened for work only — Step 9; skip with a stated reason when the issue carries no affirmation record)\n- [ ] No test failure in main branch that this work introduced, measured against a named baseline commit; any failure already present at that baseline is named and routed rather than carried silently (`skills\u002Fverification-before-completion\u002FSKILL.md` § The Completion Account)\n- [ ] No merge conflicts or issues\n- [ ] Tracking files moved to `.copilot-tracking-archive\u002F{year}\u002F{month}\u002Fissue-{ID}\u002F` (local only — do not commit)\n- [ ] Documentation is current and accurate\n- [ ] Version badge updated (if version bumped) via bump script (`pwsh .github\u002Fscripts\u002Fbump-version.ps1 -Version X.Y.Z`); plugin-only installs: `replace_string_in_file` + git — not GitHub file API\n- [ ] Release tagged (if applicable) via `git tag` + `git push origin \u003Ctag>`\n- [ ] GitHub release created with release notes\n- [ ] Branches cleaned up\n- [ ] Project tracking updated\n- [ ] Stakeholders notified (if needed)\n- [ ] Working tree clean: `git status` shows no untracked or modified files\n\n## Project-Specific Customization\n\n**[CUSTOMIZE]** Add project-specific steps:\n\n- Deployment procedures\n- Database migration verification\n- Cache invalidation\n- CDN purging\n- Monitoring setup\n- Alert configuration\n- Dependency updates\n- Security scans\n- Performance benchmarks\n\n## Emergency Rollback\n\nIf critical issues are discovered post-merge:\n\n1. **Immediate**: Revert the merge commit\n2. **Communication**: Alert team and stakeholders\n3. **Investigation**: Identify root cause\n4. **Resolution**: Create hotfix PR\n5. **Documentation**: Record incident and resolution\n\n```bash\n# Revert merge commit\ngit revert -m 1 \u003Cmerge-commit-hash>\ngit push origin main\n```\n\n## Completion\n\nOnce all checklist items are verified:\n\n- Write the close-out record if the issue was opened for work (Step 9) — this happens **before** the close, not after, and on a run that opened a pull request it was already owed **before the PR-creation action**; if it is not there by now, it is late, so write it and say so\n- Mark the original issue as closed\n- Remove any temporary resources\n- Archive any temporary documentation\n- Verify control-tower issue updated (auto-rendered by workflow after merge)\n\nThe work is now fully complete and properly documented.\n\n## Structured Outcome Contract\n\nWhen invoked from Code-Conductor's post-merge cleanup path, this skill returns a structured outcome hashtable with the following shape:\n\n```powershell\n@{\n    archive    = 'passed' | 'failed' | 'skipped'\n    docs       = 'passed' | 'failed' | 'skipped'\n    version    = 'passed' | 'failed' | 'skipped'\n    releaseTag = 'passed' | 'failed' | 'skipped'\n}\n```\n\n**Per-key outcome determination**:\n\n- `archive`: `passed` when tracking files were moved\u002Farchived and `git status` is clean; `failed` when archiving was attempted but incomplete; `skipped` when no tracking files existed.\n- `docs`: `passed` when README, CLAUDE.md, or ROADMAP edits land or explicit skip rationale is documented; `failed` when documentation is known to be out of date; `skipped` when no documentation scope applied.\n- `version`: `passed` when plugin manifest version bumps are verified (`bump-version.ps1` completed or version is already correct); `failed` when manifests are out of sync; `skipped` when no version-bump scope applied.\n- `releaseTag`: `passed` when the release tag exists on the merged commit or explicit skip rationale exists; `failed` when the tag was expected but is absent; `skipped` when no release-tag scope applied.\n\nCode-Conductor passes this hashtable to `Build-PostPrCreditRow -ChecklistOutcomes @{...}` to emit the `post-pr` credit row into the PR-body pipeline-metrics block.\n\n**Step 9 (close-out record) is deliberately not a key here.** The contract's four keys are the ones `Build-PostPrCreditRow` consumes; adding a fifth would change a shape Code-Conductor already reads. The close-out record is an issue comment written at Step 9, and its absence on an issue that was opened for work is a checklist miss rather than a credit-row outcome.\n\n## Gotchas\n\n| Trigger                                                                    | Gotcha                                                                                 | Fix                                                                                    |\n| -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |\n| `git status` shows `.copilot-tracking\u002F` files as untracked                 | These are gitignored local scaffolding, not team artifacts                             | Never `git add` them; use GitHub issues and `Documents\u002FDesign\u002F` for durable records    |\n| Updating an existing file using `mcp_github_create_or_update_file`         | Tool replaces the entire file; partial content silently truncates to just the new text | Use `replace_string_in_file` + `git commit` + `git push` for existing files            |\n| Restoring a file from git history using `Set-Content` or `Out-File`        | PowerShell may add BOM or CRLF causing noisy diffs                                     | Use `git restore --source=\u003Csha> \u003Cfile>` instead                                        |\n| Looking for the `Documents\u002FDesign\u002F` file before the PR is merged           | The file is created by Code-Conductor in the PR diff, not in the repo pre-merge        | Check the PR diff, not the repo, for the design doc                                    |\n| Version bump using `mcp_github_create_or_update_file` with partial content | Tool replaces entire file; version bump deletes all other content                      | Use `pwsh .github\u002Fscripts\u002Fbump-version.ps1 -Version X.Y.Z` or `replace_string_in_file` |\n| \"PR merged — done\" without running the cleanup checklist                   | Stale branches persist; related issues stay open; version history unclear              | Run the full post-merge checklist (Steps 1–5) before declaring done                    |\n| Skipping the pre-merge strategic assessment (Step 6 \u002F SAR)                 | Missing the window to catch low-quality patterns before they set precedent             | Complete Step 6 SAR before committing to merge on any >Medium impact PR                |\n| Archiving tracking files before committing documentation                   | PR created without updated design docs and changelog                                   | Follow checklist order: documentation first, then archive                              |\n\n## Frame Ports Filled By This Skill\n\n| Port | Work adapter | Explicit-skip adapter |\n| --- | --- | --- |\n| `post-pr` | This `SKILL.md` frontmatter declares `provides: post-pr` | [adapters\u002Fpost-pr-explicit-skip-adapter.md](adapters\u002Fpost-pr-explicit-skip-adapter.md) |\n",{"name":5,"provides":48,"description":7,"suggested-next-step":49},"post-pr","Run \u002Forchestrate {ISSUE} or follow post-pr-review skill workflow","main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Fpost-pr-review",0,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002FGrimblaz","2026-08-16 01:12:46",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add Grimblaz\u002Fagent-orchestra --skill post-pr-review",{"tool":63,"command":64},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill post-pr-review",{"tool":66,"command":67},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill post-pr-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fpost-pr-review\u002FSKILL.md",true,[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"adapters\u002Fpost-pr-explicit-skip-adapter.md","REFERENCE","参考文档",297,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fpost-pr-review\u002Fadapters\u002Fpost-pr-explicit-skip-adapter.md",[78,109,125,141,166,187],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":90,"publishedAt":43},"01M6C48YMJVFHM7DVGG1WWW5RJ","webapp-testing","Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[84,87],{"categoryNo":85,"categoryName":86,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":88,"categoryName":89,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",[91,92,93,94,95,41,96,97,98,99,100,101,102,103,104,105,106,107,108,29],"testing","webapp testing","webapp","canvas","tdd","playwright","test","web","react","component","debugging","development","browser","ci","execution","e2e","game","coverage",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":43},"01M6C48TNNP2KCSQXV8YK7SK49","verification-before-completion","Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any \"I'm finished\" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[33,116,26,117,118,40,25,37,36,27,34,32,104,119,120,121,122,29,123,124],"verification before completion","change","commit","loop","verification loop","work","check","evidence","campaign",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":43},"01M6C48QZWNTP7JGKD32QZAKKX","validation-methodology","Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fvalidation-methodology\u002FSKILL.md",[],[132,133,134,26,135,136,137,138,27,139,105,29,140],"validation","methodology","validation methodology","triage","orchestration","setup","adversarial review","flow","dispatch",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":153,"publishedAt":43},"01M6C48MCAHG5Z79BJ369CRYRZ","upstream-onboarding","Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fupstream-onboarding\u002FSKILL.md",[147,148],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":149,"categoryName":150,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[154,155,26,42,156,40,157,25,27,158,159,160,161,162,163,121,122,164,165,29],"onboarding","upstream onboarding","research","standards check","protocol","brief","boundary","designer","subagent","planner","user","session",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":180,"publishedAt":43},"01M6C48GPVE120TGPMD1CS365H","ui-testing","Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-testing\u002FSKILL.md",[172,173,174,177],{"categoryNo":85,"categoryName":86,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":88,"categoryName":89,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":175,"categoryName":176,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":178,"categoryName":179,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000032","设计师",[91,181,182,183,184,185,94,41,96,97,99,100,101,102,103,186,106,107,29,93],"ui","ui testing","frontend","design","writing","testing patterns",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":195,"publishedAt":43},"01M6C48DRJ9XBDR2FW0W37DY53","ui-iteration","Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-iteration\u002FSKILL.md",[193,194],{"categoryNo":88,"categoryName":89,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":178,"categoryName":179,"taxonomyType":151,"taxonomyTypeDesc":152},[181,196,183,184,26,41,197,27,198,199,200,201,202,121,203,204,29,205],"ui iteration","accessibility","screenshot","Tailwind","polish","ui polish","feedback","redesign","strategy","only"]