com um clique
parse
Convert a spec into a task breakdown (local, for review before syncing)
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Convert a spec into a task breakdown (local, for review before syncing)
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Co-create a customer interview guide using Mom Test principles
Transform a feature idea or stakeholder request into an outcome brief using a 4-stage framework: behavior hypothesis, risk identification, cheap experiment design, and metric definition. Use this skill when the user shares a feature idea, a stakeholder request, a PRD, a spec, or any document describing something to build and wants to pressure-test it before committing engineering capacity. Trigger on phrases like "outcome brief", "analyze this feature", "is this worth building", "test this idea", "brief this", "run the 4 questions", or when the user pastes a feature description and asks for critical analysis. Requires an input: a feature idea, document, or stakeholder request to analyze.
Produce a strategic intelligence report covering industry trends, competitive benchmarks, and opportunity mapping. Use when the PM wants market research, competitive analysis, or strategic landscape overview. Trigger on phrases like "research", "competitive analysis", "market landscape", "industry trends", or when the user wants to understand the competitive environment before building.
Conduct a structured PM interview to gather requirements, then write a complete spec document ready for development. Use this skill whenever a PM wants to spec out a feature, write up product requirements, plan what needs to be built, or turn a rough idea into a formal spec. Trigger on phrases like "spec out", "write a spec", "document requirements", "plan this feature", or when a PM describes something they want to build.
Push local tasks and tickets to GitHub Issues, Jira Cloud, or Asana
Create a standalone ticket (bug, improvement, or request)
| name | parse |
| description | Convert a spec into a task breakdown (local, for review before syncing) |
| argument-hint | <project> <feature-name> |
| model | sonnet |
| allowed-tools | Read, Write, AskUserQuestion |
| disable-model-invocation | true |
Arguments: $ARGUMENTS
Expected format: <project> <feature-name> (e.g., acme session-notes)
Parse $ARGUMENTS to extract project and feature-name. If either is missing, stop and tell the user:
"Usage: /pm:parse "
Read these files:
<project>/specs/<feature-name>.md: the spec to parse (required; stop if not found)<project>/CLAUDE.md: product and technical contextIf the spec does not exist, tell the PM: "No spec found at /specs/.md. Run /pm:spec first."
Check if <project>/tasks/<feature-name>/ already exists. If it does, ask the PM if she wants to regenerate it before continuing.
Before writing any task file, read the full spec and apply these checks:
Goal mapping: For each feature in the spec, check if it maps to a stated goal in the Problem Statement section. If a feature has no clear goal link, add a note in the task description and ask the PM to confirm it belongs in scope before writing that task.
Duplicate data: For each metric, total, score, or computed value in the spec, check if the same value already exists elsewhere in the product (as described in the spec or <project>/pm-config.md). If it does, flag it and ask the PM to confirm it is intentional before writing the task.
Create directory <project>/tasks/<feature-name>/.
Read the spec carefully. Break it into individual tasks. Each task should represent one clear unit of work a dev can pick up independently.
If .claude/overrides/rules/task-quality.md exists, Read and follow it; otherwise Read ~/.claude/pm/rules/task-quality.md.
If .claude/overrides/rules/frontmatter.md exists, Read and follow it; otherwise Read ~/.claude/pm/rules/frontmatter.md.
Rules for task breakdown:
spec_section to the exact section name.depends_on as a list of filenames for tasks that must come before (e.g., [build-onboarding-wizard.md]).status: local.Read .claude/overrides/templates/task.md if it exists, otherwise read ~/.claude/pm/templates/task.md. Use it as the output structure for each task file.
Name each task file using the task title in kebab-case: task-title.md, another-task.md, etc. No sequence prefix.
Write each task to <project>/tasks/<feature-name>/<filename>.md.
Run /pm:validate on all task files created. If any fail, fix them before finishing.
After writing all files, print:
Tasks created: [N]
task-title.md [S] Task title
another-task.md [M] Task title (depends on: task-title.md)
...
Warnings:
[Any L-sized tasks, missing acceptance criteria, etc.]
Next step: /pm:sync <project> <feature-name>