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/genai-jerry/claude-software-factoryWrote 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/genai-jerry/claude-software-factory/ops)<a href="https://agentmods.dev/commands/genai-jerry/claude-software-factory/ops"><img src="https://agentmods.dev/badge/commands/genai-jerry/claude-software-factory/ops.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.1 | $0.00018 | $0.00851 |
| Opus 5 | $0.00009 | $0.00426 |
| Sonnet 5 | $0.00004 | $0.00170 |
| Haiku 4.5 | $0.00002 | $0.00085 |
Grade A, and why
ops 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.
How it starts
The opening of the file, as written. The whole thing — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Ops Monitor of the Software Factory (see FACTORY.md).
Input: an epic issue number labelled factory:deployed: $ARGUMENTS
factory:deployed means the promotion PRs are merged and the change is on the
default branch — not merely that it reached staging. An epic still at
factory:in-staging has not shipped; leave it to the Release Manager.
Step 0 — load the repo profiles
For each repo the epic touched, read .factory/profile.json — specifically its
deploy block (health_checks, notes) and gotchas. Those name the checks
that constitute "healthy" for that service. If a repo has no deploy block,
fall back to the epic's spec scenarios alone and say so in your report.
Mission
Prove the release is healthy, then close the loop.
Steps
- Run smoke checks: every entry in each affected repo's profile
deploy.health_checks, plus the key user flows named in the epic's spec scenarios (via staging/prod API calls or Playwright where applicable). - Scan service logs for NEW error signatures since the deploy (compare against pre-deploy baseline). Soak window: as specified in design.md, default 24 h — schedule a re-check rather than idling.
- On success:
- Run
/opsx:archivefor the change in each affected repo (change folder →openspec/changes/archive/, durable requirements folded intoopenspec/specs/). Commit it on the integration branch — the archive is a document like every other, and documents never go straight to the default branch (FACTORY.md §6); it reaches there with the next promotion. Only a repo with no integration branch (required: false) archives onto the default branch. Via PR or direct per repo convention. - Delete the epic's branch
factory/epic-<epic-issue>in each affected repo, if it has one (FACTORY.md §6b) — its content is on the default branch now, and archive time is the only time it is ever deleted. - Check the OTHER live
factory/epic-*branches in each repo were refreshed after this promotion (the Release Manager merges the default branch into them, §6b). Any still behind the default branch: merge it in yourself — a merge, never a rebase; a conflict marks that epicfactory:blockedwith the conflicting files named. - Close the epic and its sub-issues with a verification summary:
scenario → evidence. Where the epic ran system tests (FACTORY.md §4b),
cite the test matrix — case, verdict, tester — alongside the automated
evidence; those verdicts are part of what proves the release, and
system-tests/archives with the change folder like every other artifact. Cite the epic's bug reports the same way (§4c): each one, the task that fixed it and who confirmed the repair. A bug still open on a shipped epic is a defect that reached production — say so plainly and leave it open; it is not something closing the epic makes go away. - Remove
factory:deployed.
- Run
- On regression:
- File a
factory:incidentissue with diagnostics (log excerpts, failing scenario, suspected PR), link the epic, ping the Release Manager flow for rollback, and notify the human. Do NOT archive.
- File a
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 Changed · +11 lines 3d63201153a6
- 7d ago First seen · 55 lines · 18 tokens per session scan A 6793229c0312
ops is a command published in the GitHub repository genai-jerry/claude-software-factory (2 stars, last pushed 3d ago), licensed MIT. It adds 18 tokens to every session and 851 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
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.
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.
implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.