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 rules/coddy-project/coddy-agent/workflowgit clone --depth 1 https://github.com/coddy-project/coddy-agentWhat 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.01476 | $0.01476 |
| Opus 5 | $0.00738 | $0.00738 |
| Sonnet 5 | $0.00295 | $0.00295 |
| Haiku 4.5 | $0.00148 | $0.00148 |
Grade A, and why
workflow 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 — 65 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Workflow (features, bugs, finish)
Specifications live in features/ (BDD)
Executable specifications for feature behavior and the happy path of a bug fix are
Gherkin .feature files in the repository-root features/ directory, run by a godog harness
(step definitions in the package that owns the behavior, e.g. external/httpserver/bdd_*_test.go,
pointing Options.Paths at ../../features/<name>.feature).
- New feature → add or extend the feature's
.featurespec infeatures/describing the scenario as it works when correct (the happy path), so the behavior is reproducible. - Bug fix → add a scenario (or feature) in
features/that reproduces the problem as a happy-path expectation, then make it pass. - Boundary / edge / error cases → do not put these in
features/; cover them with ordinary unit tests next to the code. Keep.featurefiles focused on the correct-behavior story. - Keep specs deterministic and LLM-free where possible (use a stub runner, as the existing
harnesses do). Step definitions may live near the code; the
.featurespecs stay infeatures/.
New behavior (TDD / BDD)
When adding or changing behavior (including words like feature, add, implement, фича, добавить):
- Add or extend the happy-path
.featurespec infeatures/(and/or a failing unit test) that asserts the observable outcome (red). Edge cases go in unit tests, not the spec. - Run the narrowest test scope that proves the failure is real.
- Implement the smallest change that makes the test pass (green).
- Run
make test(default,http,scheduler,ui-buildthenhttp,ui, combined scheduler tags). Everything must pass. - UI screenshots in the PR - if the change touches the SPA (
external/ui/**:.tsx,styles.css, rendered markup), attach screenshots of every changed surface to the PR description. Per edit, not one image per PR.- Screenshot the running build you already verified per
.cursor/rules/ui-verification.mdc(npx viteinexternal/ui, browser tools). Never a mockup, a hand-drawn approximation, or a re-used older image. - One image per affected view and state - a new dialog needs open and the surface it returns to; a changed row needs the row in each state the edit reaches.
- Post before/after pairs for surfaces that already existed, so the visual diff is readable without checking out the branch.
- Add narrow (390px) and wide (1280px) when layout differs between them, and light plus dark when the change adds or edits colors (the repo ships 7 themes; cover any whose tokens the change touches).
- If a surface genuinely cannot be captured (no browser available, backend-gated screen), say so explicitly in the PR and state what was verified instead - do not silently omit it.
- Screenshot the running build you already verified per
- HTTP OpenAPI narrative - If you changed the optional OpenAI-compatible HTTP API (routes, methods, headers, request or response bodies, status codes, or anything reflected in the served spec), update
external/httpserver/openapi.go(openAPISpec) so it matchesexternal/httpserver/server.gohandlers and tests. Aligndocs/http-api.md(andREADME.mdHTTP bullets) when user-facing descriptions change. - Config schema sync - If you changed the YAML config surface (
internal/configstructs: added, renamed, retyped, or removed a yaml-tagged field, enum value, or default), updatedocs/config.schema.jsonand the tables indocs/config-reference.mdto match.TestDocsConfigSchemaMatchesStructs(internal/config/docs_schema_test.go) catches key/type drift, but descriptions, defaults, enums-in-prose, and the reference tables are not auto-checked - keep them accurate by hand. Mirror user-facing fields inconfig.example.yamlandUISchemaMap()(internal/config/ui_schema.go) as well. The same change must also update the bundled self-configuration skillinternal/skills/bundled/configure-coddy/SKILL.md(its "Configuration areas" catalog and command examples are the agent-facing view of the schema) - schema edits that skip the skill ship an agent that configures against a stale surface. - Update documentation and specs if needed.
- Run
make lint(golangci-lint). Fix reported issues.
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 · 65 lines · 1,476 tokens per session scan A 3f1651237d85
workflow is a cursor rule published in the GitHub repository coddy-project/coddy-agent (127 stars, last pushed 3d ago), licensed MIT. It adds 1,476 tokens to every session, about $0.0074 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 cursor rules, from other repositories
lean
The smallest working change. Efficiency is not carelessness. Active during delivery in the aiops bundle; off during grill/alignment.
use-bun-instead-of-node-vite-npm-pnpm
../../CLAUDE.md.
angular-20
This rule provides comprehensive best practices and coding standards for Angular development, focusing on modern TypeScript, standalone components, signals, and performance optimizations.
dev-standard
Apache Superset development standards and guidelines for Cursor IDE.
typescript
Changes to these high-fan-out internals can affect every message, delta, element, or rerun. Keep work in them minimal, and benchmark changes with representative stress-test apps.
coolify-ai-docs
Master reference to all Coolify AI documentation in .ai/ directory.