メニュー
Story / Task 間の blocked-by 依存関係を設計・登録するワークフロー。Use when the user asks to "set blocked-by", "add dependency", "issue の前後関係を設定", "依存関係を整理", "blocking 関係", or wants to model ordering constraints between issues.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | gh-projects:plan-dependencies |
| description | Story / Task 間の blocked-by 依存関係を設計・登録するワークフロー。Use when the user asks to "set blocked-by", "add dependency", "issue の前後関係を設定", "依存関係を整理", "blocking 関係", or wants to model ordering constraints between issues. |
兄弟関係にない Issue 同士の前後関係（blocked-by / blocking）を設計し、GraphQL で登録する。
epic-story-task skill の方針:
入れるべき:
decompose-epic で設定済み。未設定なら張る）入れない方が良い:
AskUserQuestion でまとめて聞く:
{ blocked: 102, blocking: 101, reason: "..." } のような配列スコープ内の全 sub-issue を取得:
../../scripts/gh-project.ts sub-issue:list <owner>/<repo> <epic#>
ネストして Story の sub-issue (Task) も見るときは、各 Story について sub-issue:list を回す。
依存は body ではなく Issue の関係（sub-issue / blocked-by）が SSoT。body のテキストからは推定しない。deps:show で既存の blocked-by / blocking と sub-issue 構造を取得し、そこから候補を洗い出す。
decompose-epic で張った「検証 Story → 全体リリース Story」の blocked-by は設定済みの前提。ここでは追加・横断の依存を扱う。
構造上必要だがまだ張られていない依存はユーザーに提案して確認を取る:
提案: #102 (Add API client) は #101 (Define API schema) に blocked-by すべき。
理由: API client は schema が決まらないと実装できない。
AskUserQuestion で:
承認されたペアと既存依存を合わせて DAG として閉路チェック:
../../scripts/gh-project.ts deps:show <owner>/<repo> <issue#>
各 issue について blocked-by / blocking を取得し、循環があれば登録を止めてユーザーに報告。
簡易チェック手順（pseudo）:
graph = {}
for issue in scope:
graph[issue] = blockedBy(issue)
detect cycle via DFS
if cycle:
abort and report
各ペアを登録:
../../scripts/gh-project.ts block:add <owner>/<repo> <blocked#> <blocking#>
複数を順に処理。エラーが出たら（既存・自己参照など）スキップして続行し、最後にスキップリストを報告する。
EPIC 単位で再度棚卸し:
../../scripts/gh-project.ts deps:show <owner>/<repo> <epic#>
ユーザーに以下を返す:
{
"epic": 100,
"addedDependencies": [
{ "blocked": 102, "blocking": 101 },
{ "blocked": 104, "blocking": 103 }
],
"skipped": [{ "blocked": 105, "blocking": 105, "reason": "self-reference" }],
"cyclesDetected": [],
"nextStep": "Run review-progress to confirm the resulting graph"
}
blocked と blocking を混同しがち。CLI の引数順は block:add <repo> <blocked#> <blocking#> で、最初が「ブロックされる側」block:remove は明示的に求められた時だけ実行するThis skill should be used when the user asks to "lint AI assistant config", "check AGENTS.md", "validate SKILL.md", "agnix lint", or wants to detect and fix best-practice violations in Claude Code / agent configuration files.
This skill is the mandatory reference for all Claude Code hook creation. Use cc-hooks-ts for every hook. This skill should be used when the user asks to "create a hook", "add a hook", "write a hook", "implement a hook", "rewrite hooks in TypeScript", "use cc-hooks-ts", or needs to build any Claude Code hook — cc-hooks-ts is always required regardless of whether explicitly mentioned.
Auto-activate CCS CLI delegation for deterministic tasks. Parses user input, auto-selects optimal profile (glm/kimi/custom) from ~/.ccs/config.json, enhances prompts with context, executes via `ccs {profile} -p "task"` or `ccs {profile}:continue`, and reports results. Triggers on "use ccs [task]" patterns, typo/test/refactor keywords. Excludes complex architecture, security-critical code, performance optimization, breaking changes.
This skill should be used when the user asks to "handoff from CCS", "Claude Codeの作業を引き継ぐ", "rate limit handoff", "context overflow", or wants to resume interrupted work from another CCS profile session.
This skill should be used when the user asks for "code review", "レビューして", "review this diff", "実装をレビュー", or wants rigorous review of recently created artifacts.
Direct utility reference for code-review PR scripts. Documents unresolved-thread, comment, CI-status, and CI-log helpers used by higher-level PR workflows.