Obsidian の vault 配下にサービス設計ドキュメントを段階的に積み上げて構築する（Obsidian MCP が使えない環境では Notion に退避）。新規サービス（個人開発・業務問わず）の設計セッションを最初から最後まで支援するときも、既存サービスの情報を整理して体系化するときも、このスキルを使う。ユーザーが「サービス設計したい」「サービス設計のドキュメントを作りたい」「既存サービスを整理したい」「設計ドキュメントの体系を作りたい」と言ったとき、あるいはサービスのアイデア・コンセプトを話し始めたときは、たとえ「設計」という言葉が使われていなくても、このスキルを使うべきかどうかを必ず検討する。
Spec / plan を入力に、Linear または GitHub の親 Issue + sub-issue 群を自律的に登録する。対話深掘りステップは持たず、`pick-next` / ユーザー直接実行から呼ばれる独立スキル。tracker は `.claude/project.yml` の `tracker.type` から自己解決する。
実装専任のチーム展開スキル。実装対象 (issue 番号/ID または spec/plan パス) を引数で受け取り、developer 並列起動 → reviewer 観点別 → pr-publisher で PR まで自走する。要件定義 (brainstorming/grill-me/grill-with-docs) や issue 作成 (create-issue) は外部スキルの責務でこのスキルではやらない。
「次に何をやるか」を対話で決定する。既存 active issue（Linear / GitHub）の優先度推奨、新規テーマの候補出しと 3 軸スコア比較、判断結果に応じて Issue 作成・既存 Issue 選定・保留の 3 分岐に振り分ける。「次に何やる？」「Linear/GitHub 確認して」「優先度教えて」「次の開発内容を相談したい」と聞かれたら必ず使う。引数なし or 任意のヒント文字列で起動。
PR 作成済みまたはマージ済みの worktree を検出し、一括クリーンアップする
PR の CodeRabbit インラインコメントを確認し、指摘への対応・リプライを行う。
データの欠損・古い値・期待と異なる表示など「データが正しく見えない」系の調査を始めるとき。クライアントコードに潜る前に、まず backend のデプロイ状態と、デプロイ環境側の構成（feature flag / config / 環境差分）を確認させる。ローカルの .env や secrets ファイルは読みに行かない。
Linear の active issue (Backlog/Todo/In Progress) を確認し、依存関係・進行中作業・現在のブランチ状態を統合して、次にやるべき issue を推奨順で提示する。「次に何やる？」「Linear 確認して」「優先度教えて」と聞かれたら必ず使う。引数なしで動作。