القائمة
Create a sub-issue linked to a parent GitHub issue, honoring repository-specific issue conventions
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | create-sub-issue |
| description | Create a sub-issue linked to a parent GitHub issue, honoring repository-specific issue conventions |
| disable-model-invocation | true |
サブ Issue API を使って、親 GitHub Issue に紐づくサブ Issue を作成する。本 skill は リポジトリ固有の Issue 運用 (タイトル規約 / ラベル / GitHub Projects / Issue Type / Team 等のカスタムフィールド) を尊重する前提で動作する。固定のラベル名やテンプレートを鵜呑みにしない。
123 または #123) または URL$ARGUMENTS
gh issue view <issue-number> --json number,title,body,url,labels,projectItems
PLANS_SYNC_MARKER コメント等、文脈を補足するコメントがあれば参照する (無ければスキップ)skill 内に書かれた例 (ラベル名・テンプレ等) を既定値として鵜呑みにしないこと。 親 Issue が存在するリポの実運用を短く確認し、サブ Issue の規約を合わせる。
a. タイトル規約: 親 Issue や既存サブ Issue のタイトルを 2〜3 本サンプル確認する。
feat: / fix: 等の Conventional Commits 接頭辞を付けるか付けないかが分かれるb. ラベル: gh label list --repo <owner>/<repo> --limit 100 でラベル一覧を取得し、存在するラベルのみを使う。
sub-issue) をそのまま --label に渡すと gh issue create が失敗する。skill 内の例示ラベル名は参考に過ぎない--label を省略してユーザーに確認するc. GitHub Projects / カスタムフィールド: 親 Issue が Project に紐付いているか、Issue Type / Team 等のフィールドを持つか確認する。
projectItems / issueType / Project のカスタムフィールドを把握するd. 本文テンプレート: リポに .github/ISSUE_TEMPLATE/ があれば最適なものを利用する。無ければ親 Issue の本文構造 (Overview / Background / Acceptance criteria 等) を踏襲する。
Part of #{parent-issue-number} を記載するdocs/foo.md) または フル GitHub URL で書く。../../docs/foo.md のような作業ディレクトリ相対は GitHub Issue 上で切れるので使わない.github/ISSUE_TEMPLATE/ を利用する場合、テンプレ中の HTML コメント (<!-- ... -->) は必要な記入箇所に置き換えるか削除する。残すと Issue 本文に白紙の注釈が出るISSUE_URL=$(gh issue create \
--repo <owner>/<repo> \
--title "$TITLE" \
--body "$BODY" \
<--label オプションは手順 2b で確認したラベルに差し替える。不要なら省略>)
ISSUE_NUMBER=$(echo "$ISSUE_URL" | grep -oE '[0-9]+$')
# IMPORTANT: .id (integer) を使う。.node_id (string) ではない
SUB_ISSUE_ID=$(gh api /repos/<owner>/<repo>/issues/$ISSUE_NUMBER --jq .id)
gh api --method POST /repos/<owner>/<repo>/issues/<parent-number>/sub_issues \
-F "sub_issue_id=$SUB_ISSUE_ID"
親 Issue と同じ Project / Issue Type / Team を設定する。手順例は本ファイル末尾「リポ固有フィールド設定のリファレンス」を参照。
New / Backlog など) は通常 Project 側の既定で自動設定される。親と同じ In Progress 等に上書きするのはユーザーから明示要求があるときだけ。既定では触らない複数起票で親からの表示順を制御したい場合のみ実行する。単発起票では不要。
gh api --method PATCH /repos/<owner>/<repo>/issues/<parent-number>/sub_issues/priority \
--input - <<< '{"sub_issue_id": '$SUB_ISSUE_ID', "after_id": '$PREV_SUB_ISSUE_ID'}'
GitHub Projects のフィールド ID・オプション ID は repo / org ごとに異なる。以下は照会クエリの雛形。
gh api graphql -f query='
{
repository(owner: "<owner>", name: "<repo>") {
issueTypes(first: 20) { nodes { id name } }
issue(number: <parent-number>) {
issueType { id name }
projectItems(first: 5) {
nodes {
project { id title number }
fieldValues(first: 20) {
nodes {
... on ProjectV2ItemFieldSingleSelectValue {
field { ... on ProjectV2SingleSelectField { id name } }
name optionId
}
}
}
}
}
}
}
}'
gh api graphql -f query='
mutation($issueId: ID!, $typeId: ID!) {
updateIssueIssueType(input: {issueId: $issueId, issueTypeId: $typeId}) {
issue { number }
}
}' -f issueId="<issue node_id>" -f typeId="<issue type id>"
ITEM_ID=$(gh api graphql -f query='
mutation($projectId: ID!, $contentId: ID!) {
addProjectV2ItemById(input: {projectId: $projectId, contentId: $contentId}) {
item { id }
}
}' -f projectId="<project id>" -f contentId="<issue node_id>" --jq '.data.addProjectV2ItemById.item.id')
gh api graphql -f query='
mutation($projectId: ID!, $itemId: ID!, $fieldId: ID!, $optionId: String!) {
updateProjectV2ItemFieldValue(input: {
projectId: $projectId, itemId: $itemId, fieldId: $fieldId,
value: { singleSelectOptionId: $optionId }
}) {
projectV2Item { id }
}
}' -f projectId="<project id>" -f itemId="$ITEM_ID" \
-f fieldId="<field id>" -f optionId="<option id>"
Part of #{parent-issue-number}
[リポの慣習に従った本文。親 Issue や `.github/ISSUE_TEMPLATE/` があればそれに合わせる]
PLANS_SYNC_MARKER 等、存在すれば) を文脈として活用するGeneric thinking protocol for deriving optimal solutions through iterative self-checking. Invoke BEFORE searching within the given problem space whenever the user asks for advice, judgment, evaluation, or choice. Reframes the problem, generates options, evaluates trade-offs, runs a self-answer check (does this answer the user's actual question at the right granularity, reach upstream, match expectations, offer non-obvious value?), and loops back to upstream tracing or same-level reframing if the check fails — until convergence. Applies across any domain — technical, process, organizational, decision-making, career. Triggers when the user uses evaluation or reconsideration language ("which is best", "root cause", "is this really needed", "sustainable long-term", "ほんとうに", "そもそも", "最善は", "根本は", "筋が良い"), when validating the soundness of someone's proposal from multiple perspectives, when the problem spans multiple layers (tech / process / org / regulation / UX / cost), or when clear trade-offs exist.
Review the local diff with flat-perspective sub-agents, fix findings in a loop, then create a PR via the create-pr skill once the review is clean
計画や設計について、ユーザーを徹底的に問い詰めて一緒に詰める。実装・着手の前に計画をストレステストしたいとき、または「詰めて」「グリルして」「問い詰めて」「ツッコんで」「設計レビューして」「ほんとうにこれでいい?」などのトリガー表現が出たときに必ず使う。
.claude/rules/ 配下のルールファイル (*.md) を新規作成・編集するときに、適切なメカニズム選択と paths スコープを保証する。ルールを書く前・書いた後に必ず適用する。
Orchestrate Epic issue as team leader. Delegate sub-issues to member agents in isolated worktrees. Members run in background and communicate via SendMessage.
Fetch a GitHub issue with its sub-issues, walk up to the parent Epic, list sibling issues under that Epic, fetch the body of each sibling issue, attach the implementing PR for each closed sibling with body and diff summary, gather related code, and present as a Japanese summary so the reader can grasp the whole task context including the actual contents of siblings and their PRs