oh-my-claudecode 的 .omc 状态哪些该提交、哪些该忽略gitignore 契约与清理规则【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode用 oh-my-claudecodeOMC驱动 Claude Code 跑过几次会话后项目根目录会出现一个.omc/目录里面是模式状态、会话笔记、计划、日志和 team 交接物。这个目录混着两类内容一类是运行时状态可能包含 prompts、transcripts、绝对路径、机器标识符和工作流历史不应进仓库另一类是唯一被文档标明“有意提交”的子树.omc/skills/。本文依据 docs/REFERENCE.md 中的状态根契约、docs/ARCHITECTURE.md 的目录结构说明以及仓库自带的.gitignore契约测试回答三个问题哪些该提交、哪些该忽略、哪些可以安全清理。.omc/里有什么先分清要决策的对象docs/REFERENCE.md 把默认状态根.omc/下的内容列为子树内容.omc/state/、.omc/state/sessions/{sessionId}/模式状态、会话级状态、回放标记、恢复元数据.omc/notepad.md、.omc/project-memory.json本地会话笔记、项目记忆.omc/plans/、.omc/research/、.omc/logs/、.omc/artifacts/、.omc/handoffs/、.omc/ultragoal/生成的计划、研究产物、日志、advisor 工件、team 交接、ultragoal 账本.omc/team/team worktree 模式下的原生 worker worktree可选启用.omc/skills/唯一在团队希望共享 OMC 编写的技能时被预期提交的项目本地.omc子树docs/ARCHITECTURE.md 给出的目录树还包含notepads/{plan-name}/按计划的 learnings/decisions/issues/problems 笔记、prompts/持久化的 prompt/response 工件和autopilot/spec.md全部都属于机器本地的运行产物。gitignore 契约目录可见、内容忽略、skills 重新包含仓库根目录 .gitignore 中与.omc/相关的契约只有四行顺序即契约的一部分!.omc/ .omc/* !.omc/skills/ !.omc/skills/**语义来自 docs/REFERENCE.md 的原文.gitignore刻意保持保守——让.omc/目录本身保持可见忽略.omc/*下的一切再把.omc/skills/及其内容重新包含进来。效果是生成的状态默认全部不被 git 跟踪而项目技能可以被审阅后显式提交。行顺序有实际含义先重新包含目录!.omc/才能谈得上忽略其内容先忽略.omc/*才能谈得上重新包含 skills。仓库用契约测试 src/tests/omc-state-gitignore-contract.test.ts 把这四行内容及其相对顺序固定下来防止后续改动意外破坏这一约定。该提交的只有.omc/skills/.omc/skills/项目本地技能的规范目录docs/REFERENCE.md 也确认运行时以.omc/skills/为 OMC 的 canonical 项目技能目录。团队要共享 OMC 编写的技能时把它提交进仓库即可。运行时文件不要git add -f文档明确写道除非你是在把一份 sanitized 工件刻意附到 issue 或测试 fixture 上否则不要强制添加运行时.omc文件——运行时状态可能包含 prompts、transcripts、绝对路径、机器标识符和工作流历史这正是数据/安全上最不该入库的内容。计划文件另说.omc/plans/下的默认生成计划是本地操作产物被忽略。如果某个计划要成为持久的项目文档把它移到受跟踪的 docs 路径或把planOutput.directory配置为受审阅的目录如docs/plans机器本地的会话状态继续留在.omc/docs/REFERENCE.md。.omc/handoffs/是有意共享、有意不提交的它用于 team 阶段交接plan → prd → exec → verify的跨会话消息传递只有teamskill 可以写入由 lint 测试tests/lint/handoffs-writers.test.ts强制。交接文件按设计在 team 取消和 OMC 状态清理之后仍然存在属于事后审查工件也不应按会话作用域化它docs/REFERENCE.md。清理规则哪些可以删删之前要停掉什么清理规则出自 docs/REFERENCE.md前提条件是OMC 会话已停止且你不再需要这些子树的恢复/审计历史可以安全删除的忽略子树.omc/state/、.omc/logs/、.omc/artifacts/、.omc/research/、.omc/ultragoal/。副作用是失去对应会话的状态恢复与回放能力删除前确认没有还在跑或需要恢复的 OMC 会话。不要删除.omc/skills/除非你确实要移除这些项目级技能。会话级状态有明确边界issue #3873docs/REFERENCE.md带session_id的.omc/state/sessions/id/下的状态文件只对那个会话权威不能挂接、恢复或解除另一个会话OMC 不做基于时间的会话取消空闲时间不是会话结束的证据。因此清理工具必须保留会话拥有的文件不能按时间阈值删除活动状态。.omc/handoffs/按设计不被清理覆盖不要把它当临时文件处理。验证确认契约在你项目里生效仓库自带契约测试在仓库根目录运行npx vitest run src/__tests__/omc-state-gitignore-contract.test.ts它检查.gitignore同时包含上述四行且!.omc/.omc/*!.omc/skills/!.omc/skills/**的顺序不变。在自己的项目里核对行为时可以用 git 自带的忽略规则检查示例中autopilot-state.json是 docs/ARCHITECTURE.md 目录树里列出的真实状态文件名skill-name需替换为你项目里实际存在的技能目录名# 预期命中 .omc/* 规则输出该规则及行号 —— 文件被忽略 git check-ignore -v .omc/state/autopilot-state.json # 预期无输出退出码非 0—— 被 !.omc/skills/** 重新包含可被 git 跟踪 git check-ignore -v .omc/skills/skill-name/SKILL.md预期结果按契约语义给出运行时状态文件被忽略、skills 下的文件不被忽略。再配合git status检查正常情况下.omc/下的生成状态不会以 untracked 文件形式出现只有.omc/skills/下的内容会等待你显式添加。可选分支把状态整体移出仓库OMC_STATE_DIR如果问题不是“仓库里该提交什么”而是“worktree 删除后状态跟着没了”文档给出集中式状态方案docs/REFERENCE.md、docs/ARCHITECTURE.md# 在 shell profile~/.bashrc、~/.zshrc 等中 export OMC_STATE_DIR$HOME/.claude/omc设置后状态写入$OMC_STATE_DIR/{project-id}/而不是{worktree}/.omc/状态因此位于仓库之外、可跨 worktree 删除存活project id 取自 git remote URL 的哈希本地仓库回退到目录路径哈希同一仓库的不同 worktree 共享状态。两个必须知道的限制设置变量不会迁移已有内容。先复制或迁移遗留状态再启用集中式根否则旧的计划、notepad 和项目记忆仍留在原.omc/位置且不再可见。当遗留{worktree}/.omc/与集中式目录同时存在时OMC 会记录一条提示并采用集中式目录之后由你迁移并移除遗留目录。另有两点与状态根相关的说明没有OMC_STATE_DIR时每个 linked worktree 有自己独立的{worktree}/.omc/删除 worktree 即删除其本地状态多仓库工作区多个独立仓库共享一个非 git 父目录用.omc-workspace标记文件把.omc/锚定到父目录该方案面向多仓库工作区而非普通 monorepo。边界小结提交只有.omc/skills/docs/REFERENCE.md 明示这是唯一被预期提交的项目本地.omc子树。忽略.omc/下的其余全部生成状态由四行 gitignore 契约保证且被契约测试锁定。清理会话停止后按需删除.omc/state/、.omc/logs/、.omc/artifacts/、.omc/research/、.omc/ultragoal/不删.omc/skills/不按时间阈值动会话拥有的状态.omc/handoffs/按设计保留。强制添加运行时.omc文件仅限“把 sanitized 工件附到 issue 或测试 fixture”这一种刻意场景。更多状态根解析顺序OMC_STATE_DIR→.omc-workspace→ git toplevel → cwd与 legacy 迁移开关OMC_MIGRATE_LEGACY_STATE的语义见 docs/REFERENCE.md。【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
oh-my-claudecode 的 .omc 状态哪些该提交、哪些该忽略gitignore 契约与清理规则【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode用 oh-my-claudecodeOMC驱动 Claude Code 跑过几次会话后项目根目录会出现一个.omc/目录里面是模式状态、会话笔记、计划、日志和 team 交接物。这个目录混着两类内容一类是运行时状态可能包含 prompts、transcripts、绝对路径、机器标识符和工作流历史不应进仓库另一类是唯一被文档标明“有意提交”的子树.omc/skills/。本文依据 docs/REFERENCE.md 中的状态根契约、docs/ARCHITECTURE.md 的目录结构说明以及仓库自带的.gitignore契约测试回答三个问题哪些该提交、哪些该忽略、哪些可以安全清理。.omc/里有什么先分清要决策的对象docs/REFERENCE.md 把默认状态根.omc/下的内容列为子树内容.omc/state/、.omc/state/sessions/{sessionId}/模式状态、会话级状态、回放标记、恢复元数据.omc/notepad.md、.omc/project-memory.json本地会话笔记、项目记忆.omc/plans/、.omc/research/、.omc/logs/、.omc/artifacts/、.omc/handoffs/、.omc/ultragoal/生成的计划、研究产物、日志、advisor 工件、team 交接、ultragoal 账本.omc/team/team worktree 模式下的原生 worker worktree可选启用.omc/skills/唯一在团队希望共享 OMC 编写的技能时被预期提交的项目本地.omc子树docs/ARCHITECTURE.md 给出的目录树还包含notepads/{plan-name}/按计划的 learnings/decisions/issues/problems 笔记、prompts/持久化的 prompt/response 工件和autopilot/spec.md全部都属于机器本地的运行产物。gitignore 契约目录可见、内容忽略、skills 重新包含仓库根目录 .gitignore 中与.omc/相关的契约只有四行顺序即契约的一部分!.omc/ .omc/* !.omc/skills/ !.omc/skills/**语义来自 docs/REFERENCE.md 的原文.gitignore刻意保持保守——让.omc/目录本身保持可见忽略.omc/*下的一切再把.omc/skills/及其内容重新包含进来。效果是生成的状态默认全部不被 git 跟踪而项目技能可以被审阅后显式提交。行顺序有实际含义先重新包含目录!.omc/才能谈得上忽略其内容先忽略.omc/*才能谈得上重新包含 skills。仓库用契约测试 src/tests/omc-state-gitignore-contract.test.ts 把这四行内容及其相对顺序固定下来防止后续改动意外破坏这一约定。该提交的只有.omc/skills/.omc/skills/项目本地技能的规范目录docs/REFERENCE.md 也确认运行时以.omc/skills/为 OMC 的 canonical 项目技能目录。团队要共享 OMC 编写的技能时把它提交进仓库即可。运行时文件不要git add -f文档明确写道除非你是在把一份 sanitized 工件刻意附到 issue 或测试 fixture 上否则不要强制添加运行时.omc文件——运行时状态可能包含 prompts、transcripts、绝对路径、机器标识符和工作流历史这正是数据/安全上最不该入库的内容。计划文件另说.omc/plans/下的默认生成计划是本地操作产物被忽略。如果某个计划要成为持久的项目文档把它移到受跟踪的 docs 路径或把planOutput.directory配置为受审阅的目录如docs/plans机器本地的会话状态继续留在.omc/docs/REFERENCE.md。.omc/handoffs/是有意共享、有意不提交的它用于 team 阶段交接plan → prd → exec → verify的跨会话消息传递只有teamskill 可以写入由 lint 测试tests/lint/handoffs-writers.test.ts强制。交接文件按设计在 team 取消和 OMC 状态清理之后仍然存在属于事后审查工件也不应按会话作用域化它docs/REFERENCE.md。清理规则哪些可以删删之前要停掉什么清理规则出自 docs/REFERENCE.md前提条件是OMC 会话已停止且你不再需要这些子树的恢复/审计历史可以安全删除的忽略子树.omc/state/、.omc/logs/、.omc/artifacts/、.omc/research/、.omc/ultragoal/。副作用是失去对应会话的状态恢复与回放能力删除前确认没有还在跑或需要恢复的 OMC 会话。不要删除.omc/skills/除非你确实要移除这些项目级技能。会话级状态有明确边界issue #3873docs/REFERENCE.md带session_id的.omc/state/sessions/id/下的状态文件只对那个会话权威不能挂接、恢复或解除另一个会话OMC 不做基于时间的会话取消空闲时间不是会话结束的证据。因此清理工具必须保留会话拥有的文件不能按时间阈值删除活动状态。.omc/handoffs/按设计不被清理覆盖不要把它当临时文件处理。验证确认契约在你项目里生效仓库自带契约测试在仓库根目录运行npx vitest run src/__tests__/omc-state-gitignore-contract.test.ts它检查.gitignore同时包含上述四行且!.omc/.omc/*!.omc/skills/!.omc/skills/**的顺序不变。在自己的项目里核对行为时可以用 git 自带的忽略规则检查示例中autopilot-state.json是 docs/ARCHITECTURE.md 目录树里列出的真实状态文件名skill-name需替换为你项目里实际存在的技能目录名# 预期命中 .omc/* 规则输出该规则及行号 —— 文件被忽略 git check-ignore -v .omc/state/autopilot-state.json # 预期无输出退出码非 0—— 被 !.omc/skills/** 重新包含可被 git 跟踪 git check-ignore -v .omc/skills/skill-name/SKILL.md预期结果按契约语义给出运行时状态文件被忽略、skills 下的文件不被忽略。再配合git status检查正常情况下.omc/下的生成状态不会以 untracked 文件形式出现只有.omc/skills/下的内容会等待你显式添加。可选分支把状态整体移出仓库OMC_STATE_DIR如果问题不是“仓库里该提交什么”而是“worktree 删除后状态跟着没了”文档给出集中式状态方案docs/REFERENCE.md、docs/ARCHITECTURE.md# 在 shell profile~/.bashrc、~/.zshrc 等中 export OMC_STATE_DIR$HOME/.claude/omc设置后状态写入$OMC_STATE_DIR/{project-id}/而不是{worktree}/.omc/状态因此位于仓库之外、可跨 worktree 删除存活project id 取自 git remote URL 的哈希本地仓库回退到目录路径哈希同一仓库的不同 worktree 共享状态。两个必须知道的限制设置变量不会迁移已有内容。先复制或迁移遗留状态再启用集中式根否则旧的计划、notepad 和项目记忆仍留在原.omc/位置且不再可见。当遗留{worktree}/.omc/与集中式目录同时存在时OMC 会记录一条提示并采用集中式目录之后由你迁移并移除遗留目录。另有两点与状态根相关的说明没有OMC_STATE_DIR时每个 linked worktree 有自己独立的{worktree}/.omc/删除 worktree 即删除其本地状态多仓库工作区多个独立仓库共享一个非 git 父目录用.omc-workspace标记文件把.omc/锚定到父目录该方案面向多仓库工作区而非普通 monorepo。边界小结提交只有.omc/skills/docs/REFERENCE.md 明示这是唯一被预期提交的项目本地.omc子树。忽略.omc/下的其余全部生成状态由四行 gitignore 契约保证且被契约测试锁定。清理会话停止后按需删除.omc/state/、.omc/logs/、.omc/artifacts/、.omc/research/、.omc/ultragoal/不删.omc/skills/不按时间阈值动会话拥有的状态.omc/handoffs/按设计保留。强制添加运行时.omc文件仅限“把 sanitized 工件附到 issue 或测试 fixture”这一种刻意场景。更多状态根解析顺序OMC_STATE_DIR→.omc-workspace→ git toplevel → cwd与 legacy 迁移开关OMC_MIGRATE_LEGACY_STATE的语义见 docs/REFERENCE.md。【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
