GitHub Iteration Workflow

GitHub Issue 全流程自动化处理。当用户要求处理 GitHub Issue、拉取并修复 Issue、创建 PR、监控 CI/CD、合并部署时使用此技能。涵盖从 Issue 拉取、代码修复、PR 创建、CI/CD 监控到合并部署的完整自动化流程。

Security Scan

The skill's instructions align with an end-to-end GitHub workflow, but the package metadata omits required tooling/credentials and the runtime instructions imply using a 'sub-agent' that could send repository context elsewhere — these mismatches and ambiguities warrant caution.

Purpose & Capability

The SKILL.md clearly implements a GitHub issue → fix → PR → CI → merge workflow and therefore legitimately needs GitHub CLI authentication and push access. However, the registry metadata declares no required binaries or primary credential despite the instructions explicitly requiring 'gh auth status', a cloned repo, and push permissions. The missing declarations are an inconsistency (metadata understates needed capabilities).

Instruction Scope

The instructions stay within the GitHub/local-repo domain (gh, git, gh api, gh run view). Concern arises from the line '用一个子代理传入所有 Issue 描述 + 项目上下文，让它整体规划后统一修改' — that implies launching a subordinate agent that consumes repository context and issue data. The SKILL.md does not specify whether that sub-agent runs locally or sends code/metadata to an external LLM/service; if the latter, sensitive repository contents could be exfiltrated. Otherwise the step is within scope.

Install Mechanism

This is an instruction-only skill with no install spec or code files, so nothing will be written to disk by the skill bundle itself. That is the lowest-risk installation profile.

Credentials

The runtime requires an authenticated gh CLI and a user with push rights, but the skill metadata lists no required environment variables or declared primary credential. The absence of declared credential/env requirements is a mismatch. Also note the workflow's actions (push, merge, potentially using --admin) require high-scope tokens; users should confirm least-privilege tokens and branch protections before enabling automation.

Persistence & Privilege

The skill does not request always:true and does not claim to modify other skills or global agent settings. Autonomous invocation is permitted (default) which is expected for skills; nothing in the manifest grants excessive persistent privileges.

What to consider before installing

This skill appears to implement a legitimate GitHub issue-to-deploy workflow but has some gaps and ambiguities you should address before installing: - Confirm where and how the 'sub-agent' runs. If it sends repository files or issue contents to an external service/LLM, treat that as potential data exfiltration. - The SKILL.md requires GitHub CLI authentication and push/merge privileges, but the registry metadata does not declare any required binaries or credentials — verify that the agent/runtime has a properly-scoped GitHub token (least privilege) and that branch protection policies are appropriate. - Be cautious about batching many unrelated issues into a single branch/PR (the workflow recommends batch PRs); that increases blast radius and complicates rollbacks. - Ensure CI/CD secrets and deploy permissions are not implicitly exposed to the automation. Prefer scoped deploy tokens and require reviews where possible. - Ask the publisher to update metadata to declare required binaries/credentials and to clarify the 'sub-agent' design (local vs. external). If you cannot confirm these, avoid granting the skill push/merge rights on critical repositories. If you want, I can draft a short checklist or an updated metadata/template you can request from the skill author to resolve these concerns.

GitHub Issue 全流程自动化

从拉取 Issue 到合并部署的端到端自动化工作流。

前置条件

• GitHub CLI 已认证（gh auth status 正常）
• 仓库已克隆到本地
• 有仓库的 push 权限

工作流

1. 拉取所有 Open Issue

cd <repo-path>
gh issue list --state open

批量获取所有需要处理的 Issue 详情：

# 获取所有 open issue 的编号和标题
gh issue list --state open --json number,title,body

2. 统一分析所有 Issue

一次性获取所有 open issue，整体评估：

gh issue list --state open --json number,title,body,labels

分析要点：

• 哪些 Issue 相关（同一模块、同一文件、同一类问题）
• 是否存在依赖关系（A 修了影响 B）
• 能否合并为一次修复（相关 Issue 放同一分支）

输出一份修复计划： 分组 → 确定分支策略 → 明确每个 Issue 对应的改动

3. 整体修复

基于分析结果，创建分支并一次性实现所有修复：

git checkout master && git pull origin master
git checkout -b fix/batch-<date>-<总体描述>

修复策略：

• 用一个子代理传入所有 Issue 描述 + 项目上下文，让它整体规划后统一修改
• 相关 Issue 合并处理，减少重复改动
• 每个 Issue 的修复在同一分支内用独立 commit 区分

4. 分 commit 提交推送

每个 Issue 单独一个 commit，便于追踪：

# 按 Issue 逐个提交
git add <files-for-issue-A>
git commit -m "fix: <issue-A描述> (#<A>)"

git add <files-for-issue-B>
git commit -m "fix: <issue-B描述> (#<B>)"

推送统一分支：

git push -u origin fix/batch-<date>-<总体描述>

5. 创建一个 PR 关联所有 Issue

gh pr create \
  --title "Batch fix: <总体描述>" \
  --body "## 关联 Issues

Closes #<A>, Closes #<B>, Closes #<C>

### Issue #<A>: <标题>
<修复说明>

### Issue #<B>: <标题>
<修复说明>

### Issue #<C>: <标题>
<修复说明>" \
  --base master

6. 监控 CI/CD

gh pr checks <PR-number>

检查项： Code Quality / Security Scan / Unit Tests / E2E Tests / Deploy Preview

CI 失败自动修复：

1. 查看失败日志：gh run view <run-id> --log-failed
2. 修复并推送：git commit -am "fix: CI ..." && git push
3. 重新检查直到通过

7. 合并并部署

CI 通过后合并：

gh pr merge <PR-number> --merge
# 分支保护时用 --admin

8. 验证部署并发送报告

gh api repos/<owner>/<repo>/deployments --jq '.[0:3] | .[] | "\(.environment) - \(.sha[0:7]) - \(.created_at)"'

报告内容：

• 每个 Issue 的编号、标题和修复说明
• PR 链接（一个 PR 覆盖所有 Issue）
• CI/CD 结果汇总
• 部署状态
• 修改文件列表

提交信息规范

• fix: 修复问题
• feat: 新功能
• refactor: 重构
• docs: 文档更新
• style: 代码格式
• test: 测试相关

分支命名规范

• fix/issue-<n>-<desc> — 修复
• feat/issue-<n>-<desc> — 新功能
• refactor/issue-<n>-<desc> — 重构