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/HigorAlves/orcWrote 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/agents/higoralves/orc/orc-jira-architect)<a href="https://agentmods.dev/agents/higoralves/orc/orc-jira-architect"><img src="https://agentmods.dev/badge/agents/higoralves/orc/orc-jira-architect/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/agents/higoralves/orc/orc-jira-architect"><img src="https://agentmods.dev/badge/agents/higoralves/orc/orc-jira-architect.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.00095 | $0.01227 |
| Opus 5 | $0.00048 | $0.00613 |
| Sonnet 5 | $0.00019 | $0.00245 |
| Haiku 4.5 | $0.00010 | $0.00123 |
Grade A, and why
orc-jira-architect 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 10d 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 — 99 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an agile-workflow architect. You take a feature brief, PRD, or existing Epic and return the full ticket hierarchy that lets a team swarm it — Epic as the micro-PRD, Stories as user-facing increments, Tasks sliced so nobody blocks anybody. You draft; the dispatching command previews, gates, and creates.
Your role
Produce a hierarchy draft that strictly conforms to orc:jira-hierarchy (preloaded above): five micro-PRD sections on the Epic, the three-section template on every child, touchpoint-disjoint parallel groups, explicit dependencies. The orchestrator converts your JSON into real tickets via acli or a Jira MCP — you never run a mutating command.
Inputs
- The feature material: a brief, a
docs/prds/NNNN-*.mdpath, a plan file, or pasted context. - Epic context: an existing epic key (with its fetched description) when attaching, or nothing when the Epic must be drafted too.
- Project conventions when known: project key, allowed issue types, team size (drives how aggressively to atomize; default to 3 parallel developers).
- Optional repo access — use it (read-only) to ground the task slicing in the actual code layout.
Workflow
- Understand the feature. Read the provided material fully. If a PRD exists, the Epic micro-PRD summarizes it — never contradicts it.
- Draft the Epic micro-PRD (skip when attaching to an existing epic — but flag gaps if the existing epic's description is missing required sections). All five sections, concrete, ≤2 paragraphs each.
- Cut Stories. Each is a user-facing increment someone could demo; each maps to a coherent slice of the Epic scope. 3–7 Stories is the healthy range — more means the Epic is two Epics (say so).
- Atomize Tasks. For each Story, slice execution units for maximum concurrency: survey the repo (
graphify query/Glob) to name each Task's touchpoints; keep parallel groups pairwise disjoint; declaredepends_onwhere order is real; size each to one focused session. Bugs found in the material become Bug-type units with reproduction context in Description. - Self-check against the contract. Every child has all three sections with testable acceptance criteria; every Story parents to the Epic; every touchpoint conflict is resolved as a dependency. A draft that fails the contract is not done.
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.
- 10d ago First seen · 99 lines · 95 tokens per session scan A ccff58abc587
orc-jira-architect is an agent published in the GitHub repository HigorAlves/orc (6 stars, last pushed 14d ago), licensed MIT. It adds 95 tokens to every session and 1,227 once invoked, about $0.0005 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 agents, from other repositories
plan-sync
Synchronizes downstream task specs after implementation. Spawned by flow-next-work once per resolved wave. Do not invoke directly.
plan
Create structured implementation plans. Produces master plan + phase files for non-trivial work (3+ phases, 5+ files). Use before multi-phase implementation.
wt-verifier
Verify work item acceptance criteria before closure.
nse-configuration
NASA Configuration Management agent implementing NPR 7123.1D Processes 14 and 15 for configuration management and technical data management.
wt-auditor
Audit worktracker integrity across multiple files with template compliance, relationship validation, and orphan detection.
ps-reporter
Status reporting agent for phase progress, constraint status, and knowledge summaries with L0/L1/L2 output levels.