{"id":50379683,"url":"https://github.com/hirokisakabe/issuekit","last_synced_at":"2026-05-30T11:03:12.450Z","repository":{"id":356293493,"uuid":"1231863572","full_name":"hirokisakabe/issuekit","owner":"hirokisakabe","description":"Agent Skills for issue-driven development.","archived":false,"fork":false,"pushed_at":"2026-05-07T12:42:30.000Z","size":51,"stargazers_count":0,"open_issues_count":3,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-05-07T13:30:55.017Z","etag":null,"topics":["agent-skills","claude-code","claude-code-skills","issue-driven-development","skills-sh"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/hirokisakabe.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":"AGENTS.md","dco":null,"cla":null}},"created_at":"2026-05-07T11:08:15.000Z","updated_at":"2026-05-07T12:42:33.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/hirokisakabe/issuekit","commit_stats":null,"previous_names":["hirokisakabe/issuekit"],"tags_count":null,"template":false,"template_full_name":null,"purl":"pkg:github/hirokisakabe/issuekit","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hirokisakabe%2Fissuekit","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hirokisakabe%2Fissuekit/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hirokisakabe%2Fissuekit/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hirokisakabe%2Fissuekit/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/hirokisakabe","download_url":"https://codeload.github.com/hirokisakabe/issuekit/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hirokisakabe%2Fissuekit/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33689565,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-05-30T02:00:06.278Z","response_time":92,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["agent-skills","claude-code","claude-code-skills","issue-driven-development","skills-sh"],"created_at":"2026-05-30T11:03:10.644Z","updated_at":"2026-05-30T11:03:12.435Z","avatar_url":"https://github.com/hirokisakabe.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003cdiv align=\"center\"\u003e\n\n# 🧷 issuekit\n\n### _Issue-driven development for AI coding agents._\n\nA Claude Code skill bundle that treats each GitHub issue as the canonical \"rich plan\" for a unit of work — so volatile specs stay out of your repository and only durable code gets versioned.\n\n[![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](./LICENSE)\n[![Install via skills.sh](https://img.shields.io/badge/install-skills.sh-black)](https://skills.sh)\n[![Claude Code](https://img.shields.io/badge/Claude_Code-skill_bundle-D97757)](https://docs.claude.com/en/docs/claude-code)\n\n\u003c/div\u003e\n\n---\n\n\u003e [!NOTE]\n\u003e **Japanese-oriented plugin.** Skill bodies, descriptions, and this README are written in English, but the skills read Japanese section headers (e.g. `## 受け入れ条件`) hardcoded into issue bodies. Issue contents themselves are expected to remain in Japanese. To use issuekit with English-only issues, you will currently need to fork and adjust the hardcoded keywords.\n\n\u003e [!IMPORTANT]\n\u003e **Casual OSS.** No SLA, no response guarantees. Distributed as-is for users who share the underlying philosophy. PRs and issues are welcome but may be closed without action if they conflict with the maintainer's solo-dev workflow.\n\n## Table of Contents\n\n- [📦 Install](#-install)\n- [🛠️ Dependencies](#-dependencies)\n- [🧩 Skills](#-skills)\n- [🔁 Workflow](#-workflow)\n- [💡 Philosophy](#-philosophy)\n- [🆚 Comparison with related frameworks](#-comparison-with-related-frameworks)\n- [📄 License](#-license)\n\n---\n\n## 📦 Install\n\n### via `gh skill` (recommended — supports version pinning)\n\n```bash\n# Install a skill interactively (choose from the list)\ngh skill install hirokisakabe/issuekit\n\n# Install a specific skill (e.g. issue-implement)\ngh skill install hirokisakabe/issuekit issue-implement\n\n# Pin to a specific version\ngh skill install hirokisakabe/issuekit issue-implement@v1.0.0\n\n# Or use the --pin flag\ngh skill install hirokisakabe/issuekit issue-implement --pin v1.0.0\n\n# Install for Claude Code at user scope explicitly\ngh skill install hirokisakabe/issuekit issue-implement --agent claude-code --scope user\n```\n\nThe install location depends on `--agent` and `--scope`; for Claude Code at user scope, skills land in `~/.claude/skills/`. Version tags follow [GitHub Releases](https://github.com/hirokisakabe/issuekit/releases).\n\n### via `npx skills` (Claude Code, Codex CLI, Cursor, Gemini, …)\n\n```bash\n# Install all seven skills (always installs HEAD — version pinning not yet supported)\nnpx skills add hirokisakabe/issuekit\n\n# Or install a specific skill only\nnpx skills add hirokisakabe/issuekit --skill issue-implement\n```\n\nThis installs the skills under your agent's skill directory (e.g. `~/.claude/skills/` for Claude Code). See [skills.sh](https://skills.sh) for the list of supported agents (Claude Code, Codex CLI, Cursor, Gemini, ...).\n\n---\n\n## 🛠️ Dependencies\n\nissuekit assumes the following tools are available on the host:\n\n- **An [Agent Skills](https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview)-compatible agent runtime** (e.g. [Claude Code](https://docs.claude.com/en/docs/claude-code), Codex CLI, Cursor) that loads the skills.\n- **[`gh` CLI](https://cli.github.com/)** — used for all GitHub interactions (issue read/write, PR creation, CI status).\n- **At least one cross-review backend CLI** — required by `cross-review`. Pick whichever pairs with the agent driving the implementation:\n  - **[Codex CLI](https://github.com/openai/codex)** (`brew install --cask codex`) for the `codex` backend.\n  - **[Claude CLI](https://docs.claude.com/en/docs/claude-code)** (`npm install -g @anthropic-ai/claude-code`) for the `claude-self` backend (uses `claude --bare -p` headless mode).\n- **Claude Code v2.1.49 or newer** — required by `worktree-start` only (it uses the `EnterWorktree` tool added in 2.1.49). The other six skills run on any Agent Skills-compatible runtime.\n\n`gh` must be authenticated against the repository you want to operate on. The `cross-review` backend is selected via the `CROSS_REVIEW_BACKEND` environment variable (`codex` / `claude-self`); if it is unset, the skill auto-detects whichever CLI is on `PATH`. If neither backend CLI is available, `cross-review` fails explicitly rather than silently skipping the review.\n\n---\n\n## 🧩 Skills\n\nissuekit ships seven Claude Code skills under `skills/`:\n\n| Skill                | Role        | Description                                                                                                                                            |\n| -------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `issue-create`       | Entry point | Open a new GitHub issue using issuekit's standard format (`Status: Ready` / `Status: Draft` header, intent, plan, acceptance criteria, out-of-scope).  |\n| `issue-refine`       | Entry point | Re-shape an existing issue (title-only or partially formatted) into the standard format.                                                               |\n| `issue-pick`         | Entry point | Read-only triage: from a set of open issues, suggest the next one to take on, with rationale.                                                          |\n| `worktree-start`     | Entry point | **Claude Code only.** Switch the running session into a freshly named git worktree via the `EnterWorktree` tool. Accepts a task description **or** an issue URL/number — when the input is a `Status: Ready` issue, it chains into `issue-implement` after the worktree switch (otherwise it stops at the switch). |\n| `issue-implement`    | Orchestrator| Drive the full cycle from an issue number: status check → worktree start → implementation / commits → acceptance check → cross-review → PR → CI.     |\n| `acceptance-check`   | Verifier    | Read-only verifier that extracts `## 受け入れ条件` from an issue body and reports each item as `✓ / ✗ / ?`. Called by `issue-implement` after implementation/commits, before `cross-review`. |\n| `cross-review`       | Verifier    | Delegate a second-opinion code review to a different AI backend (Codex CLI or Claude CLI headless, selectable via `CROSS_REVIEW_BACKEND`) before PR creation. Called by `issue-implement` after `acceptance-check` passes; review fixes land as additional commits. |\n\n`issue-implement` is the orchestrator; the other skills are either entry points or verifiers it calls. `worktree-start` is the only entry point that is Claude Code-specific (`EnterWorktree` is a Claude Code primitive — Codex CLI has no equivalent), so it has no fallback under other agent runtimes. It is also the only entry point that conditionally chains into the orchestrator: when invoked with an issue URL/number whose body has `Status: Ready`, it hands off to `issue-implement` after the worktree switch.\n\n---\n\n## 🔁 Workflow\n\nThe skills compose into a single issue-driven cycle. Entry points feed an issue into the orchestrator, which calls the verifiers before producing a commit and a PR.\n\n```mermaid\nflowchart LR\n    A[issue-create] --\u003e I[(GitHub issue\u003cbr/\u003eStatus: Ready)]\n    R[issue-refine] --\u003e I\n    P[issue-pick] -. suggests .-\u003e I\n    I --\u003e W[worktree-start]\n    W --\u003e IMPL[issue-implement\u003cbr/\u003eimplementation + commits]\n    IMPL --\u003e AC[acceptance-check]\n    AC --\u003e CR[cross-review]\n    CR --\u003e C[PR + CI]\n\n    classDef entry fill:#e8f4ff,stroke:#3b82f6,color:#1e3a8a\n    classDef orch  fill:#fef3c7,stroke:#d97706,color:#78350f\n    classDef ver   fill:#ecfdf5,stroke:#10b981,color:#065f46\n    classDef out   fill:#f3f4f6,stroke:#6b7280,color:#1f2937\n\n    class A,R,P,W entry\n    class IMPL orch\n    class CR,AC ver\n    class I,C out\n```\n\n---\n\n## 💡 Philosophy\n\nMost \"spec-driven\" or \"plan-driven\" frameworks for AI coding agents store the spec **in the repository** as markdown files (`spec.md`, `plan.md`, etc.) checked in alongside the code. issuekit takes a different position:\n\n- **Specs and plans are volatile.** They describe a single unit of intent. Once the work is merged, the plan is dead — what survives is the code, the test, and (if anything) a one-line commit message.\n- **Versioning volatile artifacts in git is friction.** A merged plan rots in the repo, gets stale, and pollutes diffs and search.\n- **GitHub issues are already a versioned, queryable, time-bounded plan store.** They have state (`open` / `closed`), threading, references, and a natural lifecycle that matches the work itself.\n\nSo issuekit treats the **GitHub issue as the rich plan** for the work, and the repository contains only the durable artifacts (code, tests, configs). When the issue is closed, the plan disappears from the active surface area — exactly as intended.\n\nThis is opinionated. issuekit will not be a good fit if you want plans to live next to the code, or if your team's workflow expects spec markdown checked in.\n\n---\n\n## 🆚 Comparison with related frameworks\n\nissuekit shares one core idea with Spec Kit, cc-spex, and superpowers: **make the \"what\" an explicit contract that an AI agent can read, follow, and be checked against.** Where they differ is _where_ that contract lives, and how compliance is verified.\n\n| Framework                                          | Contract location                                           | Verification model                                                                                    | Fit                                                 |\n| -------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------- |\n| [Spec Kit](https://github.com/github/spec-kit)     | Spec markdown checked into the repo                         | Agent re-reads the spec                                                                               | Teams that want specs versioned alongside code      |\n| [cc-spex](https://github.com/rhuss/cc-spex)        | Spec markdown checked into the repo                         | Agent re-reads the spec                                                                               | Solo / small team, lighter than Spec Kit            |\n| [superpowers](https://github.com/obra/superpowers) | Skill bundle of general-purpose engineering workflows       | Skill conventions + agent judgment                                                                    | Broad augmentation of Claude Code; not spec-centric |\n| **issuekit**                                       | GitHub issue body (`## 受け入れ条件`, `## スコープ外`, ...) | `acceptance-check` skill mechanically verifies each acceptance criterion as `✓ / ✗ / ?` before PR creation | Solo dev who already runs an issue-first workflow   |\n\nThe differentiator that matters most to issuekit's design is the **verification model**. Detailed specs help agents stay on-rails, but spec compliance is itself a problem: the longer the spec, the more places the agent can drift. issuekit's response is structural rather than prescriptive — instead of writing more spec, write fewer but **mechanically verifiable** acceptance criteria, and have a dedicated skill (`acceptance-check`) check them before PR creation. The spec stays small; the verification stays honest.\n\n---\n\n## 📄 License\n\n[MIT](./LICENSE)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhirokisakabe%2Fissuekit","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fhirokisakabe%2Fissuekit","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhirokisakabe%2Fissuekit/lists"}