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/soulcodex/agentic/format-markdownnpx skills add soulcodex/agentic --skill format-markdowngit clone --depth 1 https://github.com/soulcodex/agenticWhat 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.00056 | $0.00527 |
| Opus 5 | $0.00028 | $0.00264 |
| Sonnet 5 | $0.00011 | $0.00105 |
| Haiku 4.5 | $0.00006 | $0.00053 |
Grade A, and why
format-markdown 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 2d 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.
What it actually says
Markdown Formatting Skill
Format Markdown files so they are structurally correct, readable, and consistent with the repository's formatting/lint rules.
Step 1 - Determine Scope
- If the user provides files, format only those files.
- Otherwise format changed Markdown files in the current branch/diff.
- If no changed Markdown files exist, ask for explicit paths before proceeding.
Step 2 - Load Local Conventions
- Read project formatting/lint config when present (for example
.prettierrc*,.markdownlint*, lint scripts inpackage.json,justfile,Makefile). - Apply the repository's conventions over generic defaults.
- Read
rules.mdand treat those rules as baseline behavior.
Step 3 - Apply Formatter (Preferred Order)
- Run repository-native formatting command if one exists (for example
just,make, or package script targeting markdown). - If none exists, use a standard Markdown formatter available in the repo toolchain (for example Prettier).
- If Markdown linter auto-fix is configured, run it after formatting.
Do not introduce formatting tools that are not already part of the repository unless the user asks.
Step 4 - Validate
- Run markdown checks/lint commands available in the repository.
- If checks fail with auto-fixable findings, apply fixes and re-run checks.
- Report any remaining non-auto-fixable violations with file paths.
Step 5 - Safety Rules
- Preserve document meaning and code block content.
- Do not rewrite prose for style unless the user asks.
- Do not alter links/anchors in ways that break navigation.
- Keep frontmatter valid and unchanged semantically.
Step 6 - Output
Report:
- files formatted
- command(s) used
- verification command(s) and results
- any remaining manual fixes required
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.
- 2d ago First seen · 70 lines · 56 tokens per session scan A 86d07029b0ce
format-markdown is a skill published in the GitHub repository soulcodex/agentic (10 stars, last pushed 2d ago), licensed MIT. It adds 56 tokens to every session and 527 once invoked, about $0.0003 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-31.
Other skills, from other repositories
bricks-builder
Research, implement, modify, and audit behavior inside Bricks Builder sites using the bundled Bricks Academy corpus, stable development workflows, and version-aware verification against an authorized active Bricks installation. Use when the requested outcome concerns Bricks elements, controls, schema, hooks…
help
Use when asked what the capstone plugin can do - prints the usage block.
core
Internal to the capstone suite - carries the shared rules (references/) and scripts every capstone subcommand reads; it exists so npx-skills installs ship them alongside the command skills. Not meant to be invoked directly; when invoked anyway, run references/../scripts/help.sh and output its stdout verbatim.
groom
Use when starting work on a feature or change for a project that already has capstone docs - "new feature", "add a feature", "implement X", "build X", "design a feature", "spec it out", "flesh out", "refine this idea", "let's work on X" - a doc-grounded one-question-at-a-time interview producing a traceable feature…
map
Use when asked to build, refresh, update, or check a codebase's architecture reference docs - "map the codebase", "document this repo", "are the docs current", "bring the docs in line with the code" - writes a docs/capstone/ index plus topic chapters, the logic/ business-logic map and the uiux/ surface map, then on…
feature
Use when the user wants one feature taken from idea to working code - "add a feature", "build X end to end", "take X from idea to shipped" - runs the feature chain groom -> plan -> implement consecutively, detecting the feature's stage and resuming at the first incomplete one. For the whole-product greenfield pipeline…