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/styler-ai/projectatlas/codex-coding-pluginnpx skills add styler-ai/ProjectAtlas --skill codex-coding-plugingit clone --depth 1 https://github.com/styler-ai/ProjectAtlasWhat 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.00059 | $0.01457 |
| Opus 5 | $0.00030 | $0.00728 |
| Sonnet 5 | $0.00012 | $0.00291 |
| Haiku 4.5 | $0.00006 | $0.00146 |
Grade A, and why
codex-coding-plugin 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.
How it starts
The opening of the file, as written. The whole thing — 105 lines — stays where its author put it; the contents beside it link to each section on GitHub.
ProjectAtlas Plugin Host Integration
Goal
Make ProjectAtlas releases converge to one verified version across the repository release tag, ProjectAtlas plugin manifests, native runtime binary, generated MCP configs, Codex marketplace/plugin cache, Codex global MCP registry, packaged ProjectAtlas skill files, Claude Code config, OpenCode config, and any old ProjectAtlas information that can survive in a host cache.
This is a repo-local ProjectAtlas skill. Do not generalize these rules into product claims for unrelated plugins. The point is to keep this repository's supported host integrations from reintroducing stale ProjectAtlas versions or paths.
Workflow
- Treat the ProjectAtlas release tag and plugin manifest versions as the release contract, but verify them against the native runtime with
projectatlas --format json runtime-infobefore writing configs. - Never trust one version signal alone. Check every ProjectAtlas surface that can keep stale data:
.codex-plugin/plugin.json,.claude-plugin/plugin.json, andopencode/opencode.json;- Codex plugin list version and, when exposed, the reported installed source path;
- manifest and ProjectAtlas skill artifact under the reported Codex source path;
- runtime
runtime-infoproject, major version, capabilities, executable, and version; - generated MCP
--require-version, DB path, config path, and finalmcpcommand; - Codex global MCP registry runtime, DB/config, and version guard;
- Claude Code
.mcp.jsonconfig consumption; - OpenCode
opencode.jsonconfig consumption; - downstream
.github/workflowsrelease pins that still point at old ProjectAtlas tags.
- Prefer official host commands for host state. Inspect cache/source files only after the host reports the source path and after confirming it is the official ProjectAtlas source.
- Make official ProjectAtlas paths work. If an official Codex marketplace/plugin cache is stale, repair it automatically with the supported remove/add, upgrade, or marketplace replacement flow, then re-read host state. Do not stop at a stale-cache warning unless the environment is intentionally managed or repair still cannot converge.
- Preserve user-managed environments. If the marketplace/source is not clearly the official
styler-ai/ProjectAtlassource, do not mutate it; report a concrete user-managed skip. - Claude Code and OpenCode do not use the Codex marketplace/cache model in this repo. For them, verify the generated project-local config with structured JSON parsing, then smoke the real host CLI when installed.
- Pin generated MCP configs to absolute verified runtime, DB, and config paths. Avoid PATH-only fallbacks for ProjectAtlas-installed configs.
- Compare canonical runtime paths, including symlink resolution where available. A shim path and resolved executable path must not create a false mismatch if they refer to the same verified runtime.
- Keep installer output concrete: say which host, version, path, config, cache, registry entry, or workflow pin was verified, repaired, skipped, or still mismatched.
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 · 105 lines · 59 tokens per session scan A c131de524d03
codex-coding-plugin is a skill published in the GitHub repository styler-ai/ProjectAtlas (371 stars, last pushed 2d ago), licensed MIT. It adds 59 tokens to every session and 1,457 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-30.
Other skills, from other repositories
graph
Whole-codebase structural map of the codanna index as one self-contained HTML disc. Wedges per top-level module, concentric rings with hubs at the centre, hover or click a symbol to light its edge web, search, hide or highlight modules, brush a date range on the ribbon timeline (symbols dated by git blame), heatmap of…
x-ray
Deep codebase exploration using semantic search and relationship mapping. Use when you need to understand the current codebase.
use-ivygrep
Gather focused local repository context with ivygrep before implementing, debugging, reviewing, or explaining code. Use for coding tasks involving unfamiliar paths, branch changes, stack traces, architectural relationships, callers, dependents, tests, configuration, or documentation. Prefer one bounded context pack…
codemeridian-test-planning
Plan focused tests with CodeMeridian by finding relevant test shields, coverage gaps, impacted behavior, and the smallest useful test set before implementation.
codemeridian-context
Gather minimal, graph-grounded CodeMeridian context before implementation, refactoring, deletion, debugging, or test planning.
codemeridian-frontend
Route frontend HTML/CSS/SCSS work through CodeMeridian's generic frontend-aware tools first, then use cascade and style-duplicate analysis only when the question is truly frontend-specific.