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/promptctl/laws/nextnpx skills add promptctl/laws --skill nextgit clone --depth 1 https://github.com/promptctl/lawsWhat 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.00006 | $0.01530 |
| Opus 5 | $0.00003 | $0.00765 |
| Sonnet 5 | $0.00001 | $0.00306 |
| Haiku 4.5 | $0.00001 | $0.00153 |
Grade A, and why
next 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 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.
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 — 85 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Next
Pick up the next ready ticket and start work.
Init
Run lit quickstart if you haven't already. This provides instructions for using the work tracking system.
If the user provided specific information (e.g., a ticket id or area of the codebase to work on), SKIP THE REST OF THESE INSTRUCTIONS and follow the guidance from lit quickstart to follow the user instructions. The following information is for determining which work to pick when the user did not specify.
Finding work
Take a look at the backlog (lit ready) so you understand what work is in-progress or up next. Now you need to decide whether you need to wrap up in-progress work or start new work.
In progress work
If there are uncommitted changes or open PRs in the repo, we want to wrap these up before starting new work.
Uncommitted changes
determine if these changes are related to a backlog item. If so, that is your current ticket. If not, stop and think to your self: Are these changes worthwhile? Accidential? Incidental? Should we commit or discard them? Use your brain to think about the right solution because there is no one size fits all rule.
Examples:
- uncommitted pnpm lockfile update: check it out to discard, but then regengerate the lockfile as part of your commit when you do work
- Uncommitted typo in a random file: check it out to discard, it's not needed
- Minor update to the readme to include some more instructions: commit it and proceed
- Major update to the readme that is related to the work on the current branch: commit it and proceed
- Major update to work that is clearly NOT on this branch: stash it and proceed
- A half finished feature: find the ticket it's related to. THIS TICKET IS YOUR ASSIGNED WORK. Skip the backlog scan and go straight to "Working the ticket". If it's not related to a ticket you see, do a quick code review. does the code look experimental and temporary or high quality? Does it look complete or barely started? Then briefly explain the state of the code, what it does, and any other info you have (no ticket, etc). Ask if they want you to create a ticket and continue the work, if they want it to committed to work as part of a different ticket, or whether they want you to stash or discard it. Follow that instruction.
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 · 85 lines · 6 tokens per session scan A 11966b215e63
next is a skill published in the GitHub repository promptctl/laws (4 stars, last pushed 2d ago), licensed MIT. It adds 6 tokens to every session and 1,530 once invoked, about $0.0000 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
babysit
Same-session monitoring loop for PRs, CI runs, tickets, and deployments using the monitorstart / monitorupdate / autonudgestop MCP tools. The loop re-injects your check instructions into THIS session on an idle interval — same context, same tools — and works from dashboard chat, Slack threads, and Discord DMs. Use…
teamharness-task-delegation
Use when a Leader turns ready Quick Task or Project Work state into Worker task instructions, sends assignment messages, checks submitted results, and defines completion/blocker report contracts. Do not use to create projects, create rooms, or execute Worker tasks.
github-workflow
Use GitHub workflow tools to read work status, draft reports, summarize follow-ups, and execute only approved issue mutations.
flow-next-tracker-sync
Project a flow-next spec to a tracker issue (Linear, GitHub, GitLab, Jira) and reconcile two-way. Use when asked to sync to a tracker. NOT plan-sync.
codex-session-product-reviewer-maintainer
Use when reviewing a local Codex session, task, thread, or commit as a product manager or first-principles reviewer for product correctness, scope, behavior, validation, and whether the task solved the right user problem.
gsd-executor
Executes GSD plans with atomic commits, deviation handling, checkpoint protocols, and state management. Spawned by execute-phase orchestrator or execute-plan command.