product-capability

Product Capability

這個技能將產品意圖轉換為明確的工程限制條件。

當問題不是「我們該建什麼？」而是「在實作開始前，到底哪些條件必須成立？」時使用。

使用時機

• 已有 PRD、路線圖項目、討論或創辦人筆記，但實作限制條件仍不明確
• 功能跨越 multiple 服務、儲存庫或團隊，需要在編碼前先有功能合約
• 產品意圖清楚，但架構、資料、生命週期或政策影響仍模糊
• 資深工程師在審查時不斷重複相同的隱藏假設
• 你需要一個可跨工作階段與執行環境重複使用的產出物

標準產出物

如果儲存庫已有持久的產品上下文檔案，例如 PRODUCT.md、docs/product/ 或程式規格目錄，則更新該處。

如果尚無功能清單，請使用以下範本建立：

• docs/examples/product-capability-template.md

目標不是建立另一個規劃堆疊，而是讓隱藏的功能限制條件變得持久且可重複使用。

不可妥協的規則

• 不要虛構產品事實。明確標記未解決的問題。
• 區分使用者可見的承諾與實作細節。
• 指出哪些是固定政策、哪些是架構偏好、哪些仍待決定。
• 如果請求與現有儲存庫限制衝突，清楚說明，不要粉飾太平。
• 偏好一個可重複使用的功能產出物，而非散落的臨時筆記。

輸入

只讀取必要的內容：

1. 產品意圖
   • issue、討論、PRD、路線圖筆記、創辦人訊息
2. 當前架構
   • 相關儲存庫文件、合約、schema、路由、現有工作流程
3. 現有功能上下文
   • PRODUCT.md、設計文件、RFC、遷移筆記、營運模式文件
4. 交付限制
   • 驗證、計費、合規、上線、向後相容、效能、審查政策

核心工作流程

1. 重新陳述功能

將需求壓縮為一句精確的陳述：

• 使用者或操作者是誰
• 此功能上線後新增了什麼能力
• 因為這個能力，什麼結果會改變

如果這句陳述不夠有力，實作就會偏離方向。

2. 解析功能限制條件

提取實作前必須成立的限制條件：

• 業務規則
• 範圍邊界
• 不變量
• 信任邊界
• 資料所有權
• 生命週期轉換
• 上線 / 遷移需求
• 失敗與復原預期

這些通常是只存在於資深工程師腦中的東西。

3. 定義實作面向的合約

產出 SRS 風格的規格計畫，包含：

• 功能摘要
• 明確的非目標
• 參與者與接觸面
• 必要狀態與轉換
• 介面 / 輸入 / 輸出
• 資料模型影響
• 安全性 / 計費 / 政策限制
• 可觀測性與操作者需求
• 阻礙實作的未決問題

4. 轉換為執行

以明確的交接事項結尾：

• 可直接實作
• 需要先進行架構審查
• 需要先釐清產品

如有幫助，可指向下一個 ECC 原生流程：

• project-flow-ops
• workspace-surface-audit
• api-connector-builder
• dashboard-builder
• tdd-workflow
• verification-loop

輸出格式

依序回傳結果：

CAPABILITY
- 一段重新陳述

CONSTRAINTS
- 固定規則、不變量與邊界

IMPLEMENTATION CONTRACT
- 參與者
- 接觸面
- 狀態與轉換
- 介面/資料影響

NON-GOALS
- 此流程明確不負責的事項

OPEN QUESTIONS
- 阻礙或仍需產品決策的事項

HANDOFF
- 下一步該做什麼，以及應由哪個 ECC 流程接手

良好成果

• 產品意圖已具體到無需在 PR 審查中重新發現隱藏限制即可實作。
• 工程審查有持久的產出物，而非依賴記憶或 Slack 上下文。
• 產出的計畫可在 Claude Code、Codex、Cursor、OpenCode 與 ECC 2.0 規劃介面中重複使用。