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/kirodotdev/kirocrew/pod-e2enpx skills add kirodotdev/KiroCrew --skill pod-e2egit clone --depth 1 https://github.com/kirodotdev/KiroCrewWhat 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.00147 | $0.04520 |
| Opus 5 | $0.00073 | $0.02260 |
| Sonnet 5 | $0.00029 | $0.00904 |
| Haiku 4.5 | $0.00015 | $0.00452 |
Grade A, and why
pod-e2e scanned grade A with 1 finding 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 today.
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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:5476/api/sessions # live plane still alive How it starts
The opening of the file, as written. The whole thing — 325 lines — stays where its author put it; the contents beside it link to each section on GitHub.
pod-e2e — test a worktree against an isolated full-stack pod
A worktree's full stack (backend API and frontend SPA) runs as one process
on one port — exactly like a Docker container. The kirocrew pod CLI is the
only interface you need: spin one up, get a {base_url, token} handle, test
against it, tear it down and have the teardown VERIFIED. The live gateway is
never touched.
Quickstart — run the bundled e2e suite
bash <app-skills-dir>/pod-e2e/scripts/pod-e2e.sh <worktree-name> --video
Expected success output — a POD-E2E SUMMARY ending like:
✅ auth — GET /api/sessions → 200 with token, 403 without
✅ api-tests — … → exit 0
✅ playwright — headless chromium loaded dashboard …
result: 3 passed, 0 failed
ARTIFACT_DIR=~/.kirocrew-pods/.e2e-artifacts/<worktree-name>
Exit code = number of failed phases (0 = all green). Then look at the
evidence: Read the screenshots in that ARTIFACT_DIR
(fe-smoke.png, plus any spec screenshots) to confirm the real UI rendered —
not a 403/blank page.
To smoke-test isolation after it finishes:
kirocrew pod ls # should be empty (torn down)
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:5476/api/sessions # live plane still alive
The interface — kirocrew pod CLI
# 1. bring the pod up, get a handle (JSON: base_url + token + port)
kirocrew pod up <wt> --json
# → {"name":"<wt>","status":"up","port":7958,
# "base_url":"http://127.0.0.1:7958","token":"…","ttl":"2h"}
# 2. test against the handle — full stack, ONE port:
curl -s "$base_url/api/<anything>?token=$token" # backend API
# open $base_url/?token=$token in Playwright # frontend SPA (same port)
# 3. destroy it — deletes the HOME and verifies it is gone (nonzero if not),
# live gateway untouched
kirocrew pod down <wt>
Other verbs: ls (list running pods) · status <wt> · token <wt> · url <wt>
· logs <wt> · provision <wt>. Run kirocrew pod --help for the full list.
What ships with it
2 files 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.
- today Changed · +6 lines a3c4443f37e7
- 2d ago First seen · 319 lines · 147 tokens per session scan A 88a5520ce7bf
pod-e2e is a skill published in the GitHub repository kirodotdev/KiroCrew (3,532 stars, last pushed today), licensed Apache-2.0. It adds 147 tokens to every session and 4,520 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
copilotkit-setup
Use when adding CopilotKit to an existing project or bootstrapping a new CopilotKit project from scratch. Covers framework detection, package installation, runtime wiring (managed Intelligence or self-hosted SSE), provider setup, and first working chat integration.
setup-slack-channel
Use for the PROVIDER half of getting a locally running CopilotKit Channels agent to answer in Slack, when no Slack app exists yet — setting up a Channels bot in Slack for the first time, creating the Slack app and its tokens, attaching it to a managed Intelligence Channel, or when a Channel reports setuprequired, sits…
copilotkit-channels
Use for the CODE half of a managed Intelligence Channel with Slack or Microsoft Teams: customising the Channel a CLI-scaffolded project already ships, or — for a project the CLI did not generate — writing the Channel declaration, the long-running host, and the awaited activation call. Teams provider setup is in scope…
runtime
@copilotkit/runtime — mount a fetch-native CopilotRuntime on any JS server, wire middleware, pick an AgentRunner, instantiate BuiltInAgent (Factory Mode with TanStack AI is the preferred default) or plug in any of 12 external agent frameworks (Mastra, LangGraph, CrewAI Crews/Flows, PydanticAI, ADK, LlamaIndex, Agno…
copilotkit-integrations
Use when wiring an external agent framework (LangGraph, CrewAI, PydanticAI, Mastra, ADK, LlamaIndex, Agno, Strands, Microsoft Agent Framework, or others) into a CopilotKit application via the AG-UI protocol.
copilotkit-develop
Use when building AI-powered features with CopilotKit v2 -- adding chat interfaces, registering frontend tools, sharing application context with agents, handling agent interrupts, and working with the CopilotKit runtime.