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 gvkhosla/compound-engineering-pi --skill ce-plangit clone --depth 1 https://github.com/gvkhosla/compound-engineering-piWrote 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/gvkhosla/compound-engineering-pi/ce-plan)<a href="https://agentmods.dev/skills/gvkhosla/compound-engineering-pi/ce-plan"><img src="https://agentmods.dev/badge/skills/gvkhosla/compound-engineering-pi/ce-plan.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.00098 | $0.06663 |
| Opus 5 | $0.00049 | $0.03331 |
| Sonnet 5 | $0.00020 | $0.01333 |
| Haiku 4.5 | $0.00010 | $0.00666 |
Grade A, and why
ce:plan scanned grade A with 1 finding 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 8d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
RESPONSE=$(curl -s -X POST https://www.proofeditor.ai/share/markdown \ How it starts
The opening of the file, as written. The whole thing — 653 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Create Technical Plan
Note: The current year is 2026. Use this when dating plans and searching for recent documentation.
ce:brainstorm defines WHAT to build. ce:plan defines HOW to build it. ce:work executes the plan.
This workflow produces a durable implementation plan. It does not implement code, run tests, or learn from execution-time results. If the answer depends on changing code and seeing what happens, that belongs in ce:work, not here.
Interaction Method
Use the platform's question tool when available. When asking the user a question, prefer the platform's blocking question tool if one exists (AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini). Otherwise, present numbered options in chat and wait for the user's reply before proceeding.
Ask one question at a time. Prefer a concise single-select choice when natural options exist.
Feature Description
<feature_description> #$ARGUMENTS </feature_description>
If the feature description above is empty, ask the user: "What would you like to plan? Please describe the feature, bug fix, or improvement you have in mind."
Do not proceed until you have a clear planning input.
Core Principles
- Use requirements as the source of truth - If
ce:brainstormproduced a requirements document, planning should build from it rather than re-inventing behavior. - Decisions, not code - Capture approach, boundaries, files, dependencies, risks, and test scenarios. Do not pre-write implementation code or shell command choreography. Pseudo-code sketches or DSL grammars that communicate high-level technical design are welcome when they help a reviewer validate direction — but they must be explicitly framed as directional guidance, not implementation specification.
- Research before structuring - Explore the codebase, institutional learnings, and external guidance when warranted before finalizing the plan.
- Right-size the artifact - Small work gets a compact plan. Large work gets more structure. The philosophy stays the same at every depth.
- Separate planning from execution discovery - Resolve planning-time questions here. Explicitly defer execution-time unknowns to implementation.
- Keep the plan portable - The plan should work as a living document, review artifact, or issue body without embedding tool-specific executor instructions.
- Carry execution posture lightly when it matters - If the request, origin document, or repo context clearly implies test-first, characterization-first, or another non-default execution posture, reflect that in the plan as a lightweight signal. Do not turn the plan into step-by-step execution choreography.
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.
- 8d ago First seen · 653 lines · 98 tokens per session scan A 9a15cbb1cdce
ce:plan is a skill published in the GitHub repository gvkhosla/compound-engineering-pi (51 stars, last pushed 4mo ago), licensed MIT. It adds 98 tokens to every session and 6,663 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
codex-claude-worker
Translate natural-language user requests into bounded Claude Code worker tasks while Codex or ChatGPT remains the supervisor. Use when the user gives an ordinary prompt and wants Codex to clarify scope, choose a safe work boundary, generate a worker prompt, approve or defer worker execution, read run summaries and…
write-swift
How to write modern Swift well — modeling with value types, Swift 6 data-race safety and approachable concurrency (@concurrent, main-actor-by-default, actors, task groups), protocols and generics (some vs any), API design, performance and ARC, Swift Testing, macros, and the modern language features agents don't know…
apple-design
Apple's approach to interface design and fluid, physical motion, translated for the web. Use when building or reviewing gesture-driven UI, spring animations, drag/swipe/sheet interactions, momentum and interruptible transitions, translucent materials and depth, typography (optical sizing, tracking, leading)…
emil-design-eng
This skill encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great.
provider-model-discovery
Descobre e seleciona modelos de providers LLM de forma report-only: inventário read-only de modelos, docs oficiais, quota/billing/rate gates e shortlist para canary protegido. Use antes de adicionar providers, escolher modelos ou migrar monitores/roteamento.
source-research
Research open-source libraries with evidence-backed answers and GitHub permalinks. Use when the user asks about library internals, needs implementation details with source code references, wants to understand why something was changed, or needs authoritative answers backed by actual code. Excels at navigating large…