Claude Skills by Nagiliant

The drift check. Compare what was built against the design doc and master spec. Sets the Double Gate — A3 cannot start until A1 is at zero findings.

Mechanical FR/AC compliance. Walk every functional requirement and acceptance criterion and render a binary Pass/Fail with evidence. No judgment about quality, direction, or architecture.

Code/content quality. Dead code, hardcoded values, leftover TODOs, weak error handling, security holes, performance traps, standards violations. Enforces the Double Gate — blocks until A1 is at zero findings.

Vision-gap analysis. Compared to the perfect-world North Star, what is missing, drifting, or underbuilt — and what to add or change now to close the gap. Not a passive alignment scorecard.

Research the world. Real web research to find what the best teams do for every technology and pattern in the build, then implement superior approaches now (not later). The only lens that brings outside knowledge.

The boundary ritual — review what just landed, record an approval, journal it, and advance the phase. The ONLY step that writes approvals, and it does NO git.

Formally amend the constitution, with mandatory impact analysis before any change lands. The constitution is supreme law; amendments are versioned and their downstream effects scanned first.

Interactive ideation and decision capture at any pipeline boundary. Opinionated dialogue that surfaces contradictions, gaps, and untested assumptions — not template-filling. Feeds the Furnace.

Find and close holes in the master spec before the North Star — resolve ambiguity markers, run a coverage scan, ask high-impact questions, and optionally simulate usage scenarios.

Git closure — push the branch and open a PR. The ONLY step that performs git operations. Never auto-merges.

Create or amend the constitution — the project's supreme, enforceable law. Everything built afterward must comply.

Author project-level design documentation — architecture, data models, API contracts, user journeys, glossaries, and decision records (ADRs). For per-feature design, use /genesis-feature.

Build the project profile through guided conversation — the grounding document every later phase reads. Establishes the mode and, for content projects, the work-unit registry.

Write the feature design doc — the WHY + SHAPE for a single feature. No formal requirements yet (those come in /genesis-specify).

The feature-wide final audit. Re-runs the five lenses across ALL groups together, then two extra passes — Dreamland (dream perfection, then make it real) and Simulation (realistic scale testing). Runs after every group is accepted.

Command reference for Genesis Spec-Kit. Pass a command name for detailed help on that command.

Implement one micro spec — one commit, one PR. The micro spec is the complete instruction set; write only the files in its File Operations table, verify against its acceptance criteria, commit.

Initialize Genesis Spec-Kit in a project — scaffold .genesis/ and determine the project mode (greenfield, brownfield, lowfield). Use when setting up the kit for the first time.

Write all micro specs for one group — fully self-contained implementation units, plus the group's simulation scenarios and human-testing checklist.

Write the perfect-world vision for the feature — no-compromise narrative, weighted quality dimensions, and the Compass. The qualitative reference every audit measures against.

Reconstruct the exact pipeline position from disk, load the frontier spec in full, list failed approaches not to retry, and present the next action. Read-only, any time.

Write the master spec — the WHAT. User stories, functional & non-functional requirements, acceptance criteria, and the dependency-ordered micro-spec plan. Strictly WHAT, never HOW.

Pipeline dashboard — current feature, position, per-group progress, approvals, pending PRs, blockers. Read-only, any time.