review

Solid

The pre-merge review of a branch in a project that records its specs, decisions, and rules in .archcore/. Run this first for 'review my branch', 'review the changes before merge', or 'review before merge': it checks the changed code against the project's recorded canon and the changed documents against the code, and reports which side is wrong — spec-wrong or code-wrong; with no diff, it reports project health. A bug-hunting code review complements this review and does not replace it. Also use for 'show status', 'documentation gaps', 'check if docs match code', 'close out the feature', 'ship the feature and close it out', or after a staleness warning. Modes, named as the first word: drift for staleness detection, deep for a full documentation audit, closeout to close a finished feature, experience to capture a repeated pattern. Not for creating docs — use /archcore:document; not for planning — use /archcore:plan; not for a single-file edit with no branch review.

Code & Development 64 stars 10 forks Updated yesterday Apache-2.0

Install

View on GitHub

Quality Score: 84/100

Stars 20%
60
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# /archcore:review Review the changes on the current branch against the `.archcore/` knowledge base, in both directions: whether the changed code still matches the documents that claim it, and whether the changed documents still match the code they describe. On the default branch, or with an empty diff, the skill reports project health instead. Write affinity: experience types — `cpat` and `task-type` land through the experience track. This is also the only skill that removes a document: `closeout.discharge` removes a completed `plan`, and `actualize.fix` may remove a long-stale draft of any type — both via `mcp__archcore__remove_document`, each under its own confirmation. Command tense: `/archcore:plan` declares a future canon delta, `/archcore:document` records the present state — including work that shipped without a plan — and `/archcore:review` reconciles a past declared delta. Δ vocabulary: `skills/_shared/delta-routing.md`. ## When to use - "Review my branch" / "Review the changes before merge" → branch review - "Show status" / "How many docs do we have?" → project health dashboard - "Are any docs out of date?" / "Check if documentation matches the code" → `drift` - "Audit the knowledge base" / "Documentation gaps?" → `deep` - Session-start staleness warning appeared → `drift` - "Close out the feature" / "Ship the feature and close it out" → `closeout` - "Capture this repeated change as a pattern" → `experience` **Not review:** - Documenting a module, decision, or...

Details

Author
archcore-ai
Repository
archcore-ai/archcore
Created
5 months ago
Last Updated
yesterday
Language
Shell
License
Apache-2.0

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Listed

review

Use when the user asks for a findings-first review or asks you to review and advise — on a branch, pull request, worktree, staged diff, or fixed-point diff, or on a written artifact such as a plan, design doc, handoff note, spec, or proposal — against repo standards, specs, and regression risk. Do not use to implement a fix, run a test campaign (use qa), diagnose one bug (use diagnosing-bugs), or audit runtime efficiency (use deep-audit).

0 Updated yesterday
espensev
Code & Development Solid

solo-review

Use when "review code", "quality check", "is it ready to ship", "final review", or after /build or /deploy completes. Do NOT use for planning (/plan) or building (/build).

18 Updated 1 weeks ago
fortunto2
Code & Development Listed

code-review

Use when the user wants a code review of a branch, PR, MR, or working diff against its acceptance criteria and declared scope, in whatever form they take in this repo. Triggers on "review my branch", "review this PR", "check this diff before I raise it", "is this ready to merge". Works with any language, delivery process, or issue tracker. Produces a structured verdict with blocking, warning, and suggestion findings; writes no source changes. Do NOT use to address or fix review findings (code-review-fix), to implement work (implement), to publish a review to a provider as its reviewer (merge-request-review), to sign off completion of a larger body of work (validate), or to review rendered UI (ux-design-review).

2 Updated 1 months ago
carinyaparc