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 jjdmev2/dme-skills --skill chonchigit clone --depth 1 https://github.com/jjdmev2/dme-skillsWrote 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/jjdmev2/dme-skills/chonchi)<a href="https://agentmods.dev/skills/jjdmev2/dme-skills/chonchi"><img src="https://agentmods.dev/badge/skills/jjdmev2/dme-skills/chonchi/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/jjdmev2/dme-skills/chonchi"><img src="https://agentmods.dev/badge/skills/jjdmev2/dme-skills/chonchi.svg" alt="Reviewed on agentmods" width="80" 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.00147 | $0.03737 |
| Opus 5 | $0.00073 | $0.01869 |
| Sonnet 5 | $0.00029 | $0.00747 |
| Haiku 4.5 | $0.00015 | $0.00374 |
Grade C, and why
chonchi scanned grade C with 3 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 10d 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.
Sends data to an external URLmediumData exfiltration
A POST to an outside endpoint may be telemetry or may be exfiltration; either way the mod talks to somewhere, and you should know where.
curl -X PUT --data-binary @"$OUT" \ Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
SOURCE_TRANSCRIPT="$(cat "$HOME/.claude/dme/last-transcript.path")" Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
curl -X PUT --data-binary @"$OUT" \ How it starts
The opening of the file, as written. The whole thing — 183 lines — stays where its author put it; the contents beside it link to each section on GitHub.
chonchi
The session's work is done and the user has tested it — you are now handing it off to the broader
team for review. This is the end-of-session ritual /ccthis (the build command) deliberately does NOT do,
because building is a multi-turn conversation and the export must capture the WHOLE session. Run /chonchi
once, at the end. Before the steps, locate the source transcript filename/path that will be exported and
derive a stable <SESSION_KEY> from it (for example, a deterministic hash of that canonical path). Use
that exact key for this run's comment marker and transcript filename; do not derive it from wall-clock time.
The unit is the WORK ISSUE, never the epic. /ccthis builds one work issue (a sub-issue of an epic,
or a standalone issue) per run — that work issue is what you hand off. The parent epic is touched exactly
once, in step F (the roll-up); its state, estimate and labels are aggregations of its children and are
never overwritten by one child's handoff.
Target — usually there is NO argument, and that's the normal case. You've been building ONE work issue
on ONE branch this session (that's how /ccthis works), so it is already in context — just use it.
Derive it, in order:
- the work issue
/ccthisbuilt this session — if/ccthiswas invoked on an epic ID, the work issue it selected, NOT the epic; - any Linear issue ID already fetched/updated this session that matches this branch's work;
- the current git branch name (it usually carries the ID, e.g.
kis-160-share-links→KIS-160).
If what you derived — or were explicitly handed — is an EPIC, do not hand the epic off. Resolve it to
the child work issue this session's branch actually built; ask only if you genuinely can't tell. An
explicit /chonchi KIS-160 overrides the derivation, subject to the same rule. State which work issue
you're handing off in your final summary so the user can catch a wrong guess. Throughout,
<WORK_ISSUE> = that issue.
Do the six steps below in order. Each is independent — if one fails, still do the rest and say so in
your final summary; never silently skip a step. Step E (the chonchi tag) is the success marker: apply it
only after the transcript attachment and GitHub link both succeed. Step F refreshes the parent epic only
after that state is accurate.
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.
- 10d ago First seen · 183 lines · 147 tokens per session scan C 0b89f3b7e87f
chonchi is a skill published in the GitHub repository jjdmev2/dme-skills (3 stars, last pushed 1mo ago), licensed MIT. It adds 147 tokens to every session and 3,737 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it C with 3 findings (sends data to an external url, reads agent configuration directories, makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
recipe-decompose
Decomposes Linear issues or requirement documents into the fewest implementation-ready value units, then registers the approved tasks in Linear. Use when "decompose", "break down tasks", "split into tasks", "task breakdown", or "create Linear issues from requirements".
codex-symphony
Install and operate a portable OpenAI Symphony + Linear orchestration setup in any Git repository. Use when the user wants a one-command local Symphony runner, a reusable WORKFLOW template, background launch scripts, or a Codex wrapper that restarts Symphony automatically when reopening the CLI.
issue-triage
Triage and categorize GitHub issues with priority labels. Use when user says "triage issues", "check issues", "review open issues", or during regular maintenance of GitHub issue backlog.
cyrus-setup-repository
Add one or more Git repositories to Cyrus configuration so it can process issues from those repos.
feature-dev
Guide a feature implementation through a structured seven-phase workflow with deep codebase understanding, clarifying questions, parallel architecture design, and quality review. Use this skill when the user asks to build a new feature, add functionality, or wants a methodical approach to implementation rather than…
product-manager-toolkit
Use when the user needs product management workflows such as RICE prioritization, customer interview analysis, PRD templates, discovery frameworks, go-to-market strategy, feature prioritization, research synthesis, or requirements documentation.