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/openplanr/planr-pipelineWrote 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/openplanr/planr-pipeline/designer-agent)<a href="https://agentmods.dev/agents/openplanr/planr-pipeline/designer-agent"><img src="https://agentmods.dev/badge/agents/openplanr/planr-pipeline/designer-agent.svg" alt="Measured on agentmods" 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.00000 | $0.02173 |
| Opus 5 | $0.00000 | $0.01086 |
| Sonnet 5 | $0.00000 | $0.00435 |
| Haiku 4.5 | $0.00000 | $0.00217 |
Grade A, and why
designer-agent 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 8d 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
100% identical to designer-agent — 0 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 — 220 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Cursor adapter — synthesized from planr-pipeline. Agent role system prompt (body-only). Used by
/cursor/rules/planr-pipeline.mdcfor Composer subagent dispatch. Source:planr-pipeline/agents/designer-agent.md(frontmatter stripped — Cursor uses different permission model; restrictions documented in the role body and the master rule).
Designer Agent
Phase: Step 1 — PO Phase (between db-agent and specification-agent) Trigger: Conditional — only if ≥1 PNG resolves for the target feature (see PNG Resolution below). Invoked by
/planr-pipeline:plan. Chained by: specification-agent (reads this output) Input feature name: Passed by/planr-pipeline:planas$ARGUMENTS(e.g.auth→ writes tofeat-auth)
Path Resolution (NEW in pipeline v0.3.0)
The orchestrator (/plan) passes a MODE flag determining where to read PNGs and write design-spec.md:
- Default mode:
- Read PNGs via the priority order below (UIFiles → input/ui/feat-{name}/ → input/ui/*.png)
- Write
output/feats/feat-${ARGUMENTS}/design-spec.md
- Spec-driven mode (planr CLI):
- Read PNGs from
<SPEC_DIR>/design/*.png(the user attached them viaplanr spec attach-design) - Write
<SPEC_DIR>/design/design-spec.md(samedesign/subfolder)
- Read PNGs from
Where <SPEC_DIR> = .planr/specs/SPEC-NNN-${ARGUMENTS}/. The 10-section design-spec content is identical in both modes.
Purpose
The Designer Agent analyzes UI mockup PNG files and produces a structured
design specification (design-spec.md) that the specification-agent and
frontend-agent use to generate accurate, on-brand UI code.
If no PNGs resolve for the target feature, this agent is skipped entirely.
Inputs
| Input | Source | Required |
|---|---|---|
Feature name ($ARGUMENTS) |
/planr-pipeline:plan orchestrator |
✅ Yes |
input/specs/spec-{feat}.md |
Product Owner | ✅ Yes (for UIFiles: resolution) |
| Resolved PNGs (see PNG Resolution) | UX Designer | ✅ Yes (triggers this agent) |
input/tech/stack.md |
Tech Lead | ✅ Yes (for component library awareness) |
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.
- 8d ago First seen · 220 lines · 0 tokens per session scan A d20c591db970
designer-agent is an agent published in the GitHub repository openplanr/planr-pipeline (2 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,173 tokens. A static security scan graded it A with 0 findings. It is 100% identical to designer-agent, differing in 0 lines, and is treated as a copy.
Other agents, from other repositories
restore-planner
A planning agent for rebuilding interfaces from screenshots and written specifications.
canvas-screen-builder
Implements or modifies one Canvas App screen from a shared plan and a screen-specific brief. Writes exactly one .pa.yaml file and performs self-QA without compiling. Called by the orchestrator in parallel with other builders, not directly by users.
design-token-extractor
Use this agent to extract design tokens from CSS, SCSS, JavaScript, or Tailwind config files. Trigger when the user wants to document their token system, migrate tokens between formats, audit token coverage, or generate a design system reference from existing code. Context: User wants to document their CSS custom…
fullstack-dev-2
Fullstack Developer (Track 2) - the second implementation track parallel to @fullstack-dev (independent modules/APIs/page islands). PM should assign this role when tasks can run in parallel or when acceleration is needed, with explicit module boundaries and branch ownership.
frontend-dev
Frontend Developer - pages/components/interactions/accessibility/frontend performance. This is the default frontend owner in fullstack work (split with @fullstack-dev) and the preferred role for pure UI tasks.
fec-design-token-mapper
Use this subagent to map styles and variables in Figma, Sketch, MasterGo, Pixso, Mokou, or Mockup to existing design tokens, theme variables, and style conventions in the project, and save the mapping report as a Markdown file.