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.
git clone --depth 1 https://github.com/FerroxLabs/ijfwWrote 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/commands/ferroxlabs/ijfw/team)<a href="https://agentmods.dev/commands/ferroxlabs/ijfw/team"><img src="https://agentmods.dev/badge/commands/ferroxlabs/ijfw/team/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/commands/ferroxlabs/ijfw/team"><img src="https://agentmods.dev/badge/commands/ferroxlabs/ijfw/team.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00023 | $0.00211 |
| Opus 5.5 | $0.00009 | $0.00084 |
| Sonnet 5.5 | $0.00005 | $0.00042 |
| Haiku 4.5 | $0.00002 | $0.00021 |
Grade A, and why
team 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 1mo 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
Manage project-specific agents in .ijfw/agents/.
/team (no args) -- List current team and their roles. Example output:
Team -- my-project
backend-lead Owns API routes and DB layer
frontend-lead Owns UI components and state
qa-analyst Owns test coverage and edge cases
/team setup -- Generate a team based on the project brief (or ask what you're building). /team add -- Add a specialist to the team. Describe what you need. /team remove -- Remove an agent from the team. /team swap -- Replace one agent with another.
Team agents are used automatically during workflow execution. Tasks are dispatched to the agent whose specialty matches. Parallel execution where tasks are independent.
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.
- 1mo ago First seen · 25 lines · 23 tokens per session scan A 0ee1f43708dd
team is a command published in the GitHub repository FerroxLabs/ijfw (214 stars, last pushed 2d ago), licensed MIT. It adds 23 tokens to every session and 211 once invoked, about $0.0001 per session on Opus 5.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-05.
Other commands, from other repositories
taskstoissues
A command that turns structured tasks from project design documents into ordered GitHub Issues, written in simplified Chinese.
implementation-plan
Define an incremental plan for the active task as IMPLEMENTATIONPLAN.md plus a TASKSTATE.md update: smallest safe slices with scope, validation and exit criteria. No code is written. A --spec mode derives slices from a spec or PRD. A retrofit mode annotates in-progress plans so they can adopt implement-fleet. Do not…
slice-closure
Decide whether the current slice is ready to close, separating slice completion from task completion, and record the result in slice notes and TASKSTATE.md. Use when a slice was implemented, validated or reviewed and may be ready to close. Do not use before slice implementation, during planning, or for overall task…
task-close
Close a whole finished task: verify the spec done-conditions, set TASKSTATE.md to its final closed state, and move the folder from active/ to archive/. Use when all slices are closed, the work is merged or explicitly waived, and the task is ending. Do not use for one slice (use slice-closure), unfinished work…
autonomous-run
Run one approved task in one supervised session with the direct-use reference dispatcher, delegating verifiable slices to existing commands and emitting PROPOSED diffs only and never creating commits or attestation refs. Use when a maintainer invokes Fhorja directly after approve-plan and a BOOT verdict from…
pr-feedback-ingest
Turn PR feedback (Greptile, CI, bots, humans) into a traceable backlog, so the next step is a narrow implement-approved-slice. Corrective scope only. Use when a PR has review feedback to map to files and slices. Do not use for a new direction or contract (use post-review-pivot), no payload, or task-memory drift only…