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/spytensor/openmozi/pipelinenpx skills add spytensor/openmozi --skill pipelinegit clone --depth 1 https://github.com/spytensor/openmoziWhat 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.00045 | $0.00545 |
| Opus 5 | $0.00023 | $0.00272 |
| Sonnet 5 | $0.00009 | $0.00109 |
| Haiku 4.5 | $0.00005 | $0.00055 |
Grade A, and why
pipeline 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.
What it actually says
Development Pipeline
Automate the full development lifecycle for a feature or fix described by $ARGUMENTS.
Workflow
Execute these steps in order. Stop and report if any step fails.
Step 1: Create GitHub Issue
gh issue create --title "<concise title from $ARGUMENTS>" --body "<detailed description>"
Parse the returned URL to extract the issue number. Print it.
Step 2: Plan
- Research the codebase to understand what files need changing
- Design the implementation approach
- Identify all files to modify/create
- Write the plan to a file at
.claude/plans/<issue-number>.md
Step 3: Build Agent Team & Implement
- Use
TeamCreateto create a team named after the issue - Break the plan into independent tasks using
TaskCreate - Spawn agents in parallel using the
Tasktool withteam_nameparameter:- Each agent handles one task (one file or one concern)
- Use
subagent_type: "general-purpose"withmode: "bypassPermissions" - Run agents in background when possible
- Wait for all agents to complete by checking
TaskList
Step 4: Review
- Read the modified files to verify changes are correct
- Check for obvious issues, missing imports, type errors
Step 5: Verify
Run build and tests:
pnpm build
pnpm test
If build or tests fail:
- Read the error output
- Fix the issues directly
- Re-run verification
- Repeat until passing
Step 6: Commit & Push
git add <changed files>
git commit -m "feat: <description> (#<issue-number>)
Co-authored-by: Mozi <[email protected]>"
git push origin main
Step 7: Close Issue
gh issue close <issue-number> --comment "Implemented in <commit-hash>."
Step 8: Cleanup
- Shut down all team agents via
SendMessagewithtype: "shutdown_request" - Delete the team via
TeamDelete - Report final summary: issue number, commit hash, files changed, test results
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 · 80 lines · 45 tokens per session scan A c3fffe4f35bf
pipeline is a skill published in the GitHub repository spytensor/openmozi (210 stars, last pushed 26d ago), licensed MIT. It adds 45 tokens to every session and 545 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
lobu-operator
Contribute safely to the Lobu monorepo: worktrees, package rules, red-to-green fixes, validation gates, SDK-first operations, PRs, and rollout checks.
company-agent-infrastructure
Use when designing or building internal/company AI agents that need shared context across company systems, durable organizational memory across sessions or agents, user-scoped permissions, approvals, audit, or governed actions. Also use when deciding whether ordinary MCP tools, RAG, or local agent memory are enough…
lobu-builder
Use when working inside a Lobu project generated by @lobu/cli or any repository centered on lobu.config.ts, AGENTS.md, agent prompt files, local skills, and evals. This skill helps a coding agent inspect the right files, make Lobu-native changes, keep the stack runnable, and validate semantics with chat tests and…
crm-ops
How to operate the Lobu funnel CRM — create and enrich leads, log interactions, advance funnel stages, open and update pilots, and produce the weekly digest. Use whenever the task touches the pipeline.
deliveroo-order
Turn collected lunch orders into a clean per-person order list for a human to place on Deliveroo. Use in step 2 of the lunch run, after orders are collected. The live menu is fetched automatically by the lobu-team-lunch-finalize reaction (via the Owletto Chrome extension) — this skill never places an order or touches…
lobu
Use Lobu MCP for shared, permission-aware company context, durable organizational memory, and governed actions. Trigger when the user asks what the organization knows, needs context from connected company systems, wants to preserve a durable fact or decision, or needs to discover and use Lobu SDK capabilities.