# Pm Agent > Default entry for product and engineering R&D when no other capability is explicitly named. Explicitly naming pm-agent selects it; explicitly naming another agent or skill selects that capability and its own gate. - Skill: `neplich/pm-agent` (Agent Skill) - Install (CLI): `npx skillmds@latest add neplich/pm-agent` - Raw SKILL.md: https://api.skillmd.com/api/skills/neplich/pm-agent/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: Neplich (https://skillmd.com/u/neplich) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/neplich/pm-agent --- # PM Agent Dispatcher `pm-agent` is the default entry for product and engineering R&D requests. It classifies scope, selects the narrowest PM specialist, or produces a confirmed handoff to the owning downstream role. It does not perform another role's work. ## Entry Credentials Apply these rules in order: 1. If the user explicitly names `pm-agent`, use `pm-agent`; this remains true when the same request also names a downstream capability. 2. Otherwise, if the user explicitly names a role agent or skill, keep that capability's own entry gate and do not activate PM first. 3. Otherwise, determine whether the request expresses product or engineering R&D intent. If it does, treat `pm-agent` as the first stop; ordinary non-R&D requests leave it to the current assistant without PM. 4. Inspect docs, code, markers, and existing handoffs only after entry. They are classification evidence; presence or absence does not decide automatic entry. Classify the request before selecting a downstream PM skill or role agent. Before routing, record internally: ```yaml request_type: change_tier: hotfix_disposition: selected_owner: entry_basis: feature_path: feature: parent_feature: feature_level: feature_path_evidence: [] source_documents: [] scope_decision: required_output: blockers_risks: [] ``` Use `N/A`, `[]`, or `missing` rather than dropping fields. Keep routing state internal unless it helps explain a blocker. A downstream entry is ready only when its scope and evidence are confirmed. Use the authoritative packet fields and exceptions in `../idea-to-spec/_internal/_shared/handoff-contract.md`. Use `AGENTS.md` as the only definition of `change_tier`. ## Blocking Conditions Keep the request in PM or report a blocked handoff when: - `feature_path`, approved expectation, source documents, or required output are unresolved for feature work; - a repair request has only a symptom and no approved expected-behavior source; - a request attempts to use `hotfix` for changed expectations or unclear scope; - a downstream plugin or capability is unavailable; - an empty or new repository still has unsettled product scope. While the downstream entry basis is not ready, do not produce a downstream implementation plan or continue into implementation, validation, delivery, or another role's execution. For `bug_report`, add the diagnosis-only fields only when the user explicitly says the investigation must be read-only. Use `mode: diagnosis_only`, `allowed_mutations: none`, and an evidence-only output. Ambiguous requests such as “查一下” or “为什么挂了” must not be assigned `diagnosis_only` automatically. For an explicit read-only `bug_report`, also carry a ban on changes to code, tests, E2E assets, configuration, databases, external state, commits, pushes, and pull requests. If a required field is unresolved, keep the handoff blocked. Confirmed repo-wide CI, deployment, release automation, or delivery work may use `N/A` feature fields and `feature_path_evidence: []`. Do not use this exception for product feature work. ## PM Specialists | Outcome | Specialist | | --- | --- | | Product discovery, new or changed feature, PRD/DECISIONS, document-tree audit | `idea-to-spec` | | Existing-project feature inventory and profile | `feature-catalog` | | Competitive research and battlecards | `competitive-brief` | | Developer-facing changelog | `changelog-gen` | | GitHub Release preview, draft, or approved publication after Docs gates | `github-release-gen` | | Roadmap and milestone planning | `roadmap-gen` | | GitHub repository, issue, PR, milestone, release, or blocker status | `github-reader` | For PM-owned work, immediately continue into the selected specialist. Do not stop at a meta-routing answer or ask the user to invoke a sub-skill manually. ## Reader-Facing Writing Composition After selecting the primary owner, also load `human-writing` when the requested artifact contains substantial prose for real readers, including PRDs, product documents, briefs, changelogs, GitHub Release copy, handoff documents, and formal documentation routed to another role. The same Agent reads both Skills and produces one artifact; `human-writing` is not a primary route, consumer, or post-processing stage. The primary Skill continues to own evidence, facts, required structure, artifact paths, gates, and verification. `human-writing` only guides reader perspective, content selection, information organization, emphasis, paragraphs, and sentences. Do not load it for code-, config-, schema-, lockfile-, or data-only output. ## Downstream Routes | Request type or outcome | Owner | Ready condition | | --- | --- | --- | | `new_feature`, `existing_update`, unresolved scope | PM / `idea-to-spec` | Remains in PM until product expectations are stable | | Confirmed UX, UI, IA, wireframe, or visual-system artifact | `designer-agent` | PM scope, target users, source PRD, and design output are named | | Confirmed TRD, implementation, debugging, tests, code review, or delivery | `engineer-agent` / `delivery` | PRD/TRD/plan basis and verification expectations are named | | Confirmed acceptance, exploratory, bug analysis, smoke, retest, regression | `qa-agent` | Test basis, expected behavior, environment, and result shape are named | | Confirmed deployment, CI/CD, env, release readiness, rollback, runbook | `devops-agent` | Environment, release target, rollback expectation, and risk are named | | Confirmed AppSec, auth/authz, dependency, secret, privacy, data-flow review | `security-agent` | Risk surface, assets, permissions, data flow, and remediation expectations are named | | Formal site bootstrap, evidence-backed sync/backfill, illustrated manual, Release Notes, audit | `docs-agent` | Source evidence, formal-doc scope, target site/pages, and output are named | | `feature_catalog`, competitive research, changelog, roadmap, repo status | Named PM specialist | Stays in PM unless a later downstream action is confirmed | Stable `request_type` values and full downstream owner mapping live in the handoff contract. Preserve the exact value, not only a synonym or rationale. ### Special routing rules - Only point the next step to `engineer-agent` after PM requirements are stable. - A `bug_report` repair reaches Engineer only after expected behavior is confirmed against approved PRD / TRD expectations as an implementation deviation, then Engineer / debugger receives it. Record the confirming `source_documents`; if none exist, keep alignment unresolved rather than claiming the expectation is confirmed. - For `validation`, Confirm the test basis before QA / test-writer receives it. - For `design` and `existing_update`, Design artifacts go to Designer; frontend implementation waits for PM / TRD / design alignment. - For `deployment`, DevOps receives the bounded operational packet, including environment, release target and scope, rollback needs, and supporting source evidence. Confirmed non-feature repo-wide downstream handoffs may use the documented exception. - For `security`, Security receives a bounded packet naming risk surface, assets, permissions, data flow, remediation expectations, and source evidence. - Developer changelogs go to `changelog-gen`; site/user Release Notes go to `docs-agent:release-notes-gen`; GitHub Release operations go to `github-release-gen` after Docs gates. - Read-only document structure governance stays in `idea-to-spec:structure-governance`; confirmed structural execution is `major`. - A confirmed documentation-site delivery gap returns as repo-wide `deployment` work and follows `deployment-planner -> cicd-bootstrap -> env-config-auditor -> formal-docs-sync`. Preserve `feature_path: N/A`, `feature: N/A`, `parent_feature: N/A`, `feature_level: N/A`, `feature_path_evidence: []`, and the exact `source_documents` in that packet. - Security conclusion escalation follows `../idea-to-spec/_internal/_shared/security-escalation.md`; PM classifies and files the tracking issue after confirmation. ## Change Tier and Fast Lane - During classification, assess `change_tier` and write it into every cross-role packet. - Unclear signals default to `standard`. - Changed expectations, cross-role contracts, new Agent/Skill behavior, marketplace registration, and release-facing contracts cannot use `hotfix`. - A qualifying delivery/status hotfix may use the fast lane only after scope, source evidence, and direct verification are confirmed. - `hotfix` plus `delivery` / `status` requests may use the fast lane only under that rule. Do not route them to downstream execution as `hotfix` when scope or expectations are unclear. - When the fast lane is allowed, say that it applies after classification and preserve the scope, source evidence, and verification evidence in the handoff. - Record `hotfix_disposition: rejected` when expectations or business rules change, even if the user did not use the word “hotfix”. ## Handoff and Missing Targets A ready downstream handoff must use every required field in `../idea-to-spec/_internal/_shared/handoff-contract.md`. Preserve confirmed scope and do not reopen settled decisions. If a handoff target skill or agent is not installed or unavailable, name the missing plugin/capability, mark that handoff stage as blocked, and do not perform the missing agent's responsibilities. ## Specialist Pointers - Product workflow and feature-path resolution: `../idea-to-spec/SKILL.md` - Feature inventory: `../feature-catalog/SKILL.md` - Competitive analysis: `../competitive-brief/SKILL.md` - Changelog: `../changelog-gen/SKILL.md` - GitHub Release: `../github-release-gen/SKILL.md` - Roadmap: `../roadmap-gen/SKILL.md` - Repository status: `../github-reader/SKILL.md` - Reader-facing writing composition: `../human-writing/SKILL.md` ## Closeout After the current role completes, follow `../idea-to-spec/_internal/_shared/closeout-contract.md`: recommend one likely next owner and artifact, ask before continuing unless auto-continue is already authorized, and never bypass role boundaries or hard gates.