feat: add product capability planning lane

.agents/skills/product-capability/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: product-capability
+description: 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 vague planning prose.
+origin: ECC
+---
+
+# Product Capability
+
+This skill turns product intent into explicit engineering constraints.
+
+Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?"
+
+## When to Use
+
+- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit
+- A feature crosses multiple services, repos, or teams and needs a capability contract before coding
+- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy
+- Senior engineers keep restating the same hidden assumptions during review
+- You need a reusable artifact that can survive across harnesses and sessions
+
+## Canonical Artifact
+
+If the repo has a durable product-context file such as `PRODUCT.md`, `docs/product/`, or a program-spec directory, update it there.
+
+If no capability manifest exists yet, create one using the template at:
+
+- `docs/examples/product-capability-template.md`
+
+The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.
+
+## Non-Negotiable Rules
+
+- Do not invent product truth. Mark unresolved questions explicitly.
+- Separate user-visible promises from implementation details.
+- Call out what is fixed policy, what is architecture preference, and what is still open.
+- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.
+- Prefer one reusable capability artifact over scattered ad hoc notes.
+
+## Inputs
+
+Read only what is needed:
+
+1. Product intent
+   - issue, discussion, PRD, roadmap note, founder message
+2. Current architecture
+   - relevant repo docs, contracts, schemas, routes, existing workflows
+3. Existing capability context
+   - `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs
+4. Delivery constraints
+   - auth, billing, compliance, rollout, backwards compatibility, performance, review policy
+
+## Core Workflow
+
+### 1. Restate the capability
+
+Compress the ask into one precise statement:
+
+- who the user or operator is
+- what new capability exists after this ships
+- what outcome changes because of it
+
+If this statement is weak, the implementation will drift.
+
+### 2. Resolve capability constraints
+
+Extract the constraints that must hold before implementation:
+
+- business rules
+- scope boundaries
+- invariants
+- trust boundaries
+- data ownership
+- lifecycle transitions
+- rollout / migration requirements
+- failure and recovery expectations
+
+These are the things that often live only in senior-engineer memory.
+
+### 3. Define the implementation-facing contract
+
+Produce an SRS-style capability plan with:
+
+- capability summary
+- explicit non-goals
+- actors and surfaces
+- required states and transitions
+- interfaces / inputs / outputs
+- data model implications
+- security / billing / policy constraints
+- observability and operator requirements
+- open questions blocking implementation
+
+### 4. Translate into execution
+
+End with the exact handoff:
+
+- ready for direct implementation
+- needs architecture review first
+- needs product clarification first
+
+If useful, point to the next ECC-native lane:
+
+- `project-flow-ops`
+- `workspace-surface-audit`
+- `api-connector-builder`
+- `dashboard-builder`
+- `tdd-workflow`
+- `verification-loop`
+
+## Output Format
+
+Return the result in this order:
+
+```text
+CAPABILITY
+- one-paragraph restatement
+
+CONSTRAINTS
+- fixed rules, invariants, and boundaries
+
+IMPLEMENTATION CONTRACT
+- actors
+- surfaces
+- states and transitions
+- interface/data implications
+
+NON-GOALS
+- what this lane explicitly does not own
+
+OPEN QUESTIONS
+- blockers or product decisions still required
+
+HANDOFF
+- what should happen next and which ECC lane should take it
+```
+
+## Good Outcomes
+
+- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.
+- Engineering review has a durable artifact instead of relying on memory or Slack context.
+- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.

AGENTS.md

@@ -1,6 +1,6 @@
 # Everything Claude Code (ECC) — Agent Instructions
 
-This is a **production-ready AI coding plugin** providing 39 specialized agents, 177 skills, 72 commands, and automated hook workflows for software development.
+This is a **production-ready AI coding plugin** providing 39 specialized agents, 178 skills, 72 commands, and automated hook workflows for software development.
 
 **Version:** 1.10.0
 
@@ -146,7 +146,7 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
 
 ```
 agents/          — 39 specialized subagents
-skills/          — 177 workflow skills and domain knowledge
+skills/          — 178 workflow skills and domain knowledge
 commands/        — 72 slash commands
 hooks/           — Trigger-based automations
 rules/           — Always-follow guidelines (common + per-language)

README.md

@@ -236,7 +236,7 @@ For manual install instructions see the README in the `rules/` folder. When copy
 /plugin list ecc@ecc
 ```
 
-**That's it!** You now have access to 39 agents, 177 skills, and 72 legacy command shims.
+**That's it!** You now have access to 39 agents, 178 skills, and 72 legacy command shims.
 
 ### Multi-model commands require additional setup
 
@@ -1154,7 +1154,7 @@ The configuration is automatically detected from `.opencode/opencode.json`.
 |---------|-------------|----------|--------|
 | Agents | PASS: 39 agents | PASS: 12 agents | **Claude Code leads** |
 | Commands | PASS: 72 commands | PASS: 31 commands | **Claude Code leads** |
-| Skills | PASS: 177 skills | PASS: 37 skills | **Claude Code leads** |
+| Skills | PASS: 178 skills | PASS: 37 skills | **Claude Code leads** |
 | Hooks | PASS: 8 event types | PASS: 11 events | **OpenCode has more!** |
 | Rules | PASS: 29 rules | PASS: 13 instructions | **Claude Code leads** |
 | MCP Servers | PASS: 14 servers | PASS: Full | **Full parity** |
@@ -1263,7 +1263,7 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
 |---------|------------|------------|-----------|----------|
 | **Agents** | 39 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
 | **Commands** | 72 | Shared | Instruction-based | 31 |
-| **Skills** | 177 | Shared | 10 (native format) | 37 |
+| **Skills** | 178 | Shared | 10 (native format) | 37 |
 | **Hook Events** | 8 types | 15 types | None yet | 11 types |
 | **Hook Scripts** | 20+ scripts | 16 scripts (DRY adapter) | N/A | Plugin hooks |
 | **Rules** | 34 (common + lang) | 34 (YAML frontmatter) | Instruction-based | 13 instructions |

README.zh-CN.md

@@ -106,7 +106,7 @@ cp -r everything-claude-code/rules/perl ~/.claude/rules/
 /plugin list ecc@ecc
 ```
 
-**完成！** 你现在可以使用 39 个代理、177 个技能和 72 个命令。
+**完成！** 你现在可以使用 39 个代理、178 个技能和 72 个命令。
 
 ### multi-* 命令需要额外配置
 

WORKING-CONTEXT.md

@@ -153,3 +153,4 @@ Keep this file detailed for only the current sprint, blockers, and next actions.
 - 2026-04-05: Closed PR `#1232` after full audit. The proposed `skill-scout` workflow overlaps current `search-first`, `/skill-create`, and `skill-stocktake`; if a dedicated marketplace-discovery layer returns later it should be rebuilt on top of the current install/catalog model rather than landing as a parallel discovery path.
 - 2026-04-05: Ported the safe localized README switcher fixes from PR `#1209` directly into `main` rather than merging the docs PR wholesale. The navigation now consistently includes `Português (Brasil)` and `Türkçe` across the localized README switchers, while newer localized body copy stays intact.
 - 2026-04-05: Salvaged the reusable Hermes-generated operator workflow lane without replaying the whole branch. Added six ECC-native top-level skills instead of the old nested `skills/hermes-generated/*` tree: `automation-audit-ops`, `email-ops`, `finance-billing-ops`, `messages-ops`, `research-ops`, and `terminal-ops`. `research-ops` now wraps the existing research stack, while the other five extend `operator-workflows` without introducing any external runtime assumptions.
+- 2026-04-05: Added `skills/product-capability` plus `docs/examples/product-capability-template.md` as the canonical PRD-to-SRS lane for issue `#1185`. This is the ECC-native capability-contract step between vague product intent and implementation, and it lives in `business-content` rather than spawning a parallel planning subsystem.

docs/examples/product-capability-template.md

@@ -0,0 +1,84 @@
+# Product Capability Template
+
+Use this when product intent exists but the implementation constraints are still implicit.
+
+The purpose is to create a durable capability contract, not another vague planning doc.
+
+## Capability
+
+- **Capability name:**
+- **Source:** PRD / issue / discussion / roadmap / founder note
+- **Primary actor:**
+- **Outcome after ship:**
+- **Success signal:**
+
+## Product Intent
+
+Describe the user-visible promise in one short paragraph.
+
+## Constraints
+
+List the rules that must be true before implementation starts:
+
+- business rules
+- scope boundaries
+- invariants
+- rollout constraints
+- migration constraints
+- backwards compatibility constraints
+- billing / auth / compliance constraints
+
+## Actors and Surfaces
+
+- actor(s)
+- UI surfaces
+- API surfaces
+- automation / operator surfaces
+- reporting / dashboard surfaces
+
+## States and Transitions
+
+Describe the lifecycle in terms of explicit states and allowed transitions.
+
+Example:
+
+- `draft -> active -> paused -> completed`
+- `pending -> approved -> provisioned -> revoked`
+
+## Interface Contract
+
+- inputs
+- outputs
+- required side effects
+- failure states
+- retries / recovery
+- idempotency expectations
+
+## Data Implications
+
+- source of truth
+- new entities or fields
+- ownership boundaries
+- retention / deletion expectations
+
+## Security and Policy
+
+- trust boundaries
+- permission requirements
+- abuse paths
+- policy / governance requirements
+
+## Non-Goals
+
+List what this capability explicitly does not own.
+
+## Open Questions
+
+Capture the unresolved decisions blocking implementation.
+
+## Handoff
+
+- **Ready for implementation?**
+- **Needs architecture review?**
+- **Needs product clarification?**
+- **Next ECC lane:** `project-flow-ops` / `tdd-workflow` / `verification-loop` / other

docs/zh-CN/AGENTS.md

@@ -1,6 +1,6 @@
 # Everything Claude Code (ECC) — 智能体指令
 
-这是一个**生产就绪的 AI 编码插件**，提供 39 个专业代理、177 项技能、72 条命令以及自动化钩子工作流，用于软件开发。
+这是一个**生产就绪的 AI 编码插件**，提供 39 个专业代理、178 项技能、72 条命令以及自动化钩子工作流，用于软件开发。
 
 **版本:** 1.10.0
 
@@ -147,7 +147,7 @@
 
 ```
 agents/          — 39 个专业子代理
-skills/          — 177 个工作流技能和领域知识
+skills/          — 178 个工作流技能和领域知识
 commands/        — 72 个斜杠命令
 hooks/           — 基于触发的自动化
 rules/           — 始终遵循的指导方针（通用 + 每种语言）

docs/zh-CN/README.md

@@ -209,7 +209,7 @@ npx ecc-install typescript
 /plugin list ecc@ecc
 ```
 
-**搞定！** 你现在可以使用 39 个智能体、177 项技能和 72 个命令了。
+**搞定！** 你现在可以使用 39 个智能体、178 项技能和 72 个命令了。
 
 ***
 
@@ -1096,7 +1096,7 @@ opencode
 |---------|-------------|----------|--------|
 | 智能体 | PASS: 39 个 | PASS: 12 个 | **Claude Code 领先** |
 | 命令 | PASS: 72 个 | PASS: 31 个 | **Claude Code 领先** |
-| 技能 | PASS: 177 项 | PASS: 37 项 | **Claude Code 领先** |
+| 技能 | PASS: 178 项 | PASS: 37 项 | **Claude Code 领先** |
 | 钩子 | PASS: 8 种事件类型 | PASS: 11 种事件 | **OpenCode 更多！** |
 | 规则 | PASS: 29 条 | PASS: 13 条指令 | **Claude Code 领先** |
 | MCP 服务器 | PASS: 14 个 | PASS: 完整 | **完全对等** |
@@ -1208,7 +1208,7 @@ ECC 是**第一个最大化利用每个主要 AI 编码工具的插件**。以
 |---------|------------|------------|-----------|----------|
 | **智能体** | 39 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
 | **命令** | 72 | 共享 | 基于指令 | 31 |
-| **技能** | 177 | 共享 | 10 (原生格式) | 37 |
+| **技能** | 178 | 共享 | 10 (原生格式) | 37 |
 | **钩子事件** | 8 种类型 | 15 种类型 | 暂无 | 11 种类型 |
 | **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | N/A | 插件钩子 |
 | **规则** | 34 (通用 + 语言) | 34 (YAML 前页) | 基于指令 | 13 条指令 |

manifests/install-modules.json

@@ -300,6 +300,7 @@
         "skills/investor-materials",
         "skills/investor-outreach",
         "skills/lead-intelligence",
+        "skills/product-capability",
         "skills/social-graph-ranker",
         "skills/seo",
         "skills/market-research"

skills/product-capability/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: product-capability
+description: 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 vague planning prose.
+origin: ECC
+---
+
+# Product Capability
+
+This skill turns product intent into explicit engineering constraints.
+
+Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?"
+
+## When to Use
+
+- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit
+- A feature crosses multiple services, repos, or teams and needs a capability contract before coding
+- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy
+- Senior engineers keep restating the same hidden assumptions during review
+- You need a reusable artifact that can survive across harnesses and sessions
+
+## Canonical Artifact
+
+If the repo has a durable product-context file such as `PRODUCT.md`, `docs/product/`, or a program-spec directory, update it there.
+
+If no capability manifest exists yet, create one using the template at:
+
+- `docs/examples/product-capability-template.md`
+
+The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.
+
+## Non-Negotiable Rules
+
+- Do not invent product truth. Mark unresolved questions explicitly.
+- Separate user-visible promises from implementation details.
+- Call out what is fixed policy, what is architecture preference, and what is still open.
+- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.
+- Prefer one reusable capability artifact over scattered ad hoc notes.
+
+## Inputs
+
+Read only what is needed:
+
+1. Product intent
+   - issue, discussion, PRD, roadmap note, founder message
+2. Current architecture
+   - relevant repo docs, contracts, schemas, routes, existing workflows
+3. Existing capability context
+   - `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs
+4. Delivery constraints
+   - auth, billing, compliance, rollout, backwards compatibility, performance, review policy
+
+## Core Workflow
+
+### 1. Restate the capability
+
+Compress the ask into one precise statement:
+
+- who the user or operator is
+- what new capability exists after this ships
+- what outcome changes because of it
+
+If this statement is weak, the implementation will drift.
+
+### 2. Resolve capability constraints
+
+Extract the constraints that must hold before implementation:
+
+- business rules
+- scope boundaries
+- invariants
+- trust boundaries
+- data ownership
+- lifecycle transitions
+- rollout / migration requirements
+- failure and recovery expectations
+
+These are the things that often live only in senior-engineer memory.
+
+### 3. Define the implementation-facing contract
+
+Produce an SRS-style capability plan with:
+
+- capability summary
+- explicit non-goals
+- actors and surfaces
+- required states and transitions
+- interfaces / inputs / outputs
+- data model implications
+- security / billing / policy constraints
+- observability and operator requirements
+- open questions blocking implementation
+
+### 4. Translate into execution
+
+End with the exact handoff:
+
+- ready for direct implementation
+- needs architecture review first
+- needs product clarification first
+
+If useful, point to the next ECC-native lane:
+
+- `project-flow-ops`
+- `workspace-surface-audit`
+- `api-connector-builder`
+- `dashboard-builder`
+- `tdd-workflow`
+- `verification-loop`
+
+## Output Format
+
+Return the result in this order:
+
+```text
+CAPABILITY
+- one-paragraph restatement
+
+CONSTRAINTS
+- fixed rules, invariants, and boundaries
+
+IMPLEMENTATION CONTRACT
+- actors
+- surfaces
+- states and transitions
+- interface/data implications
+
+NON-GOALS
+- what this lane explicitly does not own
+
+OPEN QUESTIONS
+- blockers or product decisions still required
+
+HANDOFF
+- what should happen next and which ECC lane should take it
+```
+
+## Good Outcomes
+
+- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.
+- Engineering review has a durable artifact instead of relying on memory or Slack context.
+- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.