From imbue-code-guardian
Assess whether the approach taken on a branch is the right way to solve the problem.
How this skill is triggered — by the user, by Claude, or both
Slash command
/imbue-code-guardian:verify-architectureThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Assess whether the approach taken on this branch is the right way to solve its problem. Specifically: does it fit existing codebase patterns and information flow, does it introduce unnecessary coupling or implicit dependencies, and is there a better alternative?
Assess whether the approach taken on this branch is the right way to solve its problem. Specifically: does it fit existing codebase patterns and information flow, does it introduce unnecessary coupling or implicit dependencies, and is there a better alternative?
If you do not already know what the changes on this branch are supposed to accomplish, STOP and ask the user before continuing.
Write a CONCISE description of the problem the branch is trying to solve, based on your knowledge of the work done so far. This description must contain ONLY the problem -- not any part of the solution. Describe what should work differently afterward, what is currently broken, or what structural problem exists in the code. Do not mention any mechanism, technique, data structure, or approach used to fix it. The analysis agent needs to evaluate the approach independently, so any hint about the implementation will bias its judgment.
echo "${GIT_BASE_BRANCH:-main}" (use this unless the user specified a different one)git rev-parse HEADSpawn a validate-diff Agent. Provide the base branch name and the problem description from Phase 1.
Based on the agent's response:
Resolve the base branch commit hash:
git rev-parse {base_branch}
Spawn a single analyze-architecture Agent. Provide:
Relay the agent's findings to the user. Report every point from the fit, unexpected choices, and verdict sections. Don't reproduce the structural footprint section on its own -- the user already knows what they built -- but reference specific details from it where needed to make the other points clear.
After reporting, create the verification marker so the stop hook knows architecture has been verified for this branch. Get the current branch name and timestamp:
git rev-parse --abbrev-ref HEAD
date -u +%Y-%m-%dT%H:%M:%SZ
Replace any / in the branch name with _ (e.g., mngr/my-feature becomes mngr_my-feature). Then use the Write tool (without checking if the directory exists) to create .reviewer/outputs/architecture/{sanitized_branch_name}.md with the content Verified at {timestamp}.
Architecture verification is per-branch, not per-commit. You do NOT need to re-run it after every commit. However, if you later make changes that fundamentally alter the approach (new abstractions, changed data flow, different module boundaries), you should run /verify-architecture again to confirm the new direction is sound.
npx claudepluginhub imbue-ai/code-guardian --plugin imbue-code-guardianReviews architecture of codebase or staged git changes via Zachman viewpoint analysis and principles validation, reporting violations with severity, remediations, and ADR links.
Performs multi-agent code review of current git branch against main: detects bugs via specialist agents, verifies findings, ranks severity, generates persistent report before push/merge.
Scans a codebase, interviews the developer, and produces a shareable architecture insights document. Use when assessing architecture, determining direction, or auditing drift.