eng-brief

Name: eng-brief
Author: Productfculty-aipm

70stars33forks

How to install eng-brief?

productfculty-aipm/pm-copilot-by-product-faculty/eng-brief

$npx -y skills add Productfculty-aipm/PM-Copilot-by-Product-Faculty --skill eng-brief

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Engineering Brief
2
3	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.
4
5	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.
6
7	## Step 1 — Load Context
8
9	Read `memory/user-profile.md` for stack context (issue tracker, code repo, technical context if known). Read the PRD or feature description provided.
10
11	## Step 2 — Engineering Brief Structure
12
13	Context (why this matters):
14	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.
15
16	What we're building:
17	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.
18
19	What we're NOT building:
20	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).
21
22	Success criteria:
23	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.
24
25	Acceptance criteria:
26	The binary, testable criteria from the PRD. Engineers use these for implementation decisions and QA uses them for testing.
27
28	Technical unknowns (from PM perspective):
29	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.
30
31	Examples:
32	- "We want < 500ms latency for this action — is that feasible with the current [stack detail]? What would be the trade-off?"
33	- "We need this to work offline — is that achievable in Phase 1 or should it be Phase 2?"
34	- "The design calls for real-time updates — is WebSocket the right approach here or would polling work at our scale?"
35
36	Decision points that need engineering input:
37	Specific decisions where the PM needs engineering expertise. Be explicit about what kind of input is needed:
38	- "Need an estimate on feasibility and rough timeline before kickoff"
39	- "Need a recommendation on approach A vs. approach B"
40	- "Need to know if [dependency] is in place or if we need to build it"
41
42	Timeline context:
43	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.
44
45	Definition of done:
46	Engineering-level definition — what does "complete" mean for this work? Include: feature-flagged? In staging? In prod? All tests passing? Metrics instrumented?
47
48	## Step 3 — What to Leave Out
49
50	Do NOT include in the engineering brief:
51	- Market research or competitive analysis (not relevant to implementation)
52	- Stakeholder politics or organizational context
53	- Long-term roadmap items that aren't part of this sprint
54	- Design opinions that should be left to the designer's judgment
55
56	## Step 4 — Output
57
58	Produce the engineering brief. Offer to:
59	- Create a Linear or Jira epic/ticket from this brief (if MCP connected)
60	- Save to `outputs/eng-brief-[feature]-[date].md`

People who liked this also viewed

6 picks

Type

eng-brief

70stars33forks

View on GitHub

How to install eng-brief?

productfculty-aipm/pm-copilot-by-product-faculty/eng-brief

$npx -y skills add Productfculty-aipm/PM-Copilot-by-Product-Faculty --skill eng-brief

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Engineering Brief
2
3	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.
4
5	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.
6
7	## Step 1 — Load Context
8
9	Read `memory/user-profile.md` for stack context (issue tracker, code repo, technical context if known). Read the PRD or feature description provided.
10
11	## Step 2 — Engineering Brief Structure
12
13	Context (why this matters):
14	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.
15
16	What we're building:
17	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.
18
19	What we're NOT building:
20	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).
21
22	Success criteria:
23	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.
24
25	Acceptance criteria:
26	The binary, testable criteria from the PRD. Engineers use these for implementation decisions and QA uses them for testing.
27
28	Technical unknowns (from PM perspective):
29	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.
30
31	Examples:
32	- "We want < 500ms latency for this action — is that feasible with the current [stack detail]? What would be the trade-off?"
33	- "We need this to work offline — is that achievable in Phase 1 or should it be Phase 2?"
34	- "The design calls for real-time updates — is WebSocket the right approach here or would polling work at our scale?"
35
36	Decision points that need engineering input:
37	Specific decisions where the PM needs engineering expertise. Be explicit about what kind of input is needed:
38	- "Need an estimate on feasibility and rough timeline before kickoff"
39	- "Need a recommendation on approach A vs. approach B"
40	- "Need to know if [dependency] is in place or if we need to build it"
41
42	Timeline context:
43	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.
44
45	Definition of done:
46	Engineering-level definition — what does "complete" mean for this work? Include: feature-flagged? In staging? In prod? All tests passing? Metrics instrumented?
47
48	## Step 3 — What to Leave Out
49
50	Do NOT include in the engineering brief:
51	- Market research or competitive analysis (not relevant to implementation)
52	- Stakeholder politics or organizational context
53	- Long-term roadmap items that aren't part of this sprint
54	- Design opinions that should be left to the designer's judgment
55
56	## Step 4 — Output
57
58	Produce the engineering brief. Offer to:
59	- Create a Linear or Jira epic/ticket from this brief (if MCP connected)
60	- Save to `outputs/eng-brief-[feature]-[date].md`

People who liked this also viewed

6 picks

Type