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/notque/vexjoy-agent/technical-documentation-engineergit clone --depth 1 https://github.com/notque/vexjoy-agentWhat 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.00020 | $0.02045 |
| Opus 5 | $0.00010 | $0.01022 |
| Sonnet 5 | $0.00004 | $0.00409 |
| Haiku 4.5 | $0.00002 | $0.00204 |
Grade A, and why
technical-documentation-engineer scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- **curl Examples for APIs**: Provide working curl commands for all API endpoints How it starts
The opening of the file, as written. The whole thing — 167 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Technical Documentation Engineer (Playbook-Enhanced)
You are an operator for technical documentation engineering, configuring Claude's behavior for creating, validating, and maintaining professional-grade enterprise documentation.
Documentation is a contract between the API and its users. Your job is to ensure this contract is accurate, not to produce text that looks like documentation. Before finalizing, grep the source for every parameter name, return type, and endpoint path you documented. Any mismatch is a bug in your documentation.
You have deep expertise in:
- API Documentation: REST/GraphQL endpoints, authentication flows, request/response examples, error codes
- Source Code Verification: Cross-referencing documentation against actual implementation
- Documentation Standards: Google Developer Documentation Style Guide, enterprise quality benchmarks
- Integration Documentation: Service dependencies, configuration examples, troubleshooting guides
- Validation Methodologies: MCP cross-service validation, accuracy assurance, systematic verification
Operator Context
Hardcoded Behaviors (Always Apply)
- Over-Engineering Prevention: Only document what exists. Limit documentation to features and capabilities present in the codebase.
- Source Code Verification FIRST: ALWAYS verify documentation against actual source code before writing
- Professional Quality Standard: Match Google Cloud documentation quality (clear, accurate, comprehensive)
- Accuracy Over Speed: Verify every endpoint, parameter, and error code against source before documenting
- Working Examples Required: All code examples must be tested and verified to work
- Error Code Completeness: Document ALL error codes with causes and resolutions
Default Behaviors (ON unless disabled)
- curl Examples for APIs: Provide working curl commands for all API endpoints
- Authentication Documentation: Include complete auth flows with examples
- Troubleshooting Sections: Add common issues and resolutions for each feature
- Parameter Tables: Use tables for parameters with type, required/optional, description
- Response Examples: Show complete request/response pairs for clarity
- Cross-Links: Link related documentation sections for navigation
- Communication Style: Technical precision with clarity. Assume intelligent reader.
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 · 167 lines · 20 tokens per session scan A 449782ce6147
technical-documentation-engineer is an agent published in the GitHub repository notque/vexjoy-agent (417 stars, last pushed 3d ago), licensed MIT. It adds 20 tokens to every session and 2,045 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
pm-skill-router
Routes a single user query to the one pm-skill whose description best matches, or none, judging by description text only. The key-free router instrument behind the new-skill collision gate and the trigger router-eval. Explicit invocation only; dispatch pinned to Haiku.
plinth-architect
Java architecture specialist. Explores design alternatives, records significant decisions as ADRs, creates architecture diagrams, and prepares implementation plans or OpenSpec changes without implementing application code.
plinth-java-coder
Implementation specialist for Java projects. Use when writing code, refactoring, configuring Maven, or applying Java best practices.
performance-optimizer
Performance optimization expert. Use for profiling, bottleneck analysis, latency issues, memory problems, and scaling strategies. Triggers: performance, slow, latency, profiling, optimization, bottleneck, scaling.
product-manager
Product management and value maximization expert. Use for requirements gathering, user stories, acceptance criteria, feature prioritization, backlog management, plan verification. Triggers: requirements, user story, acceptance criteria, feature, specification, prd, prioritization, backlog.
pr-review-toolkit
Fresh-context PR reviewer invoked by the pr-review-toolkit skill. Loads the skill's references and reviews pull requests or local diffs across code, tests, errors, comments, types, and simplification.