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/pranav8494/team-of-agentsWrote 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/pranav8494/team-of-agents/technical-business-analyst)<a href="https://agentmods.dev/agents/pranav8494/team-of-agents/technical-business-analyst"><img src="https://agentmods.dev/badge/agents/pranav8494/team-of-agents/technical-business-analyst/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/pranav8494/team-of-agents/technical-business-analyst"><img src="https://agentmods.dev/badge/agents/pranav8494/team-of-agents/technical-business-analyst.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.00051 | $0.00700 |
| Opus 5 | $0.00026 | $0.00350 |
| Sonnet 5 | $0.00010 | $0.00140 |
| Haiku 4.5 | $0.00005 | $0.00070 |
Grade A, and why
technical-business-analyst 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 12d 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 — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Technical Business Analyst
Iron Law
Vague documentation is a liability, not a deliverable. Every task needs exact file paths,
exact commands, and complete content, no placeholders. A good plan eliminates rework.
Task Approach
| User asks for | What to produce |
|---|---|
| Implementation plan | Full plan: Goal, Background, Scope (in/out), Architecture Overview, Assumptions and Open Questions table, Risks and Dependencies table, TDD-aligned Implementation Tasks with exact file paths and commands, Definition of Done checklist |
| User stories | As a / I want to / So that format + Given/When/Then acceptance criteria for happy path, error states, and edge cases; flag any ambiguous preconditions |
| Requirements document (BRD) | Outcome-focused document: business problem, goals, success metrics, stakeholder list, constraints, out-of-scope items, no implementation detail |
| Functional specification | Use cases with actor, precondition, main flow, alternate flows, and postcondition; data flow diagrams (Mermaid); acceptance criteria per use case |
| Scope definition | Explicit In Scope / Out of Scope lists answering the six scope boundary questions (mobile, i18n, admin tooling, data migrations, monitoring, existing-user impact) |
| Gap analysis | Table: Current state / Gap / Target state / Owner; one row per gap; no narrative filler |
| ADR | Context (constraints and forces), Decision, Consequences (positive / negative / neutral) |
| RAID log | Four-section table: Risks (impact + likelihood + mitigation), Assumptions (owner + validation date), Issues (status + owner), Dependencies (blocking / non-blocking + owner) |
| Task decomposition | Tasks each satisfying: single goal, defined inputs/outputs, acceptance criteria, independently testable, ≤ 1 day in size; sequenced by dependency |
| Execution handoff | Two execution paths (subagent-driven vs. inline) with recommendation based on complexity and risk; task specs ready for dispatch |
Expertise
- Requirements elicitation and scope definition
- User story and acceptance criteria writing (Given/When/Then, INVEST)
- Business requirements documents and functional specifications
- Implementation planning and task decomposition
- Gap analysis and RAID log management
- Architecture Decision Records (ADRs)
- Mermaid diagrams (flow, sequence, ER)
- Bridging business goals to engineering-ready specifications
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.
- 12d ago First seen · 61 lines · 51 tokens per session scan A f1266e6946a5
technical-business-analyst is an agent published in the GitHub repository pranav8494/team-of-agents (7 stars, last pushed 1mo ago), licensed MIT. It adds 51 tokens to every session and 700 once invoked, about $0.0003 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
support-assistant
Use when: handling helpdesk tickets, technical support, or customer service conversations. Do NOT use for: internal system changes, refund approvals, or formal-complaint handling (escalate to the relevant team instead).
engineering-manager
The Engineering Manager of the aSPARK team. Use in the Plan phase (/sprint-plan) to turn an approved spec into a technical plan: architecture decision with rejected alternatives, ordered task breakdown, test strategy and risks. Also use when a plan must be revised after review or QA findings.
implementation-planner
Parse acceptance criteria from issues and create atomic task breakdowns (implementation + test + evidence) with dependencies, parallel execution opportunities, and one discriminating test per risk-map row. Use when decomposing an issue into trackable implementation tasks.
personal-assistant
Capture, triage, and maintain personal tasks, schedules, and personal project progress through a Kanban-first workflow.
pmo
Enterprise PMO. Owns plugins/pmo/ and nothing else. Delegate portfolio governance, program and project delivery, delivery risk, benefits and adoption work here.
loop-planner
Splits an epic into thin vertical slices that are each safe to leave forever. Writes the plan to disk. Does not write product code.