ai

Use this skill to apply the PDD framework to a specific project. Triggers whenever a user wants to: review a project through a PDD lens, check how PDD principles apply to their work, get tool recommendations for a project, audit a project against PDD, or understand what PDD means in practice for a specific brief or context. Also trigger when the user says "apply PDD", "which tools should we use", "how does PDD apply here", "what should we do next", or "map this project to PDD" — even if they don't explicitly name a skill. Cowork-ready.

Use this skill to create Purpose-Driven Design (PDD) Archetype documents from user interview data. Trigger whenever a user wants to: synthesize interview data into archetypes or personas, generate archetype documents with goals/frustrations/needs/habits/quotes/demographics, or analyze user research to identify audience segments. Also trigger when the user says "archetypes", "PDD archetypes", "persona documents", or "synthesize interviews into archetypes" — even if they don't call it a skill. (To build a participant summary spreadsheet, use the pdd-interview-summary skill.) Cowork-ready with the Figma remote MCP connector enabled — it builds the FigJam board via `create_new_file` + `use_figma`, both remote-server (write-to-canvas) tools reached over the agent's MCP transport rather than the local Dev Mode bridge; pending live verification.

Use this skill to run a Purpose-Driven Design (PDD) Competitive Analysis. Triggers whenever a user wants to: compare competitors, benchmark a client's product or website against rivals, evaluate market landscape, score competitors on UX or business criteria, or create a competitive analysis spreadsheet. Also trigger when the user says "competitive analysis", "compare competitors", "benchmark", "landscape review", "audit competitors", "score products against each other", or asks "how does our client compare to X" — even if they don't explicitly call it a skill. The output is a formatted .xlsx file matching the Infinum/ETR competitive analysis template (IBM Plex Sans font, blue header bar, grey category rows, 1–3 scoring with rationale columns). Cowork-ready.

Use this skill to plan a discovery workshop for a client project. Reads the project information (goals, scope, stakeholders, time available) and recommends a plan — a warm-up plus 1–2 longer exercises (sessions are usually 1–2 hours) from the Infinum/ETR activity library, sequenced to fit the time. Triggers whenever a user wants to: plan or design a discovery workshop, build a workshop agenda or run-of-show, choose workshop activities, prepare a kick-off / alignment / ideation session with a client, or set up a FigJam facilitation board. Also trigger when the user says "discovery workshop", "workshop plan", "workshop agenda", "kickoff workshop", "facilitation board", "which exercises should we run", or "plan a session with the client" — even if they don't call it a skill. Output is a formatted .docx run-of-show plus a FigJam board scaffold (one section per activity). Cowork-ready — the .docx run-of-show uses Cowork's built-in docx toolchain, and the FigJam board builds via the Figma remote MCP connector (`cre

Use this skill to build a project estimate on the standard ETR/Infinum estimate template. It reads the project brief or RFP, benchmarks against past estimates in the team's Estimates drive, proposes a feature list with draft hours per department (Discovery, Content/SEO, UX, Design, Dev, PM), and fills the official estimate spreadsheet — keeping all of its built-in formulas. Estimates are in hours only; it never outputs dollar amounts. Triggers whenever a user wants to: estimate a project, scope hours, build an hours estimate, fill out the estimate template/sheet, price an RFP, or figure out how long a build will take. Also trigger when the user says "estimate", "estimate sheet", "scope this", "how many hours", "price this RFP", or "fill out the estimate" — even if they don't call it a skill. Output is a filled .xlsx (hours only, no dollar amounts) with all formulas intact (a local file; nothing is written to Drive). Cowork-ready.

Use this skill to build a Participant Summary spreadsheet from user-interview data — a reference table with one row per participant mapped across key dimensions (Audience Type, Goals, Habits, Frustrations, Needs, and any custom columns). It's a useful synthesis step before identifying archetypes or running a rainbow analysis. Triggers whenever a user wants to: summarize interview participants, build a participant summary/grid/matrix, map participants across dimensions, or create a per-participant reference table from transcripts or notes. Also trigger when the user says "participant summary", "participant grid", "summarize the participants", or "map participants across goals/frustrations/needs" — even if they don't call it a skill. Output is an `.xlsx` spreadsheet. Cowork-ready.

Use this skill to create a concise project brief that summarizes a project so far — what the client does, the project itself, stakeholders, goals and definition of done, out-of-scope, why now, users and their goals, differentiators, competitors/inspiration, sharp corners, and key discovery learnings. It pulls from whatever context exists (brief, RFP, stakeholder and user interviews, discovery workshop, competitive analysis) and flags anything unknown as a question for the client rather than inventing it. Triggers whenever a user wants to: summarize a project, write or update a project brief, capture where a project stands, onboard someone to a project, or consolidate discovery so far. Also trigger when the user says "project brief", "project summary", "brief", "summarize the project", "where are we on this project", or "catch me up on [project]" — even if they don't call it a skill. Output is the brief in the conversation plus a Markdown file. Cowork-ready.

Use this skill to create a Rainbow Analysis spreadsheet from user interview data. A Rainbow Analysis tallies recurring themes/observations across participants, assigns a unique color to each participant, and marks their contribution to each theme with a colored cell. Trigger whenever a user wants to: identify patterns across interviews, tally which participants mentioned which themes, create a theme frequency chart, map observations to participants, or do a "rainbow analysis" or "affinity analysis" on qualitative research. Also trigger when the user says "rainbow analysis", "theme tally", "observation frequency", "which participants said X", or "synthesize themes across interviews" — even if they don't explicitly call it a skill. Cowork-ready.

Use this skill to proactively surface project risks before they become problems and pair each with a concrete mitigation and contingency. It reads whatever project context is available — brief/scope, team, timeline, tech stack, client dynamics, current status or concerns — and produces a prioritized risk assessment across six dimensions (Timeline, Budget, Technical, Resource, Client/Stakeholder, External/Dependencies). Triggers whenever a user wants to: assess project risks, run a risk analysis, find what could go wrong, build or update a risk register, de-risk a plan, or pressure-test a project. Also trigger when the user says "risk radar", "risk assessment", "what are the risks", "what could go wrong", "risk register", or "de-risk this" — even if they don't call it a skill. Output is a structured risk assessment in the conversation plus a Markdown file. Cowork-ready.

Use this skill to build a project schedule (a dated Gantt) that matches the ETR/Infinum Project Schedule tab. It takes any project information — deliverables, phases, and existing timelines from the SOW — and lays out phases and tasks across a week/day calendar, with each phase a different colour and heading, and milestones for delivery dates and client-feedback due dates. It always previews the schedule in chat for adjustments before building the spreadsheet. Triggers whenever a user wants to: create a project schedule or timeline, lay out a Gantt chart, schedule deliverables and milestones, or turn an SOW timeline into a schedule. Also trigger when the user says "schedule", "timeline", "project schedule", "gantt", or "lay out the phases" — even if they don't call it a skill. Output is an `.xlsx`. Cowork-ready.

Use this skill to create a Stakeholder Interview Guide for a client project. Triggers whenever a user wants to: write stakeholder interview questions, create an internal interview guide for client team members, prepare interview scripts for executives or product owners, or build a guide for discovery-phase stakeholder sessions. Also trigger when the user says "stakeholder interview", "stakeholder guide", "interview questions for the client team", "discovery interviews", or "questions for [role like CEO, VP, marketing director]" — even if they don't explicitly call it a skill. The output is a formatted .docx matching the Infinum/ETR stakeholder interview style — participant list at the top, shared intro script, then a tailored per-person question set for each interviewee organized into subsections by topic. Cowork-ready — the .docx is produced by the bundled python-docx generator, which runs on Cowork's built-in office toolchain.

Use this skill to create a User Interview Guide (or User Interview / Usability Test Guide) for a research project. Triggers whenever a user wants to: write an interview script, create a user interview guide, build a research plan with screener questions, draft an intro script for user interviews, create a usability test plan, or prepare for qualitative research sessions. Also trigger when the user says "interview guide", "interview script", "research plan", "screener", "usability test plan", "user testing plan", or "write questions for user interviews" — even if they don't explicitly call it a skill. The output is a formatted .docx on the Infinum brand (structured sections, red accent, Infinum logo in the page header). Cowork-ready — the .docx is produced by the bundled python-docx generator, which runs on Cowork's built-in office toolchain.

Make a Figma design system AI-readable and MCP/Code-Connect-ready so code generation produces correct, on-brand code. The Infinum team standard for the exact structural moves — token architecture and scopes, component/layer/token naming, property wiring, structural consistency, in-file documentation — that make a library legible to AI tools (Claude, MCP, Copilot, Cursor) and clean to hand off to developers. Use when setting up or auditing a design system; naming a token, component, variant, property, or layer; defining enums or booleans; wiring component properties; checking structural consistency; or preparing a library for AI code generation. This is the executable build layer, not a conceptual primer. Platform-neutral: casing, state vocabulary, and token→theme mapping are resolved by a platform binding skill (e.g. flutter-m3-conventions) or the project CLAUDE.md — see the Platform Binding section. Cowork-ready with the Figma remote MCP connector enabled — the build/audit steps run through `use_figma` (writ

Use when building, organizing, or auditing screen and user-flow files in Figma so MCP/AI tools can navigate screens, read the flow graph, and generate correct screen-level code. Triggers on: screens file, wireframes, user flow, prototype connections, prototype reactions, frame naming, screen states, flow handoff, MCP navigation. Pairs with ai-ready-design-system (which covers the component library, not the assembled screens). Cowork-ready with the Figma remote MCP connector enabled — the build/audit steps run through `use_figma` (write-to-canvas), a remote-server tool reached over the agent's MCP transport rather than the local Dev Mode bridge; pending live verification. The naming and flow guidance itself reads fine anywhere.

Flutter Material 3 platform binding for Infinum's ai-ready-design-system skill. Resolves the casing, property-name, state-vocabulary, semantic-color naming, and token→theme decisions that ai-ready-design-system leaves open, and provides the full Flutter ColorScheme / TextTheme mapping required for Figma → Flutter code generation. Use ALONGSIDE ai-ready-design-system whenever the project targets Flutter or Material 3. Triggers on: Flutter, M3, Material 3, ColorScheme, TextTheme, Dart, mobile design system. Cowork-ready.

Due-diligence review of a new third-party dependency before you add it to a project — answers "should we take this dependency at all?". Checks necessity vs. native/existing alternatives, license (and relicensing risk), maintenance health, governance and bus factor, security track record, adoption signals, and transitive footprint, then returns a scored Adopt / Adopt-with-caution / Avoid / Don't-add verdict. Use before adding a library, when choosing between competing packages, or when the user mentions /security-check:dependency-adoption-review. Hands the deep supply-chain/malware pass off to system-package-audit. Not Cowork-ready — needs `gh`, package-registry and deps.dev egress, and optionally local package managers.

Supply-chain security audit of a system/OS package or globally-installed CLI tool (Homebrew, apt, and global npm/pip/cargo/gem installs) before you install or upgrade it — checks known CVEs, maintainer/ownership changes, install scripts, source-vs-registry integrity, the version diff, and typosquatting. Use before installing or upgrading a system package or global tool, or when the user mentions /security-check:system-package-audit. For a project's lockfile dependencies use dependency-adoption-review (before adding one) or vulnerability-report-triage (for reported vulns). Not Cowork-ready — requires local package managers (`brew`/`npm`/`pip`/etc.) and registry egress.

Triage reported vulnerabilities in a project's dependencies (Dependabot, GitHub Advisory, or an in-house weekly security report) for SOC2/compliance deadlines. Detects the tech stack, classifies each item by production-vs-development impact and direct-vs-transitive placement, judges whether it actually applies to this codebase, rates upgrade effort, scores confidence, and emits ready-to-use handoff artifacts (dismissal rationale, task/PR descriptions). Use when the user pastes a Dependabot/Revisor vulnerability report, shares a CVE/GHSA to assess against a project, shares a Slack channel/message link where a report was posted, asks to triage security alerts, or mentions /security-check:vulnerability-report-triage. Produces a report only — makes no repo changes. Not Cowork-ready — needs local package managers, `gh`, and registry/advisory egress.

Audit every plugin in this marketplace for Claude Cowork compatibility. Updates the plugins table in MARKETPLACE.md with a Cowork column and appends a status suffix to each skill's frontmatter description. Contributor-only skill — lives in `.claude/skills/`, not shipped via the marketplace. Use when adding or revising a plugin, or when refreshing Cowork readiness status. Triggers on "check cowork readiness", "audit plugins for cowork", "/cowork-readiness-check".

Scaffold a new plugin, add components to an existing plugin, or edit an existing plugin's content. Covers skills, MCP servers, slash commands, subagents, and hooks. Handles marketplace registration, semver bumps, and Cowork re-classification so the metadata never drifts from the code.

Audit Claude Code setup for vulnerabilities, malicious code, prompt injection, and security issues in plugins, skills, MCP servers, hooks, and permissions. Not Cowork-ready — reads `~/.claude/` outside the workspace mount.

Generate a Product Requirements Document (PRD) in Markdown. Use when the user asks to create a PRD, write product requirements, define a new feature, or mentions /create-prd. Cowork-ready.

Download Figma screenshots to disk. Use when the user wants to save Figma frame screenshots as image files. Triggers on "download Figma screenshot", "save Figma screenshot", "figma screenshot to file", "figma to docs". Not Cowork-ready — hits `localhost:3845` and `api.figma.com`, both unreachable from the sandbox.

Deploy the app to selected targets (e.g. staging, UAT, production, store) by wrapping the `app-deploy trigger` CLI — resolves environments from `.deploy-options.sh`, assembles a changelog, and confirms before deploying. Use when the user wants to deploy, release, or ship a build, trigger a CI deploy, or mentions `app-deploy` or `.deploy-options.sh`. Not Cowork-ready — requires the local `app-deploy` CLI and runs git against the project working tree.

Review pull requests using the laws and rules from "Code Simplicity" by Max Kanat-Alexander. Use this skill whenever reviewing a PR, doing a code review, evaluating a diff, checking a merge request, or when someone asks you to review code changes. Also use when someone asks for feedback on code quality, maintainability, or design decisions in the context of changes being proposed. This skill applies the six laws of software design as a structured review lens. Cowork-ready.

Investigate bug tasks from Productive. Fetches task details, attachments, and comments via MCP, explores codebases (including companion apps), and generates ranked hypotheses with code evidence. Use when the user shares a Productive task URL, mentions a Productive bug, or says /productive-debug. Cowork-ready.

Clean up the local repo after a pull request merges — switch to the PR's base branch, pull, confirm the merge landed, then delete the merged local branch (and its git worktree, if one was used) and offer to remove the feature's progress note. Use whenever a PR has just merged and the user wants to clean up, tidy up, prune the merged branch or worktree, get back onto a fresh base branch, or "do the cleanup" — even if they don't spell out every step. Not Cowork-ready — needs the local `gh` CLI and a persistent local git checkout, and reads/prunes `~/.claude/progress/` outside the workspace mount.

Update a local, disposable progress file for the feature/task you're working on, so the next session starts with full context. Files live at `~/.claude/progress/<project>/<feature-slug>.md` — local on disk, never committed, deletable once the feature ships. Use when the user says "wrap up", "update progress", "end of session", "/progress", or signals they're stopping. Also use proactively when a session is clearly concluding — final commit landed, feature verified, user says "great, that's done." Not Cowork-ready — needs a persistent local filesystem for cross-session continuity; Cowork's ephemeral sandbox doesn't preserve it.

Use when: (1) implementing UI from a Figma design, (2) writing or updating snapshot tests, (3) validating UI changes against a design. Enforces the loop: implement with existing components → snapshot → fetch Figma → multimodal compare → fix or STOP-and-ask. Not Cowork-ready — runs the project's snapshot tests in the user's local dev environment.