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 skills add aakashg/pm-claude-skills --skill product-designergit clone --depth 1 https://github.com/aakashg/pm-claude-skillsWrote 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/aakashg/pm-claude-skills/product-designer)<a href="https://agentmods.dev/skills/aakashg/pm-claude-skills/product-designer"><img src="https://agentmods.dev/badge/skills/aakashg/pm-claude-skills/product-designer/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/aakashg/pm-claude-skills/product-designer"><img src="https://agentmods.dev/badge/skills/aakashg/pm-claude-skills/product-designer.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 33 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.00055 | $0.02191 |
| Opus 5 | $0.00028 | $0.01095 |
| Sonnet 5 | $0.00011 | $0.00438 |
| Haiku 4.5 | $0.00006 | $0.00219 |
Grade A, and why
product-designer 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 12d 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 — 185 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Product Design Reviewer
Review a design across 6 dimensions and return prioritized, actionable feedback.
Step 0 — Read first
| Source | Path | What to extract |
|---|---|---|
| The design | screenshot, image, or Figma link the user shares | The actual screen — never review from a text description alone |
| Project context | CLAUDE.md |
Product, target users, platform, current focus |
| Screen-type checklist | references/screen-checklists.md |
The issues specific to forms, tables, onboarding, settings, modals |
| AI UX checks | references/ai-ux-review.md |
Extra checks when the design includes AI features |
| Prior feedback | any doc the user names | What was already flagged — do not re-flag resolved issues |
If the user describes the design in words only, request a screenshot before reviewing. Reviewing a described design means inventing one.
Constraints
Mandatory.
- Every issue gets all three: what is wrong, why it matters to the user, and a concrete fix.
- Never give aesthetic preference as feedback. "I don't like this blue" is a preference. "This CTA is 2.1:1 against the background, WCAG AA needs 4.5:1" is feedback.
- Never list a problem without a fix. Problems without solutions are complaints.
- Never redesign the whole page. Work within the current design direction.
- Never flag more than 3 Must Fix items. Prioritize ruthlessly — 3 high-impact issues beat 15 nitpicks.
- Never assume platform or user type. If unstated, ask.
- Never critique copy if the copy is not final. Review layout, flow, and interaction.
- Never dismiss an unconventional pattern without asking about user testing data first.
- Lead with what works, always, before any criticism.
Existence check
Before reviewing, verify:
- The artifact — a screenshot, image, or link you can actually see.
- The user goal — what the person is trying to accomplish in this flow.
- The context — platform (web/mobile/tablet) and stage (concept, pre-eng, post-launch).
What ships with it
2 files 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.
- 12d ago First seen · 185 lines · 55 tokens per session scan A 3e5a00241118
product-designer is a skill published in the GitHub repository aakashg/pm-claude-skills (106 stars, last pushed 1mo ago), licensed MIT. It adds 55 tokens to every session and 2,191 once invoked, about $0.0003 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-30.
Other skills, from other repositories
tool-design-sprint-brief
Pre-sprint brief that locks challenge, sprint questions, team and role assignments, customer recruiting plan, prototype medium, interview format, logistics, and success criteria before Monday of a Design Sprint. Use after the readiness verdict is Go and before Monday begins. Produces a two-page artifact the team and…
tool-design-sprint-prototype-plan
Day 4 (Thursday) move of a Design Sprint that produces the planning artifact for the day. Output covers the prototype role plan (Maker, Stitcher, Writer, Asset Collector, Interviewer), prototype brief (what to build, fidelity bar, time allocation per role), canonical Five-Act Interview script (Welcome, Context, Intro…
tool-design-sprint-readiness
Pre-sprint diagnostic that determines whether a team should run a Design Sprint now, postpone it, or do prerequisite work first. Produces a Go / Conditional Go / Wait verdict with diagnosis, recommended preconditions, attendee list, customer recruiting plan, and pre-sprint activities. Use when a team is considering…
tool-design-sprint-decide-and-storyboard
Day 3 (Wednesday) move of a Design Sprint that runs the art museum layout, heat map, speed critique, straw poll, Decider supervote, rumble-vs-all-in-one decision, and the storyboard that drives Thursday's prototype build. The most decision-heavy day of the sprint. Use Wednesday morning and afternoon after Tuesday's…
tool-design-sprint-map-and-target
Day 1 (Monday) move of a Design Sprint that produces the bundled Monday artifact containing long-term goal, sprint questions (3-7 testable risks), customer or system map (5-15 step flow), expert interview notes, HMW (How Might We) cluster board, and the Decider's chosen target moment. Use Day 1 morning and afternoon…
tool-design-sprint-sketch
Day 2 (Tuesday) move of a Design Sprint that structures lightning demos and the four-step independent solution sketch protocol (Notes, Ideas, Crazy 8s, Solution Sketch). Each team member produces one solution sketch individually; the skill orchestrates the day but does not author the sketches themselves. Use Tuesday…