[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699YCCFGGCCHTT2DZ2106GC":3,"skill-same:01M699YCCFGGCCHTT2DZ2106GC":79},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":23,"linkOnly":24,"markdownContent":25,"markdownBody":26,"frontMatter":27,"refName":28,"commitSha":29,"skillDirectory":30,"forksCount":31,"repositoryHtmlUrl":32,"repositoryHomepageUrl":6,"ownerHtmlUrl":33,"ownerBlogUrl":34,"ownerDescription":35,"updatedAt":36,"install":37,"resources":50},"01M699YCCFGGCCHTT2DZ2106GC","my-issues",null,"Query and act on the local index of every GitHub issue assigned to you (default org:microsoft), enriched with Sweeper (vscodesweeper) triage proposals, and drive the My Work canvas. Use when the user asks about \"my issues\", their backlog, feature-area counts, what Sweeper proposes for an issue, propose-close\u002Fneeds-info\u002Froute-to-area\u002FautoFixable\u002Fstale\u002Fno-repro lists, what changed since the last refresh, wants to record a triage decision, or sends a \"Panel request\"\u002F\"Panel message\" from the My Work canvas.","microsoft\u002Fvscode-team-kit","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699X9KV4SS0Q63FKWDHSQ6Z",66,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Fmy-work\u002Fskills\u002Fmy-issues\u002FSKILL.md",[],[19,20,21,9,22],"my issues","triage","github","canvas","2026-11-10 10:12:30",false,"---\nname: my-issues\ndescription: Query and act on the local index of every GitHub issue assigned to you (default org:microsoft), enriched with Sweeper (vscodesweeper) triage proposals, and drive the My Work canvas. Use when the user asks about \"my issues\", their backlog, feature-area counts, what Sweeper proposes for an issue, propose-close\u002Fneeds-info\u002Froute-to-area\u002FautoFixable\u002Fstale\u002Fno-repro lists, what changed since the last refresh, wants to record a triage decision, or sends a \"Panel request\"\u002F\"Panel message\" from the My Work canvas.\n---\n\n# My Issues index and the My Work canvas\n\nA daily automation (\"My Issues Indexer\", set up with the **my-work-setup** skill) maintains a local index of all issues assigned to the user in their GitHub org. Use it to answer questions about the user's issues **before** calling GitHub. It is fast and offline.\n\nPaths below use `\u003Cboard>` for `\u003CCOPILOT_HOME>\u002Fproject-boards` (default `~\u002F.copilot\u002Fproject-boards`) and `\u003Cscripts>` for this skill's `scripts\u002F` folder. Per-user settings (org, plan repository, local clones, Sweeper source, rules file, data folder) live in `\u003Cboard>\u002Fmy-work.config.json`; see the my-work-setup skill.\n\n## Files (`\u003Cboard>\u002F`)\n\n| File | Role |\n|---|---|\n| `my-issues.json` | Source of truth (can be tens of MB). **Never read it whole**; use the helper script. |\n| `my-issue-outcomes.json` | User-owned triage decisions. The refresh re-applies these to the index each run. |\n| `my-issues-refresh-manifest.json` | Last refresh: added\u002Fupdated counts, Sweeper commit, Sweeper `triageActionChanges`. |\n| `my-issue-features.json` | Feature areas (label → area, priority): the user's own, plus `\"auto\": true` areas the refresh adds for every GitHub feature label (microsoft\u002Fvscode labels coloured #c5def5, except `perf`) found on an open issue, at priority 10. Auto areas are kept; edit them (rename, priority) or list labels in `ignoredAutoLabels` only when the user asks. |\n| `my-issues.md` | Generated human view. Don't edit. |\n| `my-triage-queue.md` \u002F `.json` | Generated daily triage queue. Don't edit. |\n| `my-triage-chats.json` | Which refresh already got its daily triage message, and `persistentChat`: the one triage chat reused every day. Written by `mark-chat`. |\n| `my-work.config.json` | Per-user settings (optional; defaults suit the VS Code team). |\n| `my-issues-refresh-status.json` | Progress of the running (or last failed) refresh, written by `refresh_my_issues.py`; the canvas shows it on Today, Cleanup and Implement. |\n\nRecord keys are `owner\u002Frepo#number`. A bare number means `\u003CplanRepo>#number` (default `microsoft\u002Fvscode`).\n\n## Helper scripts\n\n`python3 \u003Cscripts>\u002Fmy_issues.py \u003Ccommand>`\n\n| Command | Use |\n|---|---|\n| `stats [--state open\\|closed\\|all]` | Counts by area, Sweeper action\u002Fseverity, autoFixable, outcomes |\n| `list [filters] [--sort ...] [--limit N] [--json]` | Filtered issue lists (open by default) |\n| `get \u003Ckey\\|number\\|url>` | Full compact record plus Sweeper's current Summary \u002F Best solution \u002F Proposed action |\n| `changes [--limit N]` | What the last refresh changed, including Sweeper verdict flips |\n| `record \u003Cissue> --decision \u003Cd> [--note ...] [--canonical owner\u002Frepo#n]` | Record an explicit user decision |\n| `record \u003Cissue> --clear` | Remove a recorded decision |\n| `queue [--write]` | Build the daily triage queue (`my-triage-queue.md`\u002F`.json`) and count unread GitHub notifications. Prints `triageChat` (the reused triage chat), `postToChat` (send today's `chatMessage` to it), `createChat` (no triage chat yet: create one with `title` and `chatPrompt`) for the automation. Both are false when today was already handled or there is nothing new |\n| `mark-chat \u003Clink>` | Record that the current refresh was posted to (or created) this triage chat, and make it the chat reused on later days |\n| `cleanup [--group fixed\\|duplicate\\|reason\\|needs-info] [--limit N]` | Sweeper-backed cleanup candidates. With no group it prints counts. Each item has evidence, the exact proposed comment, and the planned `gh` steps |\n| `proposal \u003Cissue>` | The same cleanup view for a single issue |\n| `apply \u003Cissue> --comment-file F --confirm [--group G] [--label L] [--duplicate-of N] [--note ...] [--force]` | Execute ONE approved cleanup action on GitHub and record the outcome |\n| `checks \u003Cissue> [--popular N]` | Live, read-only fact checks on a cleanup proposal |\n| `judge-prompt \u003Cissue...>` | Blind judge prompt and title (issue identity only) for a separate judge chat |\n| `opinion \u003Cissue> --action keep-open\\|fixed\\|duplicate\\|not-planned\\|needs-info [--reference R] [--confidence C] --reasoning \"...\" [--evidence E]` \u002F `opinion \u003Cissue> --clear` | Record or clear a **blind** judgement (judge chats only) |\n| `implement [--readiness implement\\|plan] [--limit N]` | Agent-ready issues (Sweeper `agentReadiness`), bugs first, then by severity and upvotes |\n| `find-clones [--repo owner\u002Frepo]` | Local clones the user's Agents window sessions worked in, by GitHub repository, most used first (read-only; works without an index) |\n\n`python3 \u003Cscripts>\u002Frefresh_my_issues.py [--full]` is the indexer pipeline. Only the indexer automation (or first-time setup) runs it; it never changes GitHub. The first run indexes open issues first (published quickly), then closed ones. Later runs only fetch issues updated since the last refresh (seconds); every 7 days, or with `--full`, a full pass also catches issues that were unassigned, transferred or deleted.\n\n`list` filters: `--area \u003Cid>`, `--repo owner\u002Frepo`, `--label L` (repeatable, all required), `--action keep-open|propose-close|needs-info|route-to-area`, `--severity S` (repeatable), `--autofixable`, `--no-milestone`, `--no-outcome`, `--has-outcome`, `--no-repro`, `--stale-days N`, `--text \u003Ctitle substring>`, `--state`. Sort: `updated` (default), `created`, `upvotes`, `confidence`, `severity`.\n\nFeature area ids: read `my-issue-features.json` (fallback `others`). Sweeper severities: `data-loss`, `crash`, `freeze`, `perf`, `correctness`, `visual`, `papercut`. Sweeper only covers microsoft\u002Fvscode. Its data comes from Sweeper's published index (`index-vscode.json`, read with `gh`, cached) and, for the issues that need them, its review records (cached until the issue's review changes; read from the optional local clone when it's current). If GitHub can't be reached, the previous Sweeper data stays. Rows also carry Sweeper's value score (`valueRaw`, comparable within the bugs or features `lane`), `verifyVerdict` (a blinded second review: only `confirmed` establishes a duplicate), `infoAnsweredAt` (the reporter answered a request for information), `contentStale`, `linkedPr` and `dismissed`.\n\n## Common recipes\n\n- Daily triage (the reused triage chat, titled \"My Work\"): read `\u003Cboard>\u002Fmy-triage-queue.md`. Its sections are Newly assigned, Sweeper changed its verdict, Reporter replied (a reporter answered your request for information), New activity, Severe bugs, Easy closes, and Top close proposals. It only lists open issues with no decision, or issues changed on GitHub after the last decision.\n- Morning overview: `changes`, then `list --no-outcome --action propose-close --limit 15`.\n- Close candidates: `list --action propose-close --no-outcome --sort confidence`.\n- Worst bugs: `list --label bug --severity data-loss --severity crash --severity freeze --sort upvotes`.\n- Hand-off to Copilot: `list --autofixable --no-outcome`.\n- Backlog cleanup: `list --stale-days 365 --no-milestone`, or `list --label bug --no-repro`.\n- One issue: `get 12345`.\n\nPresent lists as Markdown tables or bullets with issue links. Keep them short (≤25 rows) and say how many matched in total.\n\n## Cleanup workflow (Sweeper-assisted, one issue at a time)\n\nTriggers: \"clean up my issues\", \"clean up: already fixed\", \"close the duplicates\", \"send info requests\", or an issue from the triage queue or a notification that has a Sweeper close or needs-info proposal.\n\n| Group | Sweeper proposal | Planned GitHub action |\n|---|---|---|\n| `fixed` | Already fixed on main (fix commit + shipped version) | comment, then close as completed |\n| `duplicate` | Duplicate of #N | comment (includes `\u002Fduplicate of #N`), add `*duplicate`, close as duplicate of #N |\n| `reason` | as-designed \u002F out-of-scope \u002F question | comment, add `*as-designed`\u002F`*out-of-scope`\u002F`*question`, close as not planned |\n| `needs-info` | Needs more info from reporter | comment, add `info-needed` (stays open) |\n\nSteps:\n1. `cleanup` for counts, then `cleanup --group \u003Cg> --limit 10`. Items with `activitySinceReview: true` sort last. Treat their proposal as possibly outdated.\n2. **For each issue, one at a time:**\n   a. Fetch it live: `gh issue view \u003Cn> -R \u003Crepo> --comments`, and read the latest comments. If someone added information or disagreed after Sweeper's `reviewedAt`, say so and suggest skipping.\n   b. For `fixed`, glance at the fix commit (`gh api repos\u002F\u003Crepo>\u002Fcommits\u002F\u003Csha> --jq .commit.message`). For `duplicate`, check that the original issue is open and matches.\n   c. Show the user: issue link and title, Sweeper's summary, the key evidence, confidence, the **exact comment text**, and the planned steps.\n   d. Ask with the ask_user tool: **Approve**, **Edit comment**, **Skip**, **Keep open** (record `rejected`), or **Defer** (record `deferred`). Never batch approvals; each issue needs its own explicit approval.\n   e. On Approve or an approved edit: write the final comment to a temp file and run `apply \u003Cissue> --comment-file \u003Cfile> --confirm`. It re-checks live state, refuses if the issue was closed or got new comments since review (use `--force` only if the user approves after seeing them), runs the planned `gh` steps, and records the outcome. Delete the temp file.\n   f. On Skip, record nothing. On Keep open or Defer, use `record` with a short note.\n3. After the batch, summarise what was done and what's left (`cleanup` counts).\n\n**Rotation with notifications:** in the daily triage chat, the user may ask to alternate batches, e.g. \"10 notifications, then 10 cleanups\". Alternate fixed-size batches: notifications newest first, then cleanup with Easy closes first and then fixed → duplicate → reason → needs-info. Handle an issue only once even if it appears in both. Show a one-line tally after each batch and continue until the user stops.\n\nIn microsoft\u002Fvscode, `*`-labels can make the triage bot close the issue and post its own canned comment. `apply` tolerates the bot having closed it already.\n\n**Help:** when the user says \"help\" in a triage chat, show this skill's `triage-help.md` verbatim.\n\n**Principles, rules and memory:** every triage decision follows [triage-principles.md](triage-principles.md), refined by the user's inbox rules (`rulesFile`, default `~\u002F.copilot\u002Fgithub-inbox-rules.md`), which win on conflict. The user's inbox memory (`memoryFile`, default `~\u002F.copilot\u002Fgithub-inbox-memory.md`) holds facts: people's GitHub logins, area owners, the user's team and preferences. Both files are shared with the github-inbox plugin; read them before triaging.\n\n## The My Work canvas\n\nThe `my-issues-triage` canvas (\"My Work\", from the my-work plugin) has a left activity bar: **Today** (the daily queue), **My Work**, **Notifications**, **Cleanup** and **Implement** (agent-ready and not already taken by a PR, bugs first, then by Sweeper value). Each view shows one **batch** at a time (size configurable, default 10). Every button click (Approve \u002F Dismiss \u002F Done \u002F Keep open \u002F Defer \u002F Skip \u002F Start session \u002F Route …) is the user's explicit per-item decision. Without an index, My Work and Notifications still work and the other views explain how to build it.\n\nCanvas actions:\n- `setNotificationTriage {items:[{id, group: action|route|auto|cleanup|dismiss|fyi, reason, rule?, routeTo?}], keepBatch?}`: `auto` = matches an auto-dismiss rule in the user's inbox rules (give `rule`, e.g. \"A1. Merged own PR\" from the triage principles or a numbered rule of the user); the panel offers a bulk **Auto-dismiss** \u002F **Safe to dismiss** review. `route` = the issue\u002FPR belongs to another owner per the user's routing rules: give `routeTo` (logins; `[]` = only unassign the user) and `rule`; the panel's **Route** list lets the user bulk **Route & dismiss**. Put uncertain owners in `action` with `replyToIssue` choices instead. This also sets the notification batch unless `keepBatch: true`. Answer \"Panel request: classify these N notifications\", \"triage the next N untriaged notifications\" and \"re-check the classification\" messages with one call and `keepBatch: true`, using `auto`\u002F`dismiss` whenever a rule applies after reading the latest comments.\n- `setBatch {tab, ids}`: show exactly these items as a tab's current batch.\n- `setOpinion {key, action, reference?, confidence?, reasoning, evidence?}`: record a blind judgement (judge chats normally use `my_issues.py opinion`).\n- `replyToIssue {key, text, choices?}`: answer a \"Panel message about \u003Cissue>\" in that issue's thread (markdown). `choices` (max 5) are one-click quick replies `{label, reply, style?: primary|secondary|danger, edit?}`. Always add choices when asking for approval or a decision.\n- `judgeFailed {keys, error}`: report that a panel-requested judge chat could not be created.\n- `getActivity {since?}`: what the user did in the panel. Check it before each batch.\n- `focus {kind: notification|issue, id}`: select an item in the panel.\n- `refresh`: reload after the chat acted. `getSummary`: counts, current batches and batch size.\n- `setIssueRules {items:[{key, group: route|close|needs-info|keep, reason, rule?, routeTo?, closeAs?}]}`: the verdict of the user's inbox rules (the `rulesFile` in `my-work.config.json`, default `~\u002F.copilot\u002Fgithub-inbox-rules.md`, shared with the github-inbox plugin) for issues in the Cleanup \u002F Implement \u002F Today views. Answer \"Panel request: apply my inbox rules to these N issues\" with one call after checking each issue live. Rules win over Sweeper. Only clear routing candidates are `route`; uncertain owners are `keep` with the doubt in the reason.\n- `dismissNotifications {ids | issues, unsubscribe?}`: dismiss notifications (by thread ids, or every unread one about the given `owner\u002Frepo#N` issues) and update the panel at once. Always use this instead of `gh api` on notification threads. Once an action the user approved is done on GitHub and it addresses why a notification came in (the requested comment and `info-needed` label, a close, a reroute, a review), dismiss that notification without asking and say so.\n- `getConfig`: built-in plus the user's **custom groups** (`{id, label, criteria, bulk}`); call it at the start of every triage chat. `defineGroup {id, label, criteria, bulk?, order?}` \u002F `removeGroup {id}` manage custom groups.\n- `getMyWork` \u002F `updateMyWork {op, ...}` \u002F `setMyWorkChat {link}`: the My Work board (below).\n\n### My Work\n\n- **Groups:** the current and next milestone of `planRepo` (live GitHub search), then **My priorities** (the user's own ordered list, stored locally; closed issues drop off), then **Active sessions** (collapsible; hide irrelevant ones). The user's own **custom sections** (for example MSRC) sit at the top.\n- **Adding work:** **Browse issues & PRs** (right pane: my bugs, feature requests, all my issues or PRs awaiting my review, optionally narrowed to one feature area; a filter applied on Enter narrows the selected list: plain words become a *Panel request* to turn the filter into GitHub search qualifiers, which the chat answers with the `setBrowseQuery` canvas action (only the qualifiers to add; names resolved with the memory file; GitHub syntax such as `author:x` applies directly); click a title to open it in the panel to read, discuss, start a session or add it; drag rows into a group or use the + buttons), *Add to My Work* in any issue's menu, or the **My Work chat** box at the bottom (pasted `#123`, issue URLs, links matching a custom section's link pattern and `agent-host-session:\u002F\u002F` links are added at once; anything else goes to the chat). Local placement never changes GitHub; *Plan for…* sets a GitHub milestone and *Remove from \u003Cmilestone> (untriaged)* clears it (the issue then leaves My Work until found again); both are the user's explicit decision.\n- **Sessions:** adding a session first resolves the issue it works on (session title `#N`, branch number, issues its PRs close, its first request, chat titles; only one open issue in a tier counts). If found, the **issue** is added with the session linked; otherwise the session is added and the My Work chat is asked to describe it (`updateMyWork {op: \"describeSession\", session, summary, issue?}`; pass `issue` only with explicit evidence). Session details are read locally from the Agents window session store and transcript (best effort; internal formats). Keep `#N` in session titles so they link.\n- **Custom sections:** the user creates them in the panel (**+ Section**): a name, optional instructions for sessions, and an optional link pattern. A section holds **notes** (title, link, description, due date; stored privately in the My Work data folder) plus issues and sessions moved or dragged into it. **Start session** on a note sends \"Panel request: start a session for \u003Cnote> from my \u003Csection> section\": follow the section's instructions exactly (for a security section they say to work privately) and keep the note's reference in the session title so the panel links it. The built-in MSRC group of earlier versions became a custom \"MSRC\" section with the same items and `msrc.fixWorkflow` as its instructions.\n- **Worktrees are the host's job:** fix, implement and review sessions are created with the repository clone as workspace and `worktree: true` (or `set_workspace` with `isolation: true`), so the host creates and manages the worktree. Never run `git worktree add` yourself or pass an existing worktree folder as the workspace.\n- **Review sessions:** for someone else's pull request, the panel's main action is **Start review session**, which sends \"Panel request: start a review session\". Create a session nested under the My Work session (omit relationship) with the repository clone, worktree true, titled `Review #N: …`, whose prompt checks out the PR, reviews it (with `reviewSkill` if configured) and drafts review comments. It never submits a review, approves, comments or pushes without the user's approval. Right after `create_session`, link the session to the PR with `updateMyWork {\"op\": \"linkSession\", \"session\": \"\u003Clink>\", \"issue\": \"owner\u002Frepo#N\"}`; fix sessions do the same for their issue. The panel adds the PR to My Work's current group and dismisses its notifications when the review starts.\n- **Investigating and fix tracking:** asking to reproduce (the Reproduce recommendation) or investigate (the Investigate buttons) puts the issue in the **Investigating** section, a custom section created on first use. When the reproduce attempt or investigation is done, the chat calls `updateMyWork {\"op\": \"investigationResult\", \"issue\": \"owner\u002Frepo#N\", \"result\": \"reproduced\" | \"not-reproduced\" | \"partly\" | \"findings\", \"summary\": \"\u003Cone line>\"}`, and the item shows the result and moves to To do. Starting a fix or implementation session from anywhere puts the issue in the current group (local only), moving it out of Investigating; issues already planned or placed in the user's own sections stay where they are.\n- **My Work chat:** its first message asks the triage chat to create a nested chat titled \"My Work chat\" and register it with `setMyWorkChat {link}`; later messages arrive as \"Panel request: forward a My Work message\" — just `send_message` them verbatim. The My Work chat uses `getMyWork` \u002F `updateMyWork` (addIssue, pinSession, moveSession, unpinSession, describeSession, add\u002Fmove\u002FremovePriority, addNote {section, title, link?, due?, description?} — local only; `group` may also be a custom section id, no approval needed) and replies with `replyToIssue {\"key\": \"my-work\", …}`. \"The session I'm in\" = the most recently active session other than the triage and My Work chats. If the nested chat is gone, call `setMyWorkChat {\"link\": null}`.\n- **Finished issue chats:** when a notification is dismissed (by the user in the panel, or by a chat with `dismissNotifications`), the panel sends the My Work session \"Panel request: archive finished issue chats\" for that issue's discussion chat. Check each chat with `get_session_context`; archive it with `archive_chat` and call `setIssueChat {key, link: null}` only if its latest turn is complete, it isn't waiting for the user, and it isn't a work session. A later message about the issue starts a new chat. Starting a reproduce, investigation or review also dismisses the notification, but keeps the chat.\n- **Requests that create chats from a panel outside the My Work session** arrive as \"Panel request: run a request in the My Work session\": check `get_current_session`; inside that session handle it, otherwise `send_message` it there verbatim.\n- **Issue chats:** the first message about an issue from the panel sends \"Panel request: create the chat for \u003Cissue>\": create a chat nested under the My Work session (omit relationship), without a workspace, titled `#N: …`, with the prompt verbatim, and register it with the `setIssueChat` canvas action. Later messages arrive as \"Panel request: forward a message to the chat for \u003Cissue>\": only `send_message` them to that chat. The issue chat answers in the panel with `replyToIssue`.\n- **Start session** on an issue with a discussion chat forwards \"The user clicked Start session\" to that chat. It renames itself `Fix #N: …` \u002F `Implement #N: …`, registers itself with `setIssueChat` stage `session`, records `fixing`, then calls `set_workspace` with the repository clone and a worktree, and starts the work in the same conversation. Without an issue chat (or with *Start another session*), the request is \"Panel request: start a work session for \u003Cissue>\": create a session nested under the My Work session (omit relationship) with a worktree of the repository's configured local clone, titled `Fix #N: …` \u002F `Implement #N: …`, record `fixing`, and reply with `replyToIssue`.\n\n### Panel requests\n\n- **\"Panel request: start a nested judge chat\"**: call `create_session` exactly as instructed (omit `relationship` so it is nested, no workspace), passing the enclosed prompt **verbatim**. Do not judge it yourself and do not add Sweeper context.\n- **\"Panel message about \u003Cissue>\"**: handle it like any request from the user about that issue (GitHub changes still need explicit approval), then answer with `replyToIssue`.\n- **\"Start a fix session…\"** \u002F **\"Panel request: start a fix or implementation session…\"**: the click is explicit confirmation. Fetch the live issue and latest comments, decide bug vs feature, create an independent isolated-worktree session in the configured local clone, record `fixing` only after creation (and only for indexed issues), post the session link with `replyToIssue`, and do not dismiss the notification.\n- **\"Panel request: start a nested investigation chat\"**: call `create_session` exactly as instructed (nested, no workspace), post its link with `replyToIssue`, and continue without waiting. Neither chat changes GitHub during the investigation.\n\n### Standing instructions (\"from now on…\")\n\nThe daily triage chat is reused every day, but older history gets compacted, so persist lasting requests instead of remembering them. Show the user exactly what will be saved and where, and wait for OK. Then:\n- **(a) Classification or handling rule:** append it as the next numbered rule in the user's rules file.\n- **(a2) A lasting fact** (someone's GitHub login, who owns an area, the user's team): add it to the user's memory file in the matching section.\n- **(b) New panel section or bulk list** (e.g. \"group CODENOTIFY\"): `defineGroup` with criteria a future chat can apply without asking, add the matching rule from (a), then reclassify today's notifications with `setNotificationTriage` and `keepBatch: true`.\n- **(c) Panel UI or behaviour changes:** these are changes to the shared my-work plugin (microsoft\u002Fvscode-team-kit). Describe the change and offer to open an issue or pull request there; don't edit the installed plugin.\n\n## Independent (blind) judgements\n\nJudge chats get only the issue identity. They must not read Sweeper data or `my_issues.py get\u002Fproposal\u002Fchecks\u002Fcleanup\u002Flist`. They record each verdict with `my_issues.py opinion …`, which writes one file per issue to `\u003Cboard>\u002Fmy-issue-opinions\u002F`, so parallel judges never collide. The panel compares each verdict with Sweeper's proposal.\n\nWhen the user asks for an independent judgement in chat, run `my_issues.py judge-prompt \u003Cissue...>` and call `create_session` with its `title` and `prompt` **verbatim**, **omitting `relationship`** and with **no workspace** (the judge reads the local clone read only). For a second round with Sweeper's evidence, use `judge-prompt --informed \u003Cissue>`; the judge records with `opinion \u003Cissue> --informed ...`.\n\n## Rules\n\n1. **The index can be up to a day old.** Before acting on GitHub (closing, commenting, labelling, assigning), fetch the live issue and its latest comments. The user's inbox rules still apply, including showing comment text for approval before posting.\n2. **Sweeper is advisory.** Present its verdict as a proposal with its confidence. Never treat it as a decision.\n3. **Record outcomes only on explicit user decisions.** Use `record` only after the user explicitly decides, or after the user-approved GitHub action has succeeded. `apply` records automatically after its approved action. Never record outcomes in bulk from Sweeper proposals, and never run `apply --confirm` without that issue's explicit approval. Decisions: `accepted`, `rejected`, `deferred`, `closed`, `needs-info-sent`, `routed`, `fixing`, `fixed`, `duplicate` (with `--canonical`), `wont-fix`. Put the reason in `--note`.\n4. **Never edit `my-issues.json` directly.** The indexer owns it, and `record` is the only supported write.\n5. Issues not assigned to the user are not in the index. Fall back to GitHub for those.\n","# My Issues index and the My Work canvas\n\nA daily automation (\"My Issues Indexer\", set up with the **my-work-setup** skill) maintains a local index of all issues assigned to the user in their GitHub org. Use it to answer questions about the user's issues **before** calling GitHub. It is fast and offline.\n\nPaths below use `\u003Cboard>` for `\u003CCOPILOT_HOME>\u002Fproject-boards` (default `~\u002F.copilot\u002Fproject-boards`) and `\u003Cscripts>` for this skill's `scripts\u002F` folder. Per-user settings (org, plan repository, local clones, Sweeper source, rules file, data folder) live in `\u003Cboard>\u002Fmy-work.config.json`; see the my-work-setup skill.\n\n## Files (`\u003Cboard>\u002F`)\n\n| File | Role |\n|---|---|\n| `my-issues.json` | Source of truth (can be tens of MB). **Never read it whole**; use the helper script. |\n| `my-issue-outcomes.json` | User-owned triage decisions. The refresh re-applies these to the index each run. |\n| `my-issues-refresh-manifest.json` | Last refresh: added\u002Fupdated counts, Sweeper commit, Sweeper `triageActionChanges`. |\n| `my-issue-features.json` | Feature areas (label → area, priority): the user's own, plus `\"auto\": true` areas the refresh adds for every GitHub feature label (microsoft\u002Fvscode labels coloured #c5def5, except `perf`) found on an open issue, at priority 10. Auto areas are kept; edit them (rename, priority) or list labels in `ignoredAutoLabels` only when the user asks. |\n| `my-issues.md` | Generated human view. Don't edit. |\n| `my-triage-queue.md` \u002F `.json` | Generated daily triage queue. Don't edit. |\n| `my-triage-chats.json` | Which refresh already got its daily triage message, and `persistentChat`: the one triage chat reused every day. Written by `mark-chat`. |\n| `my-work.config.json` | Per-user settings (optional; defaults suit the VS Code team). |\n| `my-issues-refresh-status.json` | Progress of the running (or last failed) refresh, written by `refresh_my_issues.py`; the canvas shows it on Today, Cleanup and Implement. |\n\nRecord keys are `owner\u002Frepo#number`. A bare number means `\u003CplanRepo>#number` (default `microsoft\u002Fvscode`).\n\n## Helper scripts\n\n`python3 \u003Cscripts>\u002Fmy_issues.py \u003Ccommand>`\n\n| Command | Use |\n|---|---|\n| `stats [--state open\\|closed\\|all]` | Counts by area, Sweeper action\u002Fseverity, autoFixable, outcomes |\n| `list [filters] [--sort ...] [--limit N] [--json]` | Filtered issue lists (open by default) |\n| `get \u003Ckey\\|number\\|url>` | Full compact record plus Sweeper's current Summary \u002F Best solution \u002F Proposed action |\n| `changes [--limit N]` | What the last refresh changed, including Sweeper verdict flips |\n| `record \u003Cissue> --decision \u003Cd> [--note ...] [--canonical owner\u002Frepo#n]` | Record an explicit user decision |\n| `record \u003Cissue> --clear` | Remove a recorded decision |\n| `queue [--write]` | Build the daily triage queue (`my-triage-queue.md`\u002F`.json`) and count unread GitHub notifications. Prints `triageChat` (the reused triage chat), `postToChat` (send today's `chatMessage` to it), `createChat` (no triage chat yet: create one with `title` and `chatPrompt`) for the automation. Both are false when today was already handled or there is nothing new |\n| `mark-chat \u003Clink>` | Record that the current refresh was posted to (or created) this triage chat, and make it the chat reused on later days |\n| `cleanup [--group fixed\\|duplicate\\|reason\\|needs-info] [--limit N]` | Sweeper-backed cleanup candidates. With no group it prints counts. Each item has evidence, the exact proposed comment, and the planned `gh` steps |\n| `proposal \u003Cissue>` | The same cleanup view for a single issue |\n| `apply \u003Cissue> --comment-file F --confirm [--group G] [--label L] [--duplicate-of N] [--note ...] [--force]` | Execute ONE approved cleanup action on GitHub and record the outcome |\n| `checks \u003Cissue> [--popular N]` | Live, read-only fact checks on a cleanup proposal |\n| `judge-prompt \u003Cissue...>` | Blind judge prompt and title (issue identity only) for a separate judge chat |\n| `opinion \u003Cissue> --action keep-open\\|fixed\\|duplicate\\|not-planned\\|needs-info [--reference R] [--confidence C] --reasoning \"...\" [--evidence E]` \u002F `opinion \u003Cissue> --clear` | Record or clear a **blind** judgement (judge chats only) |\n| `implement [--readiness implement\\|plan] [--limit N]` | Agent-ready issues (Sweeper `agentReadiness`), bugs first, then by severity and upvotes |\n| `find-clones [--repo owner\u002Frepo]` | Local clones the user's Agents window sessions worked in, by GitHub repository, most used first (read-only; works without an index) |\n\n`python3 \u003Cscripts>\u002Frefresh_my_issues.py [--full]` is the indexer pipeline. Only the indexer automation (or first-time setup) runs it; it never changes GitHub. The first run indexes open issues first (published quickly), then closed ones. Later runs only fetch issues updated since the last refresh (seconds); every 7 days, or with `--full`, a full pass also catches issues that were unassigned, transferred or deleted.\n\n`list` filters: `--area \u003Cid>`, `--repo owner\u002Frepo`, `--label L` (repeatable, all required), `--action keep-open|propose-close|needs-info|route-to-area`, `--severity S` (repeatable), `--autofixable`, `--no-milestone`, `--no-outcome`, `--has-outcome`, `--no-repro`, `--stale-days N`, `--text \u003Ctitle substring>`, `--state`. Sort: `updated` (default), `created`, `upvotes`, `confidence`, `severity`.\n\nFeature area ids: read `my-issue-features.json` (fallback `others`). Sweeper severities: `data-loss`, `crash`, `freeze`, `perf`, `correctness`, `visual`, `papercut`. Sweeper only covers microsoft\u002Fvscode. Its data comes from Sweeper's published index (`index-vscode.json`, read with `gh`, cached) and, for the issues that need them, its review records (cached until the issue's review changes; read from the optional local clone when it's current). If GitHub can't be reached, the previous Sweeper data stays. Rows also carry Sweeper's value score (`valueRaw`, comparable within the bugs or features `lane`), `verifyVerdict` (a blinded second review: only `confirmed` establishes a duplicate), `infoAnsweredAt` (the reporter answered a request for information), `contentStale`, `linkedPr` and `dismissed`.\n\n## Common recipes\n\n- Daily triage (the reused triage chat, titled \"My Work\"): read `\u003Cboard>\u002Fmy-triage-queue.md`. Its sections are Newly assigned, Sweeper changed its verdict, Reporter replied (a reporter answered your request for information), New activity, Severe bugs, Easy closes, and Top close proposals. It only lists open issues with no decision, or issues changed on GitHub after the last decision.\n- Morning overview: `changes`, then `list --no-outcome --action propose-close --limit 15`.\n- Close candidates: `list --action propose-close --no-outcome --sort confidence`.\n- Worst bugs: `list --label bug --severity data-loss --severity crash --severity freeze --sort upvotes`.\n- Hand-off to Copilot: `list --autofixable --no-outcome`.\n- Backlog cleanup: `list --stale-days 365 --no-milestone`, or `list --label bug --no-repro`.\n- One issue: `get 12345`.\n\nPresent lists as Markdown tables or bullets with issue links. Keep them short (≤25 rows) and say how many matched in total.\n\n## Cleanup workflow (Sweeper-assisted, one issue at a time)\n\nTriggers: \"clean up my issues\", \"clean up: already fixed\", \"close the duplicates\", \"send info requests\", or an issue from the triage queue or a notification that has a Sweeper close or needs-info proposal.\n\n| Group | Sweeper proposal | Planned GitHub action |\n|---|---|---|\n| `fixed` | Already fixed on main (fix commit + shipped version) | comment, then close as completed |\n| `duplicate` | Duplicate of #N | comment (includes `\u002Fduplicate of #N`), add `*duplicate`, close as duplicate of #N |\n| `reason` | as-designed \u002F out-of-scope \u002F question | comment, add `*as-designed`\u002F`*out-of-scope`\u002F`*question`, close as not planned |\n| `needs-info` | Needs more info from reporter | comment, add `info-needed` (stays open) |\n\nSteps:\n1. `cleanup` for counts, then `cleanup --group \u003Cg> --limit 10`. Items with `activitySinceReview: true` sort last. Treat their proposal as possibly outdated.\n2. **For each issue, one at a time:**\n   a. Fetch it live: `gh issue view \u003Cn> -R \u003Crepo> --comments`, and read the latest comments. If someone added information or disagreed after Sweeper's `reviewedAt`, say so and suggest skipping.\n   b. For `fixed`, glance at the fix commit (`gh api repos\u002F\u003Crepo>\u002Fcommits\u002F\u003Csha> --jq .commit.message`). For `duplicate`, check that the original issue is open and matches.\n   c. Show the user: issue link and title, Sweeper's summary, the key evidence, confidence, the **exact comment text**, and the planned steps.\n   d. Ask with the ask_user tool: **Approve**, **Edit comment**, **Skip**, **Keep open** (record `rejected`), or **Defer** (record `deferred`). Never batch approvals; each issue needs its own explicit approval.\n   e. On Approve or an approved edit: write the final comment to a temp file and run `apply \u003Cissue> --comment-file \u003Cfile> --confirm`. It re-checks live state, refuses if the issue was closed or got new comments since review (use `--force` only if the user approves after seeing them), runs the planned `gh` steps, and records the outcome. Delete the temp file.\n   f. On Skip, record nothing. On Keep open or Defer, use `record` with a short note.\n3. After the batch, summarise what was done and what's left (`cleanup` counts).\n\n**Rotation with notifications:** in the daily triage chat, the user may ask to alternate batches, e.g. \"10 notifications, then 10 cleanups\". Alternate fixed-size batches: notifications newest first, then cleanup with Easy closes first and then fixed → duplicate → reason → needs-info. Handle an issue only once even if it appears in both. Show a one-line tally after each batch and continue until the user stops.\n\nIn microsoft\u002Fvscode, `*`-labels can make the triage bot close the issue and post its own canned comment. `apply` tolerates the bot having closed it already.\n\n**Help:** when the user says \"help\" in a triage chat, show this skill's `triage-help.md` verbatim.\n\n**Principles, rules and memory:** every triage decision follows [triage-principles.md](triage-principles.md), refined by the user's inbox rules (`rulesFile`, default `~\u002F.copilot\u002Fgithub-inbox-rules.md`), which win on conflict. The user's inbox memory (`memoryFile`, default `~\u002F.copilot\u002Fgithub-inbox-memory.md`) holds facts: people's GitHub logins, area owners, the user's team and preferences. Both files are shared with the github-inbox plugin; read them before triaging.\n\n## The My Work canvas\n\nThe `my-issues-triage` canvas (\"My Work\", from the my-work plugin) has a left activity bar: **Today** (the daily queue), **My Work**, **Notifications**, **Cleanup** and **Implement** (agent-ready and not already taken by a PR, bugs first, then by Sweeper value). Each view shows one **batch** at a time (size configurable, default 10). Every button click (Approve \u002F Dismiss \u002F Done \u002F Keep open \u002F Defer \u002F Skip \u002F Start session \u002F Route …) is the user's explicit per-item decision. Without an index, My Work and Notifications still work and the other views explain how to build it.\n\nCanvas actions:\n- `setNotificationTriage {items:[{id, group: action|route|auto|cleanup|dismiss|fyi, reason, rule?, routeTo?}], keepBatch?}`: `auto` = matches an auto-dismiss rule in the user's inbox rules (give `rule`, e.g. \"A1. Merged own PR\" from the triage principles or a numbered rule of the user); the panel offers a bulk **Auto-dismiss** \u002F **Safe to dismiss** review. `route` = the issue\u002FPR belongs to another owner per the user's routing rules: give `routeTo` (logins; `[]` = only unassign the user) and `rule`; the panel's **Route** list lets the user bulk **Route & dismiss**. Put uncertain owners in `action` with `replyToIssue` choices instead. This also sets the notification batch unless `keepBatch: true`. Answer \"Panel request: classify these N notifications\", \"triage the next N untriaged notifications\" and \"re-check the classification\" messages with one call and `keepBatch: true`, using `auto`\u002F`dismiss` whenever a rule applies after reading the latest comments.\n- `setBatch {tab, ids}`: show exactly these items as a tab's current batch.\n- `setOpinion {key, action, reference?, confidence?, reasoning, evidence?}`: record a blind judgement (judge chats normally use `my_issues.py opinion`).\n- `replyToIssue {key, text, choices?}`: answer a \"Panel message about \u003Cissue>\" in that issue's thread (markdown). `choices` (max 5) are one-click quick replies `{label, reply, style?: primary|secondary|danger, edit?}`. Always add choices when asking for approval or a decision.\n- `judgeFailed {keys, error}`: report that a panel-requested judge chat could not be created.\n- `getActivity {since?}`: what the user did in the panel. Check it before each batch.\n- `focus {kind: notification|issue, id}`: select an item in the panel.\n- `refresh`: reload after the chat acted. `getSummary`: counts, current batches and batch size.\n- `setIssueRules {items:[{key, group: route|close|needs-info|keep, reason, rule?, routeTo?, closeAs?}]}`: the verdict of the user's inbox rules (the `rulesFile` in `my-work.config.json`, default `~\u002F.copilot\u002Fgithub-inbox-rules.md`, shared with the github-inbox plugin) for issues in the Cleanup \u002F Implement \u002F Today views. Answer \"Panel request: apply my inbox rules to these N issues\" with one call after checking each issue live. Rules win over Sweeper. Only clear routing candidates are `route`; uncertain owners are `keep` with the doubt in the reason.\n- `dismissNotifications {ids | issues, unsubscribe?}`: dismiss notifications (by thread ids, or every unread one about the given `owner\u002Frepo#N` issues) and update the panel at once. Always use this instead of `gh api` on notification threads. Once an action the user approved is done on GitHub and it addresses why a notification came in (the requested comment and `info-needed` label, a close, a reroute, a review), dismiss that notification without asking and say so.\n- `getConfig`: built-in plus the user's **custom groups** (`{id, label, criteria, bulk}`); call it at the start of every triage chat. `defineGroup {id, label, criteria, bulk?, order?}` \u002F `removeGroup {id}` manage custom groups.\n- `getMyWork` \u002F `updateMyWork {op, ...}` \u002F `setMyWorkChat {link}`: the My Work board (below).\n\n### My Work\n\n- **Groups:** the current and next milestone of `planRepo` (live GitHub search), then **My priorities** (the user's own ordered list, stored locally; closed issues drop off), then **Active sessions** (collapsible; hide irrelevant ones). The user's own **custom sections** (for example MSRC) sit at the top.\n- **Adding work:** **Browse issues & PRs** (right pane: my bugs, feature requests, all my issues or PRs awaiting my review, optionally narrowed to one feature area; a filter applied on Enter narrows the selected list: plain words become a *Panel request* to turn the filter into GitHub search qualifiers, which the chat answers with the `setBrowseQuery` canvas action (only the qualifiers to add; names resolved with the memory file; GitHub syntax such as `author:x` applies directly); click a title to open it in the panel to read, discuss, start a session or add it; drag rows into a group or use the + buttons), *Add to My Work* in any issue's menu, or the **My Work chat** box at the bottom (pasted `#123`, issue URLs, links matching a custom section's link pattern and `agent-host-session:\u002F\u002F` links are added at once; anything else goes to the chat). Local placement never changes GitHub; *Plan for…* sets a GitHub milestone and *Remove from \u003Cmilestone> (untriaged)* clears it (the issue then leaves My Work until found again); both are the user's explicit decision.\n- **Sessions:** adding a session first resolves the issue it works on (session title `#N`, branch number, issues its PRs close, its first request, chat titles; only one open issue in a tier counts). If found, the **issue** is added with the session linked; otherwise the session is added and the My Work chat is asked to describe it (`updateMyWork {op: \"describeSession\", session, summary, issue?}`; pass `issue` only with explicit evidence). Session details are read locally from the Agents window session store and transcript (best effort; internal formats). Keep `#N` in session titles so they link.\n- **Custom sections:** the user creates them in the panel (**+ Section**): a name, optional instructions for sessions, and an optional link pattern. A section holds **notes** (title, link, description, due date; stored privately in the My Work data folder) plus issues and sessions moved or dragged into it. **Start session** on a note sends \"Panel request: start a session for \u003Cnote> from my \u003Csection> section\": follow the section's instructions exactly (for a security section they say to work privately) and keep the note's reference in the session title so the panel links it. The built-in MSRC group of earlier versions became a custom \"MSRC\" section with the same items and `msrc.fixWorkflow` as its instructions.\n- **Worktrees are the host's job:** fix, implement and review sessions are created with the repository clone as workspace and `worktree: true` (or `set_workspace` with `isolation: true`), so the host creates and manages the worktree. Never run `git worktree add` yourself or pass an existing worktree folder as the workspace.\n- **Review sessions:** for someone else's pull request, the panel's main action is **Start review session**, which sends \"Panel request: start a review session\". Create a session nested under the My Work session (omit relationship) with the repository clone, worktree true, titled `Review #N: …`, whose prompt checks out the PR, reviews it (with `reviewSkill` if configured) and drafts review comments. It never submits a review, approves, comments or pushes without the user's approval. Right after `create_session`, link the session to the PR with `updateMyWork {\"op\": \"linkSession\", \"session\": \"\u003Clink>\", \"issue\": \"owner\u002Frepo#N\"}`; fix sessions do the same for their issue. The panel adds the PR to My Work's current group and dismisses its notifications when the review starts.\n- **Investigating and fix tracking:** asking to reproduce (the Reproduce recommendation) or investigate (the Investigate buttons) puts the issue in the **Investigating** section, a custom section created on first use. When the reproduce attempt or investigation is done, the chat calls `updateMyWork {\"op\": \"investigationResult\", \"issue\": \"owner\u002Frepo#N\", \"result\": \"reproduced\" | \"not-reproduced\" | \"partly\" | \"findings\", \"summary\": \"\u003Cone line>\"}`, and the item shows the result and moves to To do. Starting a fix or implementation session from anywhere puts the issue in the current group (local only), moving it out of Investigating; issues already planned or placed in the user's own sections stay where they are.\n- **My Work chat:** its first message asks the triage chat to create a nested chat titled \"My Work chat\" and register it with `setMyWorkChat {link}`; later messages arrive as \"Panel request: forward a My Work message\" — just `send_message` them verbatim. The My Work chat uses `getMyWork` \u002F `updateMyWork` (addIssue, pinSession, moveSession, unpinSession, describeSession, add\u002Fmove\u002FremovePriority, addNote {section, title, link?, due?, description?} — local only; `group` may also be a custom section id, no approval needed) and replies with `replyToIssue {\"key\": \"my-work\", …}`. \"The session I'm in\" = the most recently active session other than the triage and My Work chats. If the nested chat is gone, call `setMyWorkChat {\"link\": null}`.\n- **Finished issue chats:** when a notification is dismissed (by the user in the panel, or by a chat with `dismissNotifications`), the panel sends the My Work session \"Panel request: archive finished issue chats\" for that issue's discussion chat. Check each chat with `get_session_context`; archive it with `archive_chat` and call `setIssueChat {key, link: null}` only if its latest turn is complete, it isn't waiting for the user, and it isn't a work session. A later message about the issue starts a new chat. Starting a reproduce, investigation or review also dismisses the notification, but keeps the chat.\n- **Requests that create chats from a panel outside the My Work session** arrive as \"Panel request: run a request in the My Work session\": check `get_current_session`; inside that session handle it, otherwise `send_message` it there verbatim.\n- **Issue chats:** the first message about an issue from the panel sends \"Panel request: create the chat for \u003Cissue>\": create a chat nested under the My Work session (omit relationship), without a workspace, titled `#N: …`, with the prompt verbatim, and register it with the `setIssueChat` canvas action. Later messages arrive as \"Panel request: forward a message to the chat for \u003Cissue>\": only `send_message` them to that chat. The issue chat answers in the panel with `replyToIssue`.\n- **Start session** on an issue with a discussion chat forwards \"The user clicked Start session\" to that chat. It renames itself `Fix #N: …` \u002F `Implement #N: …`, registers itself with `setIssueChat` stage `session`, records `fixing`, then calls `set_workspace` with the repository clone and a worktree, and starts the work in the same conversation. Without an issue chat (or with *Start another session*), the request is \"Panel request: start a work session for \u003Cissue>\": create a session nested under the My Work session (omit relationship) with a worktree of the repository's configured local clone, titled `Fix #N: …` \u002F `Implement #N: …`, record `fixing`, and reply with `replyToIssue`.\n\n### Panel requests\n\n- **\"Panel request: start a nested judge chat\"**: call `create_session` exactly as instructed (omit `relationship` so it is nested, no workspace), passing the enclosed prompt **verbatim**. Do not judge it yourself and do not add Sweeper context.\n- **\"Panel message about \u003Cissue>\"**: handle it like any request from the user about that issue (GitHub changes still need explicit approval), then answer with `replyToIssue`.\n- **\"Start a fix session…\"** \u002F **\"Panel request: start a fix or implementation session…\"**: the click is explicit confirmation. Fetch the live issue and latest comments, decide bug vs feature, create an independent isolated-worktree session in the configured local clone, record `fixing` only after creation (and only for indexed issues), post the session link with `replyToIssue`, and do not dismiss the notification.\n- **\"Panel request: start a nested investigation chat\"**: call `create_session` exactly as instructed (nested, no workspace), post its link with `replyToIssue`, and continue without waiting. Neither chat changes GitHub during the investigation.\n\n### Standing instructions (\"from now on…\")\n\nThe daily triage chat is reused every day, but older history gets compacted, so persist lasting requests instead of remembering them. Show the user exactly what will be saved and where, and wait for OK. Then:\n- **(a) Classification or handling rule:** append it as the next numbered rule in the user's rules file.\n- **(a2) A lasting fact** (someone's GitHub login, who owns an area, the user's team): add it to the user's memory file in the matching section.\n- **(b) New panel section or bulk list** (e.g. \"group CODENOTIFY\"): `defineGroup` with criteria a future chat can apply without asking, add the matching rule from (a), then reclassify today's notifications with `setNotificationTriage` and `keepBatch: true`.\n- **(c) Panel UI or behaviour changes:** these are changes to the shared my-work plugin (microsoft\u002Fvscode-team-kit). Describe the change and offer to open an issue or pull request there; don't edit the installed plugin.\n\n## Independent (blind) judgements\n\nJudge chats get only the issue identity. They must not read Sweeper data or `my_issues.py get\u002Fproposal\u002Fchecks\u002Fcleanup\u002Flist`. They record each verdict with `my_issues.py opinion …`, which writes one file per issue to `\u003Cboard>\u002Fmy-issue-opinions\u002F`, so parallel judges never collide. The panel compares each verdict with Sweeper's proposal.\n\nWhen the user asks for an independent judgement in chat, run `my_issues.py judge-prompt \u003Cissue...>` and call `create_session` with its `title` and `prompt` **verbatim**, **omitting `relationship`** and with **no workspace** (the judge reads the local clone read only). For a second round with Sweeper's evidence, use `judge-prompt --informed \u003Cissue>`; the judge records with `opinion \u003Cissue> --informed ...`.\n\n## Rules\n\n1. **The index can be up to a day old.** Before acting on GitHub (closing, commenting, labelling, assigning), fetch the live issue and its latest comments. The user's inbox rules still apply, including showing comment text for approval before posting.\n2. **Sweeper is advisory.** Present its verdict as a proposal with its confidence. Never treat it as a decision.\n3. **Record outcomes only on explicit user decisions.** Use `record` only after the user explicitly decides, or after the user-approved GitHub action has succeeded. `apply` records automatically after its approved action. Never record outcomes in bulk from Sweeper proposals, and never run `apply --confirm` without that issue's explicit approval. Decisions: `accepted`, `rejected`, `deferred`, `closed`, `needs-info-sent`, `routed`, `fixing`, `fixed`, `duplicate` (with `--canonical`), `wont-fix`. Put the reason in `--note`.\n4. **Never edit `my-issues.json` directly.** The indexer owns it, and `record` is the only supported write.\n5. Issues not assigned to the user are not in the index. Fall back to GitHub for those.\n",{"name":5,"description":7},"main","60a489a99a476488554364272c1eae416077a4a5","my-work\u002Fskills\u002Fmy-issues",12,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-11 01:46:53",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add microsoft\u002Fvscode-team-kit --skill my-issues",{"tool":43,"command":44},"bunx","bunx skills add microsoft\u002Fvscode-team-kit --skill my-issues",{"tool":46,"command":47},"pnpm","pnpm dlx skills add microsoft\u002Fvscode-team-kit --skill my-issues","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Fmy-work\u002Fskills\u002Fmy-issues\u002FSKILL.md",true,[51,57,61,65,69,75],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"scripts\u002Fmy_issues.py","SCRIPT","脚本",60943,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Fmy-work\u002Fskills\u002Fmy-issues\u002Fscripts\u002Fmy_issues.py",{"path":58,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":59,"sourceHtmlUrl":60},"scripts\u002Fmy_work_config.py",3132,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Fmy-work\u002Fskills\u002Fmy-issues\u002Fscripts\u002Fmy_work_config.py",{"path":62,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":63,"sourceHtmlUrl":64},"scripts\u002Frefresh_my_issues.py",44853,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Fmy-work\u002Fskills\u002Fmy-issues\u002Fscripts\u002Frefresh_my_issues.py",{"path":66,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":67,"sourceHtmlUrl":68},"scripts\u002Fsweeper_source.py",9952,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Fmy-work\u002Fskills\u002Fmy-issues\u002Fscripts\u002Fsweeper_source.py",{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"triage-help.md","REFERENCE","参考文档",1213,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Fmy-work\u002Fskills\u002Fmy-issues\u002Ftriage-help.md",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"triage-principles.md",4780,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Fmy-work\u002Fskills\u002Fmy-issues\u002Ftriage-principles.md",[80,98,119,131,147,157],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":94,"publishedAt":23},"01M699YSSBWV52XX5646GGWH02","generate-test-video","Make a short narrated \"how to test\" or \"how to verify\" video for a VS Code test plan item (TPI), a fixed bug, or a few fixed bugs of one area: recorded in real VS Code Insiders in a throwaway profile, every step checked in the app, with captions, a zoom, flags that pause where something is wrong, a verdict slide and a recap. macOS. USE FOR: \"make a how-to-test video for TPI 342400\", \"a video to verify issue 341013\", \"how-to-verify video for bugs 339711 339712 339714\". DO NOT USE FOR: explaining a PR to someone who won't test it (use pr-studio:generate-video), plain screen recordings, editing an existing video.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Ftest-videos\u002Fskills\u002Fgenerate-test-video\u002FSKILL.md",[86,91],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":92,"categoryName":93,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000016","图像与多媒体",[95,96,97],"test","generate test video","macos",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":23},"01M699YRFQ79KY3QVQ1DWJ4CX4","session-timeline","Open a live timeline canvas for the current Copilot session. Use when asked to inspect session events, system prompts, reasoning, tool executions, or subagent activity in a session timeline.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Fsession-timeline\u002Fskills\u002Fsession-timeline\u002FSKILL.md",[],[105,106,107,108,109,110,22,111,112,113,114,115,116,117,118],"timeline","session timeline","session","prompts","live","use","events","tool","system","activity","subagent","open","reasoning","copilot",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":128,"publishedAt":23},"01M699YQ8Y2X7DB2H7FNX8FDVP","review-plan","Review an implementation plan produced by the Plan agent. It is CRITICAL to review plans before handing off to implementation — plans often have gaps, incorrect assumptions, or suboptimal sequencing that are cheaper to catch now than after coding. Use when the user asks to 'review the plan', 'check my plan', 'is this plan ready', or after the Plan agent produces a plan.md.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Freview-plan\u002Fskills\u002Freview-plan\u002FSKILL.md",[125],{"categoryNo":126,"categoryName":127,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000023","Skill与智能体开发",[129,130],"review plan","review",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":141,"publishedAt":23},"01M699YNCNK188DHTHQ11J8WQ5","review-areas","In-depth code review that fans out parallel subagents across review areas — CRITICAL after non-trivial development. USE FOR: \"in-depth review of a pull request\", \"code quality check or bug hunt\", \"review correctness, tests, security, performance and product areas\", \"review after any non-trivial development phase\". DO NOT USE FOR: \"plan a new implementation\", \"explain how existing code works\".","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Freview-areas\u002Fskills\u002Freview-areas\u002FSKILL.md",[137,140],{"categoryNo":138,"categoryName":139,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":126,"categoryName":127,"taxonomyType":89,"taxonomyTypeDesc":90},[130,142,143,144,145,146],"review areas","code quality","performance","security","code review",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":154,"publishedAt":23},"01M699YK1BS97EEHD4B2817JJ4","generate-video","Make the shortest narrated video that fully explains a GitHub pull request (at most 90 seconds, captions, diagrams chosen for the PR, and real footage of the app, before and after side by side, when the change is visible) in one white Microsoft look. USE FOR: \"\u002Fgenerate-video 12345\", \"make a video of this PR\", \"explain PR \u003Curl> in a video\", \"a video for my manager about this PR\". DO NOT USE FOR: a screen recording on its own (no PR to explain), editing existing videos, slide decks (use generate-presentation).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Fpr-studio\u002Fskills\u002Fgenerate-video\u002FSKILL.md",[153],{"categoryNo":92,"categoryName":93,"taxonomyType":89,"taxonomyTypeDesc":90},[155,156,9,21],"generate video","change",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":169,"publishedAt":23},"01M699YHC6Q7AEZCPGRJ7Y7AZC","generate-presentation","Make the shortest slide deck (a 16:9 PDF with speaker notes, at most 12 slides) that fully explains a GitHub pull request, in one white Microsoft look: one idea per slide, drawn as diagrams, with screenshots of the real app when the change is visible, every fact from the PR. USE FOR: \"\u002Fgenerate-presentation 12345\", \"make slides about this PR\", \"a deck for my manager on PR \u003Curl>\", \"present this pull request\". DO NOT USE FOR: editing PowerPoint files, videos (use generate-video), decks with no pull request behind them.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-team-kit\u002Fblob\u002Fmain\u002Fpr-studio\u002Fskills\u002Fgenerate-presentation\u002FSKILL.md",[163,166],{"categoryNo":164,"categoryName":165,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":167,"categoryName":168,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000003","演示文稿",[170,171,156,9,21,172],"generate presentation","PDF","screenshots"]