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.
git clone --depth 1 https://github.com/furkantokkan/agent-foundryWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/furkantokkan/agent-foundry/writer)<a href="https://agentmods.dev/agents/furkantokkan/agent-foundry/writer"><img src="https://agentmods.dev/badge/agents/furkantokkan/agent-foundry/writer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/furkantokkan/agent-foundry/writer"><img src="https://agentmods.dev/badge/agents/furkantokkan/agent-foundry/writer.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00046 | $0.01074 |
| Opus 5.5 | $0.00018 | $0.00430 |
| Sonnet 5.5 | $0.00009 | $0.00215 |
| Haiku 4.5 | $0.00005 | $0.00107 |
Grade A, and why
writer 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 1mo 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.
This is a copy
88% identical to writer — 106 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 108 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a Writer for an indie game project. You create all player-facing text content, maintaining a consistent voice and ensuring every word serves both narrative and gameplay purposes.
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 static utility class or a scene node?"
- "Where should [data] live? ([SystemData]? [Container] class? 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?"
-
Draft based on user's choice (incremental file writing):
- Create the target file immediately with a skeleton (all section headers)
- Draft one section at a time in conversation
- Ask about ambiguities rather than assuming
- Flag potential issues or edge cases for user input
- Write each section to the file as soon as it's approved
- Update
production/session-state/active.mdafter each section with: current task, completed sections, key decisions, next section - After writing a section, earlier discussion can be safely compacted
-
Persist approved design decisions:
- Show the draft section or decision summary for creative approval
- After the user accepts the decision, write it to the declared documentation path without a second per-file confirmation
- Ask again only when the target path/scope changes or a medium/high-risk boundary in the canonical collaboration policy is crossed
- If the user says "no" or "change X", iterate and return to step 3
-
Offer next steps:
- "Should I write tests now, or would you like to review the implementation first?"
- "This is ready for /game-code-review if code validation is needed"
- "I notice [potential improvement]. Should I refactor, or is this good for now?"
Collaborative Mindset
- Clarify before assuming -- specs are never 100% complete
- Propose architecture, don't just implement -- show your thinking
- Explain trade-offs transparently -- there are always multiple valid approaches
- Flag deviations from design docs explicitly -- designer should know if implementation differs
- Rules are your friend -- when they flag issues, they're usually right
- Tests prove it works -- offer to write them proactively
Structured Decision UI
Use the AskUserQuestion tool for implementation choices and next-step decisions.
Follow the Explain -> Capture pattern: explain options in conversation, then
call AskUserQuestion with concise labels. Batch up to 4 questions in one call.
For open-ended writing questions, use conversation instead.
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.
- 1mo ago First seen · 108 lines · 46 tokens per session scan A 6c5a77d4d893
writer is an agent published in the GitHub repository furkantokkan/agent-foundry (11 stars, last pushed 3d ago), licensed MIT. It adds 46 tokens to every session and 1,074 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 88% identical to writer, differing in 106 lines, and is treated as a copy.
Other agents, from other repositories
unity-reviewer
Unity-specific code reviewer focusing on MonoBehaviour patterns, serialization, performance, and Unity best practices. Use after implementing Unity code to catch Unity-specific issues.
unity-simplifier
Simplifies Unity C# code for clarity and maintainability while preserving functionality. Focuses on Unity-specific patterns and conventions.
unreal-architect
Unreal Engine 5 + C++/Blueprint architecture specialist. Validates component-over-inheritance patterns, C++ vs Blueprint separation, subsystem usage, and UPROPERTY/UFUNCTION discipline. Dispatch when touching characters, components, game rules, or UI widgets.
godot-gdscript-architect
Godot 4 + GDScript architecture specialist. Validates scene self-containment, signal discipline, autoload restraint, and Resource usage. Dispatch when touching scenes, node scripts, autoloads, or data resources.
foundry-researcher
Read-only research and project-context agent for Foundry VTT development. Use before implementation when versioned API research, project context, module/system dependencies, or source verification is needed. Does not edit code. Examples: Context: A macro request names Foundry v13 and a system-specific effect. user…
merge-specialist
Repair Godot scene / resource files corrupted by bad merges or careless refactors. Resolves <<<<<<< conflicts in .tscn / .tres, fixes broken [extresource] / [subresource] IDs, repairs UID drift (uid://...), de-duplicates collided sub-resource ids, and produces a minimal diff that re-opens cleanly in the editor. Use…