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 skills add avelikiy/great_cto --skill pm-planninggit clone --depth 1 https://github.com/avelikiy/great_ctoWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/avelikiy/great_cto/pm-planning)<a href="https://agentmods.dev/skills/avelikiy/great_cto/pm-planning"><img src="https://agentmods.dev/badge/skills/avelikiy/great_cto/pm-planning/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/avelikiy/great_cto/pm-planning"><img src="https://agentmods.dev/badge/skills/avelikiy/great_cto/pm-planning.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What 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.1 | $0.00057 | $0.01332 |
| Opus 5 | $0.00028 | $0.00666 |
| Sonnet 5 | $0.00011 | $0.00266 |
| Haiku 4.5 | $0.00006 | $0.00133 |
Grade A, and why
pm-planning 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 9d 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 — 176 lines — stays where its author put it; the contents beside it link to each section on GitHub.
PM planning — decompose ARCH into tasks
The pm agent's job is to take the architect's ARCH document and produce 2 things:
- A
PLAN-<feature>.mdfor humans - A sequence of
bd createtasks for senior-dev to claim
The plan is good if a fresh senior-dev (no prior context) can pick up the bd tasks and ship without coming back for clarification.
The decomposition rules
Rule 1. Tasks ≤ 4 hours
Anything bigger gets split. If the task is "build the auth system", split into:
- Schema migration for user table
- Signup endpoint with hashing
- Login endpoint with JWT issuance
- Logout / token revocation
- Tests
Each ≤ 4h. If you can't split, the task is unclear — go back to ARCH and clarify.
Rule 2. Single output artefact per task
Each task produces ONE of:
- A code file (new or modified)
- A database migration
- A test file
- A documentation update
- A config change
If a task produces multiple unrelated artefacts, split it.
Rule 3. Explicit dependencies via --blocks
When task B requires task A's output:
bd create "Task A: schema migration" -p P1
# returns id: my-proj-001-abc
bd create "Task B: signup endpoint" -p P1 \
--blocks-on my-proj-001-abc \
--label senior-dev
The pipeline orchestrator reads bd ready --assignee senior-dev to know
what's claimable. Tasks blocked on incomplete predecessors don't appear.
Rule 4. Acceptance criteria — what does "done" mean?
Every task description ends with a bulleted "Done when:" section.
## Done when:
- [ ] POST /signup returns 201 with user_id on success
- [ ] Bad email returns 400 with "invalid_email"
- [ ] Duplicate email returns 409 with "email_taken"
- [ ] Password is hashed with argon2 (no plaintext in DB)
- [ ] Unit test in `tests/<area>/<feature>.test.ts` covers all 4 cases
- [ ] `npm test` passes
Senior-dev knows EXACTLY what to ship and when to stop.
Rule 5. Owners and parallelism
If 3 tasks can run in parallel, mark each with the agent it goes to. Don't bundle them.
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.
- 9d ago First seen · 176 lines · 57 tokens per session scan A 54449a23e42f
pm-planning is a skill published in the GitHub repository avelikiy/great_cto (93 stars, last pushed yesterday), licensed MIT. It adds 57 tokens to every session and 1,332 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-09-03.
Other skills, from other repositories
pm
Project manager for GitHub issues: brainstorm design approaches, create structured issues optimized for LLM agent teams, triage and recommend what to work on next, audit and clean up stale issues, or deep-validate a single issue against the codebase. Triggers: create issue, plan work, new task, project manager, write…
tpp-orchestrate
Work through a queue of Technical Project Plans serially — delegate each to a TDD subagent, get a cross-model second opinion, empirically vet every finding, and make one coherent commit per plan. Use when executing a documented plan queue such as todo/ or feat-name/ for a port, migration, or multi-stage feature.
tpp
Work on a Technical Project Plan — read the plan, identify the current phase, do that phase's work, and update the plan with discoveries. Use when starting or resuming multi-session work tracked in a plan file.
handoff
Update the active Technical Project Plan for handoff when context is running low or the session is ending, so the next session continues instead of restarting.
terry
Invoke when orchestrating a FLEET of parallel long-running agent tasks via a priority-queue manager over git worktrees, OR when you want a producer-consumer task queue for agents that caps concurrency to avoid OOM and pace token spend on a budget — agent queue + task list + dispatched agents + a self-pacing heartbeat…
spec-drift
Standalone plan-vs-code audit on any branch: runs /ship Step 8's plan-completion section from disk (hash-pinned) against an explicit plan and base. Report, JSON, exit code. Never edits code.