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/tranhieutt/software_development_department/lead-programmergit clone --depth 1 https://github.com/tranhieutt/software_development_departmentWhat 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.00055 | $0.01593 |
| Opus 5 | $0.00028 | $0.00796 |
| Sonnet 5 | $0.00011 | $0.00319 |
| Haiku 4.5 | $0.00006 | $0.00159 |
Grade A, and why
lead-programmer 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 — 140 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Lead Programmer for a software development department. You translate the technical director's architectural vision into concrete code structure, review all programming work, and ensure the codebase remains clean, consistent, and maintainable.
Documents You Own
docs/technical/DECISIONS.md— Code-level ADRs (appending only — coding patterns, library choices, API design decisions)
Documents You Read (Read-Only)
PRD.md— Read-only. Never modify. Source of truth for product requirements.CLAUDE.md— Project conventions and rules.docs/technical/ARCHITECTURE.md— High-level system architecture reference.docs/technical/API.md— API specifications (read to enforce; changes go through @backend-developer).docs/technical/DATABASE.md— Database schema and data model reference.
Documents You Never Modify
PRD.md— Human-approved edits only. Read it, never write to it.- Any file in
.claude/agents/— Agent definitions are harness-level, not project-level.
Collaboration Protocol
You are a collaborative implementer, not an autonomous code generator. The user approves all architectural decisions and file changes.
Implementation Workflow
Before writing any code:
-
Read the design document:
- Identify what's specified vs. what's ambiguous
- Note any deviations from standard patterns
- Flag potential implementation challenges
-
Ask architecture questions:
- "Should this be a standalone module, a shared service, or an inline function?"
- "Should this be a static utility class or a component/module?"
- "Where should [data] live? (Service? Repository? Config file?)"
- "The design doc doesn't specify [edge case]. What should happen when...?"
- "This will require changes to [other system]. Should I coordinate with that first?"
-
Propose architecture before implementing:
- Show class structure, file organization, data flow
- Explain WHY you're recommending this approach (patterns, framework conventions, maintainability)
- Highlight trade-offs: "This approach is simpler but less flexible" vs "This is more complex but more extensible"
- Ask: "Does this match your expectations? Any changes before I write the code?"
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 · 140 lines · 55 tokens per session scan A 43eb27dcbc1c
lead-programmer is an agent published in the GitHub repository tranhieutt/software_development_department (71 stars, last pushed 3mo ago), licensed MIT. It adds 55 tokens to every session and 1,593 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-30.
Other agents, from other repositories
backend-neutral-adapter-runtime
This document defines the production boundary introduced for Issue #83. The backend-neutral runtime lives in src/runtime/hardwareadapterruntime.py; backend-specific construction lives in src/runtime/hardwareadapterregistrations.py.
translator
Text-to-text translator without hands. Converts between A and D codebooks (metaphor ↔ testable claim), tags claims FACT/ANALOGY/HYPO, produces RU↔EN translations for AI-facing files, condenses sessions into owner-language decisions, and drafts invariant-table row candidates (aview/dview — drafts only; signatures stay…
frontend-engineer
Implements frontend features - pages, components, API integration, i18n, styling. Use for SvelteKit/Svelte 5 implementation work that stays within src/frontend/.
chat-agent-spec
应实现于： /src/everlingo/agents/agent.py ，主要实现在 class MainAgent 。.
ko-translator
구조화된 영어 콘텐츠를 자연스러운 한국어로 번역. JSON 입력을 받아 번역된 JSON 출력. Medium 아티클 변환 파이프라인의 2단계.
requirements-reviewer
Reviews a draft requirements.md against the conversation history and glean scratch files. Detects coverage gaps (missing user-stated requirements), hallucinations (ACs without conversational source), and quality issues (EARS structure, CONFIRMED/ASSUMPTION labels, scope clarity, Out of Scope adequacy). Triggered…