Commit working tree during active dev on feature/worktree branch. **Working phase** half of Grimoire two-phase branch workflow — rebasing-phase cleanup for `main` lives in `/finalize`.

Clause-by-clause procedure for shortening and cleaning up source-code comments without losing a guard, the comment that says why a non-obvious line must stay as it is and what breaks if it changes. Use when someone asks to shorten, trim or clean up comments, says a file has too many or overly verbose comments or is over-commented, cut comment density or comment bloat, split an essay comment or an over-long doc comment or docstring, move design rationale out of code into a decision record, remove plan, work-package, review-round or decision IDs from comments, delete comments that restate the code, bring a file under the code-docs length caps, or prepare a file or package for the code-docs comment ratchet. Not for writing the comment standards, which the code-docs rule carries, not for --help, JSON Schema, MCP tool descriptions or other text that renders to users, and not for user-facing documentation pages, which the docs-quality rules cover.

Requires commit-helper at :2. Use with triage-bot (which needs :1) to see a dependency conflict (exit 78).

Documentation verification gate for a repository that adopted the docs-quality rule set, covering the checks, configs, fixtures, harnesses and reader signals that make those rules enforceable. Use when someone asks to wire up docs checks or a docs CI gate, add doc_type and doc_tier declarations, retrofit a page declaration, set up markdownlint or Vale for prose, check docs links with lychee or a strict build, test documentation examples or code fences, add a doc-example harness, record terminal casts, capture zero-result searches, measure time to first working result, add a docs issue template, a feedback widget or privacy-preserving analytics, add a Lighthouse ratchet for a docs site, or land a new docs lint without turning every open pull request red. Not for deciding which pages to write or what the use-case tiers are, which is the docs-plan skill.

Documentation discovery and information architecture for a repository, in three tiers (first steps, everyday, integration), with user needs, a page inventory, a coverage table, a delete list, and seeded doc_type and doc_tier declarations. Use when someone asks what documentation a project needs, wants a docs plan, docs audit, docs roadmap, docs IA, page inventory, coverage table, delete list, or content gap analysis, when scoping a quickstart, getting-started page, first-steps page or tutorial, when asked which pages to write, merge, split or delete, when someone mentions user needs, top tasks, friction logs, doc_type, doc_tier, product shape, or "what should the docs cover". Not for wording one page. The docs-quality rules cover prose, examples and navigation.

Grim publishes seven artifact kinds to OCI registries. Each has its own source shape, frontmatter schema, and validation gates. This root file holds the invariants that apply to every kind; per-kind depth lives in `references/`, loaded via the routing table below.

Role: write user-facing docs for Grimoire (Markdown under `docs/`).

Thin dispatcher. It parses arguments, classifies the decision's tier, resolves overlays, runs the single meta-plan approval gate, announces the resolved config, and hands off to the matching tier file. The phase plans live in the five `tier-<tier>.md` files; the shared vocabulary (tiers, the Review-

Thin dispatcher. A plan is a few **pipelines** cut along contracts; a pipeline is a chain of **steps** in one worktree. This file resolves the target, runs the **contract wave**, dispatches steps, merges, runs the **integration gate** concurrent with the **review call**, fixes, and hands to `/hex-fi

`hex-finalize` takes a review-approved feature branch from *the work is right* to *this is ready to merge*: it verifies the branch, recomposes it into a commit series the project's own rules would accept, and — after exactly one approval — force-pushes it and readies its pull request. **The merg

Initialize or reconfigure a project for the hex swarm - audits project context (CLAUDE.md/AGENTS.md) for the knowledge the orchestrators need (how to verify, spec/plan conventions), provisions what is missing into project context, optionally seeds default templates, and bootstraps the AI-maintained swarm memory at .agents/memory/hex.md (cached pointers, orchestration preferences, perspectives of interest). Re-entrant - run again anytime to re-audit pointers or change the setup.

Thin dispatcher. It parses arguments, classifies the target's tier, resolves overlays, runs the single meta-plan approval gate, announces the resolved config, and hands off to the matching tier file. The phase plans live in the five `tier-<tier>.md` files; the shared vocabulary (tiers, the Review-Fi

Use when the user asks to run a retrospective over recorded agent friction, consolidate the retro inbox into ledger findings and proposed skill or project-config edits, or import a handwritten friction log; also run at a goal loop's retro checkpoints.

Thin dispatcher. It resolves the review target and baseline, classifies the diff's tier, resolves overlays, runs the single meta-plan approval gate, announces the resolved config, and hands off to the matching tier file. hex-review never edits its own output or loops on it — the reviewer panel run

Use when auditing the freshness of `.claude/rules/subsystem-*.md` files against current codebase state, or when a subsystem has undergone significant change.

Run an adversarial review of a code diff or a plan artifact under a second AI harness, headlessly, from an ephemeral git worktree with the repository's own instruction, hook and credential files removed. Use when a change needs a reviewer that did not write it, when a cross-model second opinion is wanted before something lands, or when a plan or an ADR should be argued against by a different model.

This skill exists only to drive grimoire's deprecation surface. Its `metadata.deprecated` notice is emitted as the `com.grimoire.deprecated` manifest annotation, which then powers:

Write a minimal SKILL.md, install it from its path, and see an agent load it.

Route a question to the team that owns an artifact. Use when a published skill misbehaves and you need the maintainer, the issue tracker, or the security contact rather than a code change.