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 LerianStudio/ring --skill writing-plansgit clone --depth 1 https://github.com/LerianStudio/ringWrote 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/lerianstudio/ring/writing-plans)<a href="https://agentmods.dev/skills/lerianstudio/ring/writing-plans"><img src="https://agentmods.dev/badge/skills/lerianstudio/ring/writing-plans.svg" alt="Measured on agentmods" 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.00094 | $0.03549 |
| Opus 5 | $0.00047 | $0.01775 |
| Sonnet 5 | $0.00019 | $0.00710 |
| Haiku 4.5 | $0.00009 | $0.00355 |
Grade A, and why
ring:writing-plans 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 7d 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 — 271 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Writing Plans
When to use
- Spec or requirements exist for a multi-step task and no implementation has started
- Feature spans multiple files/layers and needs decomposition before coding
- Handing off implementation to a separate session, agent, or human
Skip when
- Single-file change with obvious shape (just do it)
- Exploratory spike — phased plans assume known requirements
- Spec is still in brainstorming; the plan would lock premature decisions
Sequence
Runs after: ring:exploring-codebases, ring:planning-large-features (gates 0-6 artifacts) or ring:planning-small-features (gates 0-2 artifacts) — their outputs feed the spec Runs before: ring:executing-plans (rolling-wave execution) or ring:running-dev-cycle (gated subagent workflow)
Related
Companion: plan-document-reviewer-prompt.md — subagent dispatch template for thorough plan review
Write the plan assuming the implementer is skilled but has zero context for this codebase, toolset, or problem domain.
The plan is a rolling-wave document. Only the first phase is detailed to task level at plan time; later phases stay at epic level until execution reaches them. Detail decays: code written in Phase 1 invalidates assumptions baked into Phase 3 tasks, so do not write Phase 3 tasks yet. ring:executing-plans elaborates each subsequent phase against the codebase as it actually exists.
Announce at start: "Using ring:writing-plans to author the implementation plan."
Default save path: docs/plans/YYYY-MM-DD-<feature-name>.md
(User preferences override.)
Invoked from pre-dev: when dispatched as the final gate of ring:planning-large-features or ring:planning-small-features, the spec inputs are the pre-dev artifacts — trd.md (plus feature-map.md, openapi.yaml, the schema file, and dependencies.md on the Large track). On Large, plan phases MUST mirror feature-map.md phases one-to-one. Output path is docs/pre-dev/{feature}/plan.md, overriding the default above; standalone invocations keep the default. plan.md is always a SINGLE document per feature: on multi-module topologies (monorepo fullstack / multi-repo), each epic carries one line **Target:** backend | frontend | infra (placed right before **Status:**); for multi-repo features the orchestrator copies plan.md into each repo and the local dev-cycle executes only epics whose Target matches that repo. No per-module plan splits.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 7d ago First seen · 271 lines · 94 tokens per session scan A cea376a8a911
ring:writing-plans is a skill published in the GitHub repository LerianStudio/ring (211 stars, last pushed 18d ago), licensed Apache-2.0. It adds 94 tokens to every session and 3,549 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-30.
Other skills, from other repositories
clean-code-review
Run a comprehensive Clean Code audit against the codebase — module size, function complexity, long parameter lists, TODO/FIXME markers, commented-out code, duplication (DRY), Boy Scout delta, dead exports, test smells, shell-parity (PS/Bash twins), dep boundaries (cross-package imports), frozen-arrays drift…
code-review
Plan-Forge-tuned comprehensive code review — runs public-surface diff, forge analysis, architecture / security / testing / patterns checks, plus Plan-Forge-specific gates (ACI compliance, dual-shell parity, branch model). Use before merging features or at the end of a phase. With --quorum, dispatches multi-model…
forge-quench
Systematically reduce .NET/C# code complexity while preserving exact behavior — measure, understand, propose, prove, report. Use after a feature is complete and tests pass, when code works but is harder to maintain than it should be.
ds-simplify
Approved simplification — overengineering hygiene with one approval batch and zero silent deletion. Use when removing complexity, dead code, or overengineering safely.
ds-review
Code improvement — tactical fixes plus strategic architecture alignment. Use when reviewing code for bugs, quality, or architectural fit.
ds-pr
Smart pull requests — Conventional Commit title and clean body for release-please. Use when opening or formatting a pull request.