gh-workflow

Use after receiving PR review feedback to systematically address comments, verify fixes, and re-request review

Use after making changes to commit with context-aware classification that flags out-of-context modifications before committing

Explore what AI built — loads decision journal, diff, and issue context for interactive Q&A

Use when needing to create a new GitHub issue to gather requirements, check for duplicates, and create solution-agnostic issues

Use after PR is approved to merge with safe defaults, verification checks, and optional branch cleanup

Use proactively after code changes to review for quality, security, edge cases, and error handling. Use when performing self-review before PR creation or during PR review.

Use when validating Git conventions including commit messages, branch naming, PR format, and issue linkage. Use during PR review or before creating a PR.

Use when starting work on a GitHub issue to parse acceptance criteria and create a task breakdown. Use to establish implementation order and track progress.

Use to discover and run project-specific lint, test, and type-check commands. Use after code changes to verify quality gates pass before PR creation or merge.

Discovers available agents, skills, quality commands (lint, test, typecheck), and tech stack in the project environment. Use when starting implementation, creating PRs, reviewing PRs, or addressing feedback to determine which agents to dispatch and which quality commands to run. Use before workflow execution to adapt gh-workflow commands to project-specific tooling.

Generates architecture narratives and requirements adherence reports from diffs, decision journals, and issue context. Use when creating PR bodies that need comprehension reports. Use when validating that implementation meets acceptance criteria or when humans need to understand what AI built and why.

Extracts and structures development decisions from diffs, manages decision journal entries, and detects human gate triggers. Use when logging decisions during gh-start, gh-commit, or gh-address. Use when summarizing decisions for PR bodies or when checking for gate-triggering changes like new dependencies, security modifications, or scope deviations.

Detect, classify, and resolve git merge conflicts through structured analysis of conflict markers, per-file strategy selection, and post-resolution verification. Use when a branch has conflicts with its merge target, when rebasing onto an updated base, or when gh-merge detects an unmergeable PR.

Provides dynamic repository configuration patterns for gh-workflow agents. Use when an agent needs the default branch name for diffs, the repository owner/name for API calls, or branch naming and commit conventions for validation.