antarx-dev-skills

使用本地 dida CLI 创建滴答清单任务。适用于用户提示词同时提到“滴答清单”和“创建任务”，或明确要求 Codex 基于当前项目和对话上下文创建滴答清单任务。

当用户提及“代码仓初始化”“初始化代码仓”“初始化目录”“初始化项目结构”“初始化项目文档路径”“初始化 Codex 持续开发工作流”“初始化 antarx-harness 文档体系”或明确要求执行 `/init` 命令时触发；若同时提及 simple、lightweight、轻量、极简、轻量 harness、初始化轻量 harness、轻量化 agent 流程等表达，则使用轻量分支。用于在当前项目目录创建缺失的 AGENTS.md、ARCHITECTURE.md 与 docs 工作流骨架，必要时初始化 Git 仓库，并提交本次新增文档；若已有 AGENTS.md 与模板不同，必须由 agent 比对并合成为一份。

用于在完成真实任务后，判断经验、坑、约束或流程应沉淀到 Codex 架构的哪一层。触发场景包括“这次学到的规则该写到哪”、“我刚踩了一个坑想沉淀”、“帮我判断该进 AGENTS.md 还是 skill”、“有个新流程不知道放哪”。

当本轮使用 skill-creator 创建或更新 skill 后使用；询问用户是否将该 skill 纳入 antarx-dev-skills 托管。用户确认前不得导入、同步、删除或修改任何 skill；用户只同意托管但未指定分类时，先判断合适分类并使用该分类继续导入。

当 Codex 需要从任意项目会话中捕获、改进或回填可复用工作流知识到 antarx-dev-skills 仓库时使用。触发场景包括“沉淀技能”“改良技能”“同步回技能仓库”“把这个流程做成 skill”，或更新现有 Codex skill，并更新本地链接安装、打开 GitHub PR。

在创建新技能、修改已有技能或发布前验证技能有效性时使用。

Initialize an Obsidian vault as a Codex cross-project long-term memory store. Use when the user asks to "初始化obsidian codex memory", "初始化 Obsidian Codex 记忆", "初始化记忆", or otherwise mentions both memory/记忆 and initialization/初始化 for Codex or Obsidian.

判断已完成任务是否产生了长期有效知识，并更新 Codex Memory Markdown 知识库。适用于用户要求更新 Codex memory、写入 memory、memory closeout、沉淀记忆、更新记忆、更新 codex memory，或重要任务结束后需要记录可复用偏好、流程、决策、项目路径、已验证排查结论、未闭环事项的场景。

用于仓库需求澄清。当用户明确要求“需求澄清”“重新澄清”“继续澄清”“帮我澄清需求”“重新梳理需求边界”，或在设计、规划、实现前提出类似澄清诉求时使用。

需求澄清完成后，用于产出仓库对齐的设计文档与分阶段开发计划。适用于用户明确要求撰写设计文档、开发计划或二者同时产出时。必须遵循“需求澄清 -> 设计文档 -> 开发计划”的顺序。

在已有规格或需求、且任务需要多步骤实施时使用；必须在动代码前使用。

当用户明确提到架构设计、模块设计、模块划分、模块边界、职责划分、系统分层、组件关系、模块关系、依赖方向或数据流设计时使用；用于和用户充分讨论并产出架构层方案，禁止进入代码实现细节或把架构设计作为具体开发需求管理。

回顾近期 Codex 工作、memory notes、rollout summaries、可选 Chronicle discovery，以及现有 skills、custom agents 和 automations，识别值得封装的重复手工 workflow。Use when the user asks for “复盘”, “回顾”, “review”, “look back”, “retrospective”, or similar wording to find reusable workflow opportunities, create high-confidence missing skills, custom subagents, or automations, or decide whether to extend existing assets instead of duplicating them.

Build or refactor native-feeling Settings/Preferences windows for SwiftUI + macOS apps. Use when creating a dedicated Settings window scene, implementing sidebar-plus-detail Settings architecture with NavigationSplitView, stabilizing title/toolbar behavior, designing Form/Section/LabeledContent/TextField rows, choosing draft/save/immediate persistence patterns, and enforcing localization/accessibility/concurrency-safe settings workflows.

迁移已有 vibe coding 项目的文档管理体系到 antarx-harness 文档体系持续开发结构。Use when reorganizing an existing project's requirements, clarification notes, design docs, execution plans, AGENTS.md, ARCHITECTURE.md, and docs/ hierarchy into the Codex project-bootstrap layout, especially for requests like “项目结构迁移”, “迁移项目文档结构”, “把已有项目迁移到 antarx-harness 文档体系”, or “整理 vibe coding 项目的 docs 和 AGENTS”.

仅在用户明确要与代理讨论/共创设计，或需求仍明显不清晰且存在实质性方案权衡、正在进入设计阶段时使用。

当存在 2 个及以上彼此独立、无共享状态且无顺序依赖的任务时使用，用于并行派发子代理提升排障与实现效率。

在接收代码评审意见并准备落地前使用，尤其适用于评审意见不清晰或技术上可疑时。要求先验证再实现，避免表演式认同和盲从执行。

在任务完成、重大功能落地后或合并前使用，用于发起代码评审并在问题扩散前发现风险。

当用户要求“回合根源分支”“合回根源分支”“合并回主分支”“回到真正代码目录”，或要求把临时 worktree 分支合回源分支/根分支、把 worktree 改动集成回主代码目录时使用。

仅在明确需要隔离时使用（并行工作、脏工作区风险，或用户要求）。创建 worktree 前先请求用户批准，并说明为什么需要它。

在用户提及“验收通过”“测试通过”“总结变更”“提交更改”“提交改动”“保持工作区干净”“清理工作区”“收尾记录”等表示当前需求或开发计划已完成的语义时使用。

遇到任何 bug、测试失败或异常行为时，在提出修复方案前使用。要求先定位根因，再实施修复。

在实现任何功能或修复缺陷前使用。遵循先写失败测试（RED）、再最小实现（GREEN）、再重构（REFACTOR）的循环。

在声称“已完成/已修复/已通过”之前使用，尤其在提交或创建 PR 前。要求先运行验证命令并核对输出，再做任何成功陈述。

设计与增强 JSON Schema。仅在用户明确要求进行 JSON Schema 的设计、补全、扩展、增强、字段调整、结构优化或提案整理时使用；若用户仅讨论 schema 概念、规范或含义而未要求执行设计或修改，不触发。触发后默认先检查当前工作目录的 schemas/ 目录；若不存在，则要求用户提供目标 schema 文件路径或文件本身。

Enforce disciplined UI layout implementation and review for SwiftUI, web UI, or other declarative UI work. Use when creating, refactoring, or fixing layouts with padding, spacing, margins, insets, frames, flex/grid/stack/list/form containers, ScrollView/List/GeometryReader, clipping, overflow, cards, rows, sidebars, inspectors, chat surfaces, or any symptom such as unexpected blank space, clipped content, stretched content, misalignment, nested wrappers, or fixed-size hacks.