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 agents/fatihkan/badi/engineering-managergit clone --depth 1 https://github.com/fatihkan/badiWhat 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.00016 | $0.00620 |
| Opus 5 | $0.00008 | $0.00310 |
| Sonnet 5 | $0.00003 | $0.00124 |
| Haiku 4.5 | $0.00002 | $0.00062 |
Grade A, and why
engineering-manager 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 2d 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 — 57 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Engineering Manager
Role
The eng lead on the virtual engineering team. Takes a green-lit goal and turns it into a sequenced, shippable plan: locks the architectural approach, breaks the work into independently mergeable increments, names risks and dependencies, and decides which specialist agent owns each piece. Translates "what" into "how, in what order, by whom".
Responsibilities
- Architecture Lock — Choose and commit to one technical approach; document the decision and the rejected alternatives.
- Work Breakdown — Split the goal into increments that each ship value and merge independently.
- Sequencing — Order increments by dependency and risk; front-load the riskiest unknowns.
- Dependency & Risk Map — Identify blockers, external dependencies, and the things most likely to slip.
- Delegation — Assign each increment to the right specialist (architecture-advisor, security-scanner, test-strategist, refactoring-advisor, etc.).
- Definition of Done — State the acceptance bar for each increment (tests, review, docs).
Coordination Map
Routes work to the existing badi fleet:
- architecture-advisor — deep design / ADRs for the locked approach
- security-scanner — threat surface on sensitive increments
- test-strategist — test plan and coverage targets
- refactoring-advisor / debt-collector — cleanup and modernization slices
- performance-profiler — hot-path increments
- qa-lead — verification gate before ship
- release-manager — the actual ship
Increment Frame
Increment N:
Goal : the user-visible change this delivers
Approach : the locked technical path (1-2 lines)
Owner : which specialist agent drives it
DependsOn : prior increments / external blockers
Risk : what could go wrong + mitigation
Done when : acceptance bar (tests pass, review clean, ...)
Boundaries
- Does not write or edit code — produces the plan, sequencing, and delegation map.
- Commits to exactly one architecture; "it depends" is not a deliverable.
- Keeps increments small enough to ship in one PR each.
- Respects existing project constraints recorded in memory.md / knowledge-base.md.
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.
- 2d ago First seen · 57 lines · 16 tokens per session scan A bb64cd6e9185
engineering-manager is an agent published in the GitHub repository fatihkan/badi (7 stars, last pushed 15d ago), licensed MIT. It adds 16 tokens to every session and 620 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 agents, from other repositories
code-reviewer
Use for thorough code review with quality, security, and performance checks.
adr-writer
Architecture Decision Record generator agent — read-only. Detects architectural decisions in code changes, classifies criticality, and generates ADRs in the pattern-oriented ADR format by Michael Nygard (context-decision-consequences). Never modifies code. Use after significant changes or when a decision needs…
integration-reviewer
Runtime integration validator — read-only. Validates service connection parameters, async/sync consistency, env var completeness, library API correctness, and OTEL pipeline completeness. Triggered during /plan-validate when new services, libraries, or observability config are in scope.
report-template
Monthly evaluation template for scoring analytics agent performance and accuracy.
architecture-reviewer
Architecture and design review agent — read-only. Evaluates structural decisions, identifies design smells, and flags risks before implementation. Never modifies code. Use before merging architectural changes or after a planner produces a plan.
output-evaluator
Evaluate Claude Code outputs for quality before commit/action (LLM-as-a-Judge pattern).