Set up My Work

My Work combines a canvas (the my-issues-triage canvas, titled "My Work"), the my-issues skill and one daily automation that refreshes a local index of the user's issues and hands the day's triage to a reused triage chat. Walk the user through the steps below, checking what already exists first, and confirm before creating anything that runs on a schedule.

Paths: <scripts> is the absolute path of the my-issues skill's scripts/ folder (a sibling of this skill's folder: ../my-issues/scripts). First run python3 "<scripts>/my_issues.py" paths and use the board, configFile, rulesFile, memoryFile and dataDir it prints for every file you read or write. They honour COPILOT_HOME; never assume ~/.copilot or Path.home(). Below, <board> means that board path.

1. Prerequisites

Check each and tell the user what is missing:

Repository clone (never clone it for the user). First look it up: run python3 "<scripts>/my_issues.py" find-clones --repo <planRepo> (default microsoft/vscode). It reads the Agents window's session store read-only, resolves worktrees to their main clone, checks each folder's git remote, and lists matching clones with how many sessions used them. Then confirm with the user: "Your sessions use ~/work/vscode for microsoft/vscode — use that?" If several match, offer them as choices (most used first); if none match, ask where their clone is. Record the confirmed path in repoPaths (step 2). Run find-clones without --repo to suggest paths for other repositories they work on too. If they have no clone, leave it out (configured paths that don't exist are ignored): fix and investigation sessions then ask where the repository is instead of guessing.

Sweeper clone. Check git -C ~/work/vscodesweeper-state rev-parse origin/state. If it's missing, explain that it powers the Cleanup proposals and the Implement view (without it everything else works), and offer to clone it. Only after the user agrees, run git clone --single-branch --branch state https://github.com/egamma/vscodesweeper-state ~/work/vscodesweeper-state (public, read-only use; the indexer only fetches it), or into a path they choose and record it as sweeperRepo.

2. Configuration (<board>/my-work.config.json)

All fields are optional. Ask only about values that differ from the defaults, then write the file (create <board> if needed):

{
  "org": "microsoft",
  "planRepo": "microsoft/vscode",
  "repoPaths": { "microsoft/vscode": "~/work/vscode" },
  "sweeperRepo": "~/work/vscodesweeper-state",
  "rulesFile": "~/.copilot/github-inbox-rules.md",
  "memoryFile": "~/.copilot/github-inbox-memory.md",
  "dataDir": "~/.agents/data/my-work",
  "fixSkill": "",
  "login": null
}

• org: whose issues are indexed and searched. login defaults to the gh user.
• planRepo: its open milestones define My Work's current and next groups.
• repoPaths: local clones used for fix sessions and read-only investigations.
• rulesFile and memoryFile: the user's inbox rules and memory, shared with the github-inbox plugin. Rules are numbered "from now on" instructions (auto-dismiss, routing, triage); memory holds facts such as people's GitHub logins, area owners and the user's team. If github-inbox stores them with VS Code's memory tool (/memories/github-inbox-*.md) instead of ~/.copilot/, offer to copy them to ~/.copilot/ so My Work can read them. If there are none, offer starter files: rules with sections Auto-dismiss rules, Routing (who owns which areas, with GitHub logins) and Triage; memory with Team and owners and Preferences. The bundled triage principles apply either way.
• fixSkill: a skill fix sessions should use for bugs (for example a personal fix-vscode-bug skill). Check which skills the user has and suggest one; leave it empty if there is none. Without it, sessions are told to reproduce first and add a regression test.
• Custom sections (for example MSRC for security cases) are created in the panel with + Section, not in the config. A section's instructions say how sessions from it are set up (for example which private repository, branch or skill to use); they stay in the local data folder, never in a shared repository. An older msrc.fixWorkflow setting is moved into an "MSRC" section automatically.

3. Feature areas (optional)

The first refresh creates <board>/my-issue-features.json with no custom areas; feature areas are then discovered automatically from GitHub feature labels. To group several labels or give an area precedence, add entries with a priority above 10:

{ "id": "settings", "name": "Settings", "labels": ["config", "settings-editor"], "priority": 60 }

4. Open the canvas

Open it now, before the index exists, so the user can start right away: call list_canvas_capabilities for my-issues-triage, then open_canvas with instanceId "triage-board" and input {}. My Work and Notifications work immediately; Today, Cleanup and Implement show the index build's progress and fill in when it finishes. Suggest trying Browse issues & PRs and pasting an issue number into the chat box at the bottom.

5. Build the index

Start python3 "<scripts>/refresh_my_issues.py" in the background (async) and keep going; don't wait for it. On the first run it creates the feature configuration, index and manifest, indexes the user's open issues and publishes them (usually within a minute), then adds their closed issues and publishes again. It fetches issues in batches of 50, so even ten thousand issues take only minutes. It never changes GitHub. The canvas shows its progress; report the final counts when it finishes.

6. Daily automation

Read references/indexer-automation.md, replace {{SCRIPTS}} and {{BOARD}} with absolute paths, and ask the user whether they want it and at what time (default weekdays 09:00 local). If yes, create it with the automation tool: name "My Issues Indexer", a quick-chat target on the local agent host, and auto-approval so its commands can run unattended. It creates the triage chat (titled "My Work") on its first run and reuses that chat every day after. Don't run it while the first index build is still going.

Troubleshooting

• Today / Cleanup / Implement say "No issue index yet": run step 5.
• Empty Cleanup and Implement: no Sweeper clone (step 1), or no microsoft/vscode issues.
• Notifications error: run gh auth status; the token needs the notifications scope (gh auth refresh -s notifications).
• Start session cannot find the repository: add it to repoPaths.
• Sessions don't link to issues: keep #N in session titles. Session data comes from the Agents window's internal storage and can change between builds.
• Two "My Work" canvases: an older personal copy of the extension (~/.copilot/extensions/my-issues-triage) is still installed; remove it after switching to the plugin.