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 agentmods add skills/scolladon/craft/initnpx skills add scolladon/craft --skill initgit clone --depth 1 https://github.com/scolladon/craftWhat 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 | $0.00044 | $0.03830 |
| Opus 5 | $0.00022 | $0.01915 |
| Sonnet 5 | $0.00009 | $0.00766 |
| Haiku 4.5 | $0.00004 | $0.00383 |
Grade A, and why
init 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 2d 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 — 257 lines — stays where its author put it; the contents beside it link to each section on GitHub.
craft:init — named-manifest generator
Standalone session-owned skill. You (the session) probe the repo, interview the user over the full Tier-0/1 catalog, emit a manifest, lint it in a temp path, and move it into place only on a clean lint. No worker agent is spawned. Never call worktree-setup.sh (it installs deps). Never touch .claude/workflow.md.
Input: $ARGUMENTS (optional name; if absent, ask for one during interview).
Preamble — probe + name validation (read-only)
Before asking anything, build the CapabilityReport from read-only probes.
1. Name resolution
Parse --scope user|local out of $ARGUMENTS first (default local) and strip it from the string; bind the result as scope. This is only a pre-fill — the Step 1 interview still asks the scope question and the user's answer there wins.
If the remaining $ARGUMENTS is non-empty, treat it as the candidate <name>. Otherwise hold name until the interview's first question.
When a candidate name is available, validate it immediately and bind the name and its local-scope path to shell variables:
name="<the candidate name>"
manifest_final="$(node "${CRAFT_ROOT:-${CLAUDE_PLUGIN_ROOT}}/engine/bin/init-config.js" "$name")"
- Exit 0: the name is valid;
$manifest_finalholds the LOCAL-scope path (e.g..claude/craft-<name>.md) for the Done report and local-existence checks. It no longer supplies the land target — Step 3 passes$nameand$scopetoinit-land.js, which re-derives the destination itself. - Non-zero: STOP — surface the stderr diagnostic; do not proceed.
Defer validation to the moment a name is provided if it was not in $ARGUMENTS.
2. Ecosystem detection
bash "${CRAFT_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/detect-ecosystem.sh" .
Capture stdout as ecosystem (one of npm|pnpm|yarn|bun|uv|poetry|cargo|go|bundler|composer). If the command exits non-zero or produces empty output, set ecosystem = null and lockfile = null. The detected lockfile name is the file whose presence triggered the match (derive from ecosystem: npm→package-lock.json, pnpm→pnpm-lock.yaml, yarn→yarn.lock, bun→bun.lockb, uv→uv.lock, poetry→poetry.lock, cargo→Cargo.toml, go→go.mod, bundler→Gemfile.lock, composer→composer.lock).
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.
- 2d ago First seen · 257 lines · 44 tokens per session scan A c470765c6d52
init is a skill published in the GitHub repository scolladon/craft (2 stars, last pushed 13d ago), licensed MIT. It adds 44 tokens to every session and 3,830 once invoked, about $0.0002 per session on Opus 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
tdd-rust
TDD workflow for RTK filter development. Red-Green-Refactor with Rust idioms. Real fixtures, token savings assertions, snapshot tests with insta. Auto-triggers on new filter implementation.
rtk-tdd
Enforces TDD (Red-Green-Refactor) for Rust development. Auto-triggers on implementation, testing, refactoring, and bug fixing tasks. Provides Rust-idiomatic testing patterns with anyhow/thiserror, cfg(test), and Arrange-Act-Assert workflow.
debugging
Investigate failures whose root cause is still unknown — narrow the search space, instrument, and test falsifiable hypotheses. Use for intermittent or environment-dependent behavior, unexplained stack traces, regressions with no known trigger, or any symptom without a confirmed cause. Ends once the root cause is…
architecture-review
Method for assessing a codebase's structure — duplication, single-responsibility violations, layering problems, and coupling — and recommending minimal, incremental improvements. Use when asked to review architecture, assess structure or technical debt, evaluate module boundaries, or plan a refactor. Reviews the…
code-quality-review
Checklist and method for reviewing code quality — readability, maintainability, SOLID, DRY, performance, and backward compatibility. Use when asked to review code, a diff, a branch, or a merge request for quality, or before finalizing significant changes. For GitHub PR review use the built-in /review; for…
security-audit
Security review and hardening workflow — root-cause analysis of vulnerabilities, authentication and authorization checks, least privilege, input handling, secret hygiene, and security regression tests. Use when reviewing code for security, fixing a vulnerability, hardening a feature, or handling auth, permissions…