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/bex-co/bex/pmnpx skills add bex-co/bex --skill pmgit clone --depth 1 https://github.com/bex-co/bexWhat 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.00048 | $0.02572 |
| Opus 5 | $0.00024 | $0.01286 |
| Sonnet 5 | $0.00010 | $0.00514 |
| Haiku 4.5 | $0.00005 | $0.00257 |
Grade A, and why
pm 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 3d 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- pm — 94% identical, 33 lines differ
How it starts
The opening of the file, as written. The whole thing — 173 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Task: Arrange the .pm board
/pm is the only skill that writes to .pm/. It arranges milestones and tasks under the conventions below. /pm-brainstorm proposes; /pm materializes. This file is the canonical definition of the board conventions — hierarchy, sizing rule, quality gate, standing closing tasks, templates. /pm-brainstorm reads it at runtime and must not restate or diverge from it. Parse the subcommand from $ARGUMENTS (default = status).
The .pm hierarchy
| Level | Path | Meaning | Effort |
|---|---|---|---|
| Workstream | wN/ (w1, w2, w3, …) |
a general-purpose worker queue; README.md + inbox notes |
— |
| Inbox note | wN/NNN.md (w1/005.md) |
one idea or a sub-hour unit of work, plain markdown | ≤ ~1h |
| Milestone | wN/mN/ (m1, m2, …) |
a shippable chunk: README.md + task files |
> ~1h, multiple tasks |
| Task | wN/mN/tNNN.md |
a single unit | tens of minutes |
Rules (enforce every time)
- Respect the anti-goals. Read
.pm/DO_NOT_DO.mdbefore proposing or materializing work. Do not create milestones/tasks that conflict with it. - Workers are general-purpose. Every
wNmay take work anywhere in the bex project. Workstream placement records scheduling and history, not a permanent mission, specialty, component boundary, or ownership claim. Do not assign themes or missions to workstreams, and do not use prior milestones to reject otherwise appropriate work. - Sizing rule. A milestone must be > ~1 hour of work across more than one task. If a chunk is ≤ ~1h (tens of minutes, a task or two), do NOT create an
mN/directory — record it as a loose inbox notewN/NNN.md. Tasks take tens of minutes; milestones take hours. - IDs must match the path. A task's
id: wN/mN/tNNNfrontmatter must equal the directory it lives in. Never create a milestone dir whose path disagrees with the IDs inside it (the existingw2/m1-holds-w1/m1-IDs drift is the anti-example — if you touch it, flag/repair, don't copy it). - Keep status in sync across all three places it lives: the workstream
README.mdmilestone checkbox, the milestoneREADME.md**Status:**line + the— DONEmarker in the task table, and each task'sstatus:frontmatter. - Numbering: next free zero-padded 3-digit for inbox notes (
NNN) and tasks (tNNN); next freewN/mN. Scan the tree first; don't reuse a number. - Use
worker: worker1unless the workstream README names another worker. - Milestones must be meaningful. Every milestone must include direct project-goal linkage, an observable expected outcome, and why this work matters now (dependency/risk/sequence rationale).
- Every board item briefly explains why. Milestones carry it in the milestone
README.md(## Source + Goal linkage). Single tasks — inbox noteswN/NNN.md— carry it in the note itself: a one-lineWhy: …directly under the title (a sentence on the motivation/payoff is enough). - Every milestone ends with standing closing tasks, appended after the implementation tasks whenever a milestone is materialized:
What ships with it
1 file 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.
- 3d ago First seen · 173 lines · 48 tokens per session scan A 7a45074a11fb
pm is a skill published in the GitHub repository bex-co/bex (420 stars, last pushed 3d ago), licensed Apache-2.0. It adds 48 tokens to every session and 2,572 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
mariadb-operator-pr-review
Perform a structured maintainer-style PR review for the mariadb-operator repository. Gathers PR context, triages the change, and evaluates correctness, safety, pitfalls, backwards compatibility and code quality against the project conventions documented in AGENTS.md. Use whenever the user mentions a mariadb-operator…
mariadb-operator-comment
Post a comment (or a formal PR review) to a GitHub issue or pull request in mariadb-operator/mariadb-operator. Use whenever the user wants to publish something to GitHub for this repo — "comment on issue #123", "post this as a PR comment", "leave a note on #456", "reply on the PR" — and especially when they want the…
domain-docs
Generate, update, and audit per-domain docs (docs/domains/) from kubernetes manifests. Use when creating a domain doc set, refreshing docs after cluster changes, or checking for doc drift. Modes: create , update , audit.
k8s-deploy
Deploy and manage applications on Kubernetes clusters with kubectl and Helm.
argocd-expert
Expert-level ArgoCD GitOps deployment, application management, sync strategies, and production operations.
argocd-expert
Expert-level ArgoCD GitOps deployment, application management, sync strategies, and production operations.