Menu
Architecture review in hindsight — what to question, dependency analysis, abstraction assessment
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Write high-quality session prompts (SESSION_WORKER.md and SESSION_REVIEWER.md) for an agent loop. Reads repo context and follows the loop-author guide to produce targeted, effective prompts. Use when setting up a new loop or rewriting session prompts for an existing one.
Pre-flight checks and launch for agent loops. Validates branch state, session prompts, creates loop directory structure, and launches run.sh in a tmux session. Use when the user wants to start a new agent loop in the current repo.
Cross-repo visibility for agent loops. Lists running, completed, and crashed loops. Reads the registry and per-repo tracking logs. Shows tmux attach commands. Use when checking what loops are active, what ran recently, or loop details.
Capture feedback about wf, util, or vault plugins and file it as a GitHub issue for improvement. Use after any session where the tooling fell short — wrong agent behavior, missing skill coverage, misleading prompts, workflow friction, or convention gaps. Only for generic plugin improvements that would help ANY project, not repo-specific config. Files to JSai23/claude-tooling with the plugin-feedback label.
Write high-quality session prompts (SESSION_WORKER.md and SESSION_REVIEWER.md) for an agent loop. Reads repo context and follows the loop-author guide to produce targeted, effective prompts. Use when setting up a new loop or rewriting session prompts for an existing one.
Pre-flight checks and launch for agent loops. Validates branch state, session prompts, creates loop directory structure, and launches run.sh in a tmux session. Use when the user wants to start a new agent loop in the current repo.
| name | verify-design-a |
| type | action |
| description | Architecture review in hindsight — what to question, dependency analysis, abstraction assessment |
| user-invocable | false |
Action skill — Architecture review procedures: dependency analysis, abstraction assessment, output format.
Evaluating code architecture in hindsight — now that it's built, does the structure make sense?
Type and class design — Why does this class exist? Would functions suffice? Should these be separate types or one? Is inheritance justified?
Module structure — Why is this code in this package? Should modules be split or merged? Are boundaries in the right places? Does directory structure reflect architecture?
Dependencies — Why does A depend on B? Could it be inverted? Hidden coupling through shared state? Circular dependencies? Dependencies pointing toward stability?
Abstractions — Earning their complexity? More than one implementation? Interface premature? Would concrete code be clearer?
Diagrams first. Show module dependencies, data flow, layer structure. Reference diagrams in every finding.
Format findings as:
Not naming/formatting (that's style). Not fake code (that's larp). Sound architecture is the goal, not findings.
## Concern: {title}
DIAGRAM: {ASCII dependency or data flow diagram}
OBSERVATION: What the current design does
QUESTION: Why is it this way? What's the tradeoff?
ALTERNATIVE: Different approach to consider
IMPACT: What would change if refactored
Refactor candidates as prioritized list with FROM/TO/TRADEOFF for each.