[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-76403":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":13,"contributorsCount":14,"subscribersCount":14,"size":14,"stars1d":15,"stars7d":16,"stars30d":17,"stars90d":14,"forks30d":14,"starsTrendScore":18,"compositeScore":19,"rankGlobal":9,"rankLanguage":9,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":23,"hasPages":21,"topics":24,"createdAt":9,"pushedAt":9,"updatedAt":25,"readmeContent":26,"aiSummary":27,"trendingCount":14,"starSnapshotCount":14,"syncStatus":13,"lastSyncTime":28,"discoverSource":29},76403,"AICodingFlow","Terry-Mao\u002FAICodingFlow","Terry-Mao","Setup a AI Coding Flow",null,"Python",126,14,2,0,8,10,81,24,3.53,"MIT License",false,"main",true,[],"2026-06-12 02:03:41","# AICodingFlow\n\nAICodingFlow 是一套面向 AI Coding 的工作流模板。它把本地 Codex SKILL、GitHub Actions、PR Review 自动化和 Spec 驱动开发串在一起，让一个 issue 从规划、实现、审查到合并都能有稳定、可复现的操作路径。\n\n这个仓库主要提供两类能力：\n\n- 本地操作 Git 的 SKILL：帮助开发者创建分支、整理提交、推送分支和创建 PR。\n- GitHub Actions + Codex：在 CI 中装载 SKILL，自动创建 spec、审查 PR，并根据 review 反馈持续优化审查规则。\n\n## 项目背景\n\nAI Coding 最容易出问题的地方通常不是“能不能写代码”，而是流程不稳定：\n\n- 分支命名不一致，issue 和实现脱节。\n- commit 混杂，review 和回滚成本高。\n- PR 描述缺少上下文，reviewer 需要重新追 issue。\n- AI Review 使用实时 PR 状态，line number 和评论位置不稳定。\n- spec、实现和 review 之间缺少明确交接。\n\nAICodingFlow 的目标是把这些步骤标准化。它不追求替代开发者判断，而是把重复、容易出错的流程固化成可检查的 SKILL 和 workflow。\n\n## 工作流概览\n\nAICodingFlow 支持两条主线。\n\n### 本地开发流\n\n```text\nissue -> branch -> commit -> push -> pr -> review -> CI -> merge\n```\n\n适合开发者在本地和 Codex 协作完成常规改动。\n\n核心 SKILL：\n\n- `git-branch`：根据 issue 创建规范分支。\n- `git-worktree`：为并行任务创建独立 worktree。\n- `git-commit`：从真实 diff 中整理原子提交。\n- `git-push`：安全推送当前分支。\n- `create-pr`：创建或更新 GitHub PR。\n\n### Bot 协作流\n\n```text\nissue -> plan -> spec -> develop -> pr -> review -> comments -> merge\n```\n\n适合更复杂的任务，先把需求和技术方案写成 spec，再驱动实现和 review。\n\n当前仓库覆盖两类 Bot 协作：\n\n1. 从 issue 创建 spec 文档，提交 spec PR，PR Review 产生 inline\u002Fbody 级别反馈，修复后合并。\n2. 基于 issue 和已批准 spec 驱动实现，提交实现 PR，PR Review 对照 spec、diff 和仓库规则进行检查，修复后合并。\n\n## 快速开始\n\n克隆仓库并安装本地 SKILL：\n\n```bash\ngit clone git@github.com:Terry-Mao\u002FAICodingFlow.git\ncd AICodingFlow\n\nmkdir -p ~\u002F.agents\u002Fskills\nfor skill in .agents\u002Fskills\u002F*; do\n  [ -d \"$skill\" ] || continue\n  rsync -a \"$skill\u002F\" \"$HOME\u002F.agents\u002Fskills\u002F$(basename \"$skill\")\u002F\"\ndone\n```\n\n如果想先预览将会写入哪些文件：\n\n```bash\nfor skill in .agents\u002Fskills\u002F*; do\n  [ -d \"$skill\" ] || continue\n  rsync -ani \"$skill\u002F\" \"$HOME\u002F.agents\u002Fskills\u002F$(basename \"$skill\")\u002F\"\ndone\n```\n\n安装后，可以在 Codex 对话中直接点名 SKILL：\n\n```text\n$git-branch #47\n$git-worktree #48\n$git-commit\n$git-push\n$create-pr\n```\n\n## 本地开发流\n\n本地开发流围绕 `git-*` SKILL 展开，目标是让每一步都可审查、可回滚、可复现。\n\n### 1. 创建分支\n\n使用 `git-branch` 从 issue 创建分支：\n\n```text\n$git-branch #47\n```\n\n它会：\n\n- 读取 issue 标题和正文。\n- 推断 Conventional Commit 类型，例如 `feat`、`fix`、`docs`。\n- 生成 `\u003Ctype>\u002F\u003Cshort-desc>-\u003CissueID>` 格式的分支名。\n- 用组合命令一次性检查工作树、当前分支和目标分支；只有必要时才检查远端或 fetch。\n- 从 `origin\u002F\u003Cbase>` 直接创建时使用 `--no-track`，避免新分支错误跟踪 base 分支；发布时再由 `git-push` 设置 upstream。\n\n示例：\n\n```text\ndocs\u002Foptimize-readme-47\n```\n\n### 2. 创建并行 worktree\n\n使用 `git-worktree` 为另一个 issue 创建独立工作目录：\n\n```text\n$git-worktree #48\n```\n\n它会：\n\n- 复用 `git-branch` 的命名和 base 分支安全规则。\n- 在 `.worktrees\u002F\u003Cbranch-name>` 下创建新 worktree，保留分支名中的目录层级，例如 `.worktrees\u002Ffeat\u002Fexample-48`。\n- 优先把本地状态检查合并到一次 tool call；远端冲突或 freshness 只有影响结果时才检查。\n- 使用 `git worktree add --no-track -b \u003Cbranch-name> ... \u003Cbase-ref>`，避免新分支跟踪 base 分支。\n- 不复制当前工作树里的未提交改动。\n- 让 Codex 后续 tool calls 默认从新 worktree 运行。\n- 输出你自己的 shell 需要执行的 `cd .worktrees\u002F\u003Cbranch-name>`；Codex 不能改变已有终端进程的当前目录。\n\n### 3. 创建提交\n\n使用 `git-commit` 整理提交：\n\n```text\n$git-commit\n```\n\n它会：\n\n- 用一次组合检查读取 `git status`、diff stat、完整 diff 和 staged diff。\n- 判断变更是否应该拆分。\n- 精确 stage 目标文件，避免误提交无关改动。\n- 使用规范提交信息，例如 `feat(review): add spec context snapshots`。\n- 在存在 native git hook 时走正常 `git commit` 流程，让 hook 自动运行。\n\n### 4. 推送分支\n\n使用 `git-push` 推送当前分支：\n\n```text\n$git-push\n```\n\n它会：\n\n- 用一次组合检查读取当前分支、upstream 和待推送提交。\n- 避免直接推送 `main`、`master`、`develop` 等共享 base 分支。\n- 没有 upstream 时执行 `git push -u origin \u003Cbranch>`。\n- 已有 upstream 时执行普通 `git push`。\n- 遇到 rejected push 时不会默认 force push。\n\n### 5. 创建或更新 PR\n\n使用 `create-pr` 创建或更新 PR：\n\n```text\n$create-pr\n```\n\n它会：\n\n- 检查 PR base diff。\n- 确认 base 分支已经合入当前分支。\n- 生成包含 summary、validation 和 issue link 的 PR 描述。\n- 如果当前分支已有 PR，会更新而不是重复创建。\n- 保留人工写入的 PR 内容，避免覆盖 reviewer 上下文。\n\n## Bot 协作流\n\nBot 协作流用于更复杂或更需要规划的任务。它把“写 spec”和“实现代码”拆成可审查的阶段。\n\n### 流程一：Issue 到 Spec PR\n\n```text\nissue -> plan -> product.md \u002F tech.md -> spec PR -> review -> merge\n```\n\n对应 workflow：\n\n```text\n.github\u002Fworkflows\u002Fcreate-spec-from-issue.yml\n```\n\n它会：\n\n1. 读取 issue、labels、assignees、comments 和触发评论。\n2. 准备稳定的 `issue_context.json` 和 `issue_comments.txt`。\n3. 运行 spec 相关 SKILL：\n   - `spec-driven-implementation`\n   - `write-product-spec`\n   - `create-product-spec`\n   - `write-tech-spec`\n   - `create-tech-spec`\n4. 生成：\n\n```text\nspecs\u002Fissue-\u003CN>\u002Fproduct.md\nspecs\u002Fissue-\u003CN>\u002Ftech.md\npr-metadata.json\n```\n\n5. 验证输出后推送 `spec\u002Fissue-\u003CN>` 分支并创建或更新 spec PR。\n\nSpec PR 只负责规划，不应该实现功能或修改生产代码。\n\n### 流程二：Issue + Spec 到实现 PR\n\n```text\nissue + ready-to-implement -> spec context -> develop -> implementation PR -> AI review -> comments -> merge\n```\n\n实现阶段可以在本地完成，也可以由 `create-implementation-from-issue` workflow 驱动。关键点是：实现必须从稳定的 issue\u002Fspec context 出发，agent 负责写代码、同步必要 spec、运行验证并写出 summary\u002Fmetadata；外层 workflow 负责校验输出、提交并推送分支、创建或更新 PR、更新 issue progress comment。\n\n对应 workflow：\n\n```text\n.github\u002Fworkflows\u002Fcreate-implementation-from-issue.yml\n```\n\n它会：\n\n1. 读取 issue、labels、assignees、comments、默认分支和 spec PR 状态。\n2. 准备稳定的 `issue_context.json`、`issue_comments.txt`，有 spec context 时生成 `spec_context.md`。\n3. 只在 issue 满足 `ready-to-implement` 且已 assign 给配置的 bot 时启动实现。手动触发也不会绕过这两个守卫。\n4. 按优先级解析 spec context：\n   - 带 `plan-approved` label 的 `spec\u002Fissue-\u003CN>` PR。\n   - 默认分支上的 `specs\u002Fissue-\u003CN>\u002Fproduct.md` 和 `tech.md`。\n   - 没有 spec context 时仍可保守实现。\n5. 如果发现未批准 spec PR 且默认分支没有 specs，则 noop，并在 progress comment 中提示先批准计划。\n6. 运行实现相关 SKILL：\n   - `implement-specs`\n   - `spec-driven-implementation`\n   - `implement-issue`\n7. agent 产出实现 diff 时，写 `implementation_summary.md` 和 `pr-metadata.json`，并把代码变更留在工作区。\n8. workflow 校验 metadata，提交并推送 `pr-metadata.json.branch_name`，确认 branch 更新后创建或更新 PR。\n9. implementation PR 默认保持 draft，不自动触发 AI PR Review。需要 review 时，先把 PR 标记为 ready for review，再在 PR conversation comment 中发送 body-level `@AGENT_LOGIN \u002Freview` 或使用手动 workflow dispatch。\n\n目标分支规则：\n\n- 有 approved spec PR：实现直接追加到该 spec PR 的 head branch，让 spec 和实现留在同一个 PR。\n- 没有 approved spec PR：默认使用 `spec\u002Fimplement-issue-\u003CN>`，也允许 metadata 中使用 `spec\u002Fimplement-issue-\u003CN>-\u003Cslug>`。\n\n外层 workflow 会记录 run 开始时 `spec\u002Fimplement-issue-\u003CN>` 及其 slugged branches 的 SHA。这样即使 agent 输出了一个已存在的 slugged branch，也不会把旧内容误判为本次新实现。\n\n`pr-metadata.json` 必须包含：\n\n```json\n{\n  \"branch_name\": \"spec\u002Fimplement-issue-42-add-retry-logic\",\n  \"pr_title\": \"fix: add retry logic for transient API failures\",\n  \"pr_summary\": \"Closes #42\\n\\n## Summary\\n...\",\n  \"intended_files\": [\n    \"src\u002Fapi\u002Fclient.py\",\n    \"tests\u002Ftest_client.py\"\n  ]\n}\n```\n\n`pr_summary` 第一行必须是 `Closes #\u003Cissue-number>`。`intended_files` 必须精确列出外层 workflow 应提交的实现文件，不包含 workflow 临时文件、validation logs、生成缓存或未变化文件。metadata 缺失或无效时，workflow 会先更新 issue progress comment，再让 job 失败，避免用户只看到静默失败。\n\n### 实现 PR Review\n\nAI PR Review 会：\n\n- 在非 draft PR `opened` \u002F `reopened` \u002F `synchronize` \u002F `ready_for_review` 时自动运行。\n- 其他场景默认不自动重跑；需要重新 review 时，在非 draft PR conversation comment 中发送单行 `@AGENT_LOGIN \u002Freview`，或使用手动 workflow dispatch。\n- 生成稳定的 `pr_description.txt`。\n- 生成带行号的 `pr_diff.txt`。\n- 如果能找到相关 spec，生成 `spec_context.md`。\n- 纯 `specs\u002F` PR 使用 `review-spec-repo`。\n- 其他 PR 使用 `review-pr-repo`。\n- 如果 `spec_context.md` 存在，`review-pr` 会加载 `check-impl-against-spec`，把重要 spec drift 当成 review concern。\n- 输出并验证 `review.json`。\n- 通过 GitHub API 发布 PR review。\n\n`spec_context.md` 的查找顺序：\n\n1. 找到当前 PR 关联 issue。\n2. 优先查找 `spec\u002Fissue-\u003CN>` 分支上的 open PR，并要求带 `plan-approved` label。\n3. 如果没有 approved spec PR，则从 PR base commit\u002Fref 上读取 `specs\u002Fissue-\u003CN>\u002Fproduct.md` 和 `tech.md`。\n4. 如果都没有，就不生成 `spec_context.md`。\n\n这保证 review 使用的 spec context 和 `pr_diff.txt` 的 base 语境一致，不会错误读取 implementation PR 自己的 head 内容。\n\n## SKILL 一览\n\n| SKILL | 用途 |\n| --- | --- |\n| `git-branch` | 根据 issue 或任务描述创建规范分支。 |\n| `git-worktree` | 为并行 issue 或任务创建独立 worktree，并让 Codex 后续操作默认进入该目录。 |\n| `git-commit` | 从真实 diff 中整理原子提交。 |\n| `git-push` | 安全推送分支，避免误推 base 分支或强推。 |\n| `create-pr` | 创建或更新 GitHub PR。 |\n| `write-product-spec` | 编写面向行为和验收标准的 product spec。 |\n| `write-tech-spec` | 编写贴合当前代码结构的 technical spec。 |\n| `create-product-spec` | GitHub issue 场景下的 product spec 包装器。 |\n| `create-tech-spec` | GitHub issue 场景下的 tech spec 包装器。 |\n| `spec-driven-implementation` | 组织 spec-first 的开发流程。 |\n| `implement-specs` | 从已批准 spec 推进实现，并保持 spec 与实现一致。 |\n| `implement-issue` | GitHub issue 实现场景包装器，约束 target branch、summary、metadata 和 push 边界。 |\n| `review-pr` | 从稳定快照审查普通 PR，输出 `review.json`。 |\n| `review-pr-repo` | AICodingFlow 仓库的普通 PR review 包装器。 |\n| `review-spec` | 审查纯 spec PR 的文档质量。 |\n| `review-spec-repo` | AICodingFlow 仓库的 spec review 包装器。 |\n| `check-impl-against-spec` | 对照 `spec_context.md` 检查实现是否偏离 spec。 |\n| `update-pr-review` | 从人工反馈中更新本仓库的 review companion SKILL。 |\n\n## GitHub Actions\n\n### AI PR Review\n\n文件：\n\n```text\n.github\u002Fworkflows\u002Freview-pr.yml\n```\n\n主要步骤：\n\n1. 先运行轻量 preflight，解析 PR 并确认它是 open、same-repo、非 draft。\n2. draft PR 或 fork PR 只记录 skip，不启动 AI review job。\n3. checkout PR head。\n4. 生成 `pr_description.txt`。\n5. 生成 `pr_diff.txt`。\n6. 根据 changed files 选择 review skill。\n7. 按需生成 `spec_context.md`。\n8. 运行 `openai\u002Fcodex-action@v1`。\n9. 验证 `review.json`。\n10. 发布 GitHub PR review。\n11. 上传 artifact。\n\n需要配置：\n\n| 名称 | 类型 | 说明 |\n| --- | --- | --- |\n| `OPENAI_API_KEY` | Actions secret | Codex action 使用的 API key。 |\n| `OPENAI_API_ENDPOINT` | Actions variable | Responses API endpoint，可填写 base URL 或 `\u002Fresponses` URL。 |\n| `AGENT_LOGIN` | Actions variable | PR conversation comment 中通过 `@AGENT_LOGIN \u002Freview` 指令手动触发 AI review。 |\n| `GITHUB_TOKEN` | GitHub 内置 token | workflow 自动提供，用于发布 PR review。 |\n\nWorkflow 权限：\n\n```yaml\npermissions:\n  contents: read\n  pull-requests: write\n```\n\n### Create Spec From Issue\n\n文件：\n\n```text\n.github\u002Fworkflows\u002Fcreate-spec-from-issue.yml\n```\n\n这个 workflow 用于把 ready issue 转成 spec PR。它可以手动触发，也可以由 issue label、assignee 或 comment mention 触发，但所有入口都必须经过 `ready-to-spec` 和目标 agent assignment \u002F mention 守卫。若 issue 已经带有 `ready-to-implement`，spec workflow 不再启动，避免同一个 issue 同时进入 spec 和 implementation 阶段。\n\n需要配置：\n\n| 名称 | 类型 | 说明 |\n| --- | --- | --- |\n| `AGENT_LOGIN` | Actions variable | 被分配或 mention 时触发 AI workflow 的 agent 登录名。 |\n| `OPENAI_API_KEY` | Actions secret | Codex action 使用的 API key。 |\n| `OPENAI_API_ENDPOINT` | Actions variable | Responses API endpoint。 |\n\n### Create Implementation From Issue\n\n文件：\n\n```text\n.github\u002Fworkflows\u002Fcreate-implementation-from-issue.yml\n```\n\n这个 workflow 用于把 `ready-to-implement` issue 交给 Codex 实现。它可以手动触发，也可以由 issue label、assignee 或 comment mention 触发，但所有入口都必须经过 readiness 和 bot assignment 守卫。Spec PR 的 `plan-approved` label 只作为 spec context 的批准信号，不作为 workflow 触发源。创建或更新 implementation PR 后不会自动触发 AI PR Review，因为该 PR 仍是 draft；需要 review 时，先把 PR 标记为 ready for review，再在 PR conversation comment 中发送 body-level `@AGENT_LOGIN \u002Freview`。\n\n需要配置：\n\n| 名称 | 类型 | 说明 |\n| --- | --- | --- |\n| `AGENT_LOGIN` | Actions variable | 被分配或 mention 时触发 AI workflow 的 agent 登录名。 |\n| `OPENAI_API_KEY` | Actions secret | Codex action 使用的 API key。 |\n| `OPENAI_API_ENDPOINT` | Actions variable | Responses API endpoint。 |\n\n主要输出 artifact：\n\n```text\nissue_context.json\nissue_comments.txt\nspec_context.md\nbranch-start-shas.json\nimplementation_summary.md\npr-metadata.json\nvalidation-output.txt\nvalidation-error.txt\n```\n\n### Update PR Review\n\n文件：\n\n```text\n.github\u002Fworkflows\u002Fupdate-pr-review.yml\n```\n\n这个 workflow 聚合人工对 bot review 的反馈，并更新：\n\n```text\n.agents\u002Fskills\u002Freview-pr-repo\u002FSKILL.md\n.agents\u002Fskills\u002Freview-spec-repo\u002FSKILL.md\n```\n\n它只允许写 repo-local companion skill，不允许修改核心 review contract。\n\n## 目录结构\n\n```text\n.agents\u002Fskills\u002F                  # Codex SKILL\n.github\u002Fworkflows\u002F               # GitHub Actions workflow\n.github\u002Fscripts\u002F                 # workflow 使用的 Python helper\nspecs\u002F                           # issue 对应的 product\u002Ftech spec\ntests\u002F                           # Python unittest 测试\n```\n\n常用脚本：\n\n| 脚本 | 用途 |\n| --- | --- |\n| `build_pr_diff.py` | 把 git diff 转成稳定的 `PR_DIFF_V1`。 |\n| `write_pr_description.py` | 从 GitHub event 写出 PR 描述快照。 |\n| `select_review_skill.py` | 根据 changed files 选择 review skill。 |\n| `write_spec_context.py` | 为实现 PR 解析并格式化 spec context。 |\n| `post_pr_review.py` | 把 `review.json` 发布成 GitHub PR review。 |\n| `prepare_issue_spec_context.py` | 为 spec 生成准备稳定 issue context。 |\n| `prepare_issue_implementation_context.py` | 为 issue 实现准备稳定 context、spec context 和 target branch。 |\n| `validate_spec_output.py` | 校验 spec workflow 输出。 |\n| `validate_implementation_output.py` | 校验 implementation workflow 的 `pr-metadata.json`。 |\n| `commit_implementation_branch.py` | 把 Codex 留在工作区的实现 diff 提交并推送到 metadata 指定分支。 |\n| `read_branch_sha.py` | 读取 implementation branch SHA，并记录 run-start snapshot。 |\n| `finalize_implementation_pr.py` | 创建或更新 implementation PR 或 approved spec PR。 |\n| `update_implementation_progress.py` | 创建或更新 issue implementation progress comment。 |\n| `validate_review_json.py` | 校验 AI review 输出结构和 inline 目标。 |\n\n## 在其他仓库中使用\n\n复制 `.agents\u002F` 和 `.github\u002F`：\n\n```bash\nrsync -a .agents\u002F \u002Fpath\u002Fto\u002Ftarget-repo\u002F.agents\u002F\nrsync -a .github\u002F \u002Fpath\u002Fto\u002Ftarget-repo\u002F.github\u002F\n```\n\n然后在目标仓库中：\n\n1. 提交复制后的文件。\n2. 配置 `OPENAI_API_KEY` 和 `OPENAI_API_ENDPOINT`。\n3. 配置 `AGENT_LOGIN`，用于 spec 和 implementation workflow 的 assignment \u002F mention gate。\n4. 根据目标仓库调整 `review-pr-repo` 和 `review-spec-repo` 的 repo-specific guidance。\n\n## 本地开发与测试\n\n运行全部测试：\n\n```bash\npython3 -m unittest discover -s tests\n```\n\n建议在修改 workflow 或 review 相关脚本后额外检查：\n\n```bash\nPYTHONPYCACHEPREFIX=\u002Ftmp\u002Faicodingflow-pycache python3 -m py_compile \\\n  .github\u002Fscripts\u002F*.py \\\n  .agents\u002Fskills\u002Fimplement-specs\u002Fscripts\u002F*.py \\\n  .agents\u002Fskills\u002Freview-pr\u002Fscripts\u002Fvalidate_review_json.py \\\n  .agents\u002Fskills\u002Fupdate-pr-review\u002Fscripts\u002F*.py\n```\n\n如果修改 GitHub Actions，也应确认 YAML 能被解析。\n\n## 设计原则\n\n- 先稳定上下文，再让 AI 工作：PR review 使用 `pr_description.txt`、`pr_diff.txt` 和可选 `spec_context.md`。\n- 控制逻辑使用结构化数据，给 agent 阅读时再格式化成 markdown。\n- 本地 SKILL 不应该做危险操作，例如默认 force push、广泛 staging 或删除用户文件。\n- CI 中的 review skill 不直接调用 GitHub API，不发布评论，只写 `review.json`。\n- repo-local companion 可以补充审查偏好，但不能覆盖核心 schema、severity、diff-line targeting 和 validator 规则。\n\n## 反馈与问题排查\n\n如果遇到问题，请在 issue 或 PR 中提供：\n\n- 你正在运行的 SKILL 或 workflow。\n- 分支名、issue number、PR 链接。\n- 相关命令输出或 GitHub Actions 日志。\n- 对 PR review 问题，尽量附上 artifact：\n\n```text\npr_description.txt\npr_diff.txt\nspec_context.md\nreview.json\n```\n\n对 implementation workflow 问题，优先附上：\n\n```text\nissue_context.json\nspec_context.md\nbranch-start-shas.json\nimplementation_summary.md\npr-metadata.json\nvalidation-error.txt\n```\n\n这些快照能帮助复现 line number、inline comment 和 spec context 相关问题。\n","AICodingFlow 是一套面向 AI 编程的工作流模板，旨在通过标准化流程提高开发效率。其核心功能包括本地 Git 操作 SKILL 和基于 GitHub Actions 的自动化审查机制。本地 SKILL 能帮助开发者创建和管理分支、整理提交、推送代码及创建 PR；而 GitHub Actions 则能在持续集成中自动创建规范、审查 PR 并根据反馈优化审查规则。此项目特别适合需要在本地与 Codex 协同完成任务的场景，以及更复杂的需求分析和技术方案实施过程，确保从规划到合并每个环节都有稳定可复现的操作路径。","2026-06-11 03:55:03","CREATED_QUERY"]