メニュー
Orchestrator for implementing a Reihitsu GitHub issue end-to-end in Codex on Linux cloud or local Windows. Triggers when the initial prompt references a GitHub issue (e.g. "implement
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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
Review a GitHub Pull Request for the Reihitsu repository. Triggers on "review PR", "review pull request", "check PR
Review a GitHub Pull Request for the Reihitsu repository. Triggers on "review PR", "review pull request", "check PR
Write or update Reihitsu analyzer rule markdown files under documentation/rules/RH####.md. Use this when asked to create, rewrite, or review user-facing rule documentation for an analyzer rule.
Create Reihitsu issue draft markdown files under plans/issues that pass scripts/upload-issues.ps1 validation and can be uploaded with the repository script.
Add or update localized resource texts in Reihitsu. Use this when introducing new analyzer or code-fix strings in the .resx-based resource system.
| name | gh-implement |
| description | Orchestrator for implementing a Reihitsu GitHub issue end-to-end in Codex on Linux cloud or local Windows. Triggers when the initial prompt references a GitHub issue (e.g. "implement |
You are running in Codex on Linux cloud or local Windows. The repository checkout, required .NET 10 SDK, and authenticated gh CLI are present. Before builds or tests, confirm the SDK with dotnet --list-sdks; do not install an SDK, modify PATH, or otherwise change the environment. 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.
The required .NET 10 SDK is preinstalled in both supported environments. Before builds or tests, run:
dotnet --list-sdks
Do not install an SDK, modify PATH, or otherwise change the environment. If the expected SDK is unavailable, stop and report the environment issue; do not attempt to repair the environment from this skill.
gh CLIUse the authenticated gh CLI for every GitHub platform operation. Confirm the active account before making GitHub changes:
gh auth status
| Purpose | Command |
|---|---|
| Confirm identity / permissions | gh auth status |
| Read the issue | gh issue view <N> --json number,title,body,labels,state,url |
| Search for related/duplicate issues | gh issue list --search "<query>" |
| Create the draft pull request | gh pr create --draft |
| Update the draft pull request | gh pr edit <PR> --body "<body>" |
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]:
[skip ci].[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.
The issue reference comes from the initial user/agent prompt, not from the branch name. Accept any of:
#123https://github.com/<owner>/<repo>/issues/123GH-123, issue 123, implement issue 123Extract the integer issue number. If the prompt names a repository other than the current origin, pass it to gh with --repo <owner>/<repo>; otherwise default to the current repo.
If no issue number can be extracted with confidence, stop and ask. Do not guess.
Read the issue with gh issue view <N> --json number,title,body,labels,state,url. 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.
Avoid duplicate work before editing files:
Inspect the issue body, comments, and linked pull requests for an existing claim or open draft PR. If another agent or person has claimed it, stop and report the existing branch or PR.
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 switch -c codex/issue-<N>-<short-slug> origin/main
git commit --allow-empty -m "Claim issue #<N> [skip ci]"
git push -u origin codex/issue-<N>-<short-slug>
Before implementation, open a draft PR with gh pr create --draft. 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>.
The orchestrator does not implement the change itself when a specific command fits. The commands live under .codex/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 | Create the draft only; upload is a separate workflow |
| Nothing above matches | Implement inline using the rules in AGENTS.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.
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).
Make the change via the delegated command. Stage only the files that belong to this issue. Never git add -A blindly — the cloud worktree may contain unrelated changes.
Format the changed files through the CLI before tests:
dotnet run --project Reihitsu.Cli -- <changed-path-1> [<changed-path-2> ...]
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]
Immediately after the first focused implementation commit is pushed, update the existing draft PR with gh pr edit. 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.
Run from the repository root with the available .NET 10 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:
main.[skip ci] in the subject before pushing. Do not silence tests or mark them [Ignore].main independent of your change, record it in the draft PR's Review notes with gh pr edit 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 (AGENTS.md) is to keep the PR description concise.
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].
Update the existing draft PR with gh pr edit 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 workLinked 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.
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.
in-progress label. Use the linked draft PR as the ownership record.[skip ci] before validation is green — the empty trigger commit in "Complete the draft pull request" is the only exception.PATH, or otherwise change the environment. If the preinstalled toolchain is unavailable, record the environment issue in the draft PR and stop.gh CLI for GitHub platform operations. Do not call the GitHub REST API with raw curl.AGENTS.md).End-state checklist for a finished run:
dotnet --list-sdksgh auth statusgh issue viewcodex/issue-<N>-<slug> pushed with an empty claim commitCloses #<N>Reihitsu.Clidotnet build + all four dotnet test projects green[skip ci]; the final non-skip-ci trigger commit was pushed to run CI onceCloses #<N> with no ownership comment or label