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.
Install with the open skills CLI (global, non-interactive — available in every Claude Code session):
npx skills add nearai/ironclaw --skill "github-workflow" -g -a claude-code -yOr manually — clone and copy the skill directory (SKILL.md + companion files):
git clone --depth 1 https://github.com/nearai/ironclaw /tmp/ironclaw && cp -r /tmp/ironclaw/skills/github-workflow ~/.claude/skills/github-workflowThis skill is a directory: SKILL.md is the entry point; the files below ship with it.
---
name: github-workflow
version: 0.1.0
description: 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.
activation:
keywords:
- github workflow
- CI automation
- PR automation
- automate repo
- issue to merge
- workflow setup
- github automation
patterns:
- "(?i)(set ?up|install|enable).*(workflow|automation) for .+/.+"
- "(?i)automate (this |my )?(repo|repository|PRs|CI)"
- "(?i)github (workflow|automation|pipeline)"
tags:
- developer
- github
- automation
- workflow
max_context_tokens: 2000
requires:
skills:
- github
---
# 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.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when completing tasks, implementing major features, or before merging to verify work meets requirements