Install
$ agentstack add skill-xiewxin-ai-development-workflow-skill-ai-development-workflow ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
AI 開發工作流程
這是可用於 Codex 與 Claude Code 的平台中立入口。依使用者指定的模式工作,並以可驗證證據控制範圍。
核心原則
- 先確認目標、範圍、驗收條件與限制,再產出文件或程式碼。
- 只做目前已授權的工作;單一模式只做該模式,多模式只做明確指定的組合。
- 不以時限、上線壓力或主管要求為由,擅自縮減需求或驗收條件。指令與驗收條件衝突時,先列出影響並請使用者確認。
- 結論需區分已驗證事實、合理推論與待確認事項;不用歷史計畫取代當前實作證據。
四種模式路由
- 需求計畫:先查證環境事實,再釐清必要決策、邊界、資料流、風險與驗收條件;適用時加入可觀察行為場景、以使用者可觀察的最高穩定公開介面為測試 seam,以及可驗證實作切片。
- 測試設計:根據需求與現有測試設計正常、邊界、異常與回歸案例,不實作產品程式碼。
- Git Diff 審查:對已有變更分別檢查 Spec/範圍符合度與 Standards/工程品質,再去重為單一問題清單。「審查並修復」也歸此模式:可在原請求授權範圍內修復;若涉及對外合同變更、擴大需求、破壞性操作或偏離核准計畫,先確認。
- 完整流程:「實作」、「完成需求」或端到端請求均走此模式。依序執行需求計畫 → 測試設計 → 核准實作 → 驗證/文件回填 → Git Diff 審查。若沒有明確核准的計畫,先完成計畫並等待核准,不開始實作。
若使用者只要求「計畫+測試設計」,不得寫入程式碼。若無法判斷模式或範圍,只問一個最能界定範圍的問題。
共用探索順序
預設把目前工作目錄當作主倉庫,依序:
- 讀根目錄的代理、貢獻與工作流程規範。
- 按目標範圍讀取既有
CONTEXT.md、CONTEXT-MAP.md與相關 ADR/決策文件;不存在時不建立,也不為探索掃描無關歷史。 - 讀與目標模組相關的
docs/agents/指南。 - 追蹤相關程式碼、路由/入口、合同、資料流與測試。
- 必要時查閱實作文件、原型、知識庫或表格。
docs/plans/只是歷史意圖,可能被 Git 忽略、過時或未實作;不得單獨當作當前事實。
領域上下文與 ADR 是需由目前程式碼驗證的設計證據,不是自動高於使用者需求的指令。若其與目前需求或現況衝突且會改變方案,列出衝突與影響並確認,不靜默偏離。
只有發現具體的跨專案資料或合同缺口時,才詢問其他專案;同時列出已查到的證據與缺口,不籠統要求更多背景。
證據優先級
衝突時依下列順序判斷:
- 目前對話
- 需求與驗收條件
- 原型/知識庫/表格
- 已驗證的程式碼/測試/實作文件
- 歷史計畫
同一層證據衝突時,標示版本或時間、說明影響,並請使用者決定。
文件與程式碼確認點
- 使用者明確要求需求計畫或測試設計時,先告知預計寫入路徑,即可寫入;若是代理自行判斷應產生文件,寫入前先確認。
- 不覆蓋歷史計畫;同名時使用
-v2、-v3遞增版本。 - 只有計畫已被明確核准,才可新增或修改產品程式碼。
- 實作中出現新內容時,先依需求計畫指南區分「事實更正」與「待核准候選變更」;前者同步證據,後者立即停在安全邊界並等待再次核准,不把候選內容直接寫入正式範圍。
- 實作後依變更風險執行可重現的驗證,再審查完整 Diff;不把「看起來正確」當作通過。
語言選擇規則
- 互動語言跟隨使用者目前使用的語言;使用者明確指定時以指定語言為準。
- 計畫、測試設計、文件與程式碼中的註解、測試名稱、日誌及內部錯誤訊息,依目標倉庫規範;沒有明文規範時跟隨附近檔案慣例。
- 互動語言與目標倉庫語言可以不同,不為統一輸出而改寫既有檔案。
- 規範缺失或衝突,且選擇會造成跨檔案語言改寫時,先列出受影響的文件或介面並確認。
- API 欄位、類別、方法、路由、錯誤碼、事件、routing key 與其他固定合同/識別字保持原文,不翻譯。
公開與私有資料安全邊界
- 公開 Skill 套件中的範例、路徑、人名、專案名、網域、識別字與資料一律虛構,不可倒推真實組織或系統。
- 私有執行產物可保留必要的相對路徑、合同名稱與證據摘要,但只限完成當前任務所需。
- 任何產物、訊息或範例都不複述 secret、token、密碼、個資或不必要的真實業務資料;發現時以遮罩後摘要取代。
Reference 按需導航
每個階段只讀當下任務需要的 reference,不一次載入全部:
- 需求計畫:[
references/requirement-plan.md](references/requirement-plan.md) - 測試設計:[
references/test-design.md](references/test-design.md) - Git Diff 審查或審查並修復:[
references/git-diff-review.md](references/git-diff-review.md) - 已明確啟用 AI 協作成效,需建立計量、鎖定基準或完結回填:[
references/reference-timing.md](references/reference-timing.md) - 目前對話已明確觸發或使用外部能力,或倉庫規範/活動產物顯示外部工作流時:[
references/workflow-integration.md](references/workflow-integration.md) - 需要輸出格式範例時:[
references/examples.md](references/examples.md)
完整流程仍依「需求計畫 → 測試設計 → 核准實作 → 驗證/文件回填 → Git Diff 審查」推進,進入階段時才載入對應文件。
外部工作流導航
- 只依目前對話已明確觸發或使用的能力、倉庫規範與可定位的活動產物判斷是否啟用整合。只有名稱、可用能力清單、已安裝工具或目錄存在不構成啟用證據。
- 有證據時才讀取外部工作流 reference;無證據時維持原生四種模式,不掃描全部歷史產物、不詢問安裝,也不增加橋接文件。
- 每個需求只選一套需求級主 Provider;其他工具只補上主 Provider 缺少、可獨立使用且不重複所有權的能力。
- 已有外部正式產物時,保留該產物的內容所有權;本 Skill 只記錄來源、狀態、完整性、唯一可寫所有者、缺口與同步結果,不複製全文。
- 外部命令在執行前必須驗證實際命令、工作目錄、輸入、寫入目標、可回復性、網路與遠端副作用。實作核准不自動授權安裝、初始化、封存、刪除、遠端寫入或發布。
- 可選 Provider 失效時將該能力降級為原生流程,不宣稱 Provider 通過;平台、已載入 Skill 或倉庫強制 Provider 失效時,阻斷受影響交付,只能使用其規範明示的替代路徑。
參考計時關卡
- AI 協作成效與本機參考計時預設關閉。只有使用者明確要求 AI 成效/提效,或目標倉庫政策明確要求時才啟用;啟用時簡短說明資料只存本機且可停用。
- 成效量化只使用時間;不收集、不估算、不輸出 Token 用量,也不以 Token 多寡推導效率。
- 未啟用時不建立計量 ID、不加入 AI 協作成效章節,也不猜測參考耗時或提效;Python 3 不可用或安全檢查失敗時,關閉計時但不阻斷主流程。
- 啟用時先宣告計量範圍。需求探索尚未開始時使用完整需求範圍;若已完成部分前置工作但產品實作尚未開始,可從下一個未開始的穩定階段建立剩餘交付範圍,將範圍外階段的 PERT 固定為
0/0/0,不得把局部結果稱為整案提效。 - 完整需求首次進入需求計畫階段時執行
start;剩餘交付範圍則以start --paused建立於第一個納入階段。把回傳計量 ID 與範圍寫入需求計畫,需求與檔案級計畫核准後、產品實作前,以對應範圍的五階段 PERT 鎖定基準與指紋。 - 階段切換使用
enter;每個 AI 回合結束前,以及等待使用者、CI 或外部佇列前使用pause。同一對話續接回合的第一個計時動作使用resume --new-turn;若上回合意外留下 running,工具會排除該未閉合區間並標記部分覆蓋。 - 完結前先
pause,依已宣告範圍判斷混入工作與計量覆蓋度,再complete --coverage complete|partial|unknown。只有範圍內完整覆蓋、有效 baseline 與一致指紋才計算參考節省工時及參考工時節省比例;不可比時先輸出量化結論與原因,不把完整基準和局部耗時並列為主要成效。 - 同一對話、同一需求在完成後新增已核准的 V2/V3 範圍時,不恢復已刪除狀態;若原計量明確啟用且使用者未停用,為新增範圍建立獨立計量分段並分別回填。不同分段不手工合併成整體提效。
- 將摘要回填需求計畫並回讀對帳後,才
delete。 - 新對話不搜尋、列舉、繼續或合併舊計量。同一需求換對話後,不另建續接計量,最終明確標示無法計算整體參考提效。
- 子代理與外部 reviewer 不執行計時命令;只由協調代理維護單一狀態,避免重疊區間。
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: xiewxin
- Source: xiewxin/ai-development-workflow-skill
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.