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/patlux/pi-commandcode-provider/pi-commandcode-releasenpx skills add patlux/pi-commandcode-provider --skill pi-commandcode-releasegit clone --depth 1 https://github.com/patlux/pi-commandcode-providerWhat 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.00047 | $0.00737 |
| Opus 5 | $0.00023 | $0.00368 |
| Sonnet 5 | $0.00009 | $0.00147 |
| Haiku 4.5 | $0.00005 | $0.00074 |
Grade A, and why
pi-commandcode-release 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 — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
pi-commandcode-provider Release Skill
Use this skill for every pi-commandcode-provider release.
Core rule
Keep release work explicit and auditable. Do not publish, tag, push, or merge unless the user explicitly asks in the current conversation.
Required release order
Preferred order for stable releases:
- Create a release branch with the version/changelog changes.
- Open a release PR.
- Wait for CI to pass.
- Create a local annotated git tag for the release commit while the PR is still open.
- Publish the npm package from the release branch/commit.
- Create the GitHub Release from the release tag.
- Verify npm and the GitHub Release.
- Merge the release PR into
main. - Move/recreate the git tag on the merge commit if the project requires tags to point at
main, then force-update only after explicit user approval. Prefer documenting the tag target instead of force-updating. - Comment on included PRs/issues after the package and GitHub Release are live.
If branch protection or repository policy requires tags to point at main, ask before changing the order or force-updating a tag.
Version and changelog
- Increase semver appropriately; for a patch release use
npm version patch --no-git-tag-version. - Update
CHANGELOG.mdin the same PR. - Add a dated section for the new version.
- Include user-facing changes and dependency/security fixes.
- Include a
Contributorssubsection for every release that had external reports, PRs, testing, or issue validation.
Example changelog structure:
## 0.4.1 - 2026-06-16
- Fix provider registration for newer pi versions.
- Resolve npm audit findings.
### Contributors
- @user-a — fixed provider registration.
- @user-b — reported/validated retry behavior.
Validation
Run the checks from RELEASE.md. For this repo, at minimum:
npm test
npm run typecheck
npm run format:check
npm audit --audit-level=moderate
npm pack --dry-run
git diff --check
If local pi auth makes test:pi-local use the wrong provider state, rerun the suite with a harmless mock Command Code API key in the environment instead of real auth.
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 · 103 lines · 47 tokens per session scan A 303f6b059973
pi-commandcode-release is a skill published in the GitHub repository patlux/pi-commandcode-provider (131 stars, last pushed 6d ago), licensed MIT. It adds 47 tokens to every session and 737 once invoked, about $0.0002 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
surf
Control Chrome browser via CLI for testing, automation, and debugging. Use when the user needs browser automation, screenshots, form filling, page inspection, network/CPU emulation, DevTools streaming, or AI queries via ChatGPT/Gemini/Perplexity/Grok/AI Studio.
prose-review
Review prose written for others -- user-facing docs, prompts for other LLMs, inline comments, docstrings, and other-facing messages -- for local jargon leakage, orphaned references, missing grounding, and audience or genre misfit.
text-search
Search indexed text corpora with qmd. For indexed content, prefer qmd over grep.
repoprompt-tool-guidance-refresh
Refresh RepoPrompt tool guidance when the CLI/MCP surface changes. Tracks RepoPrompt CE (rpce-cli, the maintained target) across versions, and can diff the frozen Classic CLI (rp-cli) against CE. Uses /.pi/agent/skills/repoprompt-tool-guidance-refresh/scripts/track-rp-version.sh to capture/diff --help and -l (tool…
xcodebuildmcp
Build/test Xcode projects via the XcodeBuildMCP MCP server using a local CLI wrapper for pi (no MCP support). Use when the user mentions Xcode, xcodebuild, iOS builds/tests, or XcodeBuildMCP.
agent-browser
Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.