review-implementation

Name: review-implementation
Author: golbin

207stars27forks

How to install review-implementation?

golbin/agent-skills/review-implementation

$npx -y skills add golbin/agent-skills --skill review-implementation

Installs into the current project.

Summary

Review implementation against provided markdown requirements, specs, PRDs, or phase docs; optionally apply focused fixes. Use when a user supplies .md file paths and asks to verify correctness/completeness, check PRD phase completion, find missing or overbuilt work, assess critic

Files · 1

View on GitHub

SKILL.md

1	# Review Implementation
2
3	## Overview
4
5	Review code against markdown requirements and produce evidence-backed findings.
6	When the user asks for fixes, apply targeted changes that bring the
7	implementation back to the docs without expanding scope.
8
9	## Modes
10
11	- Use review-only mode when the user asks to review, assess, audit, verify,
12	or find issues.
13	- Use fix mode when the user asks to fix, update, refactor, complete,
14	apply changes, or make the implementation match the docs.
15	- In fix mode, keep changes minimal and reversible. Do not add features that are
16	not justified by the docs.
17
18	## Workflow
19
20	### 1) Intake and Discovery Gate
21
22	- Read all provided .md files and extract explicit requirements, constraints, and acceptance criteria.
23	- Read repo guidance such as AGENTS.md, README, architecture notes, and existing
24	task or PRD files when relevant.
25	- Inspect affected code, tests, fixtures, routes, schemas, migrations, services,
26	components, permissions, config, and observability surfaces as needed.
27	- Identify the current behavior, expected behavior, data flow, integration
28	points, validation options, and likely blast radius.
29	- Ask only when a critical decision cannot be made safely after discovery.
30
31	### 2) Map Requirements to Evidence
32
33	- Build an internal traceability map: requirement -> status -> code evidence ->
34	gap -> action.
35	- Classify each requirement as satisfied, partial, missing, conflicting,
36	overbuilt, or deferred.
37	- Use file/line evidence for important claims. Do not rely on general
38	impressions when code can be inspected.
39
40	### 3) Run Multi-Pass Review
41
42	Review in this order:
43
44	1. Requirements coverage: every requirement is satisfied or explicitly
45	unresolved.
46	2. Correctness: happy paths, edge cases, errors, empty states, permissions,
47	state transitions, and rollback behavior are handled.
48	3. Integration: changed modules fit together without contract breaks,
49	duplicated ownership, or hidden assumptions.
50	4. Simplicity: the solution is no more complex than necessary.
51	5. Cleanup: repeated logic, dead code, temporary code, noisy logs, unused files,
52	and unused dependencies are removed.
53	6. Security/privacy: auth, access control, secrets, sensitive data, injection
54	risks, and audit needs are safe.
55	7. Performance: expensive queries, N+1 patterns, unnecessary renders, redundant
56	network calls, and blocking work are addressed.
57	8. Validation: chosen checks are appropriate for the risk.
58	9. Documentation/operability: docs, release notes, migrations, rollback,
59	monitoring, or support notes are updated when required.
60
61	Treat overbuilt code as a review finding when it adds features, abstractions,
62	state, dependencies, or workflow paths not required by the docs.
63
64	### 4) Apply Focused Fixes
65
66	- Fix issues directly in code with minimal, targeted changes.
67	- Split overly long files/functions only when the split reduces real review or
68	maintenance risk.
69	- Remove or simplify overbuilt code that is not justified by the docs.
70	- Preserve existing patterns unless the docs or code evidence justify a change.
71	- If PRD or phase files are part of the request, update checkboxes, validation
72	notes, discoveries, and change logs only when implementation evidence supports
73	the update.
74
75	### 5) Validate with Evidence
76
77	- Choose the smallest sufficient validation for the risk: static checks, unit
78	tests, integration tests, API-level E2E, browser/UI checks, simulator checks,
79	screenshots, manual smoke checks, or observability checks.
80	- Run relevant checks when available and appropriate. If checks are unavailable,
81	too costly, or not allowed, state the gap and use the best available evidence.
82	- Do not run broad or expensive validation by reflex when a narrower check proves
83	the changed behavior.
84
85	## Report Format
86
87	Lead with the result that matters most:
88
89	- In review-only mode, list findings first in severity order with file/line
90	references, then summarize coverage, validation, and residual risk.
91	- In fix mode, summarize fixes applied, validation performed, and any remaining
92	findings or risks.
93	- If no issues are found, say so clearly and name any validation gaps.
94	- For critical blockers, stop and ask. For non-critical ambiguity, make the best
95	reasonable decision, record the assumption, and continue.

People who liked this also viewed

6 picks

Type

review-implementation

207stars27forks

View on GitHub

How to install review-implementation?

golbin/agent-skills/review-implementation

$npx -y skills add golbin/agent-skills --skill review-implementation

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Review Implementation
2
3	## Overview
4
5	Review code against markdown requirements and produce evidence-backed findings.
6	When the user asks for fixes, apply targeted changes that bring the
7	implementation back to the docs without expanding scope.
8
9	## Modes
10
11	- Use review-only mode when the user asks to review, assess, audit, verify,
12	or find issues.
13	- Use fix mode when the user asks to fix, update, refactor, complete,
14	apply changes, or make the implementation match the docs.
15	- In fix mode, keep changes minimal and reversible. Do not add features that are
16	not justified by the docs.
17
18	## Workflow
19
20	### 1) Intake and Discovery Gate
21
22	- Read all provided .md files and extract explicit requirements, constraints, and acceptance criteria.
23	- Read repo guidance such as AGENTS.md, README, architecture notes, and existing
24	task or PRD files when relevant.
25	- Inspect affected code, tests, fixtures, routes, schemas, migrations, services,
26	components, permissions, config, and observability surfaces as needed.
27	- Identify the current behavior, expected behavior, data flow, integration
28	points, validation options, and likely blast radius.
29	- Ask only when a critical decision cannot be made safely after discovery.
30
31	### 2) Map Requirements to Evidence
32
33	- Build an internal traceability map: requirement -> status -> code evidence ->
34	gap -> action.
35	- Classify each requirement as satisfied, partial, missing, conflicting,
36	overbuilt, or deferred.
37	- Use file/line evidence for important claims. Do not rely on general
38	impressions when code can be inspected.
39
40	### 3) Run Multi-Pass Review
41
42	Review in this order:
43
44	1. Requirements coverage: every requirement is satisfied or explicitly
45	unresolved.
46	2. Correctness: happy paths, edge cases, errors, empty states, permissions,
47	state transitions, and rollback behavior are handled.
48	3. Integration: changed modules fit together without contract breaks,
49	duplicated ownership, or hidden assumptions.
50	4. Simplicity: the solution is no more complex than necessary.
51	5. Cleanup: repeated logic, dead code, temporary code, noisy logs, unused files,
52	and unused dependencies are removed.
53	6. Security/privacy: auth, access control, secrets, sensitive data, injection
54	risks, and audit needs are safe.
55	7. Performance: expensive queries, N+1 patterns, unnecessary renders, redundant
56	network calls, and blocking work are addressed.
57	8. Validation: chosen checks are appropriate for the risk.
58	9. Documentation/operability: docs, release notes, migrations, rollback,
59	monitoring, or support notes are updated when required.
60
61	Treat overbuilt code as a review finding when it adds features, abstractions,
62	state, dependencies, or workflow paths not required by the docs.
63
64	### 4) Apply Focused Fixes
65
66	- Fix issues directly in code with minimal, targeted changes.
67	- Split overly long files/functions only when the split reduces real review or
68	maintenance risk.
69	- Remove or simplify overbuilt code that is not justified by the docs.
70	- Preserve existing patterns unless the docs or code evidence justify a change.
71	- If PRD or phase files are part of the request, update checkboxes, validation
72	notes, discoveries, and change logs only when implementation evidence supports
73	the update.
74
75	### 5) Validate with Evidence
76
77	- Choose the smallest sufficient validation for the risk: static checks, unit
78	tests, integration tests, API-level E2E, browser/UI checks, simulator checks,
79	screenshots, manual smoke checks, or observability checks.
80	- Run relevant checks when available and appropriate. If checks are unavailable,
81	too costly, or not allowed, state the gap and use the best available evidence.
82	- Do not run broad or expensive validation by reflex when a narrower check proves
83	the changed behavior.
84
85	## Report Format
86
87	Lead with the result that matters most:
88
89	- In review-only mode, list findings first in severity order with file/line
90	references, then summarize coverage, validation, and residual risk.
91	- In fix mode, summarize fixes applied, validation performed, and any remaining
92	findings or risks.
93	- If no issues are found, say so clearly and name any validation gaps.
94	- For critical blockers, stop and ask. For non-critical ambiguity, make the best
95	reasonable decision, record the assumption, and continue.

People who liked this also viewed

6 picks

Type