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/langerrr/zforge/feature-orchestratenpx skills add Langerrr/zforge --skill feature-orchestrategit clone --depth 1 https://github.com/Langerrr/zforgeWrote 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/skills/langerrr/zforge/feature-orchestrate)<a href="https://agentmods.dev/skills/langerrr/zforge/feature-orchestrate"><img src="https://agentmods.dev/badge/skills/langerrr/zforge/feature-orchestrate.svg" alt="Measured on agentmods" 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 | $0.00023 | $0.01735 |
| Opus 5 | $0.00012 | $0.00868 |
| Sonnet 5 | $0.00005 | $0.00347 |
| Haiku 4.5 | $0.00002 | $0.00173 |
Grade A, and why
feature-orchestrate 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 4d 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 — 70 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Autonomous Feature Execution
Run a feature plan to completion without blocking on the user. Phases execute as background subagents; decisions are recorded for asynchronous review; the planner accepts each phase by re-running its evidence.
Load $zforge:feature-execution. It owns phase state, the spawn contract, recovery, scheduling, and acceptance. This skill supplies the autonomous intent only.
Arguments
$1: Feature name (snake_case, or will be converted)
Pre-flight
- Convert the feature name to snake_case and resolve
docs/{feature_name}/. If the directory is missing, report it and suggest$zforge:plan. - Read
05_progress_overview.md,01_context.md,02_plan.md, and the Doc Map in01_context.mdfor anything else binding. - Read
decision_review.md. If it does not exist, create it from../../../templates/decision_review.md, resolved relative to thisSKILL.md. - Read
session_log.md, creating it from../../../templates/session_log.md, resolved relative to thisSKILL.md, if absent, and append a row for this session. - Note any open standing flags in the overview. A flag opened by an earlier session is inherited by this one.
- Read
07_harness_conventions.mdif the feature has one. It says how this project is run and observed, and it is what keeps the run from re-learning a fact an earlier phase already paid for.
Codex goal bridge
When Codex exposes goal tools, make an existing /goal the outer run contract without copying its state into zforge's files:
- After the document pre-flight, call
get_goal. Record whether this run adopted the active goal and retain the identity and objective fields the tool returns for later comparisons. If no goal is active on this initial check, continue normally and do not create one — invoking this skill is not permission to start or replace a goal. - When the run adopted a goal, treat its objective as the outer stopping condition and zforge's feature state as the implementation truth. Re-check the same active goal at each classification boundary before acceptance or delegation, and again immediately before spawning a worker. Apply the goal-budget overlay in
$zforge:feature-execution. - Once a run has adopted a goal, a later check that finds it paused, cleared or replaced schedules no new phase. Preserve any report already delivered using the normal REPORTED checkpoint before yielding. Only a run that never adopted a goal uses normal no-goal scheduling.
- Low remaining budget is a scheduling signal, never evidence that the feature is complete or blocked.
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.
- 4d ago First seen · 70 lines · 23 tokens per session scan A a0266e681643
feature-orchestrate is a skill published in the GitHub repository Langerrr/zforge (10 stars, last pushed 3d ago), licensed MIT. It adds 23 tokens to every session and 1,735 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 skills, from other repositories
loop-setup
Session 0. Sets up the loop in this project - detects the stack, checks which connections actually work (git, database, browser, payments sandbox), asks the few decisions only the owner can make, and writes the .loop/ files. Run this once per project, before any planning or building.
loop-plan
The planning session. Turns a goal into an ordered list of thin complete slices, decides which role and model runs each following session, and writes it all to the plan file. Use at the start of an epic, before any code.
plan-change
Turns .workflow/ /triage.json and the code into an audited implementation spec at .workflow/ /sdd.json. Use before writing code for a ticket, bug fix or feature.
draft-pr
Writes a PR title and description to .workflow/ /pr.md from the branch's commits, the plan and the recorded verification. Use when opening a PR or asked for a PR description.
frame-product
Turns a feature idea into a product decision - who, which metric, what cost, smallest sellable slice - at .workflow/idea- /frame.md. Use when a feature is proposed with no ticket or agreed scope.
implement-change
Executes an audited plan from .workflow/ /sdd.json, holding the diff to the files it lists, then verifies it into .workflow/ /evidence.md. Use to carry out a plan, after plan-change.