functional-claude

Use this skill when creating a git branch for a Linear or GitHub issue, writing a PR description, opening a pull request, or linking a PR to its tracked issue. Trigger phrases "create a branch", "new branch for this issue", "branch for

Use this skill when integrating, reading, or updating a project's conventions.md file — the document that captures house style for issue titles, labels, branch naming, PR descriptions, handoff phrasing, and review etiquette. Trigger phrases "set conventions", "load conventions", "where are the conventions", "what are our conventions", "add a convention", "edit conventions.md", "/pm-conventions", "the conventions say", "our team uses <X> format", "project conventions", "project title format". Also use proactively when another pm-* skill (pm-issues, pm-review, pm-improve, pm-branches, pm-handoff, pm-agent, pm-projects, pm-project-review) is about to write or evaluate text and a conventions file exists at `<repo>/.claude/pm/conventions.md` — the conventions must be loaded and applied before the skill writes anything user-facing.

Use this skill when the user asks to "find duplicate issues", "clean up duplicates", "what dupes are in the backlog", "/pm-dedup", or after a /pm-status briefing flags likely-dup clusters. Runs the `duplicates` lens against the team cache, has the agent judge each cluster, then offers merge / relate / close per cluster. Powered by the shared dedup engine in `hooks/lib/dedup.js`.

Use this skill when the user wants to report a bug, an unexpected result, or an improvement idea about the project-manager plugin ITSELF (or one of its pm-* skills) to the functional-claude maintainers — or when the agent has just hit a project-manager failure (a pm-* CLI error, a wrong/empty briefing, a crash, a clearly-incorrect result) and should offer to report it. Trigger phrases "report a bug in pm-review / pm-notes / any pm-* skill", "this plugin is broken", "pm gave the wrong answer", "send feedback about project-manager", "tell the functional-claude team", "/pm-feedback", "file a plugin issue". The defining cue is that the target of the complaint is the plugin or a named pm-* skill, not the user's own product. Assembles a README-shaped report (plugin + version, repro, expected vs actual, safe environment), scrubs every credential via the tested `hooks/lib/feedback-report.js` guard, previews it, then delivers — email to the Linear intake address (via resend-cli), GitHub issue fallback, or copy-paste d

Use this skill when the user wants to hand off work to another person or to the next stage of the lifecycle. Trigger phrases "hand this off to", "give this to", "I'm OOO", "passing this to", "covering for", "ready for release", "ready for QA", "ready for review", "release notes", "deploy handoff", "write a handoff", "/pm-handoff". Produces recipient-facing briefs with four required blocks (summary, what's done + how to use it, what's NOT done + next steps, open questions). Routes through configured channels (Linear, GitHub, markdown, chat/email).

Distinct from `pm-review` (which *scores* whether an issue has the right structural shape), this skill *adds* project-specific context to an existing Linear or GitHub issue — relevant files, recent commits, owning modules, best-practice references, prior-art / related issues, and clarifying questions the author should answer before work starts. Use it when you want to give an issue more material to work from, not when you want to grade it. Trigger phrases "improve this issue", "enrich issue <ID>", "add context to this issue", "what's missing from this issue", "any relevant code for this issue", "research this issue", "qna this issue", "/pm-improve". Also use proactively after `pm-review` flags structural gaps that hint at missing context. Produces a draft enrichment; with `--apply`, posts it as a comment on the issue. Safe to re-run as repo state drifts — the marker mechanic replaces rather than stacks.

Use this skill when creating, updating, or closing **an issue** (a bug, feature, task, or spike) in Linear or GitHub; when the user describes a specific untracked **issue** that should be filed; when drafting issue content; or when the user says "create an issue", "log this issue in Linear", "add this issue to Linear", "open a github issue", "file an issue", "create issue

Track a SINGLE running parent issue, epic, or project commit-by-commit — a focused phase ledger of which child issues are done, in progress, and next, with each child's shipping commit aligned to its phase. Use whenever the user is working a parent/epic/project and asks "where am I on this", "what's left on <ID>", "show progress on this epic", "what's next here", "pick up where I left off", "resume <ID>", or wants commits mapped to phases. Also use to re-orient when resuming work on a tracked parent in a fresh session. This is DEPTH on one parent — distinct from pm-status (whole-backlog breadth) and pm-report (stakeholder documents). When the user names or implies a specific parent/epic/project and wants its internal progress, prefer pm-ledger even if they say the word "status".

Use this skill when the user shares a meeting transcript or notes file and wants to know which tracked issues the conversation touched, what adjustments the discussion implies (status changes, scope updates, comments, sub-issues, closures, pivots), or wants a markdown report of proposed changes. Trigger phrases "process this meeting", "any updates from this transcript", "match this transcript to issues", "review my meeting notes", "summarize what we decided", "/pm-notes". Also use proactively when the user shares a .srt, .vtt, or transcript-shaped markdown file in a context where the project-manager plugin is configured — even if they don't explicitly ask for adjustment matching, offer to run pm-notes against it. Builds on the existing project-manager workspace cache, dedup.js similarity, and conventions/vocabulary customization layers. After rendering the dry-run report it can optionally apply accepted proposals (Step 8) by routing each through the existing pm-* verbs/skills, with provenance stamped on every

Use this skill when the user says "organize this issue", "place this issue", "where does this belong", "set status and project", "assign this issue", "file it under the right workstream", "/pm-organize", or asks how to route a workable issue into the workflow. Takes a workable issue (one that already has a type + exec-mode from pm-triage) and PLACES it — sets status, project/milestone, parent, assignee, and workstream — with tiered write-safety (auto-safe for status + existing-workstream; reversible for project/milestone/parent; always-confirm for assignee reassignment + new-workstream + new-project). Consumes the team roster via rankAssignees for assignee recommendations and the conventions

Use this skill when the user changes direction mid-feature, describes a significant scope change, says the approach isn't working, wants to abandon the current approach, or says "we need to rethink this", "let's change direction", "this isn't right", "pivot", "different approach". Also use when the user's current work no longer matches the active tracked issue (Linear or GitHub).

Use this skill to prepare an existing hitl (human-in-the-loop) issue for autonomous execution and promote it to afk — interactively resolving the human-judgment gaps (design decisions, ambiguous file targets, untestable acceptance criteria), writing the resolved answers into the issue body, and retagging hitl→afk once it clears an explicit readiness bar. It is the bridge between pm-triage (which assigns the hitl/afk label) and the autonomous pm-issue-to-pr pipeline (which only works the afk backlog). Trigger when the user says "prep this issue", "prep the hitl backlog", "make FUNC-12 afk-ready", "promote this to afk", "/pm-prep", or whenever an already-hitl issue needs to be specified well enough to run unattended; also proactively before handing a hitl issue to pm-issue-to-pr. NOT for classifying a brand-new issue as hitl vs afk at creation (that is pm-triage), and NOT for issues already labeled afk (nothing to promote).

Use this skill when the user says "estimate skills", "what is X good at", "infer proficiency", "populate the roster from history", "estimate the team's skills", "/pm-proficiency", or wants to derive a member's skill areas from their issue and code history. Estimates a member's skill areas from three weighted evidence sources — domain labels on issues assigned to them (strongest), labels on issues they commented on (participation), and code areas they touched in git (weakest) — buckets them coarsely as strong or familiar, and writes them into team.md preview-then-apply. Never writes without confirmation. Distinct from pm-team (which manages manual curated edits to the roster) and pm-organize (which assigns issues using the roster).

Enrich a project (a Linear Project / GitHub Milestone) with repo context (owning modules, related code, recent commits), related projects + prior art, best-practice references, risk surfacing, and clarifying Q&A. Pipelined after pm-project-review or standalone. --apply posts as comment (Linear) or marked description block (GitHub). Operates on a project, not an individual issue — issue improvement lives in pm-improve. Trigger phrases — "improve this project", "enrich this project", "add context to the project", "research the project", "/pm-project-improve".

Decompose a project (a Linear Project / GitHub Milestone) into milestones and draft its constituent issues. Bridges the project tier to the issue tier — each drafted issue is filed THROUGH pm-issues (so issue templates, type/exec-mode labels, and the pm-issue.js create-gate all still apply). Linear creates native milestones via linear milestone create; GitHub records phases as a checklist in the milestone description (documented degradation — no sub-milestones). Operates on a project, not an individual issue. Trigger phrases — "plan this project", "break down the project", "decompose the project into issues", "what issues does this project need", "/pm-project-plan".

Lint a project (a Linear Project / GitHub Milestone) against its registered project-type template — checks the type marker is present, the lead is assigned (Linear; skipped on GitHub Milestones), a target date exists, every required section from the manifest is substantive (non-placeholder), milestones are defined, and child issues are scoped. Optional --apply posts findings as a comment (Linear) or appends a versioned marked block to the milestone description (GitHub). Operates on a project, not an individual issue — issue review lives in pm-review. Trigger phrases — "review this project", "review project CHK", "is this project ready", "audit the project", "lint the project", "/pm-project-review".

Tag-keyed template registry for project types (feature-epic, migration, research-track, integration). Mirrors pm-templates one tier up — the registry is consulted by pm-projects create (to scaffold a project body) and by pm-project-review (to lint required sections). Operates on a project (a Linear Project / GitHub Milestone), not an individual issue. Trigger phrases — "project template", "template for an epic", "template for a migration project", "list project templates", "add a project template", "register a project type", "/pm-project-templates".

Create, update, and close out a project (a Linear Project / GitHub Milestone) — the project-tier CRUD bundle. Mirrors pm-issues one tier up. Use when the user says "create a project", "new Linear project", "file a project", "update the project target date", "close out the project", "wrap up the project", "archive the project", "/pm-projects". This operates on a project (a Linear Project or a GitHub Milestone), NOT on an individual issue — issue CRUD lives in pm-issues. Routes child issue filing through pm-issues so all issue-tier discipline (templates, labels, the pm-issue.js create-gate) still applies.

Use this skill when the user asks for a "status report", "what changed", "what's stuck", "what shipped", "velocity report", "what's next to pick up", "review prs", "open prs", "ready to merge", "is this project on track", "project health", "are projects at risk", "which projects are off track", or any project status summary that should be persisted as a document or sent as email. **Eight profiles** — movement (default — what changed), stuck (what's blocked), throughput (velocity vs prior), next-up (what's ready), exec (one-pager standup), prs (open-PR review), full (legacy daily/weekly behavior), **project-health** (per-project on-track / at-risk / off-track classification with milestone burndown — for project-tier health questions like "is this project on track" or "which projects are at risk"). Produces Markdown plus HTML and/or PDF; optional handoff to resend-cli for delivery.

Use this skill when reviewing the quality and completeness of an existing Linear or GitHub issue — does it have a type tag, does it match the template for that type, are the required sections filled, is the acceptance criteria testable. Trigger phrases "review this issue", "review issue <ID>", "is this issue ready", "check the issue", "audit this issue", "/pm-review", "review the bug I just filed", "lint the issue". Also use proactively when an issue is about to be picked up for work (handoff into "In Progress") and the operator wants a sanity pass first. Produces a structured review report; with `--apply`, posts the findings as a comment on the issue.

Use this skill when the user wants to capture, render, or rerun reusable CLI command sequences for the project — phrases like "save this as a pm script", "run the daily pull", "rerun that linear query", "make this a script", "/pm-script <name>", "list pm scripts", "create a script for this report". Scripts are bash bodies with {{var}} substitution, stored locally so the same data pull or workflow can be replayed deterministically across sessions. Particularly useful for repeatable Linear queries, multi-team data pulls, and feeding the daily/weekly reports.

Use this skill when the user asks to "set up project manager", "register this project", "configure pm", "onboard this repo", "configure Linear API key", "linear api key", "linear authentication for project-manager", "set up linear access", "configure linear api access", "initialize conventions", "set up conventions.md", or invokes the `/pm-setup` slash command. Also use proactively when the SessionStart hook nudges the user that "project-manager" is installed but no projects are configured and they ask how to fix it. Guided wizard that registers a repo as a managed project, configures Linear API access (personal API key, no CLI install required), and optionally initializes a `conventions.md` file.

Work on a spec as a grounded decision ledger — capture decisions from notes or a blank start, drive open decisions to closure one at a time (grounding each against the real code), and watch for drift as the code changes. Use when the user says "work on a spec", "capture this decision", "drive the spec decisions", "ground this spec", "what's still open on the spec", "is the spec still true", "/pm-spec". This is the UPSTREAM of pm-projects / pm-issues — capture and ground decisions locally, publish to Linear for the comment-resolution alignment cycle, then decompose to tracked issues.

Use this skill when the user asks "where are we", "what's in progress", "what should I work on next", "project status", "catch me up", "what's open", "what's stale", "what's stuck", "anything dragging", "old in-progress issues", "what's been sitting", "what needs triage", "any untriaged issues", "what's not labeled", "what needs my attention", or "anything I missed". Provides a cache-first session briefing with in-progress issues (with HITL/AFK execution-mode prefix), next suggested work, **stale-issue detection** (issues stuck in-progress longer than --stale-days, default 30), a **triage view** with four buckets (in-triage / untriaged / unknown-tag / needs-info), and delta sync on demand. Supports --refresh for full re-pull. Do NOT include past session history unless the user explicitly asks. This skill is whole-backlog BREADTH ("across everything, where are things?"). For DEPTH on one named parent/epic/project — its child issues' commit-by-commit progress, a phase ledger, or resuming where you left off — us

Use this skill when the user says "sync the team", "who's on the team", "show the roster", "set my skills", "/pm-team", or asks about team members, member skills, or assignee recommendations. Manages the team roster — Linear-synced identity (gitignored cache) paired with a curated checked-in team.md of handle + skills + owns + aliases — merged at read time by handle. The roster is the data source for pm-organize assignee recommendations and pm-notes speaker matching.

Use this skill when creating, editing, or removing **issue** templates (bug / feature / task / spike), resolving which template applies to a given issue type tag, customizing the issue-template registry for a project, or when another pm-* skill needs the body of an issue template. **For project-type templates** (feature-epic / migration / research-track / integration), use `pm-project-templates` instead. Trigger phrases "issue template", "template for a bug", "list issue templates", "add an issue template", "edit the bug template", "remove the X template", "what sections should bugs have", "what issue template should I use", "register a new issue type", or when pm-issues / pm-review / pm-improve need a template body. Also use proactively when the user describes a bug / feature / task / spike and the matching tag has no template registered. Tag-keyed registry; in-repo `.claude/pm/templates/` is canonical, plugin defaults are the fallback.

Use this skill to triage a raw or untriaged issue — one that lacks a type tag, an execution-mode label, or template structure — and turn it into workable, labeled, reviewed work. pm-triage orchestrates classification (pm-templates), structural review (pm-review), and enrichment (pm-improve), then applies the type and hitl/afk labels on the operator's confirmation, and hands the now-workable issue off to pm-organize so it leaves the Triage state instead of parking there. It is the action counterpart to pm-status's triage view. Trigger whenever the user says "triage this issue", "triage NTH-42", "triage the backlog", "clean up untriaged issues", "what needs triage", "/pm-triage", or when pm-status has just surfaced Untriaged / Unknown-tag / Needs-info buckets and the operator wants to act on them. Also use it proactively after a pm-status briefing flags untriaged work, and whenever an issue clearly needs labels plus a structural pass before it can be picked up — even if the user never says the word "triage".

Use this skill when the user says "project manager", "pm", "where are we", "what's in progress", "what should I work on next", "project status", "open issues", "what's next", "track this work", "review this issue", "improve this issue", "what are our conventions", "create a project", "plan this project", "project health", or asks about Linear issues, GitHub issues, GitHub PRs, or any issue tracking for the current project. Also use proactively when the user describes work that doesn't appear to be tracked, when starting new work on main/master, when branch naming suggests untracked work, or when the user has a spec they're about to file as a Linear initiative or GitHub project. Routes to focused pm-* skills (status, issues, templates, review, improve, conventions, branches, report, spec, handoff, setup, projects) based on the task. For autonomous multi-step work, delegate to the `pm-agent` sub-agent.

Decomposes the current plan, idea, or technical claim into atomic, individually-checkable assumptions and pressure-tests each against real evidence — project files, registered SME repos, available MCPs, CLIs, and live docs — instead of letting them ride into implementation. Iterative — walks the decision tree one branch at a time, probing before asking, and optionally writes resolved decisions into `CONTEXT.md` / `docs/adr/`. Use PROACTIVELY whenever the user is mapping out an approach, sketching a plan, deciding on architecture, or making claims about external systems (APIs, libraries, services, schemas), even if they haven't asked to verify anything. Trigger on planning language ("I think", "we should", "we'll need", "let's just", "the X does Y", "this works because Z") or explicit invocations ("ground this", "pressure-test this", "is this real", "what am I missing", "stress-test this plan"). Returns a structured resolved/open/contradictions report.

This skill should be used when the user asks to review a completed team's process, run an after-action review, or evaluate team effectiveness. Use this skill when the user says "after action review", "AAR", "process review", "team retrospective", "review team process", "how did the team work", or at the prompt after a team completes its work. Distinct from `/evaluate-spawn` (output quality). AAR evaluates team process. Both can run in the same session.

Use when the user is NEW to Claude Code agent teams or asks high-level questions about what they are, when to use them, or how they compare to subagents. Triggers: "how do agent teams work", "what are agent teams", "agent teams vs subagents", "should I use a team for this", "are agent teams enabled". Do NOT trigger for choosing a specific team blueprint (route to `team-blueprints`) or managing an active team (route to `team-coordination`). This skill is the onboarding / discovery entry point only.

This skill should be used when the user asks to evaluate a completed team spawn session, capture session learnings, or review how a spawn went. Use this skill when the user says "evaluate spawn", "evaluate-spawn", "how did the spawn go", "capture learnings", "review spawn session", "spawn retrospective", or at the soft prompt after a team completes its work. This is a voluntary post-spawn evaluation with profile-based questions tailored to all spawn types (build, think, create). Build profile asks up to 4 questions (3 explicit + 1 conditional gate bypass); Think and Create profiles ask up to 3 questions (2 explicit + 1 gate bypass). Hard cap includes auto-derived scenario coverage for Build.

Use when the user wants a pre-designed agent team configuration for a specific development phase. Triggers: "research team", "feature development team", "code review team", "debug team", "design team", "planning team", "roadmap team", "productivity team", "brainstorming team", "team blueprint", "team template", "spawn a team for [development phase]". Provides 8 ready-to-use team blueprints across the application development lifecycle. Routes to the unified spawn commands (`/spawn-build`, `/spawn-think`, `/spawn-create`).

Use when managing an ACTIVE agent team — coordinating tasks between teammates, handling team messaging, plan approval, delegate mode, display modes, or graceful shutdown. Triggers: "task management", "team communication", "delegate mode", "plan approval", "shutdown teammates", "team messaging", "how do I manage my team", "feedback gate", "dedup guard". Do NOT trigger for choosing a team blueprint or describing what agent teams are at a high level — those route to `team-blueprints` and `agent-teams` respectively. This skill is for running a team that's already spawned.

Use when the user asks about personas for agent teams, deep behavioral profiles for teammates, the productivity loop, or any of the 8 named personas (Auditor, Architect, Analyst, Refiner, Compounder, Facilitator, Visionary, Realist). Triggers: "personas", "behavioral profiles", "productivity loop", "auditor persona", "architect persona", "analyst persona", "refiner persona", "compounder persona", "facilitator persona", "what personas are available", "how do personas work". Provides 8 reusable persona definitions that add deep methodology, scoring criteria, and interaction patterns to agent team teammates.

Guide for creating specialized subagents with AGENT.md files. Use when the user asks to "create an agent", "write AGENT.md", "subagent", "specialized agent", "agent tools", or needs guidance on agent design.

Overview of Claude Code plugin development with component routing. Use when the user asks to "create a plugin", "build a plugin", "plugin structure", "how do plugins work", or needs general plugin guidance.

Guide for creating user-invocable slash commands. Use when the user asks to "create a command", "slash command", "write a command", "$ARGUMENTS", "dynamic arguments", or "@ file references".

Guide for creating event-driven hooks that validate, log, or modify Claude's behavior. Use when the user asks to "create a hook", "add PreToolUse hook", "validate tool use", "hook events", "hooks.json", or mentions hook events (PreToolUse, PostToolUse, Stop).

Guide for bundling MCP servers with plugins. Use when the user asks to "add MCP server", "integrate MCP", "external tools", ".mcp.json", or "Model Context Protocol".