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/carbeneai/forge/executingplansnpx skills add CarbeneAI/Forge --skill executingplansgit clone --depth 1 https://github.com/CarbeneAI/ForgeWhat 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.00075 | $0.03438 |
| Opus 5 | $0.00037 | $0.01719 |
| Sonnet 5 | $0.00015 | $0.00688 |
| Haiku 4.5 | $0.00007 | $0.00344 |
Grade A, and why
executing-plans 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 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
$ curl -X POST http://localhost:3000/api/login \ How it starts
The opening of the file, as written. The whole thing — 670 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Executing Plans
Systematically execute written implementation plans with batch processing, verification checkpoints, and progress reporting.
🎯 Load Full CORE Context
read ${PAI_DIR}/skills/CORE/SKILL.md
When to Activate This Skill
- "execute the plan at docs/plans/..." → Systematic implementation
- "implement from the plan" → Follow written specification
- "start working on the plan" → Batch execution with checkpoints
- User has written plan ready to execute
Core Philosophy
Plans Are Single Source of Truth
The plan document specifies:
- What to build
- How to build it
- What order to build it
- How to verify each step
Follow the plan exactly. Don't improvise or "improve" unless explicitly discussed with user.
Batch Execution with Checkpoints
Execute 3 tasks (default), then STOP and report:
- What was implemented
- Verification output
- Current status
Wait for user feedback before continuing. This enables:
- Course correction if something's wrong
- User awareness of progress
- Clear stopping points
- Better debugging
STOP When Blocked
If you encounter ANY uncertainty:
- Missing file referenced in plan
- Unclear instruction
- Dependency issue
- Environment problem
STOP and ASK. Never guess or make assumptions.
The Five-Step Process
Step 1: Load and Review Plan
Before starting any work:
- Read the entire plan from docs/plans/
- Review critically - does it make sense?
- Check prerequisites - are they met?
- Understand execution order - why this sequence?
- Raise concerns before starting
Critical Questions:
- Is the plan clear and executable?
- Are prerequisites met?
- Do file paths exist or need creation?
- Are dependencies installed?
- Is codebase state ready for this plan?
If you find issues with the plan, STOP and report them before starting.
Example Review:
## Plan Review
**Plan:** docs/plans/2026-02-03-user-auth.md
**Checked:**
- [x] Prerequisites met (Express running, Vitest configured, bcrypt installed)
- [x] File paths make sense (src/models/, tests/, src/services/)
- [x] Task sequence logical (test-first, then implement)
- [x] Verification steps clear
**Concerns:**
- None - plan looks executable
**Ready to start:** YES
Proceeding with first batch (Tasks 1-3).
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 · 670 lines · 75 tokens per session scan A 5e61645a12a0
executing-plans is a skill published in the GitHub repository CarbeneAI/Forge (9 stars, last pushed 1mo ago), licensed MIT. It adds 75 tokens to every session and 3,438 once invoked, about $0.0004 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-31.
Other skills, from other repositories
pentesting-everything
Guides authorized penetration testing with PentestingEverything as the source-grounded knowledge base. Use when scoping an engagement, building domain checklists, hunting a vulnerability class, choosing tools/commands, or drafting evidence-based findings from this repository's Markdown.
implementing-devsecops-security-scanning
Integrates Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Software Composition Analysis (SCA) into CI/CD pipelines using open-source tools. Covers Semgrep for SAST, Trivy for SCA and container scanning, OWASP ZAP for DAST, and Gitleaks for secrets detection. Activates for…
hunt-ato
Hunt account takeover taxonomy — 9 distinct paths to ATO, plus chains. Paths: (1) password reset flaws (host-header injection redirects token, predictable/numeric token, Referer leak, no-expiry/reuse), (2) email change without re-auth, (3) OAuth account-link CSRF, (4) MFA bypass (per hunt-mfa-bypass), (5) session…
aod-orchestrate
Multi-feature orchestration skill that bridges /aod.blueprint output to parallel wave execution. Groups synced GitHub Issues by ICE priority tier (P0/P1/P2) into sequential waves, creates Task records, spawns batch sessions via the orchestrator API, monitors completion, and reports results. Supports --issues…
security
Claude-powered SAST and SCA security scan skill. Invoked automatically as the Security Scan step (Step 7) of /aod.build (after Design Quality Gate, before Code Simplification) or standalone via /security. Analyzes all code files and dependency manifests changed on the feature branch relative to main for OWASP Top 10…
aod-foundation
Guided post-init workshop that helps new AOD Kit adopters establish product vision and design identity. Two-part flow: Part 1 (Vision) asks 5 guided questions to populate product-vision.md; Part 2 (Design) browses archetypes to generate brand files (brand.md, tokens.css, anti-patterns.md). Supports --vision and…