work-intake

作業の受付

概要

すべての作業依頼は受付を経由します。このスキルでは、範囲を判断し、要件を収集して、適切なワークフローに振り分けます。

基本原則： 追跡するには小さすぎる作業も、分解するには大きすぎる作業もありません。

開始時に伝えること： 「作業を始める前に、この依頼の内容と範囲を把握するため、work-intake を使用します。」

受付の流れ

┌─────────────────────────────────────────────────────────────────────┐
│                        REQUEST RECEIVED                              │
└─────────────────────────────┬───────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────────┐
│               STEP 0: PROJECT BOARD READINESS (GATE)                │
│  Is GITHUB_PROJECT_NUM set?                                         │
│  Is project board accessible?                                       │
│  Are required fields configured?                                    │
└─────────────────────────────┬───────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────────┐
│                    CLARIFYING QUESTIONS                              │
│  What is the user trying to achieve?                                │
│  What does success look like?                                        │
│  What constraints exist?                                             │
└─────────────────────────────┬───────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────────┐
│                      SCOPE ASSESSMENT                                │
│  How much investigation is needed?                                   │
│  How many deliverables?                                              │
│  How many unknowns?                                                  │
└─────────────────────────────┬───────────────────────────────────────┘
                              │
              ┌───────────────┼───────────────┬───────────────┐
              ▼               ▼               ▼               ▼
         ┌────────┐     ┌──────────┐    ┌──────────┐    ┌──────────┐
         │TRIVIAL │     │  SMALL   │    │  LARGE   │    │ MASSIVE  │
         │        │     │          │    │          │    │          │
         │1 issue │     │1-3 issues│    │1 epic    │    │Initiative│
         │no unkn.│     │few unkn. │    │research  │    │multi-epic│
         └───┬────┘     └────┬─────┘    └────┬─────┘    └────┬─────┘
             │               │               │               │
             ▼               ▼               ▼               ▼
      issue-prerequisite  issue-prerequisite  epic-management  initiative-
      + project-board-    + decomposition    + research spikes  architecture
        enforcement       + project-board-  + project-board-  + project-board-
                           enforcement       enforcement       enforcement

ステップ 0：プロジェクトボードの準備状況（ゲート）

作業の受付を始める前に、プロジェクトボードのインフラが整っていることを確認します。

これはゲートです。確認が完了するまで、明確化の質問に進まないでください。

# Derive defaults from GITHUB_PROJECT if provided
if [ -z "$GITHUB_PROJECT_NUM" ] && [ -n "$GITHUB_PROJECT" ]; then
  NUM_CANDIDATE=$(echo "$GITHUB_PROJECT" | sed -E 's#.*/projects/([0-9]+).*#\1#')
  if [ -n "$NUM_CANDIDATE" ] && [ "$NUM_CANDIDATE" != "$GITHUB_PROJECT" ]; then
    export GITHUB_PROJECT_NUM="$NUM_CANDIDATE"
    echo "Derived GITHUB_PROJECT_NUM=$GITHUB_PROJECT_NUM from GITHUB_PROJECT"
  fi
fi

if [ -z "$GH_PROJECT_OWNER" ] && [ -n "$GITHUB_OWNER" ]; then
  export GH_PROJECT_OWNER="$GITHUB_OWNER"
  echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from GITHUB_OWNER"
fi

if [ -z "$GH_PROJECT_OWNER" ] && [ -n "$GITHUB_PROJECT" ]; then
  OWNER_CANDIDATE=$(echo "$GITHUB_PROJECT" | sed -E 's#https://github.com/(orgs|users)/([^/]+)/projects/[0-9]+#\2#')
  if [ -n "$OWNER_CANDIDATE" ] && [ "$OWNER_CANDIDATE" != "$GITHUB_PROJECT" ]; then
    export GH_PROJECT_OWNER="$OWNER_CANDIDATE"
    echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from GITHUB_PROJECT"
  fi
fi

if [ -z "$GH_PROJECT_OWNER" ]; then
  REMOTE_URL=$(git remote get-url origin 2>/dev/null || true)
  OWNER_CANDIDATE=$(echo "$REMOTE_URL" | sed -E 's#(git@|https://)github.com[:/]+([^/]+)/[^/]+(\.git)?#\2#')
  if [ -n "$OWNER_CANDIDATE" ] && [ "$OWNER_CANDIDATE" != "$REMOTE_URL" ]; then
    export GH_PROJECT_OWNER="$OWNER_CANDIDATE"
    echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from git remote"
  fi
fi

# Verify environment variables are set
if [ -z "$GITHUB_PROJECT_NUM" ]; then
  echo "BLOCKED: GITHUB_PROJECT_NUM not set"
  echo "Set with: export GITHUB_PROJECT_NUM=<number>"
  exit 1
fi

if [ -z "$GH_PROJECT_OWNER" ]; then
  echo "BLOCKED: GH_PROJECT_OWNER not set"
  echo "Set with: export GH_PROJECT_OWNER=@me  # or org name"
  exit 1
fi

# Verify project is accessible
if ! gh project view "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json > /dev/null 2>&1; then
  echo "BLOCKED: Cannot access project $GITHUB_PROJECT_NUM"
  echo "Verify project exists and you have access"
  exit 1
fi

# Verify required fields exist
FIELDS=$(gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json | jq -r '.fields[].name')

for required in "Status" "Priority"; do
  if ! echo "$FIELDS" | grep -q "^$required$"; then
    echo "WARNING: Required field '$required' not found in project"
    echo "Consider adding this field for full tracking support"
  fi
done
if ! echo "$FIELDS" | grep -q "^Type$" && ! echo "$FIELDS" | grep -q "^Issue Type$"; then
  echo "WARNING: Required field 'Type' (or 'Issue Type') not found in project"
  echo "Consider adding this field for full tracking support"
fi

echo "Project board ready: $GITHUB_PROJECT_NUM"

ゲートを通過できない場合：

1. 不足している環境変数を設定します
2. 必要に応じてプロジェクトボードを作成します
3. 必須フィールド（Status、Type、Priority）を追加します
4. 準備状況の確認を再実行します

スキル： project-board-enforcement

---

ステップ 1：明確化の質問

範囲を決める前に、依頼内容を把握します。

リポジトリから回答できる質問はしないでください。 まず、以下を確認します。

• README.md、FEATURES.md、BRANDING.md、docs/、Storybook、既存のルート／ページ
• 既存の GitHub のイシューとプロジェクトボードの項目

リポジトリを確認した後も不足している情報だけをユーザーに尋ねます。

必須の質問

質問	目的
「何を実現しようとしていますか？」	作業そのものだけでなく、目標を把握します
「成功とはどのような状態ですか？」	受け入れ基準を定めます
「誰／何に影響しますか？」	影響範囲を特定します
「把握しておくべき制約はありますか？」	時期、技術、互換性を確認します
「これはより大きな取り組みの一部ですか？」	既存の取り組みと関連付けます

発見のための質問（依頼が不明確な場合）

質問	明らかになること
「これがどのように使われるか、順を追って説明していただけますか？」	ユーザージャーニー、エッジケース
「現在、何がありますか？」	出発点、移行の必要性
「すでに何を試しましたか？」	失敗したアプローチ、制約
「参考になる先行事例や例はありますか？」	設計の方向性

ステップ 2：範囲の評価

以下の基準に照らして依頼を評価します。

範囲のマトリクス

要素	ごく小規模	小規模	大規模	非常に大規模
不明点	なし	少数、回答可能	多数、調査が必要	広範囲、スパイクが必要
成果物	1 件	2～5 件	6～20 件	20 件以上
コード領域	1～2 ファイル	3～10 ファイル	10 ファイル以上	複数のシステム
依存関係	なし	内部のみ	外部サービス	新しいインフラ
期間	1 セッション未満	1～3 セッション	1～2 週間	数週間～数か月
基準	1～2 件	3～5 件	6～15 件	15 件以上

範囲の判断

IF unknowns == none AND deliverables <= 2:
  → TRIVIAL: Use issue-prerequisite directly

IF unknowns == few AND deliverables <= 5:
  → SMALL: Use issue-prerequisite, maybe issue-decomposition

IF unknowns == many OR deliverables > 5:
  → LARGE: Use epic-management with research spikes

IF unknowns == extensive OR deliverables > 20 OR new_infrastructure:
  → MASSIVE: Use initiative-architecture

ステップ 3：適切なワークフローへの振り分け

ごく小規模な範囲

**Assessment:** This is a trivial request (single deliverable, no unknowns).

**Next step:** Creating a single issue using `issue-prerequisite`.

振り分け先：issue-prerequisite

小規模な範囲

**Assessment:** This is a small request (few deliverables, minimal unknowns).

**Plan:**
1. Create parent issue for the request
2. If needed, decompose into 2-3 sub-issues
3. Begin implementation

**Next step:** Creating issue structure using `issue-prerequisite`.

振り分け先：issue-prerequisite → 必要に応じて issue-decomposition

大規模な範囲

**Assessment:** This is a large request requiring structured planning.

**Unknowns identified:**
- [ ] Unknown 1 - needs investigation
- [ ] Unknown 2 - needs research spike

**High-level deliverables:**
1. Deliverable A
2. Deliverable B
...

**Next step:** Creating epic structure using `epic-management`.

振り分け先：epic-management（必要に応じて調査スパイクを作成します）

非常に大規模な範囲

**Assessment:** This is a massive request requiring full initiative architecture.

**Why massive:**
- [Reason: extensive unknowns / new infrastructure / multi-system / etc.]

**Initial unknowns:**
- [ ] Does X exist?
- [ ] How does Y work?
- [ ] What are constraints of Z?

**Potential scope:**
- Multiple epics likely
- New capabilities needed
- Significant research required

**Next step:** Beginning initiative architecture using `initiative-architecture`.

振り分け先：initiative-architecture

再開可能性チェックポイント

振り分ける前に、受付内容をメモリに記録します。

# Store intake assessment
mcp__memory__create_entities([{
  "name": "Intake-[DATE]-[SHORT_DESC]",
  "entityType": "WorkIntake",
  "observations": [
    "Request: [Original request]",
    "Scope: [Trivial/Small/Large/Massive]",
    "Unknowns: [List]",
    "Route: [Target skill]",
    "Status: [Routing/In Progress/Complete]"
  ]
}])

例

例：ごく小規模

依頼： 「ログインページのボタンの色を少し明るくしてください。」

受付：

• 目標：ボタンの色を調整する
• 成功条件：ボタンが明るくなる
• 不明点：なし（CSS の変更）
• 成果物：1 件（色の変更）
• 範囲：ごく小規模

→ issue-prerequisite に振り分けます

例：大規模

依頼： 「アプリケーションにダークモードを追加してください。」

受付：

• 目標：テーマを切り替える機能
• 成功条件：ユーザーがダークモードとライトモードを切り替えられる
• 不明点：
  • 現在のテーマ設定の方式は？
  • コンポーネントライブラリは対応していますか？
  • 設定の保存方法は？
• 成果物：約 10 件（テーマトークン、コンポーネント、切り替え機能、設定の保存など）
• 範囲：大規模

→ epic-management に振り分けます

例：大規模

リクエスト: 「ユーザーがスマートフォンのポップアップをタップしてログインできるようにしてください。」

受付内容:

• 目標：モバイルプッシュ通知によるログイン
• 成功条件：ユーザーがプッシュ通知を受け取り、タップしてログインする
• 不明点：
  • モバイルアプリはありますか？ → 調査スパイク
  • プッシュ通知の基盤はありますか？ → 調査スパイク
  • 認証フローの設計はありますか？ → 調査スパイク
  • セキュリティ要件はありますか？ → 調査スパイク
• 成果物：30件以上（アプリの作業、バックエンド、認証、通知など）
• スコープ：非常に大規模

→ initiative-architecture に振り分けます

より大きなスコープを示す警告サイン

リクエストが見かけより大きいことを示す、次のような表現に注意してください。

表現	想定されるスコープ
「ちょっと追加して…」＋新機能	大規模（新機能には基盤が必要）
「ユーザーが…できるように」	大規模（ユーザー向け機能にはフルスタックが必要）
「…と統合して」	大規模（外部連携には API、認証、エラー処理が必要）
「［他の製品］のように…」	非常に大規模（機能の同等性には広範な作業が必要）
「モバイル／アプリ／通知」	非常に大規模（アプリがすでにある場合を除く）
「リアルタイム／同期／ライブ」	大規模（基盤が必要）

作業を断らない

リクエストがどれほど大規模でも、次の手順に従います。

1. 目標を受け止める - 「X をしたいというご要望ですね」
2. プロセスを説明する - 「これには体系的な計画が必要です」
3. 調査を始める - 不明点から着手する
4. すべてを記録する - あらゆる決定、あらゆる調査結果を記録する
5. 細分化する - 実行可能な単位になるまで分解する

「大規模なリクエスト」から「実装」までの流れ：

Massive Request
    → Initiative Architecture (document unknowns, create research spikes)
    → Research Spikes (answer unknowns)
    → Epic Structure (group deliverables)
    → Issue Decomposition (create tractable tasks)
    → Implementation (one issue at a time)

チェックリスト

• プロジェクトボードの準備状況を確認済み（ステップ 0 のゲートを通過済み）
• GITHUB_PROJECT_NUM と GH_PROJECT_OWNER を設定済み
• 明確化のための質問をした
• 目標を理解した（タスクだけでなく）
• 不明点を特定した
• 成果物の数を数えた
• スコープを評価した（些細／小規模／大規模／非常に大規模）
• 受付内容をメモリに記録した
• 適切なスキルに振り分けた（project-board-enforcement を使用）

スキル: project-board-enforcement

ゲート: プロジェクトボードの準備状況が確認されるまで、後続のスキルには進めません。