github-flow

name	github-flow
description	Complete GitHub project lifecycle automation. When the user pushes new code: auto-designs a landing page/website, records demo videos, generates promo content. Ongoing: manages PRs, issues, periodic testing, dependency updates, and cross-repo sync. Human sits on top — all destructive/unrecoverable actions require explicit approval. Trigger: GitHub push, "发上去", "GitHub Flow", managing a repo lifecycle, cross-repo monitoring
allowed_tools	["Bash","Read","Write","Edit","Skill","AskUserQuestion","delegate_task","cronjob","session_search","memory"]
agent_created	true

GitHub Flow — 全生命周期自动化

两件事：(A) 你 push 代码 → 我自动配设计/网站/视频；(B) 我持续管 issue / PR / 测试 / 依赖 / 跨仓库同步。你 sit on top，关键决定问我。

---

触发条件

用户说	触发什么
"push 了 / 发了 / 传上去了"	→ Section A: Push Pipeline
"看看我的 repo / 管理一下 XXX 仓库"	→ Section B: 初始化持续管理
"setup GitHub Flow for XXX"	→ 一次性设置 cron job
"check XXX repo's dependencies"	→ 依赖巡检
"看看相关仓库有没有更新"	→ 跨仓库同步检查

---

A. Push Pipeline（代码 push 后自动走）

当你 push 新代码或说 "发上去了"，按此流水线执行：

Phase 0 — 确认上下文

1. git remote get-url origin → 获取 repo 地址
2. gh repo view --json name,description,homepageUrl,language,topics → 了解项目
3. 问用户（用 AskUserQuestion）：
   "要做哪些？"
   选项 A: 全部（landing page + demo 视频 + promo 视频）
   选项 B: 只要 landing page
   选项 C: 只要 demo 录屏视频
   选项 D: 只要 promo 视频（AI 生成）

Phase 1 — Landing Page / Website

加载 onezion-websites 或 onezion-designer。

设计参考研究：生成 landing page 之前，先快速研究同类优秀项目的设计：

# 搜索同类项目的 README（从中提取设计灵感、ASCII art、badge 排版）
gh search repos "<项目关键词>" --sort stars --limit 5 --json name,url,description
# 浏览他们的 README、website、screenshot

关键：从 README 提取信息：

# 读取 README 获取项目核心卖点
cat README.md | head -200

Landing page 必须包含：

• Hero: 项目名 + 一句话 + GitHub stars/forks 实时 badge
• Features: 从 README 提取核心功能
• Demo/Preview: 嵌入 screenshot 或 iframe
• Quick Start: 从 README 提取安装命令
• CTA: "View on GitHub" 按钮

部署 (部署前问用户确认):

# 部署到 onezion12344.github.io/slides 的 gh-pages 分支
# 或创建独立的 GitHub Pages

Phase 2 — Demo 录屏视频

加载 onezion-video → 方案 A（HTML 录屏）。

自动生成一个 16:9 的产品演示视频：

1. 研究项目的核心 workflow（从 README + 代码中提取）
2. 为每个核心功能创建 step
3. 使用 onezion-video 方案 A 的 HTML scaffold
4. 录屏输出 demo.mp4

内容结构（产品 demo 标准模板）：

Step 1: 标题 + 一句话介绍
Step 2-4: 核心功能演示（每功能 1 step，配代码片段/效果展示）
Step 5: 安装启动（终端命令动画）
Step N: 结尾 CTA + GitHub URL

Phase 3 — Promo/广告视频

加载 onezion-video → 方案 C（Seedance AI 视频生成）或方案 A （HTML 动效）。

为项目生成一段 5-10 秒的推广视频：

• 类型 A（代码项目）: 终端打字 → 特效 → 结果展示（HTML 录屏）
• 类型 B（AI 生成）: 写 prompt → Seedance 生成

---

B. 持续管理（Ongoing Automation）

通过 cron job 实现。采用 HITL (Human-in-the-Loop) 模式：agent 发现问题 → 分析 → 提出方案 → 报告给你 → 等你确认 → 执行。

B1. Issue 管理

日常 Triage（建议 daily cron）:

# 查看新 issue
gh issue list --state open --search "no:label" --json number,title,createdAt,author
# 自动加标签
gh issue edit <N> --add-label "needs-triage"
# 分析并建议：label + assignee + priority

自动关闭陈旧 issue（建议 weekly cron）:

gh issue list --state open --search "no:assignee" --json number,title,createdAt \
  | python3 -c "
import sys, json
from datetime import datetime, timezone
for i in json.load(sys.stdin):
    age = (datetime.now(timezone.utc) - datetime.fromisoformat(i['createdAt'].replace('Z','+00:00'))).days
    if age > 90:
        print(f\"#{i['number']} ({age}d) {i['title']}\")"

B2. PR 管理

加载 github-pr-workflow。

日常巡检:

gh pr list --state open --json number,title,createdAt,author,reviewDecision,statusCheckRollup

CI 失败自动修复（发现问题 → 分析 log → 修复 → 提交 → push）：

# 找到失败的 PR
gh pr list --state open --json number,headRefName,statusCheckRollup
# 下载失败的 CI log
gh run list --branch <branch> --limit 1 --json databaseId --jq '.[0].databaseId' > /tmp/run_id
gh run view $(cat /tmp/run_id) --log-failed
# 分析 → patch → commit → push

⚠️ 不要自动 merge，必须等你确认后再 merge。

B3. 依赖巡检

Dependabot / Renovate PR 自动处理:

gh pr list --author "app/dependabot" --state open --json number,title
gh pr list --author "renovate" --state open --json number,title

手动依赖检查（如果没有 Dependabot）:

# Node.js
npx npm-check-updates 2>/dev/null || npm outdated
# Python
pip list --outdated 2>/dev/null
# Go
go list -u -m all 2>/dev/null | grep '\['

对找到的更新：

1. 判断是 patch / minor / major
2. Patch/minor → 建议 auto-merge（测试通过后）
3. Major → 报告给你，列 breaking changes

B4. 定期功能测试

根据项目的测试框架，定期跑全量测试并报告结果。

# 拉最新代码
git checkout main && git pull origin main
# 跑测试
python -m pytest 2>&1 | tail -30  # Python
npm test 2>&1 | tail -30          # Node
go test ./... 2>&1 | tail -30     # Go
cargo test 2>&1 | tail -30        # Rust

如果测试失败：

1. 读失败日志
2. 分析根因（systematic-debugging skill）
3. 如果能快速修复 → 修 + 提 PR
4. 如果不能 → 报告给你，附上分析

B5. 跨仓库同步

你指定相关仓库列表（存到 memory）:

"监控仓库" → [owner/repo1, owner/repo2, ...]

定期检查:

# 对每个监控仓库
for repo in owner/repo1 owner/repo2; do
  echo "=== $repo ==="
  gh api repos/$repo/releases/latest --jq '.tag_name + " " + .published_at'
  gh api repos/$repo/commits --jq '.[0].sha[0:7] + " " + .commit.message' -f per_page=1
done

发现更新后:

1. 读 changelog / release notes
2. 判断是否影响当前项目（API 变更、breaking、新功能）
3. 如果相关 → 分析影响 → 提建议 → 等你确认
4. 如果只是微调 → 自动创建 PR（标记 [cross-repo-sync]）

冲突处理:

# 当上游有冲突时
git fetch upstream
git merge upstream/main
# 如果有冲突
git diff --name-only --diff-filter=U
# 逐文件分析 → 智能解决 → 报告给你

---

C. Human-in-the-Loop 规则

以下操作必须先问 Harry（用 AskUserQuestion，不用 terminal 的 dangerous flag）:

操作	原因
Merge PR（特别是 major version bump）	可能有 breaking changes
关闭 issue（除非是自动 stale 关闭）	可能误判
删除文件 / 分支	不可逆操作
Force push	破坏历史
发布 release	对外可见
Deploy to production / GitHub Pages	对外可见
修改 repo settings (visibility, branch protection)	结构性改动
卸载 / 删除依赖	可能破坏功能

以下可以自动做但必须报告:

• 创建 issue / PR（告知你编号和链接）
• 打标签 / assign
• lint / test 并报告结果
• 依赖更新 PR（patch/minor）
• 读、分析、研究

---

D. 初始 Setup

首次设置 GitHub Flow 对某个 repo:

1. 确认 repo: gh repo view
2. 检测 CI 系统: 读 .github/workflows/
3. 检测测试框架: 读 package.json / pyproject.toml / go.mod / Cargo.toml
4. 检测依赖管理: dependabot.yml / renovate.json
5. 问用户: 要监控哪些相关仓库？（存到 memory）
6. 创建 cron job:

推荐 cron 配置:

Job	频率	做什么
issue-triage	Daily (9am HKT)	新 issue 标签 + 陈旧 issue 提醒
pr-check	Daily (10am HKT)	开放 PR 状态报告 + CI 失败提醒
dep-check	Weekly (Mon 9am HKT)	依赖更新检查
cross-repo-sync	Weekly (Mon 10am HKT)	相关仓库更新检查
full-test	Weekly (Sun 3am HKT)	全量测试 + 报告

---

E. 交付格式

最终报告统一用这个结构：

## GitHub Flow Report — <repo> — <date>

### 📊 Overview
- Open PRs: N | Open Issues: N | CI: ✅/❌

### 🔔 Action Items
- **需要确认**: ...
- **自动完成**: ...

### 📦 Dependencies
- 可更新: N (patch) + N (minor) + N (major ⚠️)

### 🔗 Cross-Repo
- owner/repo1: v1.2.0 → v1.3.0 (changelog summary)

### 🧪 Test Results
- Pass: N | Fail: N | Skip: N

---

F. 外部参考 & 灵感来源

研究过的两个最成熟的开源方案，已提取最佳实践融入本 skill：

参考 1: alirezarezvani/claude-code-github-workflow (51⭐, MIT)

核心贡献：生产级 GitHub Actions 蓝图 — 8 workflow + 8 slash command + 4 autonomous agent。

本 skill 借鉴的模式:

• 分支策略三层：Simple (feat→main) / Standard (feat→dev→main) / Complex (feat→dev→staging→main) — 首次 setup 时问你选哪种
• CI Auto-Fix Loop：检查失败 → 读 log → 分析根因 → patch → commit → push → 重检（最多 3 轮，然后报告你）
• 安全门禁：fork safety（fork PR 只读处理）、rate limiting、secret scanning、kill switch
• Quality Gates：lint → typecheck → test → security audit，逐级通过才往下走
• Dependabot 自动 merge：patch/minor 自动合并，major 报告等你确认

本 skill 没抄的：GitHub Actions YAML 文件（那是 repo 内 .github/workflows/ 的事，不是 Hermes skill 的 scope）；Slash commands（Hermes 用自然语言，不需要 /command）

参考 2: GabsFranke/claude-code-github-agent (5⭐, MIT)

核心贡献：Docker 微服务架构 — 40+ GitHub webhook events → Claude SDK agent。

本 skill 借鉴的模式:

• Webhook 事件驱动 vs Cron 轮询：前者实时但需要部署服务 + ngrok；后者简单但有时延。本 skill 默认用 cron（Hermes 原生），但记录 webhook 路径供高级用户
• Per-repo CLAUDE.md / SKILL.md：每个项目有自己的 agent 配置，agent 启动时自动加载
• Memory persistence：跨 session 记住 repo 结构、用户偏好（本 skill 已通过 Hermes memory 实现）

本 skill 没抄的：Docker 部署（太重，Hermes 不是微服务架构）；SurrealDB 语义索引（Hermes 用 search_files + ripgrep）

🆚 本 skill 独有（两个参考都没做）

能力	本 skill	claude-code-github-workflow	claude-code-github-agent
Landing page 生成	✅ 自动研究+设计	❌	❌
Demo 录屏视频	✅ 自动 HTML→录屏	❌	❌
Promo 广告视频	✅ Seedance AI 生成	❌	❌
跨仓库同步监控	✅ 指定仓库→定时巡检	❌	❌
Human-in-the-loop	✅ 所有破坏性操作必须确认	⚠️ 部分自动	⚠️ 部分自动
Hermes 原生集成	✅ cron + skill + delegate_task	❌（Claude Code）	❌（Claude SDK）

---

G. 关联 Skill 索引

需要时加载，不要全部预加载：

任务	Skill
PR 操作	github-pr-workflow
Issue 操作	github-issues
Code Review	github-code-review
Landing Page	onezion-websites / onezion-designer / popular-web-designs
Demo 视频 (录屏)	onezion-video → 方案 A
Promo 视频 (AI)	onezion-video → 方案 C
调试失败测试	systematic-debugging

---

注意事项

1. 首次 push 后走完整的 Phase 0→1→2→3，后续 push 默认只做 Phase 0 确认。
2. Memory 里存：监控的仓库列表、用户偏好（要不要每次都做视频、要不要自动创建 issue）。
3. 跨仓库同步时，只处理 breaking changes 和 API 变更；cosmetic commits 忽略。
4. 不要在未经确认的情况下修改 repo settings、删除任何东西、force push。
5. 所有 GitHub Pages 部署前确认。
6. 用 delegate_task 并行处理独立子任务（如同时做 landing page + demo 视频）。