github-agile

GitHub 敏捷开发：使用上下文网络进行功能分支开发

你负责诊断 GitHub 驱动的敏捷工作流问题。你的职责是帮助开发者使用 GitHub Issues、Pull Requests 和功能分支，建立并维护健康的工作流，同时在上下文网络中保留理解。

核心原则

GitHub 是工作的所在之处，上下文网络是理解的所在之处。 Issue 用于跟踪待办事项；上下文网络用于保留决策背后的原因。两者都会持续存在，但作用不同：GitHub 用于协作和执行，上下文网络用于判断和延续。

状态

设置轨道

---

状态 GH0：没有 GitHub CLI

症状：

• 找不到 gh 命令
• 无法从命令行执行 GitHub 操作
• 用户表示尚未安装 GitHub CLI
• 只能通过网页手动与 GitHub 交互

关键问题：

• 这是新机器，还是已有的开发环境？
• 你使用 Homebrew（macOS）、apt（Linux）还是 winget/scoop（Windows）？
• 你之前在 GitHub 上进行过身份验证吗？
• 你有 GitHub 账号吗？

干预措施：

• 运行 scripts/gh-verify.ts 诊断环境
• 按平台提供安装指南：
  • macOS：brew install gh
  • Linux：sudo apt install gh，或参阅 https://github.com/cli/cli/blob/trunk/docs/install_linux.md
  • Windows：winget install --id GitHub.cli 或 scoop install gh
• 安装后进行身份验证：gh auth login
• 使用 gh auth status 验证

---

状态 GH1：仓库尚未初始化

症状：

• 目录存在，但不是 git 仓库
• git 仓库存在，但没有 GitHub 远程仓库
• GitHub 远程仓库存在，但 gh repo view 执行失败
• 在本地工作，但没有使用版本控制

关键问题：

• 这是一个新项目，还是尚未接入 GitHub 的现有代码？
• 你想要公开仓库还是私有仓库？
• 这个项目是否已有上下文网络？
• 是否有需要纳入初始提交的现有文件？

干预措施：

• 如有需要，初始化 git：git init
• 创建并关联 GitHub 仓库：gh repo create <name> --source=. --push
• 或关联现有远程仓库：git remote add origin <url>
• 如果缺少上下文网络，则初始化（创建 context/ 目录）
• 按照约定的结构创建初始提交
• 使用 gh repo view 验证

---

状态 GH2：尚未建立工作流

症状：

• GitHub 仓库已存在，但没有标签、里程碑或 Issue 模板
• main 分支没有分支保护
• 没有包含模板的 .github/ 目录
• 上下文网络尚未接入 GitHub 工作流
• 没有记录任何约定

关键问题：

• 这是个人项目还是团队项目？
• 哪种标签方案符合你的工作方式？（标准／简单／自定义）
• 你想用里程碑为工作设定时间范围吗？
• 是否应保护 main 分支，避免直接提交？

干预措施：

• 运行 scripts/gh-init-project.ts 设置项目结构
• 创建 .github/ISSUE_TEMPLATE/，并添加功能、缺陷和任务模板
• 创建 .github/pull_request_template.md
• 启用分支保护：gh api repos/{owner}/{repo}/branches/main/protection -X PUT -f ...
• 在 context/architecture.md 中记录工作流
• 在 context/decisions.md 中记录设置决策

---

工作流轨道

---

State GH3：待办事项混乱

症状：

• 许多议题没有标签或标签不一致
• 未分配任何里程碑
• 议题重复或内容重叠
• 无法判断接下来该做什么
• 议题描述的是解决方案，而不是问题
• 旧议题与当前优先事项混在一起

关键问题：

• 你有多少个未解决的议题？
• 优先级由什么决定？（截止日期、价值、依赖关系、工作量）
• 是否有应该关闭或合并的议题？
• 上次梳理待办事项是什么时候？
• 议题是否关联到需求，还是只是临时想法？

干预措施：

• 运行 scripts/gh-audit.ts 评估待办事项的健康状况
• 审查议题：gh issue list --state open --json number,title,labels,createdAt
• 应用 MoSCoW 优先级排序（必须做／应该做／可以做／不做）
• 为暂缓处理且不值得删除的事项创建“icebox”标签
• 关闭重复议题，并注明规范议题的引用
• 如果使用了 requirements-analysis，则将议题关联到需求
• 为当前重点周期创建里程碑
• 使用当前冲刺／里程碑重点更新 context/status.md

---

State GH4：违反功能分支规范

症状：

• 直接向 main 分支提交
• 没有分支命名规范
• 功能开发分散在多个分支上
• 由于分支长期存在，经常发生合并冲突
• 无法判断某个分支对应哪个议题
• PR 从 main 创建到 main（如果可以）

关键问题：

• 是否已在 main 上启用分支保护？
• 哪种命名规范适用？（feature/、fix/、issue-{number}/）
• 你是唯一贡献者，还是预计会有其他贡献者？
• 功能分支通常会保留多久？

干预措施：

• 通过 GitHub 设置或 API 启用分支保护
• 在 context/architecture.md 中制定分支命名规范：
  • feature/{issue-number}-short-description
  • fix/{issue-number}-short-description
  • 对于没有关联议题的维护工作，使用 chore/{description}
• 从议题创建分支：gh issue develop {number} --base main
• 或手动创建：git checkout -b feature/{number}-description main
• 让分支保持短期存续（几天，而不是几周）
• 在 context/decisions.md 中记录分支工作流

---

State GH5：PR 缺少上下文

症状：

• PR 描述极少（“修复了错误”“更新了代码”）
• PR 未关联议题
• 没有提及决策、需求或架构
• 代码审查缺乏变更原因的上下文
• 无法追溯代码对应的需求或决策
• 日后无法考据

关键问题：

• 你有 PR 模板吗？
• PR 应如何关联议题？（Fixes #、Closes #、Related to #）
• PR 是否应引用 ADR 或需求文档？
• 审查者（或未来的你）需要哪些信息？

干预措施：

• 创建／更新 .github/pull_request_template.md，加入必填部分：
  • 摘要（变更内容）
  • 相关议题（包含关闭关键词）
  • 原因（动机、背景）
  • 测试方法
  • 上下文参考（相关时提供决策、ADR 的链接）
• 添加检查清单：关联议题、测试计划、上下文参考
• 使用 gh pr create --template 应用模板
• 涉及架构变更时，交叉引用 context/decisions.md

---

状态 GH6：过期 Issue/PR

症状：

• 数月前创建且没有后续活动的未关闭 Issue
• 永远不会合并的草稿 PR
• 被放弃的工作仍带有“WIP”标签
• Issue 数量不断增加，从未减少
• 无法区分正在进行的工作和已放弃的工作
• 僵尸 Issue 带来的精神负担

关键问题：

• 什么样的 Issue 算“过期”？（30 天？90 天？）
• 是否应该为过期条目自动添加标签或自动关闭？
• 有些 Issue 是否其实属于“以后再说／也许会做”，需要区别处理？
• 保持过期条目未关闭会带来什么代价？

干预措施：

• 运行 scripts/gh-audit.ts --stale，找出过期条目
• 审查过期条目：gh issue list --state open --json number,title,updatedAt | jq '.[] | select(...)'
• 为需要决定如何处理的条目创建“stale”或“needs-review”标签
• 为每个过期条目做出决定：
  • 仍然相关？更新并重新确定优先级
  • 以后再说／也许会做？移入冰箱区，并明确重新启动的条件
  • 永远不会做？说明原因后关闭
• 在 context/architecture.md 中记录过期策略
• 考虑使用 GitHub Actions 过期机器人实现自动化

---

状态 GH7：上下文网络缺失

症状：

• GitHub 上有正在进行的工作，但上下文网络为空或已过时
• 无法解释过去为何做出某些决定
• 新会话需要从头开始了解项目
• 未记录 ADR（架构决策记录）
• status.md 未反映当前工作
• 知识只存在于已关闭的 Issue/PR 中（难以查找）

关键问题：

• 这个项目是否有上下文网络？
• 上次更新 status.md 是什么时候？
• GitHub 讨论或 Issue 中是否有应该记录到 decisions.md 的决策？
• 仅凭上下文，别人（包括未来的你）能否理解这个项目？

干预措施：

• 如果没有上下文网络，则进行初始化：

  context/
  ├── discovery.md      # Navigation and overview
  ├── status.md         # Current work, recent changes
  ├── decisions.md      # Key decisions with rationale
  ├── architecture.md   # System design, workflows
  └── glossary.md       # Project-specific terms
  

• 运行 scripts/gh-sync-context.ts 生成状态更新
• 更新 status.md，记录当前迭代／里程碑
• 将已关闭 Issue/PR 中的决策提取到 decisions.md
• 在 architecture.md 中创建一节，记录 GitHub 工作流
• 将 GitHub 里程碑关联到上下文网络阶段

---

状态 GH8：工作流健康

症状：

• Issue 均已添加标签、确定优先级并分配到里程碑
• 所有工作都通过 PR 在功能分支上进行
• PR 关联了 Issue，并有清晰的描述
• 上下文网络反映当前状态和决策
• 能回答“我正在做什么？”和“为什么？”
• 新会话无需重新摸索即可继续工作

指标：

• gh issue list 仅显示相关且当前的工作
• gh pr status 显示目标明确的进行中工作
• context/status.md 与 GitHub 的实际情况一致
• 最近的提交位于功能分支，而不是 main
• 没有超过设定期限却未说明原因的 Issue

维护：

• 每周同步：将 GitHub 状态同步到 context/status.md
• 迭代／里程碑节点：将回顾总结记录到 decisions.md
• 架构变更：在上下文网络中创建 ADR
• 定期使用 scripts/gh-audit.ts 进行审查

---

GitHub ↔ 上下文网络的边界

存放在 GitHub 中

产物	使用 GitHub 的原因
Issue	协作、状态跟踪、通知、关联
Pull Request	代码审查、CI 集成、合并跟踪
讨论	团队／社区交流、问答、RFC
Actions/Workflows	CI/CD、自动化、强制执行
标签／里程碑	组织、筛选、进度跟踪
项目看板	可视化工作流（可选）

位于 Context Network 中

工件	为什么放在 Context Network 中
ADR（架构决策记录）	结构化推理、可搜索、与框架集成
decisions.md	跨领域决策、策略、理由
status.md	当前重点、近期变更、会话延续
architecture.md	系统设计、工作流文档
discovery.md	项目理解、导航
glossary.md	术语、共同理解
回顾总结	改进未来工作的经验

桥接工件（交叉引用）

工件	主要位置	交叉引用
需求文档	context/ 或 docs/	从 issue 链接
系统设计	context/architecture.md	在 PR 中引用
Sprint／里程碑目标	status.md	与 GitHub 里程碑对应
关键决策	decisions.md	在 issue／PR 评论中引用

---

特定模式的工作流

独立开发者模式

目的： 自律、为未来的自己留存历史、结构化思考

调整：

• 分支保护仍然很有价值（可防止意外操作）
• 自行审查 PR：将 PR 用作思考检查点，而不只是合并关卡
• 将 issue 作为记忆：为未来的会话编写 issue
• 简化标签：type:feature、type:bug、type:task、priority:high/low
• Context Network 尤其重要（没有团队成员可询问）

工作流：

1. 开始会话：检查 context/status.md 和 gh issue list
2. 选择 issue，或为新工作创建一个
3. 创建功能分支：gh issue develop {number}
4. 以常规提交进行开发（在提交消息中引用 issue）
5. 创建 PR：gh pr create --fill
6. 自行审查：像阅读他人编写的代码一样阅读差异
7. 合并：gh pr merge --squash
8. 如有重大变更，更新 context/status.md

团队模式（2-5 人）

目的： 协作、代码审查、共享理解

调整：

• 合并前必须进行代码审查
• 分配约定（明确负责人）
• 同步会议（站会、规划、回顾）
• 使用更结构化的标签，包括与负责人相关的标签
• 使用 Discussions 讨论异步决策

工作流：

1. 规划：创建／完善 issue，并分配到里程碑
2. 分配：分配 issue，并通过评论沟通
3. 开发：使用功能分支，定期提交
4. 创建 PR：填写详细说明，并邀请审查者
5. 审查：批准、要求修改或发表评论
6. 合并：获得批准后，压缩合并
7. 同步：每周更新 Context Network，回顾里程碑

团队标签（新增）：

• status:needs-review - 等待代码审查
• status:changes-requested - 审查者要求修改
• needs:discussion - 继续推进前需要团队意见

---

关键工作流

1. 项目初始化流程

触发条件： 新项目或首次集成 GitHub

步骤：

1. 确认已安装并完成身份验证的 GH CLI（GH0）：scripts/gh-verify.ts
2. 创建或关联仓库（GH1）：gh repo create 或 git remote add
3. 运行初始化：scripts/gh-init-project.ts --labels standard --templates --protection
4. 如果 Context Network 尚未建立，则进行初始化
5. 在 context/architecture.md 中记录工作流
6. 在 context/decisions.md 中记录决策
7. 为初始工作阶段创建第一个里程碑

2. 功能开发工作流

触发条件： 开始新的工作项

步骤：

1. 确保 issue 已存在（若不存在则创建）：gh issue create
2. 根据 issue 创建功能分支：

   gh issue develop {number} --base main
   # Or manually:
   git checkout -b feature/{number}-short-description main
   

3. 使用符合规范的消息进行提交：

   feat(scope): description (#123)
   fix(scope): description (#123)
   chore: description
   

4. 定期推送：git push -u origin HEAD
5. 准备就绪后创建 PR：

   gh pr create --fill
   # Or with explicit template:
   gh pr create --title "feat: description" --body-file .github/pull_request_template.md
   

6. 确保 PR：
   • 关联 issue（Closes #123）
   • 包含有意义的说明
   • 如果涉及架构，则引用 Context Network
7. 进行审查（自行审查或由团队审查）
8. 通过 gh pr merge --squash 合并（压缩可保持历史记录整洁）
9. 通过 PR 关键词自动关闭 issue
10. 删除分支：git branch -d feature/{number}-description

3. 冲刺／里程碑同步

触发时机： 里程碑开始或结束时

开始时：

1. 创建里程碑：gh api repos/{owner}/{repo}/milestones -f title="Sprint X" -f due_on="YYYY-MM-DD"
2. 将议题分配到里程碑
3. 在 context/status.md 中更新里程碑重点和目标
4. 沟通优先事项（个人：写下来；团队：召开规划会议）

结束时：

1. 审查里程碑：gh issue list --milestone "Sprint X"
2. 关闭已完成的里程碑
3. 将未完成的议题移至下一个里程碑或暂存区
4. 在 context/decisions.md 中记录回顾：
   • 哪些进展顺利？
   • 哪些进展不顺利？
   • 我们将做出哪些改变？
5. 在 context/status.md 中更新摘要

4. 上下文同步仪式

触发时机： 每周或完成重要工作后

步骤：

1. 运行审计：scripts/gh-audit.ts
2. 运行同步：scripts/gh-sync-context.ts --dry-run（先进行检查）
3. 更新 context/status.md：
   • 当前里程碑／冲刺
   • 活跃议题／PR
   • 最近完成的事项
   • 阻碍因素或待定决策
4. 将已关闭议题／PR 中的决策提取到 decisions.md
5. 如果工作流发生变化，则更新 architecture.md
6. 验证：是否有人仅凭上下文就能继续工作？

---

反模式

把 GitHub 当作 Wiki

问题： 用 GitHub 议题记录长篇文档、决策和本应保存在上下文网络中的信息。重要信息会淹没在评论中，之后难以查找。 表现： 议题描述过长、在评论中讨论架构、决策散落在已关闭的议题中。 解决方法： GitHub 跟踪工作项；上下文网络跟踪理解。如果信息需要在议题生命周期结束后继续保留，就将其移至 context/。

议题坟场

问题： 创建的议题从不关闭，导致待办列表失去意义。新议题不断堆在旧议题上。 表现： 有 200 多个未关闭议题，大多数几个月无人处理，抱着“以后再说”的心态，面对要做的工作不知所措。 解决方法： 定期整理。如果 90 天内不会完成，就移至暂存区或关闭。精简且及时更新的待办列表胜过庞大且过时的列表。该删除时就果断删除。

缺少上下文的 PR

问题： PR 只描述改了什么，却不说明原因，导致日后无法追溯。 表现： 只写“修复了 bug”“更新了样式”“重构了代码”，没有任何上下文。六个月后，没人知道原因。 解决方法： 使用包含必填部分的 PR 模板：内容、原因、测试方法、相关议题。如果涉及架构，应引用 ADR。

重复议题制造机

问题： 创建新议题前不检查是否已有相关议题，导致讨论分散、浪费精力。 表现： 多个议题讨论同一件事，精力分散在重复议题上，解决方案互相冲突。 解决方法： 创建前先搜索：gh issue list --search "keyword"。关闭重复议题，并引用权威议题。

永不结束的草稿 PR

问题： PR 以草稿形式开启后一直没有完成，阻碍工作进展，也让 PR 列表杂乱。 表现： 草稿 PR 超过 30 天，WIP 标签长期挂着，范围不断扩大，导致 PR 无法合并。 解决方法： 为草稿设定时间限制。如果两周内尚未准备好，就关闭并重新确定范围。能够合并的小型 PR 胜过无法合并的大型 PR。

绕过分支保护

问题： 以“就这一次”为由禁用分支保护并直接提交到 main，为以后绕过保护开了先例。 表现： 没有 PR 就向 main 提交，main 上的构建损坏，或想着“下次提交再修”。 解决方法： 分支保护自有其道理。即使是独立开发者，也能从 PR 工作流中受益，例如保留历史记录、设置审查节点和支持回滚。

脱节的上下文

问题： 上下文网络存在，但没有更新，沦为虚构而非文档。比没有上下文更糟糕，因为它会误导人。 症状： status.md 显示几个月前就已完成的工作，decisions.md 缺少近期架构变更，新会话无法信任上下文。 解决方法： 将上下文同步纳入工作流，而不是事后补做。结束会话时的例行检查：status.md 是否反映了实际情况？

---

可用工具

gh-verify.ts

验证 GitHub CLI 的安装和身份验证状态。

deno run --allow-run scripts/gh-verify.ts
deno run --allow-run scripts/gh-verify.ts --json

输出：

• CLI 安装状态和版本
• 身份验证状态和当前用户
• 默认仓库（如果当前位于仓库目录中）
• 缺少任何内容时给出的建议

退出代码： 0（正常）、1（缺少 gh）、2（未登录）、3（没有仓库上下文）

gh-init-project.ts

使用标签、模板和分支保护初始化 GitHub 项目。

deno run --allow-run --allow-read --allow-write scripts/gh-init-project.ts
deno run --allow-run --allow-read --allow-write scripts/gh-init-project.ts --labels standard --templates --protection
deno run --allow-run --allow-read --allow-write scripts/gh-init-project.ts --mode team --labels standard

选项：

• --labels [standard|simple|minimal] - 要创建的标签方案
• --templates - 创建 Issue 和 PR 模板
• --protection - 在 main 上启用分支保护
• --mode [solo|team] - 根据工作方式调整默认设置
• --dry-run - 显示将要创建的内容，但不实际创建

创建内容：

• 通过 gh label create 创建标签
• .github/ISSUE_TEMPLATE/，包含功能、缺陷和任务模板
• .github/pull_request_template.md
• 分支保护规则（如果使用 --protection）

gh-audit.ts

根据健康工作流指标审计当前 GitHub 状态。

deno run --allow-run scripts/gh-audit.ts
deno run --allow-run scripts/gh-audit.ts --json
deno run --allow-run scripts/gh-audit.ts --stale 30

选项：

• --json - 以 JSON 格式输出，便于脚本处理
• --stale [days] - 标记 N 天内没有活动的项目（默认值：30）
• --verbose - 显示逐项详细分析

检查项：

• 开启的 Issue 数量和标签覆盖情况
• 开启的 PR 状态（草稿、关联的 Issue、创建时间）
• 最近的提交（所在分支、是否直接提交到 main？）
• 里程碑的使用情况和进度
• 识别长期未处理的项目

输出： 健康度评分（0-100）和具体建议

gh-sync-context.ts

根据 GitHub 状态生成上下文网络更新。

deno run --allow-run --allow-write scripts/gh-sync-context.ts
deno run --allow-run scripts/gh-sync-context.ts --dry-run
deno run --allow-run --allow-write scripts/gh-sync-context.ts --status --decisions

选项：

• --dry-run - 显示将要写入的内容，但不实际写入
• --status - 生成 status.md 更新部分
• --decisions - 从带有“decision”标签的已关闭 Issue 中提取决策
• --output [dir] - 写入目录（默认值：context/）

生成内容：

• status.md 的状态更新内容
• 来自已关闭 Issue 的候选决策
• 里程碑摘要

---

示例交互

独立开发者：从头开始

开发者：“我有一个本地项目，想把它放到 GitHub 上并开始采用规范的工作流。”

**诊断：**状态 GH1（仓库尚未初始化）

处理方法：

1. 运行 scripts/gh-verify.ts - 确认 CLI 已就绪
2. 询问：“创建公开还是私有仓库？”
3. 创建仓库：gh repo create my-project --source=. --private --push
4. 运行 scripts/gh-init-project.ts --mode solo --labels simple --templates
5. 初始化上下文网络：创建 context/，并添加 status.md、decisions.md
6. 在 context/architecture.md 中记录：“使用 GitHub Issues 跟踪工作，所有变更都使用功能分支，通过 PR 进行合并和留存历史记录。”
7. 为当前工作创建第一个 Issue
8. 演示分支工作流：gh issue develop 1

团队：清理待办事项

开发者：“我们有 150 个开启的 Issue，但没人知道哪些最重要。”

**诊断：**状态 GH3（待办事项混乱）

处理方法：

1. 运行 scripts/gh-audit.ts --stale 60 - 确定范围
2. 询问：“当前优先级是什么？近期必须交付什么？”
3. 为当前重点创建里程碑
4. 对 Issue 分类处理：
   • 里程碑的关键事项 → 分配到里程碑，并添加优先级标签
   • 有效但暂不处理 → 添加 icebox 标签
   • 长期未处理且没有推进方案 → 说明原因后关闭
   • 重复事项 → 关闭并引用权威条目
5. 使用当前重点更新 context/status.md
6. 建立定期梳理机制：每周进行 15 分钟回顾

个人开发者：上下文衰减

开发者：“我一个月后重新回到这个项目，完全不知道之前在做什么。”

诊断： 状态 GH7（上下文网络缺失）

处理方法：

1. 检查 GitHub 状态：gh issue list、gh pr status
2. 运行 scripts/gh-sync-context.ts --dry-run，查看当前状态
3. 初始化或更新上下文网络：
   • status.md：当前里程碑是什么？有哪些活跃问题？
   • decisions.md：已关闭 PR 中是否有架构决策？
4. 查看上次会话期间关闭的问题和 PR，了解相关上下文
5. 在 status.md 中添加“上次会话”摘要
6. 养成习惯：每次会话结束时更新 status.md

---

输出持久化

输出位置发现

开始任何其他工作之前：

1. 检查项目中是否有 context/output-config.md
2. 如果有，查找此技能对应的条目
3. 如果没有，询问：“GitHub 工作流输出应该保存在哪里？”
   • 建议：上下文网络文件保存到 context/，GitHub 配置保存到 .github/
4. 将偏好保存到 context/output-config.md

主要输出

输出	位置
问题模板	.github/ISSUE_TEMPLATE/
PR 模板	.github/pull_request_template.md
工作流文档	context/architecture.md（GitHub 工作流部分）
设置决策	context/decisions.md
状态更新	context/status.md
审计报告	context/github-audit-{date}.md（如需持久保存）

对话与文件

保存到文件	保留在对话中
模板（.github/）	诊断讨论
工作流文档	标签方案探索
上下文网络更新	分类决策
审计报告（如有要求）	快速状态检查

---

你不会做什么

• 未经用户确认，不会创建问题
• 不会自动合并 PR
• 未经明确请求，不会删除问题、PR 或分支
• 未经明确请求，不会更改分支保护设置
• 不会跳过对 gh 是否可用的验证（始终先检查 GH0）
• 不会在未检查 gh auth status 的情况下假定可以访问 GitHub
• 不会用仅存储在 GitHub 的方式取代上下文网络
• 不会在 main 分支上创建提交（强制采用功能分支工作流）
• 不会在未告知用户的情况下推送到远程仓库
• 会先诊断并提出建议，确认后再执行——由开发者做决定

---

与其他技能的集成

来自 requirements-analysis

requirements-analysis 输出	github-agile 输入
问题陈述	创建描述问题的初始问题
需求层级	映射到问题优先级标签
约束清单	记录在 context/ 中，并在问题中引用
已验证的需求	创建功能问题，并链接到需求文档

来自 system-design

system-design 输出	github-agile 输入
ADR	存储在 context/adr/ 或 docs/adr/ 中，并在 PR 中引用
组件映射	为按组件拆分问题提供依据
行走骨架	创建首个里程碑并关联问题
集成点	记录在 context/architecture.md 中

到 requirements-analysis

当 GitHub 状态揭示需求问题时：

github-agile 状态	触发条件	requirements-analysis 状态
GH3（待办事项混乱）	问题描述的是解决方案，而非问题	RA0-RA1
GH3（待办事项混乱）	无法确定优先级（所有事项都很重要）	RA4

到 system-design

当 GitHub 状态揭示设计问题时：

github-agile 状态	触发条件	system-design 状态
GH5（缺少上下文的 PR）	PR 涉及未记录的架构决策	SD4
GH4（分支违规）	频繁发生合并冲突	SD3（缺少集成点）

---

参考资料

此技能将以下内容转化为可操作流程：

• GitHub CLI 文档：https://cli.github.com/manual/
• Context Networks 框架：references/context-networks/
• 功能分支工作流最佳实践
• Conventional Commits：https://www.conventionalcommits.org/