From pm-copilot
Use this skill when the user asks to "write an engineering brief", "brief the engineering team", "write a technical spec handoff", "summarize this PRD for engineers", "engineering kickoff doc", "write a spec for the dev team", "help me communicate this feature to engineering", or needs to translate a product decision or PRD into an engineering-ready communication that gives engineers the context to make good technical decisions.
npx claudepluginhub productfculty-aipm/pm-copilot-by-product-facultyThis skill uses the workspace's default tool permissions.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Executes pre-written implementation plans: critically reviews, follows bite-sized steps exactly, runs verifications, tracks progress with checkpoints, uses git worktrees, stops on blockers.
Guides idea refinement into designs: explores context, asks questions one-by-one, proposes approaches, presents sections for approval, writes/review specs before coding.
You are writing an engineering brief — the document that translates a product decision into the context engineers need to make good technical choices, ask the right questions, and estimate accurately.
The goal is not to tell engineers how to build — it's to give them the "why" so they can make better decisions about "how". Engineers who understand the problem are more likely to propose better solutions than the PM thought of.
Read memory/user-profile.md for stack context (issue tracker, code repo, technical context if known). Read the PRD or feature description provided.
Context (why this matters): 2–3 sentences on the user problem being solved. Why now? What signals drove this prioritization? Engineers who understand the problem often find better solutions than the PM specified.
What we're building: A plain-language description of the feature — not technical jargon, just what the user can do. Include key flows in numbered steps. Keep it close to the PRD.
What we're NOT building: Explicit out-of-scope items. This is the most important section for preventing scope creep. Each item should have a brief rationale (why it's excluded).
Success criteria: The measurable outcomes that define success. These are the product success metrics — engineers should know what their work is optimizing for, not just whether it shipped.
Acceptance criteria: The binary, testable criteria from the PRD. Engineers use these for implementation decisions and QA uses them for testing.
Technical unknowns (from PM perspective): The things the PM knows are uncertain from a technical perspective and wants engineering input on. This invites engineering into the problem, not just the solution.
Examples:
Decision points that need engineering input: Specific decisions where the PM needs engineering expertise. Be explicit about what kind of input is needed:
Timeline context: When this needs to ship, what drives the date (if anything), and how firm the date is. This helps engineering make scope-priority tradeoffs without needing to ask.
Definition of done: Engineering-level definition — what does "complete" mean for this work? Include: feature-flagged? In staging? In prod? All tests passing? Metrics instrumented?
Do NOT include in the engineering brief:
Produce the engineering brief. Offer to:
outputs/eng-brief-[feature]-[date].md