amplifier-bundle-skills

Convene the persona panel on the CURRENT conversation / work-in-progress — the plan, design, or decision you've been building in this session. The INLINE counterpart to /council (which forks and runs isolated, so it cannot see the chat). Use when you want the council to critique what we're working on right now.

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.

Momentum-driven engineering reviewer that holds one uncompromising gate — is it REAL, proven end-to-end as a user would — while driving work forward. Demands proof over claims, plumbing before polish, fail-loud over fallbacks, trust in the model over instructions, and protects the critical path so good-but-costly ideas don't stall the work. Warm, blunt, forward-driving — not a curmudgeon. A lens for any checkpoint — brainstorm, design, plan, implement, debug, or ship — not just the finish. Use when: pressure-testing whether an idea/design/plan is provable and on the critical path, whether you're building in the right order, whether a fix is real or a band-aid, or whether work is actually done/ready — any time the worry is "are we fooling ourselves about what's real?"

Use when building an Amplifier-powered workflow or automation tool and deciding how to expose it — as standalone .dot attractor pipelines (incl. inside the Resolve dot-graph resolver), an importable Python lib, agent-callable tool modules, or a CLI. Covers the four leverage levels, the DRY rule that keeps logic in ONE home, the judgment for which levels a real consumer actually needs (and when adding a level is just ceremony), and the maximally-DRY attractor-only specialization where the .dot pipeline is the sole logic home.

Hard-won patterns for probing, building, troubleshooting, and iterating against Microsoft Graph API endpoints -- especially from a browser SPA using delegated MSAL.js auth calling Graph directly with no backend (lessons generalize to any Graph integration). Covers the throwaway-probe-file methodology for de-risking before building, OData/query quirks, permission and admin-consent sequencing, recordings/transcripts access patterns (SharePoint REST, not Graph), CSP requirements for a pure-browser SPA, retry/pagination/backoff patterns, and the MSAL/EasyAuth auth-redirect-loop debugging saga. Use when integrating with Microsoft Graph, Teams APIs, MSAL.js, or EasyAuth; when hitting an unexpected Graph error (400/403/429), a silent missing-scope failure, an auth redirect loop, or a CSP violation that only appears in production; or when deciding how to validate a new Graph capability before committing it to a codebase.

Analyze images using LLM vision APIs (Anthropic Claude, OpenAI GPT-4, Google Gemini, Azure OpenAI). Use when tasks require: (1) Understanding image content, (2) Describing visual elements, (3) Answering questions about images, (4) Comparing images, (5) Extracting text from images (OCR). Provides ready-to-use scripts - no custom code needed for simple cases.

Simplicity-obsessed design reviewer that interrogates complexity, questions every abstraction, and insists on the minimal viable design. Sounds like a senior engineer who has watched too many systems collapse under their own weight and now treats every unnecessary layer as a personal affront. Not a generalist skeptic — a simplicity zealot. A lens for any checkpoint — brainstorm, design, plan, implement, debug, or review — not just design. Use when: anything looks more complex than the problem needs — a speculative idea, an abstraction, a layer, an over-built fix — any time the worry is "do we actually need this, or can it be deleted?"

Curmudgeonly engineering advisor that provides grounded skepticism, evidence-linked judgment, and constructive progress on architectural decisions, legacy refactors, tooling choices, and broad "how should I start?" questions. Sounds like a senior systems engineer who has reviewed too many designs to be impressed, but still cares about correctness. A lens for any checkpoint — brainstorm, design, plan, implement, debug, or review — not just up-front decisions. Use when: weighing consequences, hidden costs, or failure modes of any choice — an idea, an architecture, a tooling/legacy call, an implementation path, or a fix — any time the worry is "what will this cost us later?"

Goal-clarity reviewer that refuses to judge a solution until the intent behind it is pinned. Hunts goal drift and translation loss — the slow substitution of "the thing we set out to do" with "the thing we happen to be building." Sounds like a patient, relentless interrogator of "why are we doing this?" who will not be hurried past the question. Not a solution reviewer — a reviewer of whether the solution is even pointed at the right thing. A lens for any checkpoint — brainstorm, design, plan, implement, debug, or review — not just kickoff. Use when: the deliverable has quietly become the goal, the build has wandered from the brief, or nobody can say in one sentence what success looks like — any time the worry is "is this still the real goal?"

Research and plan a large-scale change, then execute it in parallel across isolated agents that each open a PR.

Build a new opinionated advisor-persona skill — a reviewer "lens" like crusty-old-engineer — modeled on a real person or archetype and proven from real evidence. Mines the subject's authentic voice and discipline, defines its one distinct load-bearing question, drafts it to the family template, proves it steers in a live session, reduces it, and publishes it 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".

Diagnose issues in the current Amplifier session — misconfigured tools, failing operations, unexpected behavior. Use when something isn't working right.

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.

Adversarial breaker that reviews code by trying to make it fail, not by confirming it works. Hunts the unhappy paths — the malformed input, the empty string, the reversed range, the race condition — that the happy-path reviewer never types. Sounds like a gleeful adversary who thinks in inputs nobody intended and assumes everything is broken until a concrete attempt to break it comes up empty. Not a QA checklist — a hostile witness for the failure that hasn't happened yet. A lens for any checkpoint — brainstorm, design, plan, implement, debug, or review — not just a test gate. Use when: the happy path is celebrated while the edges sit unexamined, "looks fine" is standing in for "I tried to break it and couldn't," or nobody has named the input that makes this fall over — any time the worry is "how does this fail, and where are the edges?"

User-need reviewer that speaks for the person who isn't in the room — the one who will actually live with what gets built. Hunts the gap between "we can build this" and "they actually want this," and between "it works" and "they can live with it." Sounds like the patient, slightly impatient voice of the absent user — uninterested in how clever the build is, relentless about whether anyone asked for it and whether it survives contact with a real person. Not a UX consultant — an advocate for the served person's desire and lived experience. A lens for any checkpoint — brainstorm, design, plan, implement, debug, or review — not just design. Use when: a feature is being built because it's buildable rather than wanted, the happy path is celebrated while the recovery path is missing, or nobody can name the person this serves — any time the worry is "does the person we serve actually want this, and can they live with it?"

Use when verifying that completed work actually works. Auto-surface during /verify mode, post-implementation review, or before claiming a task is done. Teaches the discipline of testing outcomes vs implementation, the unit/integration/smoke gradient, and what "done" actually means.

Use when building a new CLI tool that needs one-line install via uv or npm, subcommand dispatch with a default action, or 3-tier config resolution (CLI flags, config file, hardcoded defaults).

Use when designing a curl-piped install script for a project that cannot use uv tool install or npm publish — multi-service stacks (Docker Compose), raw TS/React apps, tools that bootstrap system dependencies, or installs for non-technical audiences. Documents the security trade-off, the community convention used by rustup, bun, deno, fly, ollama, and supabase, and the cases where this pattern is the wrong answer.

Use when your service needs authentication that works without friction locally but secures remote access, automatic TLS certificate setup, or token-based auth with auto-generation and localhost bypass.

Use when your tool needs persistent configuration files with safe defaults merging, atomic state writes that survive crashes, or conventional file locations for config vs state vs secrets.

Use when running tasks in Docker containers with safety limits, watchdog monitoring for resource enforcement, orphan container recovery, sidecar container provisioning, or scripting reproducible dev stack environments.

Use when processes need to communicate via the filesystem without a message broker — JSONL event logs, atomic state snapshots, async request/response via file pairs, or SSE streaming from file tailing.

Use when building an HTTP service with FastAPI lifecycle management, background poll loops, SPA static file serving with API reverse proxy, bidirectional WebSocket relay, or SSE event streaming.

Use when your system manages multiple concurrent instances or sessions that each need isolated storage directories, per-instance file locking, or a prepare-once/create-many session factory pattern.

Use when making a system extensible with runtime plugin discovery via Python entry points, a file-based plugin registry, multi-backend provider abstractions, or schema-driven input validation.

Use when building a React frontend that dynamically loads independent bundles sharing a single React instance via import maps, needs frecency-based autocomplete, dynamic schema-driven forms, or Zustand state with localStorage.

Use when adding a doctor diagnostic command, self-update/upgrade mechanism, cross-platform service installation (systemd and launchd), or post-upgrade verification to a CLI tool.

Adapt a skill written for another AI coding assistant (Claude Code, Cursor, etc.) into a properly structured Amplifier SKILL.md file. Reads the source skill, identifies platform-specific conventions, researches the source platform if needed, and produces an Amplifier-native skill conforming to the Agent Skills specification with Amplifier extensions. 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.

Capture a repeatable process from the current session into a reusable Amplifier SKILL.md skill file. Analyzes the conversation, interviews the user to confirm structure, and writes a complete skill to disk. 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.

Amplifier design philosophy using Linux kernel metaphor. Covers mechanism vs policy, module architecture, event-driven design, and kernel principles. Use when designing new modules or making architectural decisions.

Guide for creating new Amplifier modules including protocol implementation, entry points, mount functions, and testing patterns. Use when creating new modules or understanding module architecture.

Python coding standards for Amplifier including type hints, async patterns, error handling, and formatting. Use when writing Python code for Amplifier modules.

Review changed code for reuse, quality, and efficiency, then fix any issues found.