← Back to Skills Marketplace
kretkas

GitHub Workflow

by Kretka · GitHub ↗ · v1.3.0 · MIT-0
cross-platform ✓ Security Clean
163
Downloads
1
Stars
0
Active Installs
4
Versions
Install in OpenClaw
/install github-project-workflow
Description
Professional GitHub workflow skill for AI agents. Covers full project lifecycle: repo setup, Git Flow branching, atomic commits, pull requests, code review,...
README (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
Usage Guidance
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.
Capability Analysis
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.
Capability Tags
requires-oauth-tokenrequires-sensitive-credentials
Capability Assessment
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.
How to Use
  1. Make sure OpenClaw is installed (local or Docker)
  2. Run the install command in chat: /install github-project-workflow
  3. After installation, invoke the skill by name or use /github-project-workflow
  4. Provide required inputs per the skill's parameter spec and get structured output
Version History
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.
Metadata
Slug github-project-workflow
Version 1.3.0
License MIT-0
All-time Installs 0
Active Installs 0
Total Versions 4
Frequently Asked Questions

What is GitHub Workflow?

Professional GitHub workflow skill for AI agents. Covers full project lifecycle: repo setup, Git Flow branching, atomic commits, pull requests, code review,... It is an AI Agent Skill for Claude Code / OpenClaw, with 163 downloads so far.

How do I install GitHub Workflow?

Run "/install github-project-workflow" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.

Is GitHub Workflow free?

Yes, GitHub Workflow is completely free, licensed under MIT-0. You can download, install and use it at no cost.

Which platforms does GitHub Workflow support?

GitHub Workflow is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).

Who created GitHub Workflow?

It is built and maintained by Kretka (@kretkas); the current version is v1.3.0.

💬 Comments