mcpField
P
post-implementation-reviewer

post-implementation-reviewer

github.com/ehoTesting & quality139 installsUpdated 8w ago
Repository

About post-implementation-reviewer

A report-only skill for auditing an implemented feature against its design document. It checks story delivery, acceptance evidence, integration, code, and documentation without making changes.

Key features

  1. 01Map stories to issues and pull requests
  2. 02Check acceptance criteria and evidence
  3. 03Inspect code and cross-story integration
  4. 04Review security and compatibility concerns
  5. 05Run relevant repository verification
  6. 06Produce a complete findings report

Use cases

  1. 01Assess whether a feature is ready
  2. 02Find gaps between implementation and design
  3. 03Review integration across delivered stories
  4. 04Prepare a consolidated remediation report

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/eho/agent-skills --skill post-implementation-reviewer

After installing, type/post-implementation-reviewerin Claude Code to confirm it loaded.

Details

From the project README

Post-Implementation Reviewer

Audit the complete implemented feature against its design document. Remain report-only: do not edit code, push commits, merge PRs, change issues, or create remediation issues.

Audit

  1. Read repository instructions and the complete design document.
  2. Extract every current story, dependency, and acceptance criterion.
  3. Map each story to its canonical GitHub Issue and delivered Pull Request. Flag missing, duplicate, open, unmerged, unreviewed, or stale work.
  4. Verify that every acceptance criterion has meaningful implementation and evidence.
  5. Inspect the current codebase rather than relying only on issue or PR descriptions.
  6. Test important cross-story integration and critical user flows.
  7. Check architecture, APIs, data contracts, state ownership, security, permissions, failures, compatibility, migrations, rollout, and rollback where relevant.
  8. Audit user-facing and operational documentation, examples, configuration, diagnostics, and terminology.
  9. Run the strongest relevant repository verification that is not already covered by trustworthy exact-head evidence. Do not imply unrun checks passed.
  10. Complete the entire audit even after finding a blocker so remediation receives one complete finding set.

Classify findings as:

  • an existing story gap;
  • a cross-story integration or documentation gap;
  • a product decision requiring user authority; or
  • a genuinely non-blocking follow-up.

Report Ready only when no blocking finding remains. Creating a follow-up issue does not make a blocking finding non-blocking.

Report

## Findings
- Blocking findings first.
- If none: No blocking findings found.

## Story Completion
| Story | Issue | PR | Acceptance Evidence | Status |
| --- | --- | --- | --- | --- |

## Integration and Design Alignment
- Critical flows:
- Design or implementation drift:

## Documentation and Operations
- Current:
- Missing or stale:

## Verification
- Commands/checks:
- Not verified:
- Residual risk:

## Required Remediation
- Existing story gaps:
- Cross-story gaps:
- Product decisions:
- Non-blocking follow-ups:

## Release Readiness
Decision: Ready | Not ready

Comments

Markdown supported