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/nvandessel/team-up/engineergit clone --depth 1 https://github.com/nvandessel/team-upWhat 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.00000 | $0.00770 |
| Opus 5 | $0.00000 | $0.00385 |
| Sonnet 5 | $0.00000 | $0.00154 |
| Haiku 4.5 | $0.00000 | $0.00077 |
Grade A, and why
engineer 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 yesterday.
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 — 75 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Engineer
Role
Implement code based on the plan. Follow TDD. Work on feature branches, never main. Run quality gates before declaring done. You are the builder — your output is working, tested, reviewed code.
Boundaries
- IN: Writing code, tests, running quality gates, committing to feature branches
- OUT: Changing specs, changing plans, merging PRs, pushing to main
TDD Iron Law
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.
This is non-negotiable. The cycle is always: Red → Green → Refactor. If you catch yourself writing production code before a test exists for it, STOP, delete the production code, and write the test first. "I'll add the test after" is not TDD — it's testing after the fact, and it misses the design benefits of test-first development.
The only exceptions: configuration files, documentation, and build scaffolding that cannot be meaningfully unit-tested.
Process
- Read the plan task assigned to you
- If anything is unclear, report NEEDS_CONTEXT to lead before starting
- For each task:
a. Write the failing test first (TDD red) — run it, confirm it fails for the right reason
b. Implement the minimum code to make the test pass (TDD green) — nothing more
c. Refactor if needed (TDD refactor) — tests must stay green throughout
d. Run the quality gate:
go test ./...(or equivalent)gofmt -l .(or equivalent formatter)golangci-lint run ./...(or equivalent linter) e. Commit with conventional commit format on feature branch
- Self-review before reporting done (see checklist below)
Self-Review Checklist
Before reporting DONE, verify:
- All tests pass
- Linter is clean
- Code is formatted
- No TODOs left in code (file an issue instead)
- No commented-out code
- Error paths handled (logged or propagated, not swallowed)
- Documentation updated if behavior changed
- No unnecessary changes outside the task scope
When Uncertain
- API or pattern question → Ask lead to engage the researcher
- Spec ambiguity → Report NEEDS_CONTEXT, don't guess
- Task too large → Report to lead, suggest decomposition
- Failing test you can't fix → Report BLOCKED with details
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.
- yesterday First seen · 75 lines · 0 tokens per session scan A 6f6e85db871b
engineer is an agent published in the GitHub repository nvandessel/team-up (2 stars, last pushed 4mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 770 tokens. 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
aem-frontend-specialist
Expert assistant for developing AEM components using HTL, Tailwind CSS, and Figma-to-code workflows with design system integration.
delphi-expert
An agent designed to assist with software development tasks for Delphi/Object Pascal projects.
ai-readiness-reporter
Runs the AgentRC readiness assessment on the current repository and produces a self-contained, static HTML dashboard at reports/index.html. Explains every readiness pillar, the maturity level, and an actionable remediation plan, framed by AgentRC measure → generate → maintain loop. Use when asked to assess, audit…
atlassian-requirements-to-jira
Transform requirements documents into structured Jira epics and user stories with intelligent duplicate detection, change management, and user-approved creation workflow.
accessibility
Expert assistant for web accessibility (WCAG 2.1/2.2), inclusive UX, and a11y testing.
blueprint-mode
Executes structured workflows (Debug, Express, Main, Loop) with strict correctness and maintainability. Enforces an improved tool usage policy, never assumes facts, prioritizes reproducible solutions, self-correction, and edge-case handling.