Borrowing it
Nothing to install: this file belongs to c9r-io/orchestrator. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/c9r-io/orchestrator/main/.claude/skills/design-brief-gen/SKILL.mdgit clone --depth 1 https://github.com/c9r-io/orchestratorWrote 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/skills/c9r-io/orchestrator/design-brief-gen)<a href="https://agentmods.dev/skills/c9r-io/orchestrator/design-brief-gen"><img src="https://agentmods.dev/badge/skills/c9r-io/orchestrator/design-brief-gen/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/skills/c9r-io/orchestrator/design-brief-gen"><img src="https://agentmods.dev/badge/skills/c9r-io/orchestrator/design-brief-gen.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.00127 | $0.01607 |
| Opus 5.5 | $0.00051 | $0.00643 |
| Sonnet 5.5 | $0.00025 | $0.00321 |
| Haiku 4.5 | $0.00013 | $0.00161 |
Grade A, and why
design-brief-gen 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 2mo 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 — 152 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Design Brief Gen
Turn conversational design intent into a structured Design Brief and matching UIUX test documents — the design-first entry point for feature development.
Why This Skill Exists
Feature requests (FR) start from behavior ("what should the system do?"). Design Briefs start from user experience ("what should the user see and feel?"). This skill captures design intent through conversation — the same low-friction model as FR — and produces two outputs:
- Design Brief: Structured screen/flow/component documentation under
docs/design_brief/ - UIUX Test Doc: Testable scenarios aligned to the design, under
docs/uiux/
The Design Brief becomes the upstream artifact that drives implementation, much like an FR drives code.
Workflow
1. Interview: Clarify design intent through conversation
2. Discover constraints from design system
3. Generate Design Brief document
4. Generate UIUX test scenarios from the brief
5. Cross-check existing UIUX docs for impact
6. Update indexes
Step 1: Interview — Clarify Design Intent
Extract the following from the conversation. Ask for missing pieces — but keep it conversational, not a form.
Required:
- What: What screens/pages/flows are being designed?
- Why: What user problem does this solve?
- Who: Who are the target users?
- Where: Where does this live? (portal, standalone app, component library)
Helpful but optional (infer from context if not stated):
- Layout preferences (sidebar + content, full-width, split panel, etc.)
- Key components (tables, charts, forms, cards, etc.)
- Interaction patterns (CRUD, dashboard, wizard, etc.)
- Responsive requirements
- Reference designs or existing screens to emulate
If the user provides design images or mockups, reference them in the brief's Assets section. Images are input context, not hard requirements — the brief should describe intent, not pixel-match an image.
Step 2: Discover Design System Constraints
Read docs/design-system.md to extract applicable constraints:
- Token palette (light/dark)
- Glass/surface treatment rules
- Spacing, radius, typography scales
- Accessibility requirements (contrast, focus ring, ARIA)
- Animation and reduced-motion policy
- Responsive breakpoint strategy
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 2mo ago First seen · 152 lines · 127 tokens per session scan A e183c5ccb8f8
design-brief-gen is a skill published in the GitHub repository c9r-io/orchestrator (21 stars, last pushed 1mo ago), licensed MIT. It adds 127 tokens to every session and 1,607 once invoked, about $0.0005 per session on Opus 5.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-30.
Other skills, from other repositories
site-preship-review
Use before publishing or relaunching any website — six parallel single-dimension reviewers (design, mobile, states, user flows, launch prep, security & infra) that render and look at every page, then one or two fix passes. Includes launch-readiness and rendered-page checks.
codew-release-qa-sweep
Use before claiming Codewhale release work is done: run the full gate sweep and list the manual QA targets.
design-qa
Internal prototype QA helper. Use only after a Product Design prototype, URL-to-code build, or image-to-code build has a source visual target and a rendered implementation to compare before handoff. Do not use for broad UX critique, design critique, product audits, or flow reviews; route those user-facing requests to…
cw-dogfood
Use when a Codewhale change needs proving in the real product, or when asked to build/install/dogfood the local binaries: stamped release build, atomic install, fresh-shell verification, and the manual QA that gates cannot cover.
cw-gates
Use before claiming any Codewhale change is done, green, or ready to land: the focused-to-broad verification ladder, the budget checks CI enforces, and the rules for what counts as a passing test.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code.