gh-implement

name	gh-implement
description	Orchestrator for implementing a Reihitsu GitHub issue end-to-end in a Claude Code Cloud Agent environment. Triggers when the initial prompt references a GitHub issue (e.g. "implement

Implement GitHub Issue (Cloud Agent Orchestrator)

You are running inside a Claude Code Cloud Agent sandbox — a Linux environment, essentially identical to the one you are executing in right now. The repository checkout is present, but the build toolchain is not, and there is no gh CLI. Your job is to take a single GitHub issue from unclaimed to a validated draft PR, delegating the actual implementation to the repository's task-specific slash commands whenever one fits.

You own the environment, the issue lookup, the branch, the validation, and the pull request. The delegated command owns the production change and its tests.

Build environment (after the issue claim)

The cloud sandbox is Linux and does not ship with the .NET SDK. Claim the issue first; then, before doing anything that touches dotnet, install the latest .NET 10 SDK. The repository targets net10.0 (see any *.csproj) and there is no global.json.

1. Probe the toolchain:

   dotnet --list-sdks
   

   If the command is missing or no 10.* SDK is listed, install it. Do not fall back to an older SDK — the full test suite will not run on net10.0 without it.

2. Install via the official dotnet-install.sh script (no admin rights required, installs into $HOME/.dotnet). This is a Linux environment, so use the shell script — there is no PowerShell path to consider:

   curl -sSL https://dot.net/v1/dotnet-install.sh -o /tmp/dotnet-install.sh
   bash /tmp/dotnet-install.sh --channel 10.0 --install-dir "$HOME/.dotnet"
   export PATH="$HOME/.dotnet:$PATH"
   dotnet --list-sdks
   

   Keep $HOME/.dotnet on PATH for every later dotnet invocation in the run.

3. If the script itself cannot be reached (no network egress, mirror missing, etc.), record the failure in the already-open draft PR's Review notes and stop. Do not proceed with a partial validation — a green run without the SDK is meaningless.

GitHub access — MCP only, no gh CLI

The sandbox has no gh CLI and no direct GitHub API access. Every GitHub interaction — reading the issue, opening the PR, commenting back — goes through the GitHub MCP server (mcp__github__* tools). If those tools are not yet loaded, use ToolSearch (e.g. github pull request, github issue) to surface them first.

Never shell out to gh, git against the API, or curl the GitHub REST API by hand. Use:

Purpose	MCP tool
Confirm identity / permissions	mcp__github__get_me
Read the issue	mcp__github__issue_read
Search for related/duplicate issues	mcp__github__search_issues / mcp__github__list_issues
Create the pull request (draft)	mcp__github__create_pull_request
Update the draft pull request	mcp__github__update_pull_request

The local git CLI is still available for branch/commit/push — only the GitHub platform calls go through MCP.

Keep CI silent until everything is done

SonarCloud.yml runs on push to main and on pull_request (opened/synchronize/reopened) against main. Left alone that means one CI run per push while the branch is still being claimed, implemented, and fixed up — noise that only needs to happen once, at the end. GitHub Actions skips the workflow run entirely when the triggering commit's message contains [skip ci], so every commit this skill creates except the final one must end its subject with [skip ci]:

• The claim commit, every focused implementation commit, and any fix-up commit made while chasing a validation failure all get [skip ci].
• The single exception is the run's last commit, pushed in "Complete the draft pull request" once validation is fully green — it must not contain [skip ci], so it becomes the one CI run for the issue.

Don't rely on "whichever commit happens to be last" to satisfy this — "Complete the draft pull request" adds a dedicated, empty, non-skip-ci commit so the trigger is unambiguous even when validation needed no fix-up commits.

Parse the issue reference

The issue reference comes from the initial user/agent prompt, not from the branch name. Accept any of:

• #123
• https://github.com/<owner>/<repo>/issues/123
• GH-123, issue 123, implement issue 123

Extract the integer issue number. If the prompt names a repository other than the current origin, use that owner/repo when calling the GitHub MCP tools; otherwise default to the current repo.

If no issue number can be extracted with confidence, stop and ask. Do not guess.

Read the issue

Read the issue with mcp__github__issue_read (owner, repo, issue number). Capture its number, title, body, labels, state, and URL.

Use the labels and body to pick a delegate (see next section). Cache the issue URL and title — you will need them for the branch name, commit message, and PR body.

Claim the issue with an immediate draft PR

Avoid duplicate work before installing dependencies or editing files:

1. Inspect the issue body, comments, and linked pull requests for an existing claim or an open draft PR. If another agent or person has claimed it, stop and report the existing branch or PR; do not create a competing branch.

2. Create the branch from the current remote baseline, add an empty claim commit so the branch differs from main, and push it:

   git fetch origin main
   git checkout -b claude/issue-<N>-<short-slug> origin/main
   git commit --allow-empty -m "Claim issue #<N> [skip ci]"
   git push -u origin claude/issue-<N>-<short-slug>
   

3. Before implementation, open a draft PR with mcp__github__create_pull_request and set draft to true. Use the issue title and fill every section of .github/PULL_REQUEST_TEMPLATE.md with the current plan:

   ## Summary
   
   Planned: <one or two sentences describing the intended change>
   
   ## Why
   
   <explain the issue's impact or motivation>
   
   ## Linked issues
   
   Closes #<N>
   
   ## Review notes
   
   Implementation has not started. This draft reserves the issue; details will be updated after focused implementation commits.
   
   ## Follow-up work
   
   To be determined during implementation.
   

The linked draft PR is the ownership record. Do not post a claim comment, PR-link comment, or in-progress label on the issue. GitHub links the PR automatically through Closes #<N>.

Delegate to the matching slash command

The orchestrator does not implement the change itself when a specific command fits. The commands live under .claude/commands/ and each one has its own mandatory workflow, checklist, and validation guidance. Pick the most specific match:

Issue signal	Delegate to	Notes
Formatter produces wrong output, regression in formatting	fix-formatter	Regression test first, then fix
Bug in an existing analyzer rule (RH#### listed)	fix-analyzer-rule	Reproduce in test first
New analyzer rule requested	create-analyzer-rule	Only ship a code fix if comprehensive
New or extended formatter behavior	extend-formatter	Match existing pipeline phases
Missing or stale rule doc under documentation/rules/	create-rule-doc	Keep helpLinkUri in sync
Localized resource string add / change	add-resource-texts	Update every locale
Issue itself is a draft to be uploaded	draft-issue	Validates against upload-issues.ps1
Nothing above matches	Implement inline using the rules in CLAUDE.md	Still run the full validation below

Delegation rule. When a command matches, follow that command's workflow as written. The orchestrator's job is to wrap it with the environment setup, the validation, and the PR — it does not relax or override the delegated command's own checklist (regression-test-first, single focused tests, code-fix-only-if-comprehensive, etc.).

If the issue contains two clearly separable concerns (e.g. a formatter bug and a new resource text), prefer two PRs over one. Open the most blocking one first and leave a Follow-up work note in the PR pointing at the second.

Branch and commit

The branch already contains the empty claim commit, is pushed, and has an open draft PR. Its slug is a lower-kebab-case excerpt of the issue title (≤ 4 words).

1. Make the change via the delegated command. Stage only the files that belong to this issue. Never git add -A blindly — the cloud sandbox may contain unrelated SDK install artifacts.

2. Format the changed files through the CLI before tests:

   dotnet run --project Reihitsu.Cli -- <changed-path-1> [<changed-path-2> ...]
   

3. Commit with a Conventional-Commits style subject that mentions the issue and ends with [skip ci] (see "Keep CI silent until everything is done"), then push it:

   Fix RH3204 code fix for interpolated strings (#<N>) [skip ci]
   

Update the draft after focused commits

Immediately after the first focused implementation commit is pushed, update the existing draft PR with mcp__github__update_pull_request. Replace the intent-only wording with what the commits actually changed, retain Closes #<N>, and fill every template section. Update the body again whenever later commits materially change the summary, review notes, or follow-up work. Keep the PR draft while validation is running and implementation continues.

Validation (always run, never skip)

Run from the repo root with the just-installed SDK on PATH:

dotnet build Reihitsu.sln -c Release --verbosity minimal
dotnet test Reihitsu.Analyzer.Test/Reihitsu.Analyzer.Test.csproj -c Release --verbosity minimal
dotnet test Reihitsu.Formatter.Test/Reihitsu.Formatter.Test.csproj -c Release --verbosity minimal
dotnet test Reihitsu.Core.Test/Reihitsu.Core.Test.csproj -c Release --verbosity minimal
dotnet test Reihitsu.Cli.Test/Reihitsu.Cli.Test.csproj -c Release --verbosity minimal

All four test projects must pass. If any fails:

1. Read the failure, decide if it is caused by your change or a pre-existing issue on main.
2. Fix issues caused by your change and commit with [skip ci] in the subject before pushing. Do not silence tests or mark them [Ignore].
3. If a failure exists on main independent of your change, record it in the draft PR's Review notes with mcp__github__update_pull_request and stop. Do not continue implementation on top of a broken baseline.

Do not list the executed test commands in the PR body. CI re-runs them and the repo convention (CLAUDE.md) is to keep the PR description concise.

Complete the draft pull request

1. Push any remaining validation fix-up commits, then add the run's single non-skip-ci commit so the push triggers the one CI run for this issue:

   git push
   git commit --allow-empty -m "Ready for CI (#<N>)"
   git push
   

   This is the only commit in the run that must not contain [skip ci].

2. Update the existing draft PR with mcp__github__update_pull_request so its body describes the final implementation. Use .github/PULL_REQUEST_TEMPLATE.md as the body layout and fill every section:

   • ## Summary
   • ## Why
   • ## Linked issues
   • ## Review notes
   • ## Follow-up work

   Linked issues must retain GitHub-native linking so the issue auto-closes on merge:

   Closes #<N>
   

   Use this final body structure:

   ## Summary
   
   <one or two sentences on what changed>
   
   ## Why
   
   <link the motivation to the issue, do not just restate the title>
   
   ## Linked issues
   
   Closes #<N>
   
   ## Review notes
   
   <call out any risk, behavior change, or trade-off the reviewer should know>
   
   ## Follow-up work
   
   <None, or one line per deferred item>
   

   Keep the PR draft. The reviewer flips it to ready when they have eyes on it.

3. Verify that the PR is still draft and that Closes #<N> links it to the issue. Do not post an issue comment; the linked draft PR is the ownership and status record.

Hard rules

• Never mark the draft PR ready for review without running the full validation above. A green build on three of four test projects is a regression — run all four.
• Never open a non-draft PR from the cloud agent. The human reviewer marks ready.
• Never delay the initial draft PR until implementation exists. Create the empty claim commit and intent-only draft before installing dependencies or editing files.
• Never post claim, PR-link, or status comments on the issue, and do not apply an in-progress label. Use the linked draft PR as the ownership record.
• Never silence or skip a failing test to make the PR go green.
• Never push a commit without [skip ci] before validation is green — the empty trigger commit in "Complete the draft pull request" is the only exception.
• Never modify global.json or the TargetFramework to dodge an SDK install — install the SDK via dotnet-install.sh instead.
• Never reach for the gh CLI or a raw GitHub API call — it is not available. Use the GitHub MCP server (mcp__github__*).
• Never edit files outside the scope of the issue. Out-of-scope cleanups go in a separate issue or a follow-up note.
• Never include a list of locally executed tests in the PR body (per CLAUDE.md).

Quick reference

End-state checklist for a finished run:

• .NET 10 SDK installed via dotnet-install.sh and on PATH
• Issue number extracted and read via mcp__github__issue_read
• Existing claim or draft PR checked; claude/issue-<N>-<slug> pushed with an empty claim commit
• Intent-only draft PR opened before implementation with every template section filled and Closes #<N>
• Delegated command (or inline plan) selected from the routing table
• Change made, files formatted via Reihitsu.Cli
• First focused implementation commit pushed and the draft PR body updated to the actual changes
• dotnet build + all four dotnet test projects green
• Every commit up to that point contains [skip ci]; the final non-skip-ci trigger commit was pushed to run CI once
• Final draft PR body current; issue linked only through Closes #<N> with no ownership comment or label