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/spytensor/openmozi/coding-agentnpx skills add spytensor/openmozi --skill coding-agentgit clone --depth 1 https://github.com/spytensor/openmoziWhat 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.00016 | $0.00676 |
| Opus 5 | $0.00008 | $0.00338 |
| Sonnet 5 | $0.00003 | $0.00135 |
| Haiku 4.5 | $0.00002 | $0.00068 |
Grade A, and why
coding-agent 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 yesterday.
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 — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Coding Agent
When to Use
- User asks to implement a feature, fix a bug, or modify code
- User asks to build, create, or set up a project or component
- Any task that involves writing or modifying source code
- Always active: enforces the structured workflow for all coding tasks
How to Execute
Phase 1: Read & Understand
- Read the relevant source files to understand the current state.
- Identify the exact files, functions, and lines that need to change.
- Check for existing tests, types, and conventions in the codebase.
- Read any related config files, schemas, or documentation.
Phase 2: Plan
- State what will change and what will NOT change.
- List every file to be modified or created.
- If the change is non-trivial (>20 lines), describe the approach before writing code.
- If the request conflicts with existing architecture, state the conflict and options.
- Get user confirmation on the plan for large changes.
Phase 3: Implement
- Make the minimum change that satisfies the requirement.
- Match existing code style — indentation, naming, patterns.
- Add JSDoc to public functions. Use TypeScript strict types.
- Handle errors explicitly — no silent swallows, no bare
catch {}. - Add timeouts to external I/O calls.
- Do NOT refactor unrelated code unless explicitly asked.
Phase 4: Test
- Run existing tests to ensure nothing is broken:
pnpm test. - If new behavior was added, write tests that prove it works.
- Tests must cover: happy path, error case, edge case.
- Mock external boundaries in unit tests; keep real provider calls in explicit integration tests.
Phase 5: Verify
- Run
pnpm buildto confirm TypeScript compiles cleanly. - Run
pnpm testto confirm all tests pass. - List every file modified and summarize each change.
- Identify the most likely failure point in the new code.
Examples
Input: "Add a health check endpoint to the API" Workflow: Read index.ts and Fastify setup → Plan: add GET /health route → Implement the route → Write test → Verify build + tests pass.
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.
- yesterday First seen · 71 lines · 16 tokens per session scan A d8db2a8c0323
coding-agent is a skill published in the GitHub repository spytensor/openmozi (192 stars, last pushed 25d ago), licensed MIT. It adds 16 tokens to every session and 676 once invoked, about $0.0001 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-30.
Other skills, from other repositories
design-taste-frontend
Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check.
stitch-design-taste
Semantic Design System Skill for Google Stitch. Generates agent-friendly DESIGN.md files that enforce premium, anti-generic UI standards — strict typography, calibrated color, asymmetric layouts, perpetual micro-motion, and hardware-accelerated performance.
full-output-enforcement
Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly. Apply to any task requiring exhaustive, unabridged output.
imagegen-frontend-mobile
Elite mobile app image-generation skill for creating premium, app-native screen concepts and flows. Designed for iOS, Android, and cross-platform mobile products. Prioritizes clean hierarchy, comfortably readable text, strong multi-screen consistency, controlled color palettes, non-generic creative direction, textured…
image-to-code
Elite website image-to-code skill for Codex. For visually important web tasks, it must first generate the design image(s) itself, deeply analyze them, then implement the website to match them as closely as possible. In Codex, it must prefer large, readable, section-specific images instead of tiny compressed boards…
imagegen-frontend-web
Elite frontend image-direction skill for generating premium, conversion-aware website design references. CRITICAL OUTPUT RULE — generate ONE separate horizontal image FOR EVERY section. A landing page with 8 sections produces 8 images. Never compress multiple sections into one image. Enforces composition variety (not…