菜单
Use when implementing any non-trivial feature, integration, refactor, or bugfix in this repo where there is a risk of skipping analysis/design/planning or skipping tests due to time pressure, scope pressure, or sunk-cost pressure.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when starting a new repo or onboarding an AI agent and you need to create or overhaul an AGENTS.md so work stays safe, testable, and consistent across environments (e.g., Godot + SDK + demo apps), especially when the project has strict tooling, sandboxes, or multiple "products" in one codebase.
适用于需要 PRD/Spec + 版本化执行计划（docs/plan/vN-*）+ 端到端验证的项目。通过严格的 PRD ↔ 计划 ↔ 测试 ↔ 代码追溯链，防止文档漂移与返工，直到愿景与实现之间无差异、无保留、无妥协。
Use when Codex repeatedly prompts for the same safe actions (running tests, reading logs, git operations) and the user wants those already-approved actions persisted into Codex approval config (trust levels + allow rules) so future sessions don’t require re-approval.
Render and view webpages using a headless browser (Playwright) to fetch JS-rendered HTML, extract visible text, and optionally save full-page screenshots. Use when a user asks to “无头浏览器打开/查看网页”, needs the rendered DOM instead of raw curl HTML, or wants a screenshot of a page.
End-to-end source code repository deep dive and review. Use when you need to understand a repo’s architecture, core abstractions, entrypoints and execution flow, extension points, and operational/developer setup; and when you must deliver a structured report (Markdown + standalone HTML) with diagrams (Mermaid), actionable recommendations, and a scored evaluation.
Use when a single file/class has grown into tightly coupled “spaghetti” (mixed UI, IO, state, input, gameplay), making changes risky, tests hard to write, and refactors frequently break behavior—especially under strict type/warning-as-error environments like Godot 4.x.
基于 SOC 职业分类
| name | tashan-development-loop |
| description | Use when implementing any non-trivial feature, integration, refactor, or bugfix in this repo where there is a risk of skipping analysis/design/planning or skipping tests due to time pressure, scope pressure, or sunk-cost pressure. |
目标：把“纪律”固化成默认行为。不要先写实现、不要先堆工程量、不要凭感觉说完成。只认：可复现的分析、可执行的计划、可跑的测试、可验证的输出。
口号：不要伤亡报告，我只要塔山。
git commit 并 git push（简短提交信息，按计划命名）。把下面每一项都写进 update_plan，并严格按顺序推进（一次只做一个 in_progress）：
git commit + git push（每个工程计划一个提交）这些场景会诱发“跳步/偷跑”：
基线失败模式（没有这份 Skill 时容易发生）：
| 常见自我说服 | 反制语句（强制执行） |
|---|---|
| “先写实现更快，测试后补” | 先写红测；否则没有目标函数，只有随机游走。 |
| “我已经手动测过了” | 手动不是回归；必须把成功标准固化成测试。 |
| “这次不一样，TDD 太慢” | 一旦说“这次不一样”，说明风险更高，更要 TDD。 |
| “先把架子搭完再补红测” | 这是沉没成本陷阱；先做最小闭环（红→绿），再扩展。 |
| “工程量无所谓，先铺开” | 铺开会放大返工；先把最小 slice 做成可验证闭环。 |
| “提交/推送太麻烦，用户自己来” | 这是交接风险：每个工程计划完成都必须 commit+push，否则不算交付。 |
必须写清楚：
如果缺关键信息：一次只问一个问题，直到能定义测试。
输出 2–3 个方案：
当满足任一条件时，必须写计划文档：
写到：docs/plans/YYYY-MM-DD-<topic>.md
每个 Task 必须包含：
规则：
在声称“完成/修复/通过”之前：
每次交付都要回答：
定义：一个“工程计划”指你当前在执行的那份计划（例如某个 docs/plan/v1-feature-XX-*.md 或一次明确的实现计划）。
规则：只要该工程计划的验收已绿（测试/构建通过），就必须完成一次 git commit 并 git push；否则不算交付完成。
git status --porcelain=v1.gitignore（例如 *.tsbuildinfo）并移除已跟踪文件（git rm --cached ...）git add -Agit commit -m "<short message>"git push提交信息要求：
v1-feature-01: events and sessions）。chore: 用于仓库卫生/工具链调整；docs: 用于纯文档变更。如果推送失败（网络/权限/远程未配置），必须在回顾里明确记录失败原因和下一步；不得“假装已交付”。
看到以上任何一句：停止。回到分析/计划/红测。