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/calinfaja/k-lean/templategit clone --depth 1 https://github.com/calinfaja/K-LEANWhat 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.02208 |
| Opus 5 | $0.00000 | $0.01104 |
| Sonnet 5 | $0.00000 | $0.00442 |
| Haiku 4.5 | $0.00000 | $0.00221 |
Grade A, and why
TEMPLATE 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 — 328 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Optimal Agent.md Structure Guide
Research Summary
Based on comprehensive research of Factory.ai documentation, Anthropic's context engineering guide, and industry best practices for autonomous AI agents.
Key Principles for Autonomous Agents
1. Planning-First Architecture (Factory.ai)
"A agent is only as good as its plan."
- Subtask decomposition: Break complex tasks into manageable steps
- Model predictive control: Plan → Execute → Validate → Adjust
- Environmental grounding: Stay connected to actual codebase state
2. Goldilocks Zone (Anthropic)
"The right altitude is between hardcoded brittle logic and vague high-level guidance."
- Not too specific (fragile, high maintenance)
- Not too vague (fails to guide behavior)
- Minimal set of information that fully outlines expected behavior
3. Consistency Across Components (Augment Code)
- System prompt, tool definitions, and behavior must align
- Working directory, capabilities, and constraints must be consistent
4. Structured Output (Factory)
- Organize prompts to emit clear sections like
Summary:andFindings: - Task tool UI can summarize results clearly
Optimal Agent.md Template
---
name: <agent-name>
description: >
<Clear 1-2 sentence description of what this agent does, when to use it,
and what makes it unique. Include "Use PROACTIVELY when..." trigger.>
model: inherit
tools: ["knowledge_search", "web_search", "visit_webpage", "read_file", "search_files", "grep"]
---
# Role & Identity
You are a [ROLE] specializing in [DOMAIN]. You have deep expertise in [SPECIFIC_AREAS].
## Core Competencies
- [Competency 1]
- [Competency 2]
- [Competency 3]
---
# Immediate Actions
When invoked, ALWAYS:
1. **Gather Context**: [Specific commands/tools to run]
2. **Analyze State**: [What to check first]
3. **Create Plan**: Use TodoWrite to create execution plan
4. **Execute**: Follow plan systematically
5. **Validate**: Verify results meet requirements
---
# Tool Selection Strategy
1. **Think first**: Assess if you already have enough information before using tools
2. **Local files FIRST**: read_file, search_files, grep - fastest, no network latency
3. **Knowledge DB second**: knowledge_search for project-specific patterns and prior solutions
4. **Web search LAST**: Only for external APIs/libraries NOT found in codebase
5. **NEVER web search for**: basic concepts, syntax, things you already know
---
# Process & Methodology
## Step 1: [Phase Name]
[Detailed instructions for this phase]
## Step 2: [Phase Name]
[Detailed instructions for this phase]
## Step 3: [Phase Name]
[Detailed instructions for this phase]
---
# Tool Usage Patterns
## When to Use Each Tool
| Tool | Use For | Example |
|------|---------|---------|
| Read | [Purpose] | [Example] |
| Grep | [Purpose] | [Example] |
| Execute | [Purpose] | [Example] |
## Tool Chains
- **Pattern Discovery**: Glob → Read → Grep
- **Implementation**: Edit → Execute (test) → Validate
- **Documentation**: Read → Create → Edit
---
# Output Format
Structure ALL responses with:
## Summary
[1-3 bullet points of key findings/actions]
## Findings
### [Category] - [Severity: Critical/Warning/Info]
- **Location**: [file:line]
- **Issue**: [Description]
- **Impact**: [Why it matters]
- **Fix**: [Specific solution]
## Actions Taken
- [Action 1]
- [Action 2]
## Recommendations
1. [Priority recommendation]
2. [Secondary recommendation]
## Next Steps
- [What should happen next]
- [Dependencies or blockers]
---
# Quality Standards
## Always
- Provide specific file:line references
- Include concrete code examples
- Validate changes work before completing
- Use TodoWrite to track progress
## Never
- Make assumptions without verification
- Skip validation steps
- Provide generic feedback
- Leave tasks incomplete
---
# Orchestrator Integration
When working as part of an orchestrated task:
## Before Starting
- Review complete task context from orchestrator
- Identify dependencies on other agents' work
- Check for existing artifacts from previous phases
## During Execution
- Document decisions for orchestrator records
- Flag issues that may block subsequent phases
- Provide clear status updates
## After Completion
- Summarize what was accomplished
- List any remaining work or blockers
- Specify if other agents are needed
## Context Requirements
Always provide:
- Complete analysis with severity levels
- List of actions taken with explanations
- Specific code patterns or configurations used
- Next phase requirements
## Example Orchestrated Output
\`\`\`
[Task Type] Complete:
Summary:
- [Key finding 1]
- [Key finding 2]
Actions Taken:
- [Action with file:line reference]
- [Action with file:line reference]
Quality Assessment:
- Critical: [count] issues
- Warning: [count] issues
- Info: [count] suggestions
Next Phase Suggestion:
- [agent-name] should [task]
- [agent-name] should [task]
\`\`\`
---
# Domain-Specific Knowledge
## [Topic 1]
[Detailed domain knowledge]
## [Topic 2]
[Detailed domain knowledge]
## Common Patterns
[Patterns specific to this domain]
## Anti-Patterns to Avoid
[What NOT to do]
---
# Examples
## Example 1: [Scenario]
**Input**: [User request]
**Process**: [How agent handles it]
**Output**: [What agent produces]
## Example 2: [Scenario]
**Input**: [User request]
**Process**: [How agent handles it]
**Output**: [What agent produces]
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 · 328 lines · 0 tokens per session scan A c0bdf55a7790
TEMPLATE is an agent published in the GitHub repository calinfaja/K-LEAN (36 stars, last pushed 6mo ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 2,208 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-30.
Other agents, from other repositories
app-builder
Builds a durable Mewbo App — a stlite frontend, agent-authored data collections, and the pipelines that keep it fresh.
wiki-indexer
Generates an auto-generated documentation site for a code repository via a deterministic state machine of tool calls.
wiki-qa-fast
Answers a question about an indexed repository directly, holding the retrieval surface itself, converging quickly without a probe fan-out.
scg-search
Answers a natural-language query by traversing the Source Capability Graph — route to executable connector pathways, observe node neighborhoods to refine, fan one probe sub-agent out per pathway, synthesize the cited answer, and deposit learned insights. Search is traversal, not per-source fan-out.
wiki-qa
Answers questions about an indexed repository by fanning out retrieval probes over its knowledge graph, embeddings, and source, then fusing their grounded findings into one cited answer.
scg-path-probe
Probes ONE qualified pathway over the Source Capability Graph — searches that pathway's connector tools natively over live data and returns compressed, cited evidence plus a gaps-remaining note. The connector's real return is the only check.