| name | harness-architecture-review |
| description | Finds architecture deepening opportunities using seams, module depth, deletion tests, evidence hierarchy, and repository ownership boundaries. Use when reviewing architecture, reducing coupling, improving testability, or evaluating whether a module, trait, adapter, worker, service, or boundary is too shallow.
|
Harness Architecture Review
Use this skill to surface architecture friction before proposing refactors.
Workflow skills guide process. Ownership skills still decide writable boundaries.
Process
- Read
AGENTS.md, agent/codemap.yml, docs/architecture/north-star.md, and accepted ADRs in the area.
- Explore code and tests before judging architecture.
- Identify where understanding requires bouncing across many shallow modules.
- Apply the deletion test to suspected pass-through modules.
- Check whether a seam has real variation, testing value, or topology-late value.
- Check ownership boundaries before recommending changes.
- Present candidates only. Do not edit first.
Candidate Format
For each candidate, report:
- files or owner areas involved
- problem and evidence
- why the current module or seam is shallow
- proposed deeper interface in plain English
- benefit in leverage, locality, and testability
- ADR or north-star conflict, if any
- risk and suggested verification
Ask which candidate to explore before designing interfaces or changing code.
Repository-Specific Rules
- A service library can be a semantic boundary without becoming a process boundary.
- A Rust trait is not automatically a useful seam.
- Platform metadata must not absorb service-local semantics.
- Server handlers adapt protocols; they do not own domain rules.
- Worker reliability claims require executable retry, checkpoint, dedupe, replay, and recovery evidence at the claimed level.
