Genesis a1
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.From its SKILL.md
npx -y skills add Nagiliant/Genesis-Legacy-V2 --skill genesis-a1Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.4 KB, as published. Nobody here has run it
A1 — Design + Master-Spec Consistency
The drift check, and the first lens. A1 compares what was actually built against the two authoritative intent documents — the design doc (architecture, data models, boundaries, technology choices, data flow) and the master spec (the WHAT). Has the architecture been honored? Are boundaries respected? Was anything built that isn't specified (scope creep), or specified but not built?
A1 is the gate-setter: /genesis-a3 cannot begin until A1 reports zero findings.
Inputs
design.md(required — refuse if missing) ·spec.md(required — refuse if missing)- The group's micro specs and the implementation code in scope
- The constitution ·
northstar.md· the project mode
Process
- Detect the mode (greenfield/brownfield/lowfield) — it drives the checklist.
- Confirm every spec in the group is implemented; if not, refuse: "Cannot audit — {spec-id} is not implemented."
- Design doc vs implementation: are architecture decisions reflected in code? boundaries respected? any forbidden/unconstitutional dependency introduced? does data flow match the design?
- Master spec vs implementation: anything implemented but not specified (scope creep)? anything specified but not implemented? did the micro-spec plan structure hold?
- Determine fix direction per divergence — code wrong → fix code; code right but docs stale → update docs; both → a finding for each. A1 is the only lens that judges fix direction; it does not assume the code is wrong. Where both directions are plausible, the finding declares which interpretation it assumes.
- (Brownfield) scope strictly to the spec's File Operations table; classify each finding Introduced (added on this branch) vs Inherited (pre-existing) via git blame. Both get fixed; the classification is reported.
- Write the report to
audits/{scope}-a1.md: a design-consistency table (decision → code → match/drift), a spec-consistency table (FR/behavior → implemented → match/drift/extra), document-update recommendations, and a reasoning trace per finding.
The finding format, the zero-tolerance loop, the Double Gate, and conviction
These are shared by all five lenses — see docs/the-audit-system.md for the full definitions. In brief:
- Finding format carries: Severity, Conviction (0–100), File:lines, Requirement (FR/AC ID or "general quality"), Classification (Introduced/Inherited/N/A), Description, a Reasoning Trace (premises, alternatives considered, why this is a finding), a Suggested Fix, and Status.
- Zero-tolerance loop: A1 loops until it reports zero findings. No "won't fix," no "out of scope." Every finding becomes a fix, a new micro spec, or a tracked design input — and the open-finding count must reach zero.
- Double Gate: A1 must reach zero before A3 may run. There is no override.
- Conviction: write the finding first, then score it 0–100 against the conviction scale; record it in the finding. Zero findings ⇒ conviction 100.
Natural language triggers
- "a1 audit group 1"
- "design consistency audit"
- "check for drift"