| name | eng-brief |
| description | 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. |
| version | 2.0.0 |
Engineering Brief
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.
Step 1 — Load Context
Read memory/user-profile.md for stack context (issue tracker, code repo, technical context if known). Read the PRD or feature description provided.
Step 2 — Engineering Brief Structure
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:
- "We want < 500ms latency for this action — is that feasible with the current [stack detail]? What would be the trade-off?"
- "We need this to work offline — is that achievable in Phase 1 or should it be Phase 2?"
- "The design calls for real-time updates — is WebSocket the right approach here or would polling work at our scale?"
Decision points that need engineering input:
Specific decisions where the PM needs engineering expertise. Be explicit about what kind of input is needed:
- "Need an estimate on feasibility and rough timeline before kickoff"
- "Need a recommendation on approach A vs. approach B"
- "Need to know if [dependency] is in place or if we need to build it"
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?
Step 3 — What to Leave Out
Do NOT include in the engineering brief:
- Market research or competitive analysis (not relevant to implementation)
- Stakeholder politics or organizational context
- Long-term roadmap items that aren't part of this sprint
- Design opinions that should be left to the designer's judgment
Step 4 — Output
Produce the engineering brief. Offer to:
- Create a Linear or Jira epic/ticket from this brief (if MCP connected)
- Save to
outputs/eng-brief-[feature]-[date].md
