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 commands/jeet129/praxis/slicegit clone --depth 1 https://github.com/jeet129/praxisWhat 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.00027 | $0.00980 |
| Opus 5 | $0.00014 | $0.00490 |
| Sonnet 5 | $0.00005 | $0.00196 |
| Haiku 4.5 | $0.00003 | $0.00098 |
Grade A, and why
slice 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 — 87 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Run ONE implementation slice end-to-end. You do NOT execute the slice yourself. You do NOT spawn a specialist. You delegate the whole thing to delivery-lead, which orchestrates.
What you do
Ask me which slice (if not obvious from the roadmap in .project/working/). Show me:
- Acceptance criteria
- Estimated size (must be 2-5 days; if larger, decompose first — reject the slice back to
/architector/discoverif it's too big) - Stack(s) involved
- Dependencies on prior slices
Once I confirm, delegate to delivery-lead via the Task tool:
Task({
subagent_type: "praxis:delivery-lead",
prompt: "Run implementation-slice.yaml for slice <slice-id>.
Follow the workflow STRICTLY. Do NOT skip any step.
1. Open the slice. Update .project/working/active-workflow.md.
2. Spawn lead-developer FIRST. Give it the slice spec, AC, and touched
modules. Wait for its output — BOTH artifacts, not just the first:
- the implementation packet at
.project/working/slice-<slice-id>-packet.md (decomposed tasks per
specialist, dependencies, relevant NFRs, test-plan skeleton)
- the task ledger at .project/working/slice-<slice-id>-tasks.yaml
(per references/loop-contracts.md §2: per-task agent, tier, ac,
verify command, depends_on). The ledger is what makes the slice
drive-eligible — without it /drive has nothing to iterate.
3. ONLY AFTER the packet + ledger exist, dispatch specialists.
PREFERRED: lead-developer dispatches them per the ledger's dependency
DAG (two-tier delegation — you route phases, Lead Developer routes
tasks). FALLBACK: only if the harness cannot nest agent spawns, you
dispatch specialists yourself, passing each its portion of the packet.
Run specialists in parallel where the DAG allows.
4. When every specialist has produced a PR, spawn (in parallel):
- code-reviewer for every PR
- ux-designer for visual review when the slice has UI tasks
(screenshots vs design plan + tokens, per frontend-design)
- security-reviewer if the slice is security-bearing
(touches auth, data-handling, public surface, deps, or
compliance-bearing code)
- qa-engineer for every PR
5. If any reviewer returns a blocker: fix loop. Same specialist that
owns the file gets the finding; re-review by the blocking reviewer.
Loop until all reviewers pass.
6. Close the slice. Write acceptance verdict and episodic entry.
Update .project/working/active-workflow.md with next-slice pointer
or workflow-complete marker.
NEVER spawn a specialist directly for slice implementation. Lead
Developer builds the packet first. This rule holds even if the slice
looks small or only one specialist appears needed."
})
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 · 87 lines · 27 tokens per session scan A fa52eb935474
slice is a command published in the GitHub repository jeet129/praxis (7 stars, last pushed 5d ago), licensed MIT. It adds 27 tokens to every session and 980 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 commands, from other repositories
git
Git operations with intelligent commit messages and workflow optimization.
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.