# Github Workflow

> Install and operate a full GitHub issue-to-merge workflow for any repository using event-driven and cron missions. Handles issue planning, PR monitoring, CI fixing, staging review, and post-merge learning.

- Skill: `suyoumo/github-workflow` (Agent Skill)
- Install (CLI): `npx skillmds@latest add suyoumo/github-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/suyoumo/github-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: suyoumo (https://skillmd.com/u/suyoumo)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/suyoumo/github-workflow

---


# GitHub Workflow Automation

Install and maintain a complete issue-to-merge workflow for any GitHub repository. Maps GitHub webhook events and cron schedules into automated missions for planning, implementation, review, CI fixing, staging validation, and post-merge learning.

## Workflow

1. Gather project parameters from `projects/<owner>-<repo>/project.md` or ask the user.
2. Verify runtime prerequisites.
3. Install or update mission set from templates.
4. Run a dry test with `event_emit`.
5. Monitor outcomes and tune prompts/filters.

## Parameters

Read these from the project file in workspace, or collect from the user:
- `repository`: `owner/repo` (required)
- `maintainers`: GitHub handles allowed to trigger implement/replan actions
- `staging_branch`: default `staging` (or null if no staging workflow)
- `main_branch`: default `main`
- `batch_interval_hours`: default `8`

## Prerequisites

Before installing missions, verify:
- GitHub skill authenticated (for issue/PR/comment/status operations).
- GitHub webhook delivery configured to `POST /webhook/tools/github`.
- Webhook HMAC secret configured in the secrets store as `github_webhook_secret`.
- Events can also be emitted via `event_emit` tool for testing.

## Install Procedure

1. Open [`workflow-routines.md`](references/workflow-routines.md).
2. For each template block:
   - Replace placeholders (`{{repository}}`, `{{maintainers}}`, branch names)
   - Namespace mission names with the repo slug (e.g. `wf-issue-plan-nearai-ironclaw`)
   - Call `mission_create` with `name`, `goal` (the prompt), and `cadence` (cron expression or `event:<pattern>`)
3. If a mission already exists (check `mission_list`), update rather than duplicate.
4. If `staging_branch` is null, skip `wf-staging-batch-review`.
5. Write installation status to `projects/<owner>-<repo>/project.md`.
6. Confirm install with `mission_list`.

## Mission Set

Install these missions per repository:
- `wf-issue-plan-<slug>`: on `issue.opened` or `issue.reopened`, generate implementation plan comment.
- `wf-maintainer-gate-<slug>`: on maintainer comments, decide update-plan vs start implementation.
- `wf-pr-monitor-<slug>`: on PR open/sync/review-comment/review, address feedback and refresh branch.
- `wf-ci-fix-<slug>`: on CI status/check failures, apply fixes and push updates.
- `wf-staging-review-<slug>`: every N hours, review ready PRs, merge into staging, run batch correctness analysis, fix findings, then merge staging to main.
- `wf-learning-<slug>`: on merged PRs, extract mistakes/lessons and write to shared memory.

## Event Filters

Use top-level filters for stability:
- `repository_name` (e.g., `owner/repo`)
- `sender_login`, `comment_author`
- `issue_number`, `pr_number`
- `ci_status`, `ci_conclusion`
- `review_state`, `pr_merged`

## Operating Rules

- All implementation work on non-main branches.
- PR loop must resolve both human and AI review comments.
- On conflicts with origin/main, refresh branch before continuing.
- Staging-batch is the only path for bulk correctness verification before mainline merge.
- Memory update runs only after successful merge.

## Validation

After install, run:
1. `event_emit` with a synthetic `issue.opened` payload for the target repo.
2. Confirm at least one mission fired.
3. Check corresponding mission status.
4. Confirm no unrelated missions fired.