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/5uck1ess/devkit/executingnpx skills add 5uck1ess/devkit --skill executinggit clone --depth 1 https://github.com/5uck1ess/devkitWhat 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.00024 | $0.00486 |
| Opus 5 | $0.00012 | $0.00243 |
| Sonnet 5 | $0.00005 | $0.00097 |
| Haiku 4.5 | $0.00002 | $0.00049 |
Grade A, and why
executing 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.
What it actually says
Executing
The Loop
For each step in the plan:
- Understand — Re-read the step. What exactly needs to change?
- Implement — Make the smallest change that completes the step.
- Verify — Run tests, check behavior, confirm it works.
- Commit — Save the working state before moving on.
Do not skip verify. Do not batch multiple steps into one change.
Discipline
- One step at a time. Finish step N before starting step N+1. The urge to "quickly also do" the next thing leads to half-done work.
- Don't go down rabbitholes. If you discover something unrelated that needs fixing, note it and come back later. Stay on the current step.
- Keep changes small. A 20-line diff is easy to review. A 200-line diff hides bugs. If a step produces a large diff, it should have been broken into smaller steps.
- Verify at the boundary. After completing a step, confirm the system still works end-to-end, not just the part you touched.
When Things Go Wrong
- Step is harder than expected — Stop. Re-plan. Break it into sub-steps. Don't push through with a "it'll work out" mindset.
- Step reveals a flaw in the plan — Update the plan. Plans are living documents.
- Tests break — Fix them now, not later. Broken tests that you "plan to fix" become permanently broken tests.
- You're stuck for 15+ minutes — Step back. Re-read the requirements. Try a different approach. Ask for help.
Checkpointing
Commit after each verified step. Commit messages should reference the plan step:
step 3: add input validation to parseConfig
This creates a clean, reviewable history and makes it easy to bisect if something breaks later.
Done Means Done
A step is done when:
- The implementation matches the step description
- All existing tests pass
- Any new behavior has tests
- The code is clean (no TODOs, no commented-out code, no "temporary" hacks)
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 · 50 lines · 24 tokens per session scan A 863ee71e39f6
executing is a skill published in the GitHub repository 5uck1ess/devkit (5 stars, last pushed 13d ago), licensed MIT. It adds 24 tokens to every session and 486 once invoked, about $0.0001 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
dynamic-workflows
Ultracode / Max-Parallel mode — dynamic workflows fan work out across tens–hundreds of adversarially-verified parallel subagents for large, decomposable jobs (codebase-wide audits, big migrations, cross-checked research). Opt-in; higher token spend.
cost-efficiency
Smart Routing — the DEFAULT CCGodMode routing policy. Risk-based, minimal-agent paths that preserve required safety gates for the changed scope.
agent-teams
Experimental Agent Teams orchestration — run CCGodMode agents as parallel teammates with SharedTaskList coordination (requires CLAUDECODEEXPERIMENTALAGENTTEAMS=1).
quality-gates
Parallel quality gate orchestration — @validator and @tester run simultaneously after @builder, with mandatory decision matrix for pass/fail routing.
sprint-planning
Plan-first orchestration (ADR-004): comprehensive PLAN.md, sprint files with write-scope ownership, preflight checks, serialized integration, and the release sprint. Use for any non-trivial or multi-part request BEFORE dispatching agents.
workflows
CCGodMode Full-Gates workflow definitions — used for high-risk work and when Smart Routing escalates. Default routing is Smart Routing (skills/cost-efficiency/).