Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Nagiliant/Genesis-Legacy-V2 --skill genesis-a1git clone --depth 1 https://github.com/Nagiliant/Genesis-Legacy-V2Wrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/nagiliant/genesis-legacy-v2/genesis-a1)<a href="https://agentmods.dev/skills/nagiliant/genesis-legacy-v2/genesis-a1"><img src="https://agentmods.dev/badge/skills/nagiliant/genesis-legacy-v2/genesis-a1/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/nagiliant/genesis-legacy-v2/genesis-a1"><img src="https://agentmods.dev/badge/skills/nagiliant/genesis-legacy-v2/genesis-a1.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00044 | $0.00787 |
| Opus 5.5 | $0.00018 | $0.00315 |
| Sonnet 5.5 | $0.00009 | $0.00157 |
| Haiku 4.5 | $0.00004 | $0.00079 |
Grade A, and why
A1 — Design & Master-Spec Consistency scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 45 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 45 lines · 44 tokens per session scan A 6dfe8da87b1b
A1 — Design & Master-Spec Consistency is a skill published in the GitHub repository Nagiliant/Genesis-Legacy-V2 (2 stars, last pushed 4mo ago), licensed Apache-2.0. It adds 44 tokens to every session and 787 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
code-reviewer
Review completed implementation batches for spec compliance and code quality. Invoke after execution batches complete, before merging, or when a review gate is reached in the workflow.
arrow-maintenance
Navigation and audit overlay for linked-intent development. Use when working with docs/arrows/ — orienting via index.yaml, auditing spec-to-code coherence, detecting reverse orphans and drift, splitting/merging/renaming/re-parenting segments. Dual-mode: ambient guidance when the overlay is present…
review-depth
Experimental declared review depth for linked-intent development. Use when a LID project's instruction file declares a review depth in prose (e.g. 'Review depth - I review through LLD; below that, consolidate to one review') or the user asks to batch phase reviews, consolidate stops, or let go below a phase depth.…
bidirectional-differential
Audit coherence across an arrow of intent by running two parallel fresh Claude sessions — one reconstructs code from a single EARS, the other reconstructs the EARS from stripped code — then classifies the drift between them. Use when the user invokes /differential-audit, asks to audit EARS-to-code drift for a feature…
code-simplifier
Always-active simplicity rules: no speculative abstractions, one job per function, max 30 lines, flat over nested with early returns, descriptive names, comments explain why.
critical-review
4-phase adversarial review protocol: pre-flight analysis, adversarial execution check, self-correction loop, and [VALIDATION] report.