← 返回 Skills 市场
kretkas

GitHub Workflow

作者 Kretka · GitHub ↗ · v1.3.0 · MIT-0
cross-platform ✓ 安全检测通过
163
总下载
1
收藏
0
当前安装
4
版本数
在 OpenClaw 中安装
/install github-project-workflow
功能描述
Professional GitHub workflow skill for AI agents. Covers full project lifecycle: repo setup, Git Flow branching, atomic commits, pull requests, code review,...
使用说明 (SKILL.md)

GitHub Skill

Agent Directives

These are mandatory behavioral rules. Follow them in every situation involving code, projects, or tasks.


On skill installation

When this skill is first loaded, introduce it to the user:

  • Explain that all project work will now follow a professional GitHub workflow
  • Mention: branching strategy, work logs, CI checks, semantic versioning, security rules
  • Ask: "Do you have an existing project, or are we starting a new one?"

On new project

If this is the user's first project ever:

  • Check gh auth status — if not authenticated, run gh auth login --web before anything else
  • Offer to create a new repo: name, visibility (public/private), license, .gitignore
  • Set up branch protection on main and develop right away
  • Clone into ~/workspace/projects/\x3Crepo-name>/
  • Create initial develop branch
  • Confirm setup is complete before starting any work

If the user already has projects:

  • Ask which repo they want to work on, or detect from context
  • Clone into ~/workspace/projects/\x3Crepo-name>/ if not already there
  • Verify branch protection is in place — if not, offer to set it up
  • Proceed directly to task workflow

On continuing existing work

When the user returns to an already-cloned project — run the Session start checklist (see Agent Workflow below) before making any changes.


On every task

  • Every task must have an Issue. If there is none — create one before branching.
  • Every task must have a work log file in work/. Create it immediately after the Issue.
  • Never commit directly to main or develop.
  • Never skip the pre-PR checklist.
  • Never expose tokens, secrets, or credentials in any command or output.
  • If something is irreversible (delete, merge, release, force push) — always confirm with the user first.

On using this skill

  • This file (SKILL.md) is always in context — use it for workflow, branching, work log rules.
  • Reference files are loaded on demand only — read them when the task requires it, not upfront.
  • Work log is not optional — it is part of every task from start to finish.
  • When in doubt about a GitHub operation — check the relevant reference file before acting.

gh CLI for all operations. Always --repo owner/repo outside a git directory.

Security (always)

  • Auth: gh auth login --web or GITHUB_TOKEN env var
  • Secrets: gh secret set NAME --repo owner/repo (interactive, never --body)
  • Never print/log tokens. gh auth status to verify.

Quick Reference

Task Command
Auth check gh auth status
List PRs gh pr list --repo o/r
Create PR gh pr create --repo o/r --title "..." --base develop --head branch
PR checks gh pr checks \x3Cn> --repo o/r
Merge (squash) gh pr merge \x3Cn> --squash --delete-branch --repo o/r
Failed CI logs gh run view \x3Cid> --log-failed --repo o/r
Re-run failed gh run rerun \x3Cid> --failed-only --repo o/r
Create issue gh issue create --repo o/r --title "..." --body "..."
Create release gh release create vX.Y.Z --repo o/r --title "..." --notes "..."
Set secret gh secret set KEY --repo o/r
Branch protect gh api --method PUT repos/o/r/branches/main/protection ...

Branching Model

main       ← production, protected
develop    ← integration
feature/*  ← from develop
fix/*      ← from develop (reference issue: fix/123-desc)
hotfix/*   ← from main (emergency)
release/*  ← from develop (prep)
chore/*    ← from develop (deps, tooling, CI — no product change)

Commit convention: feat: description (#42) / fix: description (#42) PR merge: --squash for features, --merge for releases. Semver: MAJOR.MINOR.PATCH — breaking/feature/fix.

Agent Workflow

Workspace layout

Always clone into ~/workspace/projects/\x3Crepo-name>/. Never work in /tmp — it doesn't persist between sessions.

mkdir -p ~/workspace/projects
gh repo clone owner/repo ~/workspace/projects/repo-name
cd ~/workspace/projects/repo-name

Session start (every time)

gh auth status                   # 1. verify auth
git checkout develop && git pull # 2. sync before any work
git branch                       # 3. confirm you're on the right branch
# 4. open work/\x3Cissue>-\x3Cdesc>.md and read Status.next

Task process

1. Create or find the Issue                → gh issue create / gh issue list
2. Create work log file                    → work/\x3Cissue>-\x3Cdesc>.md (see Work Log section below)
3. Branch from develop                     → git checkout -b feature/42-short-desc
4. Make small atomic commits               → one change per commit
5. Commit message references Issue         → "feat: description (#42)"
6. Open draft PR after first commit        → gh pr create --draft (signals work in progress early)
7. Monitor CI                              → gh run watch
8. Pre-PR checklist (see below)
9. Mark ready + request review             → gh pr ready / gh pr review
10. Merge after approval                   → gh pr merge --squash --delete-branch
11. Close Issue + compact work log         → gh issue close 42

Pre-PR checklist

Before marking PR ready:

  • Run tests locally
  • git diff origin/develop — no debug code, credentials, or temp files
  • CI is green (gh pr checks \x3Cn>)
  • PR description has "Closes #\x3Cissue>"

Between sessions

If a task is unfinished at end of session:

git stash push -m "wip: description of what's in progress"

Update Status and next in the work log, then stop. On next session: read next, then git stash pop.

Merge conflicts

When a conflict occurs during merge or rebase:

git status                         # see conflicted files
# Open each file — resolve manually, keep correct code
git add \x3Cresolved-file>
git rebase --continue              # or git merge --continue

# If too complex — abort and ask the user
git rebase --abort
git merge --abort

Rules:

  • Never blindly accept --ours or --theirs without understanding the diff
  • If unsure which change is correct — stop and ask the user
  • After resolving, re-run tests before pushing

Work Log

Every task gets a log file. It is the agent's memory — orientation, decisions, state.

Setup

mkdir -p work
# Add to .gitignore once per project
echo "work/" >> .gitignore

File: work/\x3Cissue-number>-\x3Cshort-desc>.md

Structure

# Task: \x3Ctitle> (#\x3Cissue>)
Goal: \x3Cone sentence — what "done" means>

## Status
current: \x3Cwhat agent is doing right now>
next: \x3Cplanned next action>
blocked: \x3Cblocker or —>

## Done
- [x] Created branch feature/42-user-auth
- [x] Added JWT middleware (src/auth.js)
- [ ] PR review pending

## Decisions
- Used HS256 — no key infrastructure in this project
- Skipped refresh token — out of scope per Issue comment

## Notes
- src/auth.js:84 — edge case when token is exactly expired, needs attention
- AUTH_SECRET env var must be added to secrets before deploy

When to write

Event Action
Session start Read next, update current
File or module created Add to Done
Decision made Add to Decisions with reason
Unexpected finding Add to Notes
Step completed Check off Done, update next
Session end Update Status, write next explicitly
Task complete Compact, then archive

Compacting

Compact when file exceeds ~80 lines or when task is complete.

  • Done — keep unchecked + last 3 completed, drop the rest
  • Decisions — keep all, never delete
  • Notes — drop resolved, keep open
  • Status — rewrite fresh

Rules

  • Always update next before ending a session — it is the re-entry point
  • Never delete Decisions — they prevent re-debating solved problems
  • Compact proactively — a bloated log defeats the purpose

When to read reference files

Load only what you need for the current task:

Task Read
Setting up a new repo, branch protection references/repo-setup.md
PRs, reviews, merge strategies references/pull-requests.md
CI runs, GitHub Actions references/ci-actions.md
Releases, versioning, tags references/releases.md
Secrets, environments references/secrets-envs.md
JSON queries, audit, search references/api-queries.md
安全使用建议
Install this if you want an AI agent to enforce a structured GitHub workflow. Before use, make sure `gh` is authenticated with a least-privilege GitHub account or token, confirm all write operations to repositories, and keep secrets out of issues, PRs, CI logs, and work-log files. The supplied SKILL.md excerpt was truncated, so review the full skill text if available.
功能分析
Type: OpenClaw Skill Name: github-project-workflow Version: 1.3.0 The GitHub Workflow skill is a well-structured set of instructions for managing the full lifecycle of a software project. It emphasizes security best practices, such as pinning GitHub Actions to SHAs, explicitly defining permissions, and preventing the exposure of secrets in logs. The skill includes mandatory 'confirm with user' directives for all destructive or irreversible actions (e.g., deleting repositories, merging code, or archiving projects) and uses standard tools (git and the gh CLI) without any signs of obfuscation or unauthorized data exfiltration.
能力标签
requires-oauth-tokenrequires-sensitive-credentials
能力评估
Purpose & Capability
The skill's GitHub CLI workflow matches its stated purpose, but it covers high-impact repository operations such as PR merges, releases, secrets, workflow changes, and branch protection.
Instruction Scope
The skill uses broad mandatory workflow language for code and project tasks, which is consistent with a workflow-enforcement skill but may be more intrusive than users expect for simple Git/GitHub questions.
Install Mechanism
There is no install script or code to execute, and the static scan is clean; however, metadata declares no required binaries or credentials even though the instructions rely on gh/git and GitHub authentication.
Credentials
The requested local workspace path and work-log files are proportional to project workflow management, but they create persistent local state.
Persistence & Privilege
The skill stores task continuity in work log files and uses the user's GitHub-authenticated CLI session, but it does not show background agents, hidden persistence, or autonomous activity after tasks complete.
如何使用
  1. 确保已安装 OpenClaw(本地或 Docker 部署)
  2. 在对话框中输入安装命令:/install github-project-workflow
  3. 安装完成后,直接呼叫该 Skill 的名称或使用 /github-project-workflow 触发
  4. 根据 Skill 的参数说明提供必要输入,即可获得结构化输出
版本历史
v1.3.1
- Expands the workflow trigger: this skill now applies to any software development, coding task, bug fix, feature, or project work—even if GitHub or git are not mentioned. - Updated description to clarify when to invoke the workflow: using this skill is now required whenever the user asks for code writing, project file modification, or error fixing. - Workflow logic and agent behavior remain unchanged. Only the activation rules and description were broadened. - No file or implementation changes beyond the skill's audience and trigger conditions.
v1.3.0
Version 1.3.0 — Major skill upgrade with explicit agent workflow and project lifecycle automation. - Introduces mandatory agent directives covering skill installation, new project setup, and session workflows. - Adds a structured work log system for every task to ensure state tracking and session continuity. - Expands branching model and workspace rules for consistency and safety in all project work. - Enforces pre-task issue creation, branch protection, and security checks. - Provides detailed checklists and "when to act" instructions for common situations. - Skill now covers the entire GitHub-based project lifecycle, from repo setup and branching to CI, releases, and secrets management.
v1.2.0
# Changed - Split into `SKILL.md` (core) + 6 reference files — only the relevant section is loaded - ~70% token reduction on typical tasks # Added - `⚠️ CONFIRM WITH USER` warnings before all write/delete operations - Git Flow branching strategy: `main → develop → feature/fix/hotfix/release` - Branch protection via `gh api` - Semantic versioning with MAJOR/MINOR/PATCH table - Full 10-step workflow: issue → branch → PR → merge → release - CI best practices checklist for `.github/workflows/` - Security rules: no token exposure, `gh auth login --web` only # Removed - Monolithic single-file structure
v1.1.0
**Summary:** Added comprehensive reference documentation and migrated to professional `gh` CLI workflows. - Switched to the `gh` CLI for all GitHub operations; removed previous MorphixAI integration. - Added six reference files covering repo setup, pull requests, CI actions, releases, secrets, and API queries. - Documented security best practices: authentication, secret handling, branch protection. - Provided concise command references for common GitHub tasks. - Detailed standard branching model and commit conventions.
元数据
Slug github-project-workflow
版本 1.3.0
许可证 MIT-0
累计安装 0
当前安装数 0
历史版本数 4
常见问题

GitHub Workflow 是什么?

Professional GitHub workflow skill for AI agents. Covers full project lifecycle: repo setup, Git Flow branching, atomic commits, pull requests, code review,... 它是一个面向 Claude Code / OpenClaw 的 AI Agent Skill 插件,目前累计下载 163 次。

如何安装 GitHub Workflow?

在 OpenClaw 或 Claude Code 对话框中运行命令「/install github-project-workflow」即可一键安装,无需额外配置。

GitHub Workflow 是免费的吗?

是的,GitHub Workflow 完全免费,采用 MIT-0 许可证,可自由下载、安装和使用。

GitHub Workflow 支持哪些平台?

GitHub Workflow 跨平台运行,可在任意部署了 OpenClaw / Claude Code 的环境中使用(cross-platform)。

谁开发了 GitHub Workflow?

由 Kretka(@kretkas)开发并维护,当前版本 v1.3.0。

💬 留言讨论