Skills

IDD Skill: An Issue-Driven Development Workflow Template

Best for letting AI coding agents run the full development loop in your own Git repository, from claiming an issue to merging a PR; before use, prepare git, an authenticated gh CLI, jq, and curl, and confirm the default fully autonomous merge policy fits your team's norms.

Official source · IDD Skill

Install

Import and onboard github:kurone-kito/idd-skill's IDD into this repository.

Who it's for

  • Developers and small teams who run their daily development in their own Git repositories and want to make "from issue to merge" a repeatable process: after import, the AI coding agent inside the repository follows the officially described workflow — discover ready issues, claim ownership, implement on a branch, open a PR, handle review feedback, wait for CI, merge according to the repository's selected merge policy, and clean up. The project describes the workflow as "portable": it comes in with the repository rather than being tied to a single tool.
  • Developers who use several AI coding tools and don't want the process locked to a single client: the official documentation states the core loop runs across GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode, and Antigravity CLI (formerly Gemini CLI).
  • Teams that need several work sessions advancing different issues in parallel: the official documentation states the distributed mode's default policy is fully_autonomous_merge, which lets worker sessions go straight through to merge; how sessions coordinate and avoid conflicts is not explained officially.
  • What to confirm before adopting: the official page does not say whether hosting platforms beyond GitHub are supported — this is unconfirmed; if your team doesn't accept fully autonomous merges, the default policy needs to be assessed or adjusted first, and the official docs don't cover how to adjust it.

Your first attempt in 3 minutes

  • Prerequisites: a Git repository where you may create branches and open PRs; an environment equipped with the complete loop dependencies listed officially — git, an authenticated gh CLI (or an equivalent GitHub MCP integration, either one suffices), jq, and a REST client such as curl.
  • Where and how it installs: no manual file copying needed. The official onboarding method is to give the import instruction directly to the AI agent inside the target repository, and the onboarding guide completes the template copy.
  • Trigger: open a supported agent in the repository and enter this official instruction verbatim:
Import and onboard github:kurone-kito/idd-skill's IDD into this repository.
  • Keep the first attempt to low-risk actions: have the agent read the workflow guide, list the existing ready issues, and explain its plan for the next step — without claiming anything and without changing code. The officially described loop starts exactly at "read the guide, discover a ready issue, claim it"; before a claim happens you can stop it at any time.
  • Success signal: the agent can restate the workflow essentials and accurately list the existing issues, which means the import and guide reading took effect; the template files being copied into the repository means onboarding is complete. The official docs give no specific on-disk path — go by the agent's actual output (unconfirmed).

Use cases

Case 1: Deliver a ready issue end to end. Scenario: the backlog already has issues marked ready, and you want to verify the closed loop from claim to merge. Instruct the agent: "Claim a ready issue and complete the implementation." It will walk the full official loop — read the workflow guide, claim the issue, implement on a branch, open a PR, handle review feedback, wait for CI, merge according to the repository's selected merge policy, and clean up. The observable milestones, in order: a branch appears, the PR is created, CI status changes, merge and branch cleanup — each step corresponds to a fixed stage of the official loop. Under the default fully_autonomous_merge policy a worker session can go all the way to merge, so before the first run confirm that CI gates and branch protection are in place, or state explicitly in the instruction that this run stops at the PR.

Case 2: Discover and plan only, change nothing. Scenario: you want to first assess whether the process fits the repository and don't intend to let it act yet. Instruct the agent: "Read the workflow guide, list all ready issues with an implementation approach for each, and claim none of them." Only the first half of the loop is used (read the guide, discover issues); no branch or PR is created. How an issue gets marked "ready" is not explained officially; if the agent reports an empty list, first check how issue statuses are labeled in the repository. The expected result is an issue list and a written implementation plan; your next instruction decides whether implementation starts. Once the plan proves solid, pick one issue and run the full loop as in Case 1.

Boundaries of use

  • Side effects and confirmation points: importing copies template files into the repository; whether it only adds files or also modifies existing ones is not stated officially, so after importing review the change list the agent provides first. The full loop creates branches, commits code, opens PRs, and proceeds to merge under the default fully_autonomous_merge policy. Which actions request confirmation beforehand is not itemized officially, so explicitly bound the allowed scope in every instruction.
  • Network and command access: the full loop requires an authenticated gh CLI or an equivalent GitHub MCP integration and names REST clients such as curl — meaning the agent reaches GitHub APIs through these tools during the loop (reading issues, creating and merging PRs, etc.); which endpoints exactly and whether other network access occurs is not itemized officially.
  • Runtime and client prerequisites: the official list says the core loop runs across GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode, and Antigravity CLI (formerly Gemini CLI); whether agents outside the list work, whether there are extra OS requirements, and whether it degrades gracefully with missing dependencies are all unstated.
  • Explicit official limits and unknowns: the official material does not mention support for hosting platforms beyond GitHub, nor what merge policies exist besides fully_autonomous_merge or how to switch between them; the agent's retry behavior after a CI failure is likewise unconfirmed — for these details, the text of the workflow guide imported into the repository is authoritative.