Run several planned GitHub Issues as one unit: collect them under an Epic Issue with sub-issues, implement each on a shared epic/ branch in dependency order, verify the branch as a whole, and open a single Pull Request into the integration branch. Use when the user wants several Issues fixed, verified and released together. Triggers include requests such as Issue1,2,3をまとめて対応して / まとめて修正してリリースしたい / この3件を一緒に出して, 'batch these issues', 'do issues 1 2 3 together', 'ship these issues as one release'. Prerequisite: every member Issue needs an agreed plan comment from gh-issue-planner. For a single Issue, or for Issues that ship separately, use gh-issue-resolver instead.

Turn a rough, hand-written intent into a well-scoped GitHub Issue before planning starts. Takes a loose 'what I want' from the user, proposes the missing structure (Done definition, Out of scope, Design constraints), gets the user's approval, and creates the Issue via the gh CLI with a scoped-issue marker so gh-issue-planner can pick it up. When the intent is too large for one Issue, it proposes splitting it into independent Issues or an Epic with sub-issues. This is the human-authored counterpart to report-to-issues (which registers machine-generated findings). Use when the user wants to file a new Issue from a rough idea, is about to write an Issue by hand, or asks to turn a note/thought into an Issue. Triggers include requests like Issueを起こして / Issueを作って / ざっくり書くのでIssueにして, 'draft an issue', 'create an issue for', 'turn this into an issue', 'file an issue'. Does NOT plan or implement — hand off to gh-issue-planner for the response plan, then gh-issue-resolver for implementation.

Fetch a GitHub Issue by ID using the gh CLI, investigate related code, propose a structured response plan (policy, impact scope, implementation steps), and post the agreed plan as a comment on the issue. Implementation/PR creation is out of scope — use gh-issue-resolver for that. Use when the user provides a GitHub Issue ID or asks to investigate/analyze/plan a GitHub Issue. Triggers include issue IDs like #42 or 'issue 42', requests such as Issueを調査して / Issueの対応方針を立てて, analyze issue #N, plan issue #N, investigate issue, look at issue. Accepts several Issues at once (e.g. '1,2,3' or 'Issue 1と2を計画して'): it investigates once and posts one agreed-plan comment per Issue.

Implement and verify a fix for a GitHub Issue whose response plan has already been posted as a comment by gh-issue-planner. Creates a feature branch, applies the agreed plan, runs tests, and opens a Pull Request. Use when the user asks to implement/fix/resolve a planned GitHub Issue. Triggers include requests such as Issueを実装して / Issueを修正して / Issueを対応して, implement issue #N, fix issue #N, resolve issue #N, work on issue #N. Prerequisite: an agreed plan comment must exist on the issue (run gh-issue-planner first if not).

Evaluate code quality across five pillars (Architecture, Reliability, Observability, Security, DX) and produce a 1-10 scorecard with a strategic improvement roadmap. Use when you want a comprehensive quality review of a directory or module. Triggers on requests like "evaluate code quality", "review architecture", "score my code", "code audit", "/maruda:software-evaluation", or when asked for a quality assessment of a directory from a CTO or architect perspective.