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-implementgit 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-implement)<a href="https://agentmods.dev/skills/nagiliant/genesis-legacy-v2/genesis-implement"><img src="https://agentmods.dev/badge/skills/nagiliant/genesis-legacy-v2/genesis-implement/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-implement"><img src="https://agentmods.dev/badge/skills/nagiliant/genesis-legacy-v2/genesis-implement.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.00040 | $0.00643 |
| Opus 5.5 | $0.00016 | $0.00257 |
| Sonnet 5.5 | $0.00008 | $0.00129 |
| Haiku 4.5 | $0.00004 | $0.00064 |
Grade A, and why
Implement 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 — 51 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implement — One Spec, One Commit, One PR
Implement exactly one micro spec per invocation. The micro spec is the complete instruction set — no task selection, no group management. Write the code/content for the files in its File Operations table, verify against its acceptance criteria, then commit.
Gate: the active group's micro specs are written and the prior phase is accepted. Followed by the A1–A5 audits once the group's specs are all implemented.
Inputs
- The single target micro spec at
.genesis/features/<feature>/micro-specs/{spec-id}.md(the complete instruction set). .genesis/project-state.md(mode), the constitution,northstar.md.approvals/master.json/approvals/group-<N>.jsonfor position.- The files listed in the spec's
readsinterface.
Process
- Pre-flight: confirm the feature/group/spec and that the prior phase is accepted; read the target spec in full.
- Implement (mode-branched):
- Greenfield: implement the files in the File Operations table; satisfy every FR/AC; write tests per the constitution.
- Brownfield: stay strictly within the spec's File Operations table (scope discipline); preserve existing behavior; classify any touched code inherited vs introduced via git blame; ensure no regressions.
- Lowfield: produce the stage's artifacts per the declared artifact schema; verify the schema validates.
- Verify: run the project's
build/test/lintcommands as declared in the constitution, and confirm the spec's acceptance criteria pass. Do not write outside the spec's File Operations table. - Finalize: one commit scoped to the spec (
implement: {spec-id} — {title}), then open one PR. Log any failed approaches totried.jsonso they are not retried.
Anti-laziness
What you write runs. No stubs, no TODO, no "simplified version," no narrowing the spec to dodge it. A change is not done at the first file — sweep the blast radius named in the File Operations table (callers, types, tests, configs). If the spec cannot be satisfied as written, stop and surface why — do not ship a partial.
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 · 51 lines · 40 tokens per session scan A 30792b4c32f1
Implement is a skill published in the GitHub repository Nagiliant/Genesis-Legacy-V2 (2 stars, last pushed 4mo ago), licensed Apache-2.0. It adds 40 tokens to every session and 643 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
workflow
Run the complete 5-step development workflow: focus problem → prevent over-development → test-first (TDD) → document → smart commit. Use when starting a new feature, or when the user runs /workflow or asks for the full development flow.
smart-commit
Create clean Conventional Commits: inspect the diff, group related changes, run quality checks, and write type(scope) messages. Use when committing work, or when the user runs /smart-commit or asks to commit changes.
review
Structured code review with parallel audit agents, confidence-scored triage, and optional auto-fix. Examines uncommitted changes, staged diffs, commit ranges, or specific paths. Produces a tiered report (MUST-FIX / RECOMMENDED / NIT) backed by evidence, then optionally applies fixes with verification.
branch-commit
Return a branch name and concise commit message (max 3 lines) for the current task, grounded in the real git diff; with --apply, create the commit after showing the staged diff. Use when the user only needs quick branch and commit naming before committing, PR packaging is unnecessary, and a real diff exists; use…
feedback-resolution
Address PR review feedback through surgical fixes traceable to specific comments, apply the Boy Scout Rule only to already-modified files (separate improve: commits), recover context by code snippet rather than line number, and enforce pushback only when factually incorrect, test-breaking, or CLAUDE.md-violating. Use…
change-classification
Classify code changes as in-context, uncertain, or out-of-context using primary signals (branch diff, issue keywords, active tasks), secondary signals (directory proximity, test naming), and red-flag patterns (secrets, large binaries). Use when preparing commits or reviewing staged changes. This skill MUST be…