From 05d836387e27f292bfe3693663bd131cb2acf3c5 Mon Sep 17 00:00:00 2001 From: Affaan Mustafa Date: Sun, 5 Apr 2026 16:58:02 -0700 Subject: [PATCH] feat: add product capability planning lane --- .agents/skills/product-capability/SKILL.md | 141 +++++++++++++++++++ AGENTS.md | 4 +- README.md | 6 +- README.zh-CN.md | 2 +- WORKING-CONTEXT.md | 1 + docs/examples/product-capability-template.md | 84 +++++++++++ docs/zh-CN/AGENTS.md | 4 +- docs/zh-CN/README.md | 6 +- manifests/install-modules.json | 1 + skills/product-capability/SKILL.md | 141 +++++++++++++++++++ 10 files changed, 379 insertions(+), 11 deletions(-) create mode 100644 .agents/skills/product-capability/SKILL.md create mode 100644 docs/examples/product-capability-template.md create mode 100644 skills/product-capability/SKILL.md diff --git a/.agents/skills/product-capability/SKILL.md b/.agents/skills/product-capability/SKILL.md new file mode 100644 index 00000000..4e3509a4 --- /dev/null +++ b/.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. diff --git a/AGENTS.md b/AGENTS.md index b7b7ca01..6665336b 100644 --- a/AGENTS.md +++ b/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) diff --git a/README.md b/README.md index 06d47807..d558f292 100644 --- a/README.md +++ b/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 | diff --git a/README.zh-CN.md b/README.zh-CN.md index bc6e27bc..867c4b3a 100644 --- a/README.zh-CN.md +++ b/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-* 命令需要额外配置 diff --git a/WORKING-CONTEXT.md b/WORKING-CONTEXT.md index 572397fd..de4e6093 100644 --- a/WORKING-CONTEXT.md +++ b/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. diff --git a/docs/examples/product-capability-template.md b/docs/examples/product-capability-template.md new file mode 100644 index 00000000..1a7a0c84 --- /dev/null +++ b/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 diff --git a/docs/zh-CN/AGENTS.md b/docs/zh-CN/AGENTS.md index 0af49033..3ccbd596 100644 --- a/docs/zh-CN/AGENTS.md +++ b/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/ — 始终遵循的指导方针（通用 + 每种语言） diff --git a/docs/zh-CN/README.md b/docs/zh-CN/README.md index f1d36a4f..4a9881ac 100644 --- a/docs/zh-CN/README.md +++ b/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 条指令 | diff --git a/manifests/install-modules.json b/manifests/install-modules.json index 7b65866c..3cbaa7db 100644 --- a/manifests/install-modules.json +++ b/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" diff --git a/skills/product-capability/SKILL.md b/skills/product-capability/SKILL.md new file mode 100644 index 00000000..4e3509a4 --- /dev/null +++ b/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.