3209 skills
Authoritative consultant for all skills-related questions. Use when creating or modifying skills, understanding the Agent Skills spec, troubleshooting skill loading or invocation issues, leveraging enhanced format features (context fork, model_role, user-invocable), writing cross-harness portable skills, ensuring Claude Code Skills 2.0 compatibility, or deciding between skills vs agents.
Capture a repeatable process from the current session into a reusable Amplifier SKILL.md skill file. Use when the user wants to create a skill, save a workflow as a skill, turn a process into a reusable skill, or mentions "skillify", "create skill", "make a skill", "save as skill", "capture workflow", "turn this into a skill", "new skill", or wants to automate a repeatable process they just performed.
Diagnose issues in the current Amplifier session — misconfigured tools, failing operations, unexpected behavior. Use when something isn't working right.
Independent review of current work or a past session. USE WHEN a user wants a second opinion. DO NOT USE WHEN ordinary code review is wanted — use code-review.
Momentum-driven engineering reviewer holding one uncompromising gate: is it REAL, proven end-to-end as a user would? Warm, blunt, forward-driving — proof over claims, plumbing before polish, fail-loud over fallbacks, trust in the model over instructions, critical path protected. Use at any checkpoint — brainstorm, design, plan, implement, debug, ship — when testing whether work is provable, built in the right order, or actually done rather than band-aided: "are we fooling ourselves about what's real?"
Convene the Product Development Council — six orthogonal product-delivery lenses anchored by a mandatory problem-validation gate. Cold independent fan-out, debate-to-consensus, synthesized verdict with recorded dissent and a roster manifest.
Convene the Product Development Council on the CURRENT conversation — the plan, roadmap, or scope decision built in this session. The INLINE counterpart to /product-council (which forks isolated and cannot see the chat). Use when you want the council to critique what we're working on right now.
Competitive-differentiation reviewer that refuses to accept "the user wants this" as sufficient. Demands the plan say why a real customer would choose it over every alternative, including doing nothing — voice of a positioning strategist who has watched well-liked products lose to a clearer story. Use at any product checkpoint — plan, roadmap, go-to-market framing — when nobody can say why users would switch or pay, the competitive landscape is unaddressed, or "no one else does this" is asserted without checking: "why us, why this, why now?"
Build a new opinionated advisor-persona skill — a reviewer "lens" like crusty-old-engineer, modeled on a real person or archetype. Mines the subject's authentic voice, defines its one load-bearing question, drafts it to the family template, and proves it steers a live session before publishing to a skills bundle. Use when creating or authoring a persona/advisor skill, adding a sibling to the crusty-old-engineer family, or turning a person's real direction style into a reusable reviewer skill. Also triggers on "personafy" / "personify".
Outcome-clarity reviewer that asks whether you have defined what you're trying to achieve and validated that the problem is real. Catches people BEFORE they build — the moment between "I should build X" and actually building it. Use when a build is starting without a validated problem or a plain-language definition of what success looks like.
Outcome-validity reviewer that refuses to count shipped work as progress until it maps to a measurable change in behavior. Hunts the gap between "we shipped it" and "we moved the number" — the output mistaken for an outcome. Use at any product checkpoint — plan, roadmap, PRD, ship review — when deliverables carry no metric, "done" is confused with "worked," or nobody can say how success will be measured: "what measurable outcome defines success, and how will we know we moved it?"
Run a bounded, self-checking polling loop (sleep -> check -> decide, repeat) WITHOUT ENDING THE TURN. The turn ends only when the watched thing is done, has failed, or genuinely needs the user's attention — which is what makes Amplifier's end-of-turn notification fire correctly and honestly. Primarily invoked explicitly via `/monitor <thing to watch>`, e.g. `/monitor the CI run for PR 412, check every 2m, stop after 1h`. May also be self-invoked in the rare case you are about to tell the user "I'll keep working and let you know" for something with a genuinely checkable, bounded condition — see
Research and plan a large-scale change, then execute it in parallel across isolated agents that each open a PR.
Goal-clarity reviewer that refuses to judge a solution until the intent behind it is pinned. A patient interrogator of "why are we doing this?", hunting goal drift — the deliverable quietly replacing the goal. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when the build has wandered from the brief or nobody can say in one sentence what success looks like: "is this still the real goal?"
Analyze images using LLM vision APIs (Anthropic Claude, OpenAI GPT-4, Google Gemini, Azure OpenAI). Use when a task requires understanding image content, describing visual elements, answering questions about images, comparing images, or extracting text from images (OCR). Provides ready-to-use scripts.
Use for tool/service work: CLI packaging, installers, config/state, HTTP, auth/TLS, file IPC, plugins, instance storage, containers, React MFE, Graph, self-update, tool leverage.
Curmudgeonly engineering advisor: grounded skepticism and evidence-linked judgment on architecture, legacy refactors, and tooling choices. Voice of a senior systems engineer who has reviewed too many designs to be impressed but still cares about correctness. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when weighing consequences, hidden costs, or failure modes of a choice, or for broad "how should I start?" questions: "what will this cost us later?"
Simplicity-obsessed reviewer that interrogates complexity and insists on the minimal viable design. Voice of a senior engineer who treats every unnecessary layer as a personal affront. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when anything looks more complex than the problem needs: a speculative idea, an abstraction, a layer, an over-built fix. The worry: "do we actually need this, or can it be deleted?"
Build a NEW complete "council" for a domain — a panel of orthogonal review lenses that fan out cold, debate to consensus, and return a synthesized verdict with recorded dissent, exactly like /council and /design-council. Identifies the distinct lenses a domain needs (one load-bearing question each, mined from real archetypes — not invented), reuses existing lenses, and builds only the genuinely-missing ones (persona SKILLs via personafy, or agents when the role is an active builder). Use when creating a council, standing up a review panel for a domain (product, security, performance, data), or
Convene the persona panel — six orthogonal review lenses — on a target. Cold independent fan-out, debate-to-consensus, synthesized verdict with recorded dissent and a roster manifest.
Convene the persona panel on the CURRENT conversation — the plan, design, or decision built in this session. The INLINE counterpart to /council (which forks isolated and cannot see the chat). Use when you want the council to critique what we're working on right now.
Review changed code for reuse, quality, and efficiency, then fix any issues found.
Delivery-risk reviewer that sizes a plan's investment against the team's real confidence it will land. Voice of a delivery lead who has watched too many "should be straightforward" estimates blow up on the one unknown nobody named. Use at any product checkpoint — plan, roadmap, investment/sequencing decision — when a timeline carries more confidence than the team has, the riskiest unknown is buried, or nobody has said what would make this slip: "is the investment sized to our confidence?"
Adapt a skill written for another AI assistant (Claude Code, Cursor, etc.) into a proper Amplifier SKILL.md. Use when the user wants to adapt a skill, port a skill, convert a skill to amplifier, translate a skill, or has a SKILL.md from another platform they want to bring into Amplifier.
