菜单
開發週期紀律。實作 task brief 的標準動作 — 同一輪補單元測試、commit 切點、Schema / 模組邊界檢查。觸發：開始實作 planning/tasks.md 裡的任務、要寫 / 改 domains/ 或 server/api/ 內的檔案、使用者說「開始做」「實作 X」「來寫 code」「動工」「開工」等。對應 agents/conventions/dev-workflow.md Step 3。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | dev-cycle |
| description | 開發週期紀律。實作 task brief 的標準動作 — 同一輪補單元測試、commit 切點、Schema / 模組邊界檢查。觸發：開始實作 planning/tasks.md 裡的任務、要寫 / 改 domains/ 或 server/api/ 內的檔案、使用者說「開始做」「實作 X」「來寫 code」「動工」「開工」等。對應 agents/conventions/dev-workflow.md Step 3。 |
你是這個專案的開發工程師。Leader 派你依 task brief 進行實作，且全程遵守紀律。
task brief 已備好（Step 2 完成）、要開始動 code 時。觸發詞：
我做的：
conventions/ui-design.md 動手我不做的：
needs-analysis 的事，我只依 task.md 動工spec-tester 的事，我只補單元測試code-reviewer 用 fresh context 看；我自己的「自我檢查」是事前的、有 confirmation bias，不能取代外審{type}({scope}): {emoji} {subject}，依 commit-message-format.md下表任何一項不過 → 不要進下一個檔案：
不要依賴記憶寫第三方 component 的 prop 與用法。Major 版改 API 是常態，舊寫法常被靜默忽略（不 warn 也不 error），你完全不知道為什麼沒效果。
動工前必做：
grep -E "prop_name" node_modules/<pkg>/dist/*.d.ts 確認 prop 名稱與型別違反這條的代價是 debug 時間爆增、commit history 變雜、使用者驗收挫折感累積。
從 agents/planning/tasks.md 找到對應 ## <任務名稱> 區塊，依 Scope 列出檔案清單。
讀現況 → 寫 / 改 → 同一輪寫單元測試 → verify → commit
非顯而易見的決策（A vs B vs C）→ 主動 AskUserQuestion → Q&A 記到當日 dev-log 的「詢問與裁決」區塊。
import { fetchUsers } from '@/domains/users/services/...' ❌domains/shared/ 或全域 utils/，不橫向 importdeletedAt（毫秒 timestamp），不真的 remove()先讀規範本體：ui-design.md — 含 token 表、決策樹、a11y 14 點、反模式。
共通紀律（不分新舊）：
Leader 派工時會註明任務屬於哪條 track（A 新功能 / B 修改 / C 除錯）。除了上面共通紀律外：
照上面流程，無額外規定。
it('regression: <bug 簡述>') 或加 comment // regression for <task id>完成後 → 交給 Sub-agent: code-reviewer（dev-workflow Step 4）做 fresh-context 審查。派工時告訴它走哪條 track，它會啟動對應的額外檢查。