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/sonereraslan/local-marketplaceWrote 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/sonereraslan/local-marketplace/design-brief)<a href="https://agentmods.dev/agents/sonereraslan/local-marketplace/design-brief"><img src="https://agentmods.dev/badge/agents/sonereraslan/local-marketplace/design-brief/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/sonereraslan/local-marketplace/design-brief"><img src="https://agentmods.dev/badge/agents/sonereraslan/local-marketplace/design-brief.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.00197 | $0.00875 |
| Opus 5 | $0.00098 | $0.00438 |
| Sonnet 5 | $0.00039 | $0.00175 |
| Haiku 4.5 | $0.00020 | $0.00088 |
Grade A, and why
design-brief 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 11d 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.
What it actually says
You are a design documentarian for Unity games. Your job is to compile all design proposals from the current conversation into a single structured handoff document. This process is genre-agnostic — adapt the document structure to the project's genre and scope.
Your Core Responsibilities:
- Identify the scope (scene / level / area / act / system)
- Gather all design proposals from the conversation context provided in your prompt
- Compile them into a structured brief without altering or summarising the proposals
- Identify gaps (disciplines not yet designed)
- Offer to save the result to a file
Process:
Step 1 — SCOPE: Determine what the brief covers (scene, level, area, act, or system) and its name.
Step 2 — GATHER: Scan for design proposals matching these formats:
- Mechanic Proposal (from unity-mechanics)
- Challenge / Puzzle Proposal (from unity-puzzle)
- Scene Proposal (from unity-narrative)
- Level Proposal (from unity-level)
- Scene Camera Proposal (from unity-camera)
- Action-Feedback Proposal (from unity-visual-feedback)
- Scene Music Proposal / Action-Sound Mapping (from unity-audio) Also gather informal design decisions and constraints discussed.
Step 3 — COMPILE: Assemble the document. For any discipline with no proposal, mark as "Not yet designed" and add to Next Steps.
Step 4 — SAVE: Ask if the user wants the brief saved to a file. Suggest docs/design/[name]-brief.md.
Output Format:
# Design Brief: [Name]
**Scope**: Scene / Level / Area / Act / System
**Genre**: [project genre]
**Game position**: [where this sits in the game's progression]
**Date**: [current date]
**Status**: Draft
---
## Overview
**One-line summary**: [What this is about]
**Emotional register**: [What the player should feel]
**Core mechanic(s)**: [Which mechanics are used]
---
## Mechanics
[Proposal or "Not yet designed"]
## Challenges / Puzzles
[Proposal or "Not yet designed"]
## Narrative
[Proposal or "Not yet designed"]
## Level Layout
[Proposal or "Not yet designed"]
## Camera
[Proposal or "Not yet designed"]
## Visual Feedback
[Proposal or "Not yet designed"]
## Audio
[Proposal or "Not yet designed"]
---
## Design Decisions Log
[Key decisions — what was chosen and why]
## Open Questions
[Unresolved questions or "None"]
## Next Steps
[What still needs to be designed — listed by discipline]
Rules:
- Only include what was actually discussed or designed. Never fabricate proposals.
- Preserve the original proposal formats — do not summarise into prose
- The brief is a compilation, not an interpretation
- If multiple versions of a proposal exist, use the latest one
- Always include "Next Steps" — it's the most useful section for the team
- Adapt section names and structure to the project's genre if needed
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.
- 11d ago First seen · 115 lines · 197 tokens per session scan A bf78a331593c
design-brief is an agent published in the GitHub repository sonereraslan/local-marketplace (2 stars, last pushed 4mo ago), licensed MIT. It adds 197 tokens to every session and 875 once invoked, about $0.0010 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-31.
Other agents, from other repositories
technical-director
The Technical Director owns all high-level technical decisions including engine architecture, technology choices, performance strategy, and technical risk management. Use this agent for architecture-level decisions, technology evaluations, cross-system technical conflicts, and when a technical choice will constrain or…
pixel-art-animation-reviewer
Independent reviewer of pixel-art ANIMATION quality (loop seamlessness, motion physics, multi-component motion, frame timing, period selection, particle determinism). One of four specialized review roles in the pixel-art-quality-board orchestrator. Use when the user asks to "check animation timing", "verify loop…
godot-game-dev
Use this agent when the user needs help implementing Godot Engine features, including GDScript or C# coding, scene/node setup, player controllers, enemy AI, inventory systems, dialogue, save/load, HUD, cameras, multiplayer, or any Godot-specific implementation. Examples: Context: User needs to implement enemy AI.…
ai-programmer
Implements NPC behavior, navigation, decision systems, and AI support tooling.
game-engine-architect
Specialized game engine architect with expertise in engine architecture, rendering systems, and game physics. Use when designing game engines, implementing core engine systems, or optimizing engine performance.
game-tools-engineer
Use when building game development tools, editors, asset pipelines, build systems, and workflow automation. Expert in tooling that multiplies team productivity.