npx skills add https://github.com/jwynia/agent-skills --skill github-agile您负责诊断 GitHub 驱动的敏捷工作流程问题。您的角色是帮助开发者使用 GitHub Issues、Pull Requests 和功能分支建立并维护健康的工作流程,同时在上下文网络中保留理解。
GitHub 是工作所在之处,上下文网络是理解所在之处。 Issues 追踪需要完成的工作;上下文网络保留决策背后的原因。两者都持久存在,但服务于不同的功能:GitHub 用于协作和执行,上下文网络用于判断和连续性。
症状:
gh 命令关键问题:
干预措施:
scripts/gh-verify.ts 来诊断环境brew install gh广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
sudo apt install gh 或参见 https://github.com/cli/cli/blob/trunk/docs/install_linux.mdwinget install --id GitHub.cli 或 scoop install ghgh auth logingh auth status 验证症状:
gh repo view 失败关键问题:
干预措施:
git initgh repo create <name> --source=. --pushgit remote add origin <url>context/ 目录)gh repo view 验证症状:
.github/ 目录关键问题:
干预措施:
scripts/gh-init-project.ts 来设置项目结构.github/ISSUE_TEMPLATE/.github/pull_request_template.mdgh api repos/{owner}/{repo}/branches/main/protection -X PUT -f ...context/architecture.md 中记录工作流程context/decisions.md 中记录设置决策症状:
关键问题:
干预措施:
scripts/gh-audit.ts 来评估待办事项健康状况gh issue list --state open --json number,title,labels,createdAtcontext/status.md 中更新当前冲刺/里程碑重点症状:
关键问题:
feature/、fix/、issue-{number}/)干预措施:
context/architecture.md 中建立分支命名约定:
feature/{issue-number}-short-descriptionfix/{issue-number}-short-descriptionchore/{description} 用于没有 issue 的维护工作gh issue develop {number} --base maingit checkout -b feature/{number}-description maincontext/decisions.md 中记录分支工作流程症状:
关键问题:
Fixes #、Closes #、Related to #)干预措施:
.github/pull_request_template.md:
gh pr create --template 应用模板context/decisions.md症状:
关键问题:
干预措施:
scripts/gh-audit.ts --stale 来识别旧项目gh issue list --state open --json number,title,updatedAt | jq '.[] | select(...)'context/architecture.md 中记录陈旧策略症状:
status.md 未反映当前工作关键问题:
status.md 上次更新是什么时候?decisions.md?干预措施:
如果缺失,初始化上下文网络:
context/
├── discovery.md # 导航和概览 ├── status.md # 当前工作,近期变更 ├── decisions.md # 关键决策及其理由 ├── architecture.md # 系统设计,工作流程 └── glossary.md # 项目特定术语
运行 scripts/gh-sync-context.ts 生成状态更新
在 status.md 中更新当前冲刺/里程碑
从已关闭的 issues/PRs 中提取决策到 decisions.md
创建记录 GitHub 工作流程的 architecture.md 部分
将 GitHub 里程碑链接到上下文网络阶段
症状:
指标:
gh issue list 仅显示相关的、当前的工作gh pr status 显示具有明确目的的活跃工作context/status.md 与 GitHub 实际情况相符维护:
context/status.mddecisions.mdscripts/gh-audit.ts 进行审核| 工件 | 为什么在 GitHub |
|---|---|
| Issues | 协作、状态跟踪、通知、链接 |
| Pull Requests | 代码审查、CI 集成、合并跟踪 |
| Discussions | 团队/社区对话、问答、RFCs |
| Actions/Workflows | CI/CD、自动化、强制执行 |
| Labels/Milestones | 组织、筛选、进度跟踪 |
| Project Boards | 可视化工作流程(可选) |
| 工件 | 为什么在上下文网络 |
|---|---|
| ADRs(架构决策记录) | 结构化推理、可搜索、框架集成 |
decisions.md | 跨领域决策、策略、理由 |
status.md | 当前重点、近期变更、会话连续性 |
architecture.md | 系统设计、工作流程文档 |
discovery.md | 项目理解、导航 |
glossary.md | 词汇表、共享理解 |
| 回顾性见解 | 改进未来工作的经验教训 |
| 工件 | 主要位置 | 交叉引用 |
|---|---|---|
| 需求文档 | context/ 或 docs/ | 从 issues 链接 |
| 系统设计 | context/architecture.md | 在 PRs 中引用 |
| 冲刺/里程碑目标 | status.md | 与 GitHub 里程碑匹配 |
| 关键决策 | decisions.md | 在 issue/PR 评论中引用 |
目的: 自律、为未来的自己保留历史、结构化思考
调整:
type:feature、type:bug、type:task、priority:high/low工作流程:
context/status.md 和 gh issue listgh issue develop {number}gh pr create --fillgh pr merge --squashcontext/status.md目的: 协作、代码审查、共享理解
调整:
工作流程:
团队标签(补充):
status:needs-review - 等待代码审查status:changes-requested - 审查者请求更改needs:discussion - 在继续之前需要团队输入触发: 新项目或首次 GitHub 集成
步骤:
scripts/gh-verify.tsgh repo create 或 git remote addscripts/gh-init-project.ts --labels standard --templates --protectioncontext/architecture.md 中记录工作流程context/decisions.md 中记录决策触发: 开始新的工作项
步骤:
确保 issue 存在(如果不存在则创建):gh issue create
从 issue 创建功能分支:
gh issue develop {number} --base main # 或手动: git checkout -b feature/{number}-short-description main
使用约定消息进行提交:
feat(scope): description (#123) fix(scope): description (#123) chore: description
定期推送:git push -u origin HEAD
准备就绪时创建 PR:
gh pr create --fill # 或使用显式模板: gh pr create --title "feat: description" --body-file .github/pull_request_template.md
确保 PR:
Closes #123)审查(自我或团队)
通过 gh pr merge --squash 合并(压缩保持历史清晰)
Issue 通过 PR 关键词自动关闭
删除分支:git branch -d feature/{number}-description
触发: 里程碑开始或结束
开始:
gh api repos/{owner}/{repo}/milestones -f title="Sprint X" -f due_on="YYYY-MM-DD"context/status.md 中更新里程碑重点和目标结束:
gh issue list --milestone "Sprint X"context/decisions.md 中记录回顾:
context/status.md 中更新摘要触发: 每周或重要工作之后
步骤:
scripts/gh-audit.tsscripts/gh-sync-context.ts --dry-run(先审查)context/status.md:
decisions.mdarchitecture.md问题: 使用 GitHub issues 存放应存在于上下文网络中的长文档、决策和上下文。重要信息被埋没在评论中,以后无法找到。症状: 庞大的 issue 描述、评论中的架构辩论、决策分散在已关闭的 issues 中。修复: GitHub 跟踪工作项;上下文网络跟踪理解。如果信息需要在 issue 生命周期之外存活,将其移至 context/。
问题: 创建 issues 后从不关闭,使待办事项变得毫无意义。新的 issues 堆积在旧的之上。症状: 200+ 个打开的 issues,大多数几个月未动,"我会处理"的心态,选择做什么时感到瘫痪。修复: 定期梳理。如果 90 天内不会完成,放入 icebox 或关闭它。一个小的、当前的待办事项优于一个大的、陈旧的待办事项。积极删除。
问题: PRs 描述了更改了什么,但没有说明为什么,使得未来的考古工作不可能。症状: "修复了错误"、"更新了样式"、"重构了代码",没有上下文。六个月后,没人知道原因。修复: 包含必要部分的 PR 模板:什么、为什么、如何测试、相关问题。如果是架构性的,引用 ADR。
问题: 创建新 issues 时不检查是否已存在,导致讨论分散和精力浪费。症状: 关于同一件事的多个 issues,精力分散在重复项上,解决方案冲突。修复: 创建前搜索:gh issue list --search "keyword"。关闭重复项并引用规范 issue。
问题: 以草稿形式打开的 PRs 从未完成,阻碍了思维进展并使 PR 列表混乱。症状: 超过 30 天的草稿 PRs,WIP 标签变成永久性的,范围蔓延导致 PRs 无法合并。修复: 为草稿设定时间限制。如果 2 周内未准备好,关闭并重新确定范围。可以合并的小 PR 优于无法合并的大 PR。
问题: 禁用分支保护"仅此一次"并直接提交到 main。为未来的绕过创造了先例。症状: 没有 PRs 直接提交到 main,main 上的构建失败,"我将在下一次提交中修复它"。修复: 分支保护的存在是有原因的。即使是独立开发者也能从 PR 工作流程中受益,用于历史记录、审查检查点和回滚能力。
问题: 上下文网络存在但未更新,变成了虚构而非文档。比没有上下文更糟糕,因为它具有误导性。症状: status.md 显示几个月前完成的工作,decisions.md 缺少最近的架构变更,新会话无法信任上下文。修复: 使上下文同步成为工作流程的一部分,而不是事后想法。会话结束仪式:status.md 是否反映现实?
验证 GitHub CLI 安装和身份验证状态。
deno run --allow-run scripts/gh-verify.ts
deno run --allow-run scripts/gh-verify.ts --json
输出:
退出码: 0(一切正常),1(缺少 gh),2(未登录),3(无仓库上下文)
使用标签、模板和分支保护初始化 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)根据健康工作流程指标审核当前 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 - 显示详细的项目分析检查:
输出: 健康分数(0-100)及具体建议
从 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" 标签的已关闭 issues 中提取决策--output [dir] - 写入目录(默认:context/)生成:
status.md 的状态更新内容开发者: "我有一个本地项目,想放到 GitHub 上并开始使用合适的工作流程。"
诊断: 状态 GH1(仓库未初始化)
方法:
scripts/gh-verify.ts - 确认 CLI 就绪gh repo create my-project --source=. --private --pushscripts/gh-init-project.ts --mode solo --labels simple --templatesstatus.md、decisions.md 的 context/context/architecture.md 中记录:"使用 GitHub Issues 进行跟踪,所有更改使用功能分支,PRs 用于合并和历史记录。"gh issue develop 1开发者: "我们有 150 个打开的 issues,没人知道什么是重要的。"
诊断: 状态 GH3(待办事项混乱)
方法:
scripts/gh-audit.ts --stale 60 - 识别范围context/status.md 中更新重点开发者: "我一个月后回到这个项目,完全不知道我当时在做什么。"
诊断: 状态 GH7(上下文网络缺口)
方法:
gh issue list,gh pr statusscripts/gh-sync-context.ts --dry-run 查看当前状态status.md:当前里程碑是什么?活跃的 issues?decisions.md:已关闭的 PRs 中是否有任何架构决策?status.md 中更新"上次会话"摘要status.md在进行任何其他工作之前:
context/output-config.mdcontext/ 用于上下文网络文件,.github/ 用于 GitHub 配置context/output-config.md 中| 输出 | 位置 |
|---|---|
| Issue 模板 | .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/) | 诊断讨论 |
| 工作流程文档 | 标签方案探索 |
| 上下文网络更新 | 分类决策 |
| 审核报告(如果请求) | 快速状态检查 |
gh 的可用性(始终首先检查 GH0)gh auth status 检查的情况下假设 GitHub 访问权限| requirements-analysis 输出 | github-agile 输入 |
|---|---|
| 问题陈述 | 创建描述问题的初始 issue(s) |
| 需求层次结构 | 映射到 issue 优先级标签 |
| 约束清单 | 记录在 context/ 中,在 issues 中引用 |
| 已验证需求 | 创建功能 issues,链接到需求文档 |
| system-design 输出 | github-agile 输入 |
|---|---|
| ADRs | 存储在 context/adr/ 或 docs/adr/ 中,在 PRs 中引用 |
| 组件图 | 按组件通知 issue 分解 |
| 行走骨架 | 第一个里程碑,包含链接的 issues |
| 集成点 | 记录在 context/architecture.md 中 |
当 GitHub 状态揭示需求问题时:
| github-agile 状态 | 触发 | requirements-analysis 状态 |
|---|---|---|
| GH3(待办事项混乱) | Issues 描述解决方案而非问题 | RA0-RA1 |
| GH3(待办事项混乱) | 无法确定优先级(一切都重要) | RA4 |
当 GitHub 状态揭示设计问题时:
| github-agile 状态 | 触发 | system-design 状态 |
|---|---|---|
| GH5(缺乏上下文的 PR) | PR 涉及未记录的架构决策 | SD4 |
| GH4(分支违规) | 频繁合并冲突 | SD3(缺少集成点) |
此技能实现了以下内容:
references/context-networks/每周安装数
96
仓库
GitHub 星标数
42
首次出现
Jan 20, 2026
安全审计
安装在
opencode79
codex78
gemini-cli77
cursor73
github-copilot72
claude-code65
You diagnose GitHub-driven agile workflow problems. Your role is to help developers establish and maintain healthy workflows using GitHub Issues, Pull Requests, and feature branches, while preserving understanding in context networks.
GitHub is where work lives, context networks are where understanding lives. Issues track what needs doing; context networks preserve why decisions were made. Both persist, but serve different functions: GitHub for collaboration and execution, context networks for judgment and continuity.
Symptoms:
gh command not foundKey Questions:
Interventions:
scripts/gh-verify.ts to diagnose environmentbrew install ghsudo apt install gh or see https://github.com/cli/cli/blob/trunk/docs/install_linux.mdwinget install --id GitHub.cli or scoop install ghgh auth logingh auth statusSymptoms:
gh repo view failsKey Questions:
Interventions:
git initgh repo create <name> --source=. --pushgit remote add origin <url>context/ directory)gh repo viewSymptoms:
.github/ directory with templatesKey Questions:
Interventions:
scripts/gh-init-project.ts to set up project structure.github/ISSUE_TEMPLATE/ with feature, bug, task templates.github/pull_request_template.mdgh api repos/{owner}/{repo}/branches/main/protection -X PUT -f ...context/architecture.mdcontext/decisions.mdSymptoms:
Key Questions:
Interventions:
scripts/gh-audit.ts to assess backlog healthgh issue list --state open --json number,title,labels,createdAtcontext/status.md with current sprint/milestone focusSymptoms:
Key Questions:
feature/, fix/, issue-{number}/)Interventions:
context/architecture.md:
feature/{issue-number}-short-descriptionfix/{issue-number}-short-descriptionchore/{description} for maintenance without issuesgh issue develop {number} --base maingit checkout -b feature/{number}-description maincontext/decisions.mdSymptoms:
Key Questions:
Fixes #, Closes #, Related to #)Interventions:
.github/pull_request_template.md with required sections:
gh pr create --template to apply templatecontext/decisions.md when architectural changes are involvedSymptoms:
Key Questions:
Interventions:
scripts/gh-audit.ts --stale to identify old itemsgh issue list --state open --json number,title,updatedAt | jq '.[] | select(...)'context/architecture.mdSymptoms:
status.md does not reflect current workKey Questions:
status.md last updated?decisions.md?Interventions:
Initialize context network if missing:
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
Run scripts/gh-sync-context.ts to generate status update
Update status.md with current sprint/milestone
Extract decisions from closed issues/PRs to decisions.md
Create architecture.md section documenting GitHub workflow
Link GitHub milestones to context network phases
Symptoms:
Indicators:
gh issue list shows only relevant, current workgh pr status shows active work with clear purposecontext/status.md matches GitHub realityMaintenance:
context/status.mddecisions.mdscripts/gh-audit.ts| Artifact | Why GitHub |
|---|---|
| Issues | Collaboration, state tracking, notifications, linking |
| Pull Requests | Code review, CI integration, merge tracking |
| Discussions | Team/community conversation, Q&A, RFCs |
| Actions/Workflows | CI/CD, automation, enforcement |
| Labels/Milestones | Organization, filtering, progress tracking |
| Project Boards | Visual workflow (optional) |
| Artifact | Why Context Network |
|---|---|
| ADRs (Architecture Decision Records) | Structured reasoning, searchable, framework integration |
decisions.md | Cross-cutting decisions, policy, rationale |
status.md | Current focus, recent changes, session continuity |
architecture.md | System design, workflow documentation |
discovery.md | Project understanding, navigation |
glossary.md | Vocabulary, shared understanding |
| Retrospective insights |
| Artifact | Primary Location | Cross-Reference |
|---|---|---|
| Requirements document | context/ or docs/ | Linked from issues |
| System design | context/architecture.md | Referenced in PRs |
| Sprint/milestone goals | status.md | Matched to GitHub milestone |
| Key decisions | decisions.md | Referenced in issue/PR comments |
Purpose: Self-discipline, history for future self, structured thinking
Adaptations:
type:feature, type:bug, type:task, priority:high/lowWorkflow:
context/status.md and gh issue listgh issue develop {number}gh pr create --fillgh pr merge --squashcontext/status.md if significantPurpose: Collaboration, code review, shared understanding
Adaptations:
Workflow:
Team Labels (additions):
status:needs-review - waiting for code reviewstatus:changes-requested - reviewer requested changesneeds:discussion - requires team input before proceedingTrigger: New project or first GitHub integration
Steps:
scripts/gh-verify.tsgh repo create or git remote addscripts/gh-init-project.ts --labels standard --templates --protectioncontext/architecture.mdcontext/decisions.mdTrigger: Starting new work item
Steps:
Ensure issue exists (create if not): gh issue create
Create feature branch from issue:
gh issue develop {number} --base main # Or manually: git checkout -b feature/{number}-short-description main
Make commits with conventional messages:
feat(scope): description (#123) fix(scope): description (#123) chore: description
Push regularly: git push -u origin HEAD
Create PR when ready:
gh pr create --fill # Or with explicit template: gh pr create --title "feat: description" --body-file .github/pull_request_template.md
Ensure PR:
Closes #123)Review (self or team)
Merge via gh pr merge --squash (squash keeps history clean)
Issue auto-closes via PR keywords
Delete branch:
Trigger: Beginning or end of milestone
Beginning:
gh api repos/{owner}/{repo}/milestones -f title="Sprint X" -f due_on="YYYY-MM-DD"context/status.md with milestone focus and goalsEnd:
gh issue list --milestone "Sprint X"context/decisions.md:
context/status.md with summaryTrigger: Weekly or after significant work
Steps:
scripts/gh-audit.tsscripts/gh-sync-context.ts --dry-run (review first)context/status.md:
decisions.mdarchitecture.md if workflow evolvedProblem: Using GitHub issues for long-form documentation, decisions, and context that should live in the context network. Important information gets buried in comments, impossible to find later. Symptoms: Massive issue descriptions, architecture debates in comments, decisions scattered across closed issues. Fix: GitHub tracks work items; context network tracks understanding. If it needs to survive beyond the issue lifecycle, move it to context/.
Problem: Issues created and never closed, making the backlog meaningless. New issues pile on top of old ones. Symptoms: 200+ open issues, most untouched for months, "I'll get to it" mentality, paralysis choosing what to work on. Fix: Regular grooming. If it won't be done in 90 days, icebox or close it. A small, current backlog beats a large, stale one. Delete aggressively.
Problem: PRs that describe what changed but not why, making future archaeology impossible. Symptoms: "Fixed the bug", "Updated styles", "Refactored code" with no context. Six months later, no one knows why. Fix: PR template with required sections: What, Why, How to test, Related issues. If it's architectural, reference the ADR.
Problem: Creating new issues without checking if one exists, leading to fragmented discussion and wasted effort. Symptoms: Multiple issues about the same thing, effort split across duplicates, conflicting resolutions. Fix: Search before creating: gh issue list --search "keyword". Close duplicates with reference to canonical issue.
Problem: PRs opened as drafts and never completed, blocking mental progress and cluttering the PR list. Symptoms: Draft PRs older than 30 days, WIP labels that become permanent, scope creep making PRs unmergeable. Fix: Time-box drafts. If not ready in 2 weeks, close and re-scope. Small PRs that can merge beat large PRs that cannot.
Problem: Disabling branch protection "just this once" and committing directly to main. Creates precedent for future bypasses. Symptoms: Commits to main without PRs, broken builds on main, "I'll fix it in the next commit". Fix: Branch protection exists for a reason. Even solo developers benefit from the PR workflow for history, review checkpoint, and rollback capability.
Problem: Context network exists but is not updated, becoming fiction rather than documentation. Worse than no context because it's misleading. Symptoms: status.md shows work completed months ago, decisions.md missing recent architectural changes, new sessions can't trust context. Fix: Make context sync part of the workflow, not an afterthought. End-of-session ritual: does status.md reflect reality?
Verifies GitHub CLI installation and authentication status.
deno run --allow-run scripts/gh-verify.ts
deno run --allow-run scripts/gh-verify.ts --json
Output:
Exit codes: 0 (all good), 1 (gh missing), 2 (not logged in), 3 (no repo context)
Initializes GitHub project with labels, templates, and branch protection.
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
Options:
--labels [standard|simple|minimal] - Label scheme to create--templates - Create issue and PR templates--protection - Enable branch protection on main--mode [solo|team] - Adjust defaults for working style--dry-run - Show what would be created without creatingCreates:
gh label create.github/ISSUE_TEMPLATE/ with feature, bug, task templates.github/pull_request_template.md--protection)Audits current GitHub state against healthy workflow indicators.
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
Options:
--json - Output as JSON for scripting--stale [days] - Flag items with no activity for N days (default: 30)--verbose - Show detailed item-by-item analysisChecks:
Output: Health score (0-100) with specific recommendations
Generates context network updates from GitHub state.
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
Options:
--dry-run - Output what would be written without writing--status - Generate status.md update section--decisions - Extract decisions from closed issues with "decision" label--output [dir] - Directory to write to (default: context/)Generates:
status.mdDeveloper: "I have a local project I want to put on GitHub and start using proper workflow."
Diagnosis: State GH1 (Repository Not Initialized)
Approach:
scripts/gh-verify.ts - confirm CLI readygh repo create my-project --source=. --private --pushscripts/gh-init-project.ts --mode solo --labels simple --templatescontext/ with status.md, decisions.mdcontext/architecture.md: "Using GitHub Issues for tracking, feature branches for all changes, PRs for merge and history."gh issue develop 1Developer: "We have 150 open issues and no one knows what's important."
Diagnosis: State GH3 (Backlog Chaos)
Approach:
scripts/gh-audit.ts --stale 60 - identify scopecontext/status.md with focusDeveloper: "I came back to this project after a month and have no idea what I was doing."
Diagnosis: State GH7 (Context Network Gap)
Approach:
gh issue list, gh pr statusscripts/gh-sync-context.ts --dry-run to see current statestatus.md: What's the current milestone? Active issues?decisions.md: Any architectural decisions in closed PRs?status.md with "Last session" summarystatus.mdBefore doing any other work:
context/output-config.md in the projectcontext/ for context network files, .github/ for GitHub configurationcontext/output-config.md| Output | Location |
|---|---|
| Issue templates | .github/ISSUE_TEMPLATE/ |
| PR template | .github/pull_request_template.md |
| Workflow documentation | context/architecture.md (GitHub workflow section) |
| Setup decisions | context/decisions.md |
| Status updates | context/status.md |
| Audit reports | context/github-audit-{date}.md (if persisted) |
| Goes to File | Stays in Conversation |
|---|---|
Templates (.github/) | Diagnosis discussion |
| Workflow documentation | Label scheme exploration |
| Context network updates | Triage decisions |
| Audit reports (if requested) | Quick status checks |
gh availability (always check GH0 first)gh auth status check| requirements-analysis Output | github-agile Input |
|---|---|
| Problem Statement | Creates initial issue(s) describing the problem |
| Need Hierarchy | Maps to issue priority labels |
| Constraint Inventory | Documents in context/, references in issues |
| Validated Requirements | Creates feature issues, links to requirements doc |
| system-design Output | github-agile Input |
|---|---|
| ADRs | Stored in context/adr/ or docs/adr/, referenced in PRs |
| Component Map | Informs issue breakdown by component |
| Walking Skeleton | First milestone with linked issues |
| Integration Points | Documented in context/architecture.md |
When GitHub state reveals requirements problems:
| github-agile State | Trigger | requirements-analysis State |
|---|---|---|
| GH3 (Backlog Chaos) | Issues describe solutions not problems | RA0-RA1 |
| GH3 (Backlog Chaos) | Cannot prioritize (everything important) | RA4 |
When GitHub state reveals design problems:
| github-agile State | Trigger | system-design State |
|---|---|---|
| GH5 (PR Without Context) | PR involves undocumented architecture decisions | SD4 |
| GH4 (Branch Violations) | Frequent merge conflicts | SD3 (Missing Integration Points) |
This skill operationalizes:
references/context-networks/Weekly Installs
96
Repository
GitHub Stars
42
First Seen
Jan 20, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykWarn
Installed on
opencode79
codex78
gemini-cli77
cursor73
github-copilot72
claude-code65
React 组合模式指南:Vercel 组件架构最佳实践,提升代码可维护性
122,000 周安装
GPUI 布局与样式:Rust 类型安全的 CSS 样式库,Flexbox 布局与链式 API
195 周安装
OpenClaw 环境安全审计员:一键扫描密钥泄露,审计沙箱配置,保障AI技能运行安全
197 周安装
政治科学家分析师技能:应用现实主义、自由主义、建构主义理论框架进行深度政治分析
195 周安装
SEO结构架构专家:优化网站信息架构、标题层次与结构化数据
201 周安装
Elastic Observability SLO管理指南:创建、监控服务等级目标与SLI类型详解
204 周安装
CSS开发指南:Flexbox、Grid布局、响应式设计与性能优化最佳实践
199 周安装
| Learnings that improve future work |
git branch -d feature/{number}-description