Task Routing

Task Routing

Route issues to the correct repo using the routing config from CLAUDE.md. Part of the Personal Corp framework: project-init → task-routing → weekly-planning / weekly-retro.

How It Works

digraph routing {
    "New task" -> "Read routing config from CLAUDE.md";
    "Read routing config from CLAUDE.md" -> "Match keywords → target repo";
    "Match keywords → target repo" -> "Check duplicates in target repo";
    "Check duplicates in target repo" -> "Duplicate found?" [shape=diamond];
    "Duplicate found?" -> "Update existing issue" [label="yes"];
    "Duplicate found?" -> "Check W-label exists in target repo" [label="no"];
    "Check W-label exists in target repo" -> "Create issue in target repo";
}

Step 1: Read Routing Config

Find the ### Task Routing section in CLAUDE.md of the current project (or the HQ repo if running from there):

### Task Routing (which issues go where)
routing:
  - pattern: "bot, broadcast, onboarding"
    repo: owner/bot-repo
  - pattern: "content, lessons"
    repo: owner/content-repo
  - pattern: "strategy, cross-cutting"
    repo: owner/main-repo

This config is created by project-init. If it doesn't exist — STOP and tell the user to run project-init first.

Step 2: Match Pattern

Match the task description against routing patterns. Rules:

• Match by keywords in the task, not by where you happen to be running
• If multiple patterns match, pick the most specific
• If no pattern matches, ask the user: "This doesn't match any routing pattern. Which repo?"
• Never default to the current repo — routing must be explicit

Step 3: Check Duplicates

# Check target repo
gh issue list -R {target_repo} -s open --json number,title --jq '.[].title'

# Check unified project (if configured)
gh project item-list {project_id} --owner {owner} --format json | \
  python3 -c "import json,sys; [print(i['title']) for i in json.load(sys.stdin)['items']]"

If a similar issue exists → update it instead of creating a duplicate.

Step 4: Check W-label

W-labels (W13, W14...) are created by weekly-planning, not manually.

# Check if current week label exists in target repo
gh label list -R {target_repo} | grep "W[0-9]"

• If W-label exists → use it
• If W-label does NOT exist → do not create it. Create the issue without a W-label. It will get labeled during next weekly-planning run.

Step 5: Create Issue

gh issue create -R {target_repo} \
  -t "prefix: title" \
  -l "{w_label_if_exists}" \
  --body "..."

Issue title prefixes follow conventional commits:

• ops: — operational task
• feat: — new feature
• fix: — bug fix
• content: — content creation
• research: — research task
• menti: — mentoring related

Red Flags — STOP

Common Mistakes

Minimal Example

# 1. Read routing from CLAUDE.md
# routing says: "bot, broadcast" → owner/hsl-mozg

# 2. User says: "создай задачу — рассылка по alumni"
# Keywords: "рассылка" matches "broadcast" → target = owner/hsl-mozg

# 3. Check duplicates
gh issue list -R owner/hsl-mozg -s open --json title --jq '.[].title' | grep -i alumni

# 4. Check W-label
gh label list -R owner/hsl-mozg | grep "W13"
# Found → use it

# 5. Create
gh issue create -R owner/hsl-mozg -t "ops: рассылка по alumni" -l "W13"