Agent-Skills.md

Agent Skills: sub-issue-maker

Provide coarse, agent-ready task granularity for cutting GitHub sub-issues. Use implementation contracts and blackbox acceptance, avoid creating sub-issues for policy clarification, unresolved decisions, or specification contradictions.

UncategorizedID: uuta/dotfiles/sub-issue-maker

Repository

uuta/dotfiles
uuta
12

Install this agent skill to your local

pnpm dlx add-skill https://github.com/uuta/dotfiles/tree/HEAD/skills/sub-issue-maker

Skill Files

Browse the full folder contents for sub-issue-maker.

Download Skill

Loading file tree…

skills/sub-issue-maker/SKILL.md

Skill Metadata

Name
sub-issue-maker
Description
"Choose coarse implementation issue boundaries and readiness criteria before drafting or creating sub-issues."

Conditions

もし何かを実装する必要があるなら

sub-issue は ready な実装単位だけに切る。agent が issue を読んでそのまま実装・検証に入れないものは作らない。

まず、親 issue が ready か確認してください。

初めて扱う基盤・外部サービス、または複数機能をまたぐPBIでは、pbi-task-split の全体像共有手順に従い、分割前に explanation-diagram で構成と既存・新規・未確認の接続を図示する。既存の正確な図は再利用し、単純な局所修正には追加しない。分割後は未完成の部品・接続に担当issueまたはphase gateを対応付け、実際に使えるまでの仕事が漏れていないか確認する。

分割案ができたら、sub-issue を作る前に sub-issue-coverage で、親 issue の要件・決定事項すべてに担当の分割案があるか、作るもの（endpoint など）すべてに使う側があるかを照合する。担当なし・宛先のない先送り・使う側なしがあれば、分割案を直してから作る。

sub-issue にしてはいけないもの:

  • 方針決定、仕様確認、単なる「明確化」
  • 親 issue の矛盾や未決事項を子 issue に逃がしているもの
  • acceptance criteria が現在のコード・運用契約で実行不能なもの
  • 成果物が code / test / docs / config / migration / UI vocabulary contract / visual baseline などの review 可能な差分として定義できないもの

この場合は sub-issue を作らず、親 issue に spec correction コメントまたは本文修正案を出してください。

以下に当てはまる場合は Boundary / Contract を先に固定 してください。ただし、原則として contract は親 issue または実装 sub-issue 本文に書き、単なる contract 明確化だけの sub-issue は作らないでください。

  • Frontend / Backend が別々に進む
  • 複数 agent や複数人が並列で進める
  • endpoint、DTO、認証、ownership、error shape のズレが起きやすい
  • bootstrap / onboarding のように、複数画面・複数APIをまたぐフローがある

Boundary / Contract の内容例:

  • canonical endpoint / route の確定
  • request / response / error shape の固定
  • auth source of truth と ownership の明示
  • OpenAPI / Swagger / interface の更新
  • sequence diagram や request examples の記述

Boundary / Contract を独立 sub-issue にできるのは、OpenAPI 更新、typed client 更新、DB migration 契約、UI vocabulary contract / primitive API、visual regression baseline など、成果物が実装可能で test / review できる場合に限ります。

task 粒度の目安:

  • 1 PBI につき 1〜3 sub-issue、最大 5

  • 複数レイヤーをまたいでも、同じ目的・同じ acceptance・同じ rollback boundary なら 1 sub-issue にまとめる

  • phase は原則 sub-issue ではなく、issue 本文内の review / gate checkpoint として扱う

  • 各 sub-issue に Done when / Not done if / Required verification を書く

  • Required verification の書き方は pbi-task-split §2.5 に従う（外部状態が必要な確認は、担当付きの「Merge 前の確認」に分ける）

  • verification は単体テストだけでなく blackbox / runtime acceptance を含める

  • Frontend

    • boundary / contract の consumer 実装
    • constantsの修正
    • domainの修正
    • infrastructureの修正（APIを定義・修正したりする場合のみ）

  • Backend

    • boundary / contract の provider 実装
    • controllerの修正
    • domainの修正
    • use caseの修正
    • infrastructureの修正（外部APIを新たに定義・修正したり、table schemaを新たに定義・修正したりする必要がある場合のみ）

要件を読んで、他に必要そうなタスクがあれば適宜切ってください（Dockerfileの修正等）

重要:

  • interface が未確定なら、実装 sub-issue を切らず親 issue の contract を直す
  • 並列実装したい場合、contract の source of truth を親 issue または artifact として明示する
  • 「実装」と「契約」は分離しすぎない。agent-ready な 1 issue に目的、scope、phase gate、verification をまとめる

他の要件に関して

要件に応じて適切なサイズでtaskを切ってください。細分化より、ready な契約と検証可能な acceptance を優先してください。