go-cms-architecture-review

Reviews Go CMS architecture changes for invariant violations and dependency drift.

Updated Jun 15, 2026
One-click install
npx skills add https://github.com/vernal96/go-cms --skill go-cms-architecture-review-vernal96
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: go-cms-architecture-review
Source: https://github.com/vernal96/go-cms/tree/main/.codex/skills/go-cms-architecture-review
Command: npx skills add https://github.com/vernal96/go-cms --skill go-cms-architecture-review-vernal96

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Reviewing cross-cutting refactors, commits, and PRs in a layered Go CMS is hard because architectural invariants (ownership, dependency direction, cache coherence, runtime publication) are easy to break silently. This Skill provides a structured review procedure that scopes the analysis from the diff, traces only relevant execution paths, and classifies findings by severity. ## Core Features & Use Cases - Scoped review workflow: Starts from changed files, reads consumers of changed public contracts, and traces only relevant paths (boot/reload/request, read/write/invalidate, registration/compile/dispatch). - Severity classification: Ranks findings as Critical, Major, Medium, Minor, or acceptable trade-off, with current behavior, impact, smallest fix, and a regression test for material issues. - Invariant checklist: Covers kernel vs module vs adapter ownership, dependency direction, state lifetime, SiteRuntime publication, cache coherence, HTTP transport leakage, extension precedence, and module dependency ordering. - Use Case: After a PR modifies the cache invalidation layer, run this review to verify every mutation path preserves cached-read coherence before merging. ## Quick Start Ask the assistant to review the current diff or PR for GO CMS architecture invariant violations and produce a severity-ordered findings report.

Frequently Asked Questions about go-cms-architecture-review

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

FAQPage Schema
How do I review a Go backend PR for architecture violations?▼

Start from the diff, read consumers of changed public contracts and nearest tests, then trace only relevant execution paths such as boot, request, or cache invalidation. Classify findings by severity and require a regression test for each material issue.

What architecture invariants should a layered Go CMS enforce?▼

Key invariants include correct ownership across kernel, module, adapter, and transport layers, dependency direction where lower layers avoid project knowledge, proper state lifetimes, no per-request runtime rebuilds, and cache coherence on every mutation path.

When should I use an architecture review instead of a normal code review?▼

Use it for cross-cutting refactors, commits touching public contracts, or suspected drift from project invariants. It is not intended for normal implementation tasks or style-level feedback.

How are architecture review findings prioritized by severity?▼

Critical covers corruption, security, or broken runtime publication; Major covers broken core invariants or extensibility; Medium is design debt likely to grow costly; Minor is local quality issues; intentional contained deviations are acceptable trade-offs.

What are the limitations of diff-scoped architecture review?▼

It expands beyond the diff only when traced execution paths reach other packages, so very broad changes may require a full architecture analysis. It also intentionally skips style comments while material architectural issues exist.