Issue

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Take a tracked ticket — a GitHub issue or a Jira ticket — from "just filed" to "pull request open for review, with review comments already left" in one pass. This skill orchestrates iru-explore, iru-plan, iru-code, iru-pr-description, and iru-pr-review — it does not duplicate their logic, it sequences them around branch creation, ticket triage, and PR creation.

Purpose

iru-issue is the top-level, end-to-end entry point for working a tracked ticket, auto-detecting whether it’s a GitHub issue or a Jira key the same way iru-explore does. Unlike iru-explore and iru-plan, it requires a ticket id and stops immediately if none is given. It fetches the ticket, classifies it as a feature or a hotfix, then works out which branch the work should be based on: it detects whether the run is happening locally or in a Claude Code cloud/web session (from a claude/ branch name and sandbox/environment markers), proposes the current branch as the base for a local run and the repository’s default branch — never the throwaway claude/ session branch — for a cloud run, and always asks the user to confirm that base before branching, since it is both the fork point and the pull request’s eventual destination. It creates the matching branch off the confirmed base, runs iru-explore and iru-plan to produce a reviewable implementation_plan.md — recording the confirmed base in the plan’s Task summary as a Base branch: line, so that a later, separate /iru-pr-description session can recover the choice — then — depending on the user’s choice — either stops for manual review or hands implementation off to iru-code inside a sub-agent. Once implementation finishes successfully, it attaches the archived implementation plan back onto the original ticket — as a GitHub issue comment (via gh issue comment, since GitHub’s API has no generic file-attachment endpoint) or a Jira attachment/comment (via connected Jira MCP tools) — so a future exploration of that same ticket has the full plan as precedent, skipping this step entirely if iru-code never actually archived a plan. It then pushes the branch, opens the pull request (as a draft, using whichever tooling matches the detected repository host), drafts its description with iru-pr-description, and leaves an initial review on it with iru-pr-review. If iru-code’s security gate (backed by `iru-check-security) ever fires during implementation — even if iru-code goes on to resolve it and finish cleanly — this skill treats that as a hard stop distinct from an ordinary blocker: it warns the user with the specifics and never attaches anything to the ticket, pushes the branch, or opens a PR for that run.

Purpose group

Issue-to-PR Development Cycle

Invocation

/iru-issue <ticket-id>

Inputs

Argument Required Description Default

ticket-id

Yes

A GitHub issue number or a Jira key (e.g. PROJ-123) to work end to end, auto-detected by pattern. If omitted, the skill asks for one via AskUserQuestion; if the user still declines or gives none, the skill stops entirely rather than falling back to a codebase-only mode.

None — no default; this is the one catalog skill that hard-stops without a ticket id.

Outputs

  • A new local branch, feature/<ticket-id> or hotfix/<ticket-id> depending on classification, created off the branch /iru-issue was invoked from.

  • implementation_plan.md at the repository root (produced by iru-plan), ready for manual review, or already executed by iru-code if the user chose automatic implementation.

  • If implementation proceeded automatically and completed successfully, with iru-code’s security gate never firing: the archived plan attached back onto the ticket (a GitHub comment or a Jira attachment/comment), or skipped with no error if `iru-code never archived one; the branch pushed to origin, a pull request opened as a draft back to the base branch (title "<ticket-title> (#<ticket-id>)" or "(<ticket-id>)" for Jira, body linking the ticket via the convention matching the detected host), its description filled in by iru-pr-description, and an initial review left on it by iru-pr-review.

  • If the user chose manual review instead, iru-code reports a blocker, or `iru-code’s security gate ever fired during the run, the skill stops short of attaching anything, pushing, or opening a PR, and reports exactly where it stopped — for the security-gate case, with an explicit warning naming what was flagged and reminding the user to verify the resolution themselves before pushing anything.

  • A final summary: ticket id/title, classification and why, the branch and its base, and one of: manual review pending, the security gate fired (with the sub-agent’s implementation summary and what was flagged), or the full implementation/PR/review outcome — always noting the PR is a draft still needing the user’s own review.

Execution flow

flowchart TD A[Start /iru-issue] --> B{Ticket id given?} B -- no --> C["Ask user for a ticket id"] C -- still none --> Z["Stop: ticket id is required"] C -- given --> D B -- yes --> D["Detect type: Jira key vs.\nbare number/#N (GitHub)"] D --> E["Fetch ticket via gh issue view\nor Jira MCP tools"] E --> F["Classify as feature or hotfix\n(labels/iru-issue type, then title/body content,\nthen ask user if still ambiguous)"] F --> F1{"Local run or cloud run?\n(claude/* branch name,\nsandbox/env markers)"} F1 -- local --> F2["Propose current branch\nas base branch"] F1 -- cloud --> F3["Propose repository default branch\nas base branch (never claude/*)"] F1 -- ambiguous --> F4["Ask user: local or cloud?"] F4 --> F2 F2 --> F5{"Confirm base branch with user\n(always, on both environments)"} F3 --> F5 F5 -- stop --> Z2["Stop: user declined the base branch"] F5 -- confirmed --> G["Create feature/&lt;id&gt; or hotfix/&lt;id&gt;\nbranch off the confirmed base"] G --> H["Invoke explore skill\n(scoped to ticket id)"] H --> I["Invoke plan skill\n(scoped to ticket id)"] I --> I2["Record 'Base branch:' line in\nimplementation_plan.md Task summary"] I2 --> J{"Ask user: proceed\nautomatically with code,\nor review manually?"} J -- manual review --> K["Stop: implementation_plan.md\nready for user to run /iru-code later"] J -- automatic --> L["Delegate full code skill run\nto isolated-skill-executor agent"] L -- blocker reported --> M["Surface blocker to user and stop"] L -- security gate fired --> N["Hard stop: warn user what was\nflagged; do NOT attach, push,\nor open PR"] L -- clean success --> AP{"Did iru-code archive\na plan (per its Step 9)?"} AP -- no --> O AP -- yes --> AP2["Attach archived plan to ticket:\ngh issue comment (GitHub) or\nJira attachment/comment"] AP2 --> O["Confirm with user, then\npush branch"] O --> P["Open pull request as draft\n(placeholder body, host-appropriate\nticket reference)"] P --> Q["Invoke pr-description skill"] Q --> R["Re-confirm ticket reference\nstill in PR body"] R --> S["Invoke pr-review skill\n(passing PR id and ticket id)"] S --> T["Report final summary\n(PR still a draft)"]

Dependencies

Invokes

  • Explore — Step 5 runs iru-explore scoped to the ticket id as the first step of the explore → plan → code → PR pipeline.

  • Plan — Step 5 runs iru-plan scoped to the ticket id right after iru-explore, producing implementation_plan.md.

  • Code — Step 6, when the user chooses automatic implementation over manual review, runs iru-code via the iru-isolated-skill-executor agent so the whole implementation run starts from a clean context rather than carrying the exploration/planning transcript into it.

  • PR Description — Step 7 invokes it to draft the new pull request’s description from the actual diff, then re-checks its output still references the ticket.

  • PR Review — Step 7 invokes it, passing both the new PR’s id and the ticket id explicitly (rather than relying on its own auto-detection), to leave an initial review on the PR.

Invoked by

None — iru-issue is a top-level entry point; no other skill in this catalog invokes it, though Create GitHub Issue and Create Jira Ticket each file a ticket meant to be picked up by a subsequent, separate /iru-issue invocation.

Related agents

  • iru-isolated-skill-executor — wraps the entire iru-code run in Step 6, so implementation happens in an isolated context and this skill can keep running afterward to open the pull request in Step 7.

Source

SKILL.md on GitHub — the file this page was generated from.