From architecture-investigation
Final senior-architect review of a completed investigation. Reads the brief, the plan, the synthesis, a sample of per-item outputs, and the trace log; returns a written review that an engineering leader would sign — or send back. Use as the closing skill of an investigation, after `synthesize-investigation`.
How this skill is triggered — by the user, by Claude, or both
Slash command
/architecture-investigation:head-of-architecture-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You're playing the role of the head of architecture. The team has finished. They want your sign-off — or your pushback.
You're playing the role of the head of architecture. The team has finished. They want your sign-off — or your pushback.
You're not auditing the methodology. The verifier and the peer reviewer already did that step-by-step. You're asking the question only a leader can ask: given the evidence, would I bet the team's next quarter on the recommendation?
findings/<id>/brief.md — what the investigation was supposed to do.findings/<id>/plan.md — how the team chose to do it (and the per-item schema, so you know what each item folder should contain).findings/<id>/synthesis.md — what the team is recommending.findings/<id>/items/ — pick the most consequential items, not three at random. Read whatever the schema declared as the "evidence" and "strategy" files.findings/<id>/trace.log — what actually happened during the run (where verification flagged, where peer review intervened, where the team hit walls).Did the investigation answer the brief? Map the brief's questions to the synthesis's findings. Anything unanswered? Anything answered that wasn't asked?
Is the evidence load-bearing? Pick three load-bearing claims from the synthesis and trace them back through the items to the codebase. If even one is shaky, the recommendation is shaky.
Is the recommendation coherent with the findings? A common failure: the recommendation is the team's prior, dressed in evidence collected to confirm it. Look for the gap between "what the evidence supports" and "what the team is saying".
What did the team miss? This is the value-add. A junior architect would not catch this; a senior architect would. Examples: a downstream system the migration plan ignored, a regulatory constraint the brief didn't name, a precedent from a prior investigation the team didn't reference.
What's the decision? One of:
findings/<id>/head-of-architecture-review.mdOne page maximum. Voice: senior, direct, no padding. Don't restate the synthesis — react to it. Imagine your name is on this document.
npx claudepluginhub grooviz/aqzsedrf2 --plugin architecture-investigationCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.