architecture-repair

Applies targeted fixes to an architecture document based on reviewer findings.

Updated Aug 4, 2026
One-click install
npx skills add https://github.com/rombel00/game-processes --skill architecture-repair-rombel00
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: architecture-repair
Source: https://github.com/rombel00/game-processes/tree/main/plugins/delivery/skills/architecture-repair
Command: npx skills add https://github.com/rombel00/game-processes --skill architecture-repair-rombel00

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When an architecture document fails review with a rework verdict, the original author tends to rewrite correct sections alongside the flagged ones. This Skill performs surgical repairs: it fixes only what the reviewer flagged, preserving everything that was already correct. ## Core Features & Use Cases - Finding-driven edits: Every critical and important review finding maps to an explicit document change, with no silent deferrals. - Scoped modification: Untouched sections stay intact; the artifact is updated in place rather than forked or rewritten. - Honest escalation: Findings that cannot be resolved with the given inputs become open questions to the owner instead of fake fixes. - Debt tracking: Non-critical residue after the second review cycle is recorded as accepted debt inside the architecture document itself. - Use Case: After architecture-reviewer returns a rework verdict on your system design doc, run this Skill to close each finding, write a repair report to .process/<task-id>/architecture_repair.md, and resubmit for re-review. ## Quick Start Fix the architecture document according to the architecture-review findings and write the repair report.

Frequently Asked Questions about architecture-repair

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix an architecture document after a failed review?▼

Read the previous document and the full review report first, then map every critical and important finding to an explicit edit. Update the artifact in place, write a repair report listing closed and unresolved findings, and resubmit for re-review.

When should I use a dedicated repair step instead of fixing the document myself?▼

Use a separate repair role when the document is large and the original author risks rewriting correct sections alongside flagged ones. It is only triggered after a rework verdict from the architecture reviewer; other gates have no repair role.

What happens to review findings that cannot be resolved?▼

Unresolvable findings are reported as open questions to the owner rather than marked as fixed. If critical findings remain, the skill returns a blocked status with remaining_blockers and blocking_questions populated.

How many review cycles are allowed after architecture repair?▼

The workflow enforces a limit of two review cycles. Non-critical findings remaining after the second cycle are recorded as accepted debt inside the architecture document itself, not only in the transient repair report.

Where is the architecture repair report stored?▼

The repair report is written to .process/<task-id>/architecture_repair.md, while the architecture artifact itself is updated in place. The report lists closed findings, unresolved items, changed sections, and open questions.