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/ohswedd/praxis/code-craftnpx skills add Ohswedd/praxis --skill code-craftgit clone --depth 1 https://github.com/Ohswedd/praxisWhat 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.00090 | $0.01038 |
| Opus 5 | $0.00045 | $0.00519 |
| Sonnet 5 | $0.00018 | $0.00208 |
| Haiku 4.5 | $0.00009 | $0.00104 |
Grade A, and why
code-craft 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 — 82 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Craft
Production code is read far more than it is written. These are the standards praxis applies to every change so the result is clean, professional, and maintainable, not just working.
Comments: the core discipline
Explain why, not what. The code already says what it does; a good comment says why it does it that way, what it protects against, or what non-obvious constraint it satisfies.
- Bad:
// increment i by 1 - Bad:
// loop over users - Good:
// Retry once: the upstream returns 503 during its rolling deploy. - Good:
// Must run before auth middleware, it populates the request context.
Rules:
- Do not comment the obvious. If the comment restates the code, delete it and improve the name instead.
- Comment intent, invariants, edge-case reasoning, non-obvious performance or security decisions, and links to the spec/issue/doc that justifies a choice.
- Keep comments next to the code they describe and update them in the same edit a stale comment is worse than none.
- Use the language's documentation convention for public APIs (docstrings, JSDoc/TSDoc, Javadoc, rustdoc, GoDoc): describe purpose, parameters, return, errors/exceptions, and side effects, not the line-by-line implementation.
- Prefer self-documenting code over comments: a well-named function or variable removes the need for the comment entirely.
- Write comments in the language and style already used in the file/project, and keep that style consistent across it.
- No scaffolding or narration. Don't number steps ("Step 1: …"), don't leave section-label comments that only restate the block below, and don't point at a doc or a step list in place of the reasoning. Cite a doc only to justify a specific non-obvious choice (rule 2), never as a stand-in for explaining it.
TODO hygiene
- Do not leave bare
TODO/FIXMEin delivered code. If a follow-up is genuinely out of scope, surface it in the task report's "Out of scope / follow-ups" section so the user knows about it: do not bury it in a comment. - Never ship
NotImplemented, stub returns,...,pass # implement, orthrow "not implemented"as a substitute for finishing in-scope work.
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 · 82 lines · 90 tokens per session scan A 160eea550c13
code-craft is a skill published in the GitHub repository Ohswedd/praxis (1 stars, last pushed 1mo ago), licensed MIT. It adds 90 tokens to every session and 1,038 once invoked, about $0.0005 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
seo
Optimize for search engine visibility and ranking. Use when asked to "improve SEO", "optimize for search", "fix meta tags", "add structured data", "sitemap optimization", or "search engine optimization".
core-web-vitals
Optimize Core Web Vitals (LCP, INP, CLS) for better page experience using field and lab evidence. Use when asked to "improve Core Web Vitals", "fix LCP", "reduce CLS", "optimize INP", "page experience optimization", or "fix layout shifts".
release
Cut a sim-use release end-to-end. Use when the user runs /release or asks to "ship a release", "publish a version", "cut a release", or "release to homebrew". Drives scripts/local-release.sh; never reimplement its build/sign/tarball logic.
agent-desktop-ffi
C-ABI bindings over agent-desktop's PlatformAdapter. Consumers (Python ctypes, Swift, Node ffi-napi, Go cgo, C++, Ruby fiddle) link libagentdesktopffi.{dylib,so,dll} and call ad functions directly instead of spawning the CLI binary per call. The canonical observe-act workflow is: adinit → adadaptercreate[withsession]…
Accessibility Auditor
Comprehensive WCAG 2.1 AA compliance testing combining automated axe-core scans with manual keyboard navigation, screen reader compatibility, and focus management verification.
GitHub Hub
Your intelligent GitHub command center -- start here. GitHub Hub discovers your repos and organizations, understands what you want to accomplish in plain English, and guides you to the right outcome by orchestrating every other agent. No commands to memorize. Just talk.