product-capability

Name: product-capability
Author: affaan-m

232kstars35kforks

How to install product-capability?

affaan-m/ecc/product-capability

$npx -y skills add affaan-m/ECC --skill product-capability

Installs into the current project.

Summary

Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of va

Files · 1

View on GitHub

SKILL.md

1	# Product Capability
2
3	This skill turns product intent into explicit engineering constraints.
4
5	Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?"
6
7	## When to Use
8
9	- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit
10	- A feature crosses multiple services, repos, or teams and needs a capability contract before coding
11	- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy
12	- Senior engineers keep restating the same hidden assumptions during review
13	- You need a reusable artifact that can survive across harnesses and sessions
14
15	## Canonical Artifact
16
17	If the repo has a durable product-context file such as `PRODUCT.md`, `docs/product/`, or a program-spec directory, update it there.
18
19	If no capability manifest exists yet, create one using the template at:
20
21	- `docs/examples/product-capability-template.md`
22
23	The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.
24
25	## Non-Negotiable Rules
26
27	- Do not invent product truth. Mark unresolved questions explicitly.
28	- Separate user-visible promises from implementation details.
29	- Call out what is fixed policy, what is architecture preference, and what is still open.
30	- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.
31	- Prefer one reusable capability artifact over scattered ad hoc notes.
32
33	## Inputs
34
35	Read only what is needed:
36
37	1. Product intent
38	- issue, discussion, PRD, roadmap note, founder message
39	2. Current architecture
40	- relevant repo docs, contracts, schemas, routes, existing workflows
41	3. Existing capability context
42	- `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs
43	4. Delivery constraints
44	- auth, billing, compliance, rollout, backwards compatibility, performance, review policy
45
46	## Core Workflow
47
48	### 1. Restate the capability
49
50	Compress the ask into one precise statement:
51
52	- who the user or operator is
53	- what new capability exists after this ships
54	- what outcome changes because of it
55
56	If this statement is weak, the implementation will drift.
57
58	### 2. Resolve capability constraints
59
60	Extract the constraints that must hold before implementation:
61
62	- business rules
63	- scope boundaries
64	- invariants
65	- trust boundaries
66	- data ownership
67	- lifecycle transitions
68	- rollout / migration requirements
69	- failure and recovery expectations
70
71	These are the things that often live only in senior-engineer memory.
72
73	### 3. Define the implementation-facing contract
74
75	Produce an SRS-style capability plan with:
76
77	- capability summary
78	- explicit non-goals
79	- actors and surfaces
80	- required states and transitions
81	- interfaces / inputs / outputs
82	- data model implications
83	- security / billing / policy constraints
84	- observability and operator requirements
85	- open questions blocking implementation
86
87	### 4. Translate into execution
88
89	End with the exact handoff:
90
91	- ready for direct implementation
92	- needs architecture review first
93	- needs product clarification first
94
95	If useful, point to the next ECC-native lane:
96
97	- `project-flow-ops`
98	- `workspace-surface-audit`
99	- `api-connector-builder`
100	- `dashboard-builder`
101	- `tdd-workflow`
102	- `verification-loop`
103
104	## Output Format
105
106	Return the result in this order:
107
108	```text
109	CAPABILITY
110	- one-paragraph restatement
111
112	CONSTRAINTS
113	- fixed rules, invariants, and boundaries
114
115	IMPLEMENTATION CONTRACT
116	- actors
117	- surfaces
118	- states and transitions
119	- interface/data implications
120
121	NON-GOALS
122	- what this lane explicitly does not own
123
124	OPEN QUESTIONS
125	- blockers or product decisions still required
126
127	HANDOFF
128	- what should happen next and which ECC lane should take it
129	```
130
131	## Good Outcomes
132
133	- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.
134	- Engineering review has a durable artifact instead of relying on memory or Slack context.
135	- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.

People who liked this also viewed

6 picks

Type

product-capability

232kstars35kforks

View on GitHub

How to install product-capability?

affaan-m/ecc/product-capability

$npx -y skills add affaan-m/ECC --skill product-capability

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Product Capability
2
3	This skill turns product intent into explicit engineering constraints.
4
5	Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?"
6
7	## When to Use
8
9	- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit
10	- A feature crosses multiple services, repos, or teams and needs a capability contract before coding
11	- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy
12	- Senior engineers keep restating the same hidden assumptions during review
13	- You need a reusable artifact that can survive across harnesses and sessions
14
15	## Canonical Artifact
16
17	If the repo has a durable product-context file such as `PRODUCT.md`, `docs/product/`, or a program-spec directory, update it there.
18
19	If no capability manifest exists yet, create one using the template at:
20
21	- `docs/examples/product-capability-template.md`
22
23	The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.
24
25	## Non-Negotiable Rules
26
27	- Do not invent product truth. Mark unresolved questions explicitly.
28	- Separate user-visible promises from implementation details.
29	- Call out what is fixed policy, what is architecture preference, and what is still open.
30	- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.
31	- Prefer one reusable capability artifact over scattered ad hoc notes.
32
33	## Inputs
34
35	Read only what is needed:
36
37	1. Product intent
38	- issue, discussion, PRD, roadmap note, founder message
39	2. Current architecture
40	- relevant repo docs, contracts, schemas, routes, existing workflows
41	3. Existing capability context
42	- `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs
43	4. Delivery constraints
44	- auth, billing, compliance, rollout, backwards compatibility, performance, review policy
45
46	## Core Workflow
47
48	### 1. Restate the capability
49
50	Compress the ask into one precise statement:
51
52	- who the user or operator is
53	- what new capability exists after this ships
54	- what outcome changes because of it
55
56	If this statement is weak, the implementation will drift.
57
58	### 2. Resolve capability constraints
59
60	Extract the constraints that must hold before implementation:
61
62	- business rules
63	- scope boundaries
64	- invariants
65	- trust boundaries
66	- data ownership
67	- lifecycle transitions
68	- rollout / migration requirements
69	- failure and recovery expectations
70
71	These are the things that often live only in senior-engineer memory.
72
73	### 3. Define the implementation-facing contract
74
75	Produce an SRS-style capability plan with:
76
77	- capability summary
78	- explicit non-goals
79	- actors and surfaces
80	- required states and transitions
81	- interfaces / inputs / outputs
82	- data model implications
83	- security / billing / policy constraints
84	- observability and operator requirements
85	- open questions blocking implementation
86
87	### 4. Translate into execution
88
89	End with the exact handoff:
90
91	- ready for direct implementation
92	- needs architecture review first
93	- needs product clarification first
94
95	If useful, point to the next ECC-native lane:
96
97	- `project-flow-ops`
98	- `workspace-surface-audit`
99	- `api-connector-builder`
100	- `dashboard-builder`
101	- `tdd-workflow`
102	- `verification-loop`
103
104	## Output Format
105
106	Return the result in this order:
107
108	```text
109	CAPABILITY
110	- one-paragraph restatement
111
112	CONSTRAINTS
113	- fixed rules, invariants, and boundaries
114
115	IMPLEMENTATION CONTRACT
116	- actors
117	- surfaces
118	- states and transitions
119	- interface/data implications
120
121	NON-GOALS
122	- what this lane explicitly does not own
123
124	OPEN QUESTIONS
125	- blockers or product decisions still required
126
127	HANDOFF
128	- what should happen next and which ECC lane should take it
129	```
130
131	## Good Outcomes
132
133	- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.
134	- Engineering review has a durable artifact instead of relying on memory or Slack context.
135	- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.

People who liked this also viewed

6 picks

Type