[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6999MPR3GZ1W61BMWC4X6WH":3,"skill-same:01M6999MPR3GZ1W61BMWC4X6WH":71},{"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":23,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6999MPR3GZ1W61BMWC4X6WH","chat-pet-sprite-creation",null,"Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable\u002FInsiders variants, or pet transitions under src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fchat\u002Fbrowser\u002Fwidget\u002Fmedia\u002FchatPet.","microsoft\u002Fvscode","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M6998NK2WED5M549DX06VBCH",195270,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fchat-pet-sprite-creation\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"PET","creation","chat","chat pet sprite creation","transitions","when","animations","variants","contrib","sheets","widget","Art","use","src","Media","browser","state","code","2026-11-10 10:12:30",false,"---\nname: chat-pet-sprite-creation\ndescription: Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable\u002FInsiders variants, or pet transitions under src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fchat\u002Fbrowser\u002Fwidget\u002Fmedia\u002FchatPet.\n---\n\n# Chat Pet Sprite Creation\n\nCreate pet sprites that feel like one continuous character rather than separate drawings. Start from the current pet body, preserve its visual anchor, and make every difference intentional.\n\n## Source of truth\n\n- Sprite art: `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fchat\u002Fbrowser\u002Fwidget\u002Fmedia\u002FchatPet\u002F`\n- Runtime states, dimensions, timing, and transitions: `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fchat\u002Fbrowser\u002Fwidget\u002FchatPetWidget.ts`\n- Eye geometry, facing, clipping, and motion CSS: `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fchat\u002Fbrowser\u002Fwidget\u002Fmedia\u002FchatPet.css`\n- Unit tests: `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fchat\u002Ftest\u002Fbrowser\u002Fwidget\u002FchatPetWidget.test.ts`\n\nRead the current implementation before drawing. Existing dimensions and timings may have changed since this skill was written.\n\n## PR precedence and lineage\n\nThis skill distills the complete pet PR history. When rules conflict, use this precedence:\n\n1. Current code and tests\n2. The newest relevant open PR\n3. Newer merged PRs\n4. Older historical behavior\n\nIn particular, animation cleanup PR #330399 supersedes the old revive-sign flow and several earlier sprite\u002Ftiming assumptions.\n\n| PR | Durable learning |\n|---|---|\n| #327063 | The pet is one semantic button; sprite canvases, images, eyes, and effects are visual-only and `aria-hidden`. Resolve asset URLs through `FileAccess`. |\n| #327412 | Model reactions as explicit states. Do not immediately repeat ordinary random reactions; sample rare transformations separately. |\n| #327588 | Double-buffer sprite images and swap only after the pending image loads. Never blank the active sprite while a new source is loading. |\n| #327696 | Stable\u002FInsiders is a typed, persisted appearance choice. Keep variant naming and geometry systematic. |\n| #327714 | Animated art is a horizontal sprite sheet plus a deliberate static reduced-motion PNG. Timing is runtime data, not image metadata. |\n| #328334 | Persistent behavior such as “on the run” belongs in service state. Multi-phase animations advance from completion signals, not guessed delays. |\n| #328480 | A drag release must not also trigger a click reaction. Gestures that share pointer events need explicit suppression\u002Fownership. |\n| #328530 | Waking consumes the interaction that woke the pet; it must not also trigger a random reaction. Reduced motion may skip the wake transition. |\n| #329121 | Coalesce gaze updates, pause sprite timers while the document is hidden, and resume from elapsed time rather than replaying missed frames. |\n| #329347 | Keep pixel-art pose changes in sprite frames and spatial motion in layout\u002FCSS\u002Fphysics. Complete falls from transition signals. |\n| #329729 | Face the interaction before starting a reaction. Give each transient state an explicit lifetime and use real completion events for chained phases. |\n| #329852 | Pointer and keyboard gestures need equivalent outcomes. Reduced motion preserves the state change while removing the travel animation. |\n| #329867 | Attention animations are bounded; clapping stops after the confirmation-attention window even if the confirmation remains pending. |\n| #330160 | Eyes are a composited runtime layer with tracking\u002Fblinking modes. Rapid facing changes can trigger a separate dizzy state. Wide art must respect live bounds. |\n| #330275 | Physics uses the body footprint, bounded frame steps, and explicit impact moments. Recompute geometry when layout changes during flight. |\n| #330399 | Latest animation contract: wide sleep\u002Fwake art, frame-aware blink composition, fixed-orientation decorations, and reverse despawn → forward respawn using one effect sheet. |\n\n## The logical pixel\n\nThe canonical art unit is one **logical pixel**:\n\n- `8×8` source pixels\n- `4×4` CSS pixels at the standard `96×96` source → `48×48` display scale\n\nCore silhouettes, facial features, props, and repeated details must use the same logical-pixel scale. Do not make a new object from smaller or larger blocks simply to fit more detail.\n\nEffects may deliberately subdivide the logical pixel—for example, small stars, bubbles, or curved motion—but the subdivision must:\n\n1. Serve a specific effect that cannot read on the core grid.\n2. Stay consistent throughout that effect.\n3. Never come from antialiasing or resampling.\n\nUse nearest-neighbor rendering only. Keep transparent backgrounds and hard pixel edges. Do not introduce blur, feathered alpha, color interpolation, or accidental off-grid scaling.\n\n## Start from a baseline\n\nNever redraw the pet body from memory.\n\n- Use the current **idle** sprite as the baseline for resting, pointer-driven, or playful states.\n- Use the current **rendering** sprite as the baseline for request\u002Fprocessing states.\n- Copy the complete body first, then alter only the parts required by the new state.\n\nThis preserves:\n\n- Body width and height\n- Bottom baseline\n- Antenna roots and spacing\n- Highlight and shadow ramps\n- Eye sockets\n- Collision\u002Finteraction footprint\n\nThe first and last key poses must transition cleanly to idle or rendering without a body-position, silhouette, baseline, or scale pop.\n\n## Canvas and anchoring\n\nThe default source canvas is `96×96`, or `12×12` logical pixels.\n\nUse a larger canvas only when content intentionally extends outside the canonical body box:\n\n- A terminal or button may need extra width.\n- A note, star, or bubble may need extra height.\n- The body must remain anchored exactly where it sits in the baseline sprite.\n\nDo not center the body inside a wider frame. Keep the body in the canonical `96×96` region and let the prop\u002Feffect overhang. Declare every nonstandard source dimension in `chatPetWidget.ts` and update wide-sprite boundary handling.\n\nThe runtime collision and movement box belongs to the pet body, not to a decorative overhang.\n\n## Eyes\n\nThe standard open eye is **`1×2` logical pixels**:\n\n- `8×16` source pixels\n- `4×8` CSS pixels\n\nUse a different eye shape only when the state communicates a special expression, such as sleep, dizzy, love, worry, or impact.\n\n### DOM eye layer\n\nThe DOM eye layer has two independent modes:\n\n- **Tracking** supplies gaze, facing, blink, and drag expressions.\n- **Blinking** can temporarily show DOM eyes for a non-tracking state and can vary by sprite frame.\n\nStates that use runtime gaze must use eye-less `*-tracking-96` assets. States that use DOM blinking, such as typing, button press, or love in PR #330399, must also leave the corresponding pupil area available for the overlay.\n\nWhen adding or changing a DOM-eye state:\n\n1. Keep the sprite eye sockets empty.\n2. Add cursor behavior to `doesChatPetStateTrackCursor` when appropriate.\n3. Add blink behavior to `doesChatPetStateBlink(state, frameIndex)` when appropriate.\n4. Verify the tall-eye blink, state-specific eye height, and pointer offsets in both facing directions.\n5. Verify frames that intentionally stop blinking, such as a held terminal pose.\n\nNever combine baked pupils with the runtime eye overlay.\n\n### Baked-eye states\n\nStates with a fixed expression should bake the eyes into the art and opt out of cursor tracking. Preserve the standard eye position unless the expression intentionally changes it.\n\n## Stable and Insiders parity\n\nStable and Insiders are palette variants of the same animation.\n\nThey must have identical:\n\n- Canvas dimensions\n- Frame count and ordering\n- Alpha mask and geometry\n- Body anchor and overhang\n- Static fallback pose\n- Timing and iteration behavior\n\nCreate one geometry master and apply the two established palettes. Do not redraw variants independently.\n\nReview the two variants side by side. Any shape difference is a bug unless the product explicitly requires it.\n\n## Facing and mirroring\n\nAuthor one canonical facing direction and let the runtime mirror it for the other direction.\n\nTest both directions because mirroring also changes where wide sprites overhang. Keep enough room for boundary correction near the left and right edges.\n\nDecorations that must retain their screen orientation—such as text, musical notation, or directional symbols—must not be baked into a layer that the runtime mirrors. Model them as fixed-orientation decorations or render them separately.\n\n## Static asset and sprite sheet\n\nEach animated state needs both variants of:\n\n- A static PNG for reduced motion: `buddy-\u003Cstate>-\u003Cvariant>-\u003Cheight>.png`\n- A horizontal sprite sheet: `buddy-\u003Cstate>-\u003Cvariant>-\u003Cheight>.spritesheet.png`\n\nThe sprite sheet contract is:\n\n```text\nsheet width = frame width × frame count\nsheet height = frame height\n```\n\nEvery frame uses the same rectangle. Never shift frame boundaries or add per-frame padding.\n\nChoose a meaningful static pose that communicates the state without motion. Do not assume the first animation frame is automatically the best reduced-motion fallback.\n\n## Layered accessories\n\nWearable accessories use a body-owned attachment rig and one palette-independent atlas per appearance under `media\u002FchatPet\u002Faccessories\u002F`. Do not export copies for individual runtime states or frames. Body animation metadata owns attachment movement; an accessory atlas only contains the few canonical shapes needed when the body geometry changes.\n\nThe default atlas is `256×192`, divided into `64×64` cells. A hat whose supplied silhouette genuinely needs the full 12-logical-pixel body width may declare `atlasCellSize: 96` and use a `384×288` atlas with `96×96` cells. Do not choose the wider tier merely to add detail; both tiers still use the same whole `8×8` logical pixels.\n\n```text\ncolumns: upright | sleeping | impact | splat\nrow 0:   head back layers\nrow 1:   head front layers\nrow 2:   right-eye front layers\n```\n\nAn appearance may leave any cell transparent. For example, a plain hat leaves the eye row empty, while a combined Top Hat & Monocle appearance uses both head rows and the eye row. The airborne rig pose reuses the upright column. Add another canonical column only when an existing pose plus body-owned translation cannot preserve the intended silhouette.\n\nAttachment tracks live in `chatPetAccessoryRig.ts`. Each track uses compressed frame spans with a canonical pose and independent head\u002Fright-eye anchors. A slot is omitted while a body-authored expression, prop, or complete silhouette replacement owns the same geometry, such as dizzy eyes, sunglasses, or the rare icon transformation. When frames inside one sheet bake different facing directions, the track marks those frames so the head accessory mirrors with the body before the whole pet's outer facing transform is applied. Update the body-owned track only when body geometry changes. Adding an ordinary accessory must not require editing tracks or renderer code.\n\nHead-slot anchors include a one-logical-pixel wear offset so hats overlap the top of the head rather than resting on its silhouette. The love animation suppresses head accessories because its transformed head\u002Fantenna silhouette is the reaction. Treat slot visibility and fit as body-owned behavior, not per-hat exceptions.\n\nAppearances that tuck the antennae under a larger hat opt into `coversAntennae`. The compositor uses body-owned occlusion bounds before drawing the hat front, so the behavior follows animation tracks and mirroring without painting body-colored cover pixels into each atlas.\n\nDirectional head accessories are authored for the canonical right-facing body and mirror with the complete pet canvas. A hat with directional structure should stay visually balanced over the head while expressing facing through a restrained one-logical-pixel cue in its brim, visor, lean, nose guard, or other asymmetric detail; do not shift the whole silhouette far off-center. Make asymmetric parts read correctly after mirroring. Identity-bound eye accessories may opt out of mirroring and use a direction-specific eye anchor so they remain on the same eye; the Top Hat & Monocle is the reference. Fixed-eye anchors must include the body origin shift for wide frames (`frameWidth - 96`). Review every appearance in both directions with the facing fixture.\n\nStatic reduced-motion art may represent a later frame of its animated sheet. Keep `getChatPetReducedMotionRigFrame()` aligned with the representative body frame; do not assume rig frame zero merely because the static PNG has one image frame.\n\nAuthor every wearable part on the same `8×8` logical-pixel grid as the body. Brims, crowns, bands, rims, chains, highlights, and shadows must all be composed from whole aligned logical pixels; do not use diagonal polygons or source-pixel stair steps to imply curves. The small-effect exception does not apply to wearable accessories. Use the current Stable body sheets as geometry guides and validate that every alpha value is fully transparent or fully opaque. The runtime mirrors layers with the body; fixed-orientation body decorations are restored without erasing accessory pixels.\n\nWhen changing the accessory source at runtime, keep the current composite visible until the replacement image loads and passes exact dimension validation. Redraw the current frame without restarting the body animation. A failed or malformed accessory source falls back to the body alone and must not repeatedly retry.\n\n## Animation design\n\nAnimate key poses, not noise.\n\n- The trigger should be readable.\n- The action should have a clear apex or strongest pose.\n- The result should be readable before returning to the baseline.\n- Holds are useful; duplicate motion is not.\n\nFrame duration is part of the art. Define it in the matching `*_FRAME_DURATIONS` array in `chatPetWidget.ts`; do not encode or infer timing from the PNG.\n\nKeep the transient-state duration consistent with the intended loops or one-shot playback. Explicitly choose whether the sheet:\n\n- Plays once and holds its final pose\n- Loops until the transient state ends\n- Plays in reverse as part of another transition\n\n### Reversible effects\n\nIf one sheet is reused in reverse, as with respawn → despawn:\n\n- Design both endpoints to work as starts and finishes.\n- Check the effect in both directions.\n- Avoid one-way visual cues that become nonsensical backward.\n- Verify the reverse effect at its actual destination, not only on a neutral canvas.\n\nPR #330399 is the reference pattern: the respawn burst plays backward to despawn at the bottom, then forward to respawn at the top. The old revive-sign interstitial is superseded.\n\n### Separate pose animation from spatial motion\n\nUse sprite frames for changes to the pet or prop silhouette. Use CSS transforms or the physics loop for:\n\n- Translation\n- Rotation\n- Enter\u002Fexit motion\n- Drag resistance\n- Search reveal\u002Fhide\n- Falls, throws, rebounds, and impacts\n\nDo not redraw every translated\u002Frotated pose into the sheet. Conversely, do not use a CSS transform to fake a body deformation that should be readable in the pixel art.\n\nAdvance multi-phase behavior from deterministic completion signals:\n\n- Sprite completion for one-shot sheets\n- `animationend` for CSS keyframes\n- `transitionend`\u002F`transitioncancel` for falls\n- Physics settlement for throws\n\nDo not guess a completion time with an unrelated timeout.\n\n### Frame scheduling and restart behavior\n\nSprite timing uses elapsed-time scheduling at frame boundaries, not a display-refresh polling loop. A late callback recalculates the correct frame and shortens the next delay.\n\n- Pause frame timers while the document is hidden.\n- On visibility return, recompute from elapsed time.\n- Finite animations hold their terminal frame.\n- Reverse playback must use the reversed frame durations, not only reversed frame indices.\n- Restart a loaded state without forcing a redundant image fetch.\n- Force a style flush before re-adding a CSS animation class when a blink or motion must restart.\n\n## Environment and layering\n\nReview the sprite in the same environment where it runs:\n\n- Platform\u002Finput edge\n- Transparent background\n- Left and right workbench boundaries\n- Platform clipping and occlusion\n- Drag, fall, throw, and respawn motion\n- Any speech bubble or fixed decoration\n\nPixels intended to pass behind the platform must be clipped or layered behind it. Do not leave body\u002Feffect pixels visible below an occluding platform.\n\nMovement should preserve the body anchor until physics intentionally moves the whole pet. Decorative frame size must not change the physics target.\n\n## State and gesture ownership\n\nThe rendered state has a deliberate priority. Busy\u002Ftask states must not be accidentally hidden by decorative reactions. Preserve the current order in `getChatPetBaseState` and the transient-state guards in `getChatPetRenderedState`.\n\nInteraction rules:\n\n- Dragging owns the pointer until release and suppresses the following click.\n- A wake interaction wakes only.\n- Yapping or other idle-only reactions yield to non-idle base states.\n- Keyboard interaction is disabled while the pet is dead, pointer-controlled, or airborne.\n- Dizzy consumes the direction-change gesture that triggered it.\n- Confirmation clapping is an attention cue, not a permanent pending-state animation.\n\nRare interactions should be sampled independently from the ordinary non-repeating pool so adding a common reaction does not silently change an easter egg's probability.\n\n## Rendering and performance\n\nKeep the current rendering architecture:\n\n- Two sprite elements provide load-time double buffering.\n- Compare an image's original source with `getAttribute('src')`; `.src` may normalize VS Code resource URLs.\n- Size the canvas at source-native frame dimensions and the CSS box at display dimensions.\n- Keep `imageSmoothingEnabled = false` and `image-rendering: pixelated`.\n- Cache resolved sprite source descriptors per variant.\n- Coalesce pointer gaze updates to one animation frame.\n- Use `requestAnimationFrame` for physics, but cap integration steps to prevent tunneling after a slow frame.\n- Re-read throw geometry when layout changes during flight.\n\n## Runtime wiring\n\nWhen adding a state, update every applicable surface:\n\n1. Add the state to `ChatPetState`.\n2. Map the filename in `getChatPetSpriteName`.\n3. Add frame durations in `getChatPetFrameDurations`.\n4. Declare nonstandard source width\u002Fheight constants.\n5. Register animated and reduced-motion sources in `getSpriteSources`.\n6. Choose cursor-tracking and frame-aware blinking behavior.\n7. Choose one-shot, loop, reverse, or static iteration behavior.\n8. Add the transient-state duration and trigger.\n9. Add deterministic completion transitions for multi-phase states.\n10. Add facing, overhang, fixed-decoration, clipping, or CSS treatment.\n11. Add a localized ARIA status announcement for user-triggered interactions.\n12. Update accessible help when the gesture is discoverable\u002Fuseful.\n13. Update focused unit tests.\n\nDo not add art without completing the runtime contract.\n\nKeep the visuals silent: images, canvases, eyes, and effects use empty alt text and `aria-hidden`. The button owns the accessible label, focusability, and localized `status()` announcements. Hidden, dead, or non-interactive states must leave the tab order.\n\n## Validation checklist\n\n### Art\n\n- [ ] Core art uses the same `8×8` source-pixel logical unit.\n- [ ] Body derives from current idle or rendering art.\n- [ ] Body baseline and canonical anchor stay fixed.\n- [ ] Standard eyes are `1×2` logical pixels.\n- [ ] DOM-eye sprites contain no baked pupils under the overlay.\n- [ ] Stable and Insiders geometry\u002Falpha masks match.\n- [ ] Transparent regions stay fully transparent.\n- [ ] No interpolation or antialiasing appears.\n\n### Animation\n\n- [ ] First and last poses transition without popping.\n- [ ] Static reduced-motion pose communicates the state.\n- [ ] Frame dimensions and count match both variants.\n- [ ] Timing arrays match the intended holds and loops.\n- [ ] Reverse playback reads correctly when used.\n- [ ] Both facing directions read correctly.\n- [ ] Multi-phase transitions use completion signals, not guessed delays.\n- [ ] The static fallback communicates the same outcome under reduced motion.\n\n### Integration\n\n- [ ] Wide\u002Ftall source constants and boundary logic are updated.\n- [ ] Platform clipping and layering are correct.\n- [ ] Interaction\u002Fcollision geometry remains body-based.\n- [ ] Drag\u002Fclick, wake\u002Fclick, and pointer\u002Fkeyboard gesture ownership is unambiguous.\n- [ ] User-triggered behavior has localized screen-reader output.\n- [ ] Visual children are `aria-hidden`; the button owns semantics and tab order.\n- [ ] `ChatPetWidget` tests cover state names, exact timings, geometry, state priority, and reduced motion.\n- [ ] Every runtime state maps to the intended body-owned attachment track.\n- [ ] The atlas matches its declared compact (`256×192`) or wide (`384×288`) cell tier and the documented column\u002Frow contract.\n- [ ] Every accessory color\u002Falpha block is aligned to the `8×8` logical-pixel grid.\n- [ ] Atlas artwork stays within the body canvas after applying the documented pivots and anchors.\n- [ ] Head accessories overlap the head by the shared wear offset and are absent during love.\n- [ ] Asymmetric artwork reads correctly in both canonical and mirrored facing directions.\n- [ ] Adding the accessory requires no state-specific exports or renderer changes.\n- [ ] Reduced-motion sources use the rig frame represented by their static body art.\n- [ ] Body-authored eye expressions and props suppress incompatible eye-slot accessories.\n- [ ] Switching accessories preserves the active body frame and animation timer.\n- [ ] Accessory load failure leaves the body visible and does not retry continuously.\n\nUse the `chat\u002FchatPetAccessoryRig\u002FchatPetAccessoryRig\u002FCriticalPoses` component fixture to review critical animated and reduced-motion poses, and `AllAccessoriesFacing` to compare every appearance in both directions.\n\nRun the focused unit tests using the repository's `unit-tests` skill. At minimum, run the `ChatPetWidget` test suite.\n\nPrefer exporting pure helpers for timing, geometry, random selection, and state precedence, then test them directly. Use fake timers for scheduler behavior. Assert exact frame-duration arrays so art and runtime timing cannot drift independently.\n\n## Optional public-preview update\n\nThe public showcase lives in the sibling `vscode-chat-pet` repository. Use its `update-pet-previews` skill after production sprites are final.\n\nWhen replacing an existing APNG, prefer a new versioned filename in the README so GitHub and browser caches cannot keep showing the previous animation.\n","# Chat Pet Sprite Creation\n\nCreate pet sprites that feel like one continuous character rather than separate drawings. Start from the current pet body, preserve its visual anchor, and make every difference intentional.\n\n## Source of truth\n\n- Sprite art: `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fchat\u002Fbrowser\u002Fwidget\u002Fmedia\u002FchatPet\u002F`\n- Runtime states, dimensions, timing, and transitions: `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fchat\u002Fbrowser\u002Fwidget\u002FchatPetWidget.ts`\n- Eye geometry, facing, clipping, and motion CSS: `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fchat\u002Fbrowser\u002Fwidget\u002Fmedia\u002FchatPet.css`\n- Unit tests: `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fchat\u002Ftest\u002Fbrowser\u002Fwidget\u002FchatPetWidget.test.ts`\n\nRead the current implementation before drawing. Existing dimensions and timings may have changed since this skill was written.\n\n## PR precedence and lineage\n\nThis skill distills the complete pet PR history. When rules conflict, use this precedence:\n\n1. Current code and tests\n2. The newest relevant open PR\n3. Newer merged PRs\n4. Older historical behavior\n\nIn particular, animation cleanup PR #330399 supersedes the old revive-sign flow and several earlier sprite\u002Ftiming assumptions.\n\n| PR | Durable learning |\n|---|---|\n| #327063 | The pet is one semantic button; sprite canvases, images, eyes, and effects are visual-only and `aria-hidden`. Resolve asset URLs through `FileAccess`. |\n| #327412 | Model reactions as explicit states. Do not immediately repeat ordinary random reactions; sample rare transformations separately. |\n| #327588 | Double-buffer sprite images and swap only after the pending image loads. Never blank the active sprite while a new source is loading. |\n| #327696 | Stable\u002FInsiders is a typed, persisted appearance choice. Keep variant naming and geometry systematic. |\n| #327714 | Animated art is a horizontal sprite sheet plus a deliberate static reduced-motion PNG. Timing is runtime data, not image metadata. |\n| #328334 | Persistent behavior such as “on the run” belongs in service state. Multi-phase animations advance from completion signals, not guessed delays. |\n| #328480 | A drag release must not also trigger a click reaction. Gestures that share pointer events need explicit suppression\u002Fownership. |\n| #328530 | Waking consumes the interaction that woke the pet; it must not also trigger a random reaction. Reduced motion may skip the wake transition. |\n| #329121 | Coalesce gaze updates, pause sprite timers while the document is hidden, and resume from elapsed time rather than replaying missed frames. |\n| #329347 | Keep pixel-art pose changes in sprite frames and spatial motion in layout\u002FCSS\u002Fphysics. Complete falls from transition signals. |\n| #329729 | Face the interaction before starting a reaction. Give each transient state an explicit lifetime and use real completion events for chained phases. |\n| #329852 | Pointer and keyboard gestures need equivalent outcomes. Reduced motion preserves the state change while removing the travel animation. |\n| #329867 | Attention animations are bounded; clapping stops after the confirmation-attention window even if the confirmation remains pending. |\n| #330160 | Eyes are a composited runtime layer with tracking\u002Fblinking modes. Rapid facing changes can trigger a separate dizzy state. Wide art must respect live bounds. |\n| #330275 | Physics uses the body footprint, bounded frame steps, and explicit impact moments. Recompute geometry when layout changes during flight. |\n| #330399 | Latest animation contract: wide sleep\u002Fwake art, frame-aware blink composition, fixed-orientation decorations, and reverse despawn → forward respawn using one effect sheet. |\n\n## The logical pixel\n\nThe canonical art unit is one **logical pixel**:\n\n- `8×8` source pixels\n- `4×4` CSS pixels at the standard `96×96` source → `48×48` display scale\n\nCore silhouettes, facial features, props, and repeated details must use the same logical-pixel scale. Do not make a new object from smaller or larger blocks simply to fit more detail.\n\nEffects may deliberately subdivide the logical pixel—for example, small stars, bubbles, or curved motion—but the subdivision must:\n\n1. Serve a specific effect that cannot read on the core grid.\n2. Stay consistent throughout that effect.\n3. Never come from antialiasing or resampling.\n\nUse nearest-neighbor rendering only. Keep transparent backgrounds and hard pixel edges. Do not introduce blur, feathered alpha, color interpolation, or accidental off-grid scaling.\n\n## Start from a baseline\n\nNever redraw the pet body from memory.\n\n- Use the current **idle** sprite as the baseline for resting, pointer-driven, or playful states.\n- Use the current **rendering** sprite as the baseline for request\u002Fprocessing states.\n- Copy the complete body first, then alter only the parts required by the new state.\n\nThis preserves:\n\n- Body width and height\n- Bottom baseline\n- Antenna roots and spacing\n- Highlight and shadow ramps\n- Eye sockets\n- Collision\u002Finteraction footprint\n\nThe first and last key poses must transition cleanly to idle or rendering without a body-position, silhouette, baseline, or scale pop.\n\n## Canvas and anchoring\n\nThe default source canvas is `96×96`, or `12×12` logical pixels.\n\nUse a larger canvas only when content intentionally extends outside the canonical body box:\n\n- A terminal or button may need extra width.\n- A note, star, or bubble may need extra height.\n- The body must remain anchored exactly where it sits in the baseline sprite.\n\nDo not center the body inside a wider frame. Keep the body in the canonical `96×96` region and let the prop\u002Feffect overhang. Declare every nonstandard source dimension in `chatPetWidget.ts` and update wide-sprite boundary handling.\n\nThe runtime collision and movement box belongs to the pet body, not to a decorative overhang.\n\n## Eyes\n\nThe standard open eye is **`1×2` logical pixels**:\n\n- `8×16` source pixels\n- `4×8` CSS pixels\n\nUse a different eye shape only when the state communicates a special expression, such as sleep, dizzy, love, worry, or impact.\n\n### DOM eye layer\n\nThe DOM eye layer has two independent modes:\n\n- **Tracking** supplies gaze, facing, blink, and drag expressions.\n- **Blinking** can temporarily show DOM eyes for a non-tracking state and can vary by sprite frame.\n\nStates that use runtime gaze must use eye-less `*-tracking-96` assets. States that use DOM blinking, such as typing, button press, or love in PR #330399, must also leave the corresponding pupil area available for the overlay.\n\nWhen adding or changing a DOM-eye state:\n\n1. Keep the sprite eye sockets empty.\n2. Add cursor behavior to `doesChatPetStateTrackCursor` when appropriate.\n3. Add blink behavior to `doesChatPetStateBlink(state, frameIndex)` when appropriate.\n4. Verify the tall-eye blink, state-specific eye height, and pointer offsets in both facing directions.\n5. Verify frames that intentionally stop blinking, such as a held terminal pose.\n\nNever combine baked pupils with the runtime eye overlay.\n\n### Baked-eye states\n\nStates with a fixed expression should bake the eyes into the art and opt out of cursor tracking. Preserve the standard eye position unless the expression intentionally changes it.\n\n## Stable and Insiders parity\n\nStable and Insiders are palette variants of the same animation.\n\nThey must have identical:\n\n- Canvas dimensions\n- Frame count and ordering\n- Alpha mask and geometry\n- Body anchor and overhang\n- Static fallback pose\n- Timing and iteration behavior\n\nCreate one geometry master and apply the two established palettes. Do not redraw variants independently.\n\nReview the two variants side by side. Any shape difference is a bug unless the product explicitly requires it.\n\n## Facing and mirroring\n\nAuthor one canonical facing direction and let the runtime mirror it for the other direction.\n\nTest both directions because mirroring also changes where wide sprites overhang. Keep enough room for boundary correction near the left and right edges.\n\nDecorations that must retain their screen orientation—such as text, musical notation, or directional symbols—must not be baked into a layer that the runtime mirrors. Model them as fixed-orientation decorations or render them separately.\n\n## Static asset and sprite sheet\n\nEach animated state needs both variants of:\n\n- A static PNG for reduced motion: `buddy-\u003Cstate>-\u003Cvariant>-\u003Cheight>.png`\n- A horizontal sprite sheet: `buddy-\u003Cstate>-\u003Cvariant>-\u003Cheight>.spritesheet.png`\n\nThe sprite sheet contract is:\n\n```text\nsheet width = frame width × frame count\nsheet height = frame height\n```\n\nEvery frame uses the same rectangle. Never shift frame boundaries or add per-frame padding.\n\nChoose a meaningful static pose that communicates the state without motion. Do not assume the first animation frame is automatically the best reduced-motion fallback.\n\n## Layered accessories\n\nWearable accessories use a body-owned attachment rig and one palette-independent atlas per appearance under `media\u002FchatPet\u002Faccessories\u002F`. Do not export copies for individual runtime states or frames. Body animation metadata owns attachment movement; an accessory atlas only contains the few canonical shapes needed when the body geometry changes.\n\nThe default atlas is `256×192`, divided into `64×64` cells. A hat whose supplied silhouette genuinely needs the full 12-logical-pixel body width may declare `atlasCellSize: 96` and use a `384×288` atlas with `96×96` cells. Do not choose the wider tier merely to add detail; both tiers still use the same whole `8×8` logical pixels.\n\n```text\ncolumns: upright | sleeping | impact | splat\nrow 0:   head back layers\nrow 1:   head front layers\nrow 2:   right-eye front layers\n```\n\nAn appearance may leave any cell transparent. For example, a plain hat leaves the eye row empty, while a combined Top Hat & Monocle appearance uses both head rows and the eye row. The airborne rig pose reuses the upright column. Add another canonical column only when an existing pose plus body-owned translation cannot preserve the intended silhouette.\n\nAttachment tracks live in `chatPetAccessoryRig.ts`. Each track uses compressed frame spans with a canonical pose and independent head\u002Fright-eye anchors. A slot is omitted while a body-authored expression, prop, or complete silhouette replacement owns the same geometry, such as dizzy eyes, sunglasses, or the rare icon transformation. When frames inside one sheet bake different facing directions, the track marks those frames so the head accessory mirrors with the body before the whole pet's outer facing transform is applied. Update the body-owned track only when body geometry changes. Adding an ordinary accessory must not require editing tracks or renderer code.\n\nHead-slot anchors include a one-logical-pixel wear offset so hats overlap the top of the head rather than resting on its silhouette. The love animation suppresses head accessories because its transformed head\u002Fantenna silhouette is the reaction. Treat slot visibility and fit as body-owned behavior, not per-hat exceptions.\n\nAppearances that tuck the antennae under a larger hat opt into `coversAntennae`. The compositor uses body-owned occlusion bounds before drawing the hat front, so the behavior follows animation tracks and mirroring without painting body-colored cover pixels into each atlas.\n\nDirectional head accessories are authored for the canonical right-facing body and mirror with the complete pet canvas. A hat with directional structure should stay visually balanced over the head while expressing facing through a restrained one-logical-pixel cue in its brim, visor, lean, nose guard, or other asymmetric detail; do not shift the whole silhouette far off-center. Make asymmetric parts read correctly after mirroring. Identity-bound eye accessories may opt out of mirroring and use a direction-specific eye anchor so they remain on the same eye; the Top Hat & Monocle is the reference. Fixed-eye anchors must include the body origin shift for wide frames (`frameWidth - 96`). Review every appearance in both directions with the facing fixture.\n\nStatic reduced-motion art may represent a later frame of its animated sheet. Keep `getChatPetReducedMotionRigFrame()` aligned with the representative body frame; do not assume rig frame zero merely because the static PNG has one image frame.\n\nAuthor every wearable part on the same `8×8` logical-pixel grid as the body. Brims, crowns, bands, rims, chains, highlights, and shadows must all be composed from whole aligned logical pixels; do not use diagonal polygons or source-pixel stair steps to imply curves. The small-effect exception does not apply to wearable accessories. Use the current Stable body sheets as geometry guides and validate that every alpha value is fully transparent or fully opaque. The runtime mirrors layers with the body; fixed-orientation body decorations are restored without erasing accessory pixels.\n\nWhen changing the accessory source at runtime, keep the current composite visible until the replacement image loads and passes exact dimension validation. Redraw the current frame without restarting the body animation. A failed or malformed accessory source falls back to the body alone and must not repeatedly retry.\n\n## Animation design\n\nAnimate key poses, not noise.\n\n- The trigger should be readable.\n- The action should have a clear apex or strongest pose.\n- The result should be readable before returning to the baseline.\n- Holds are useful; duplicate motion is not.\n\nFrame duration is part of the art. Define it in the matching `*_FRAME_DURATIONS` array in `chatPetWidget.ts`; do not encode or infer timing from the PNG.\n\nKeep the transient-state duration consistent with the intended loops or one-shot playback. Explicitly choose whether the sheet:\n\n- Plays once and holds its final pose\n- Loops until the transient state ends\n- Plays in reverse as part of another transition\n\n### Reversible effects\n\nIf one sheet is reused in reverse, as with respawn → despawn:\n\n- Design both endpoints to work as starts and finishes.\n- Check the effect in both directions.\n- Avoid one-way visual cues that become nonsensical backward.\n- Verify the reverse effect at its actual destination, not only on a neutral canvas.\n\nPR #330399 is the reference pattern: the respawn burst plays backward to despawn at the bottom, then forward to respawn at the top. The old revive-sign interstitial is superseded.\n\n### Separate pose animation from spatial motion\n\nUse sprite frames for changes to the pet or prop silhouette. Use CSS transforms or the physics loop for:\n\n- Translation\n- Rotation\n- Enter\u002Fexit motion\n- Drag resistance\n- Search reveal\u002Fhide\n- Falls, throws, rebounds, and impacts\n\nDo not redraw every translated\u002Frotated pose into the sheet. Conversely, do not use a CSS transform to fake a body deformation that should be readable in the pixel art.\n\nAdvance multi-phase behavior from deterministic completion signals:\n\n- Sprite completion for one-shot sheets\n- `animationend` for CSS keyframes\n- `transitionend`\u002F`transitioncancel` for falls\n- Physics settlement for throws\n\nDo not guess a completion time with an unrelated timeout.\n\n### Frame scheduling and restart behavior\n\nSprite timing uses elapsed-time scheduling at frame boundaries, not a display-refresh polling loop. A late callback recalculates the correct frame and shortens the next delay.\n\n- Pause frame timers while the document is hidden.\n- On visibility return, recompute from elapsed time.\n- Finite animations hold their terminal frame.\n- Reverse playback must use the reversed frame durations, not only reversed frame indices.\n- Restart a loaded state without forcing a redundant image fetch.\n- Force a style flush before re-adding a CSS animation class when a blink or motion must restart.\n\n## Environment and layering\n\nReview the sprite in the same environment where it runs:\n\n- Platform\u002Finput edge\n- Transparent background\n- Left and right workbench boundaries\n- Platform clipping and occlusion\n- Drag, fall, throw, and respawn motion\n- Any speech bubble or fixed decoration\n\nPixels intended to pass behind the platform must be clipped or layered behind it. Do not leave body\u002Feffect pixels visible below an occluding platform.\n\nMovement should preserve the body anchor until physics intentionally moves the whole pet. Decorative frame size must not change the physics target.\n\n## State and gesture ownership\n\nThe rendered state has a deliberate priority. Busy\u002Ftask states must not be accidentally hidden by decorative reactions. Preserve the current order in `getChatPetBaseState` and the transient-state guards in `getChatPetRenderedState`.\n\nInteraction rules:\n\n- Dragging owns the pointer until release and suppresses the following click.\n- A wake interaction wakes only.\n- Yapping or other idle-only reactions yield to non-idle base states.\n- Keyboard interaction is disabled while the pet is dead, pointer-controlled, or airborne.\n- Dizzy consumes the direction-change gesture that triggered it.\n- Confirmation clapping is an attention cue, not a permanent pending-state animation.\n\nRare interactions should be sampled independently from the ordinary non-repeating pool so adding a common reaction does not silently change an easter egg's probability.\n\n## Rendering and performance\n\nKeep the current rendering architecture:\n\n- Two sprite elements provide load-time double buffering.\n- Compare an image's original source with `getAttribute('src')`; `.src` may normalize VS Code resource URLs.\n- Size the canvas at source-native frame dimensions and the CSS box at display dimensions.\n- Keep `imageSmoothingEnabled = false` and `image-rendering: pixelated`.\n- Cache resolved sprite source descriptors per variant.\n- Coalesce pointer gaze updates to one animation frame.\n- Use `requestAnimationFrame` for physics, but cap integration steps to prevent tunneling after a slow frame.\n- Re-read throw geometry when layout changes during flight.\n\n## Runtime wiring\n\nWhen adding a state, update every applicable surface:\n\n1. Add the state to `ChatPetState`.\n2. Map the filename in `getChatPetSpriteName`.\n3. Add frame durations in `getChatPetFrameDurations`.\n4. Declare nonstandard source width\u002Fheight constants.\n5. Register animated and reduced-motion sources in `getSpriteSources`.\n6. Choose cursor-tracking and frame-aware blinking behavior.\n7. Choose one-shot, loop, reverse, or static iteration behavior.\n8. Add the transient-state duration and trigger.\n9. Add deterministic completion transitions for multi-phase states.\n10. Add facing, overhang, fixed-decoration, clipping, or CSS treatment.\n11. Add a localized ARIA status announcement for user-triggered interactions.\n12. Update accessible help when the gesture is discoverable\u002Fuseful.\n13. Update focused unit tests.\n\nDo not add art without completing the runtime contract.\n\nKeep the visuals silent: images, canvases, eyes, and effects use empty alt text and `aria-hidden`. The button owns the accessible label, focusability, and localized `status()` announcements. Hidden, dead, or non-interactive states must leave the tab order.\n\n## Validation checklist\n\n### Art\n\n- [ ] Core art uses the same `8×8` source-pixel logical unit.\n- [ ] Body derives from current idle or rendering art.\n- [ ] Body baseline and canonical anchor stay fixed.\n- [ ] Standard eyes are `1×2` logical pixels.\n- [ ] DOM-eye sprites contain no baked pupils under the overlay.\n- [ ] Stable and Insiders geometry\u002Falpha masks match.\n- [ ] Transparent regions stay fully transparent.\n- [ ] No interpolation or antialiasing appears.\n\n### Animation\n\n- [ ] First and last poses transition without popping.\n- [ ] Static reduced-motion pose communicates the state.\n- [ ] Frame dimensions and count match both variants.\n- [ ] Timing arrays match the intended holds and loops.\n- [ ] Reverse playback reads correctly when used.\n- [ ] Both facing directions read correctly.\n- [ ] Multi-phase transitions use completion signals, not guessed delays.\n- [ ] The static fallback communicates the same outcome under reduced motion.\n\n### Integration\n\n- [ ] Wide\u002Ftall source constants and boundary logic are updated.\n- [ ] Platform clipping and layering are correct.\n- [ ] Interaction\u002Fcollision geometry remains body-based.\n- [ ] Drag\u002Fclick, wake\u002Fclick, and pointer\u002Fkeyboard gesture ownership is unambiguous.\n- [ ] User-triggered behavior has localized screen-reader output.\n- [ ] Visual children are `aria-hidden`; the button owns semantics and tab order.\n- [ ] `ChatPetWidget` tests cover state names, exact timings, geometry, state priority, and reduced motion.\n- [ ] Every runtime state maps to the intended body-owned attachment track.\n- [ ] The atlas matches its declared compact (`256×192`) or wide (`384×288`) cell tier and the documented column\u002Frow contract.\n- [ ] Every accessory color\u002Falpha block is aligned to the `8×8` logical-pixel grid.\n- [ ] Atlas artwork stays within the body canvas after applying the documented pivots and anchors.\n- [ ] Head accessories overlap the head by the shared wear offset and are absent during love.\n- [ ] Asymmetric artwork reads correctly in both canonical and mirrored facing directions.\n- [ ] Adding the accessory requires no state-specific exports or renderer changes.\n- [ ] Reduced-motion sources use the rig frame represented by their static body art.\n- [ ] Body-authored eye expressions and props suppress incompatible eye-slot accessories.\n- [ ] Switching accessories preserves the active body frame and animation timer.\n- [ ] Accessory load failure leaves the body visible and does not retry continuously.\n\nUse the `chat\u002FchatPetAccessoryRig\u002FchatPetAccessoryRig\u002FCriticalPoses` component fixture to review critical animated and reduced-motion poses, and `AllAccessoriesFacing` to compare every appearance in both directions.\n\nRun the focused unit tests using the repository's `unit-tests` skill. At minimum, run the `ChatPetWidget` test suite.\n\nPrefer exporting pure helpers for timing, geometry, random selection, and state precedence, then test them directly. Use fake timers for scheduler behavior. Assert exact frame-duration arrays so art and runtime timing cannot drift independently.\n\n## Optional public-preview update\n\nThe public showcase lives in the sibling `vscode-chat-pet` repository. Use its `update-pet-previews` skill after production sprites are final.\n\nWhen replacing an existing APNG, prefer a new versioned filename in the README so GitHub and browser caches cannot keep showing the previous animation.\n",{"name":5,"description":7},"main","1e8d1cfee2152578c213d0693068c3b617e8cf20",".github\u002Fskills\u002Fchat-pet-sprite-creation",43791,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode","https:\u002F\u002Fcode.visualstudio.com","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 03:13:10",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add microsoft\u002Fvscode --skill chat-pet-sprite-creation",{"tool":63,"command":64},"bunx","bunx skills add microsoft\u002Fvscode --skill chat-pet-sprite-creation",{"tool":66,"command":67},"pnpm","pnpm dlx skills add microsoft\u002Fvscode --skill chat-pet-sprite-creation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fchat-pet-sprite-creation\u002FSKILL.md",true,[],[72,97,119,133,148,164],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":42},"01M70H0ANBKZAVEP1NVV4K28M3","sweeper-query","Answer natural-language questions about the VS Code Sweeper's published issue index (index-\u003Cname>.json for microsoft\u002Fvscode and the enrolled family repos) — which issues are agent-ready to implement or plan, what the sweeper proposed for an assignee or area, whether the sweeper knows a report as a duplicate, the highest-value open bugs in a lane — and, for one issue, the review's full record (evidence with file citations, fix brief, proposed comment). Use ONLY when the request explicitly names the sweeper — \"sweeper\", \"vscodesweeper\", \"sweeper-query\", a sweeper verdict, record, brief or index, an agent-ready issue — or asks what \"the sweeper\" found, proposed or knows. Do NOT use for general questions about issues, duplicates, priorities or ranking that do not mention the sweeper. Read-only; discovery only.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsweeper-query\u002FSKILL.md",[],[79,80,81,82,83,29,84,85,86,87,88,89,90,91,92,93,94,95,96,41],"sweeper query","query","sweeper","review","fix","request","which","natural-language","ranking","duplicates","ready","only","read","plan","open","Citations","brief","issues",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":42},"01M699DRJS4YJCV600Q72SVVWE","update-skills","Create or update repository skills and instructions when major learnings are discovered during a session. Use when the user says \"learn!\", when a significant pattern or pitfall is identified, or when reusable domain knowledge should be captured for future sessions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fupdate-skills\u002FSKILL.md",[],[104,105,106,107,108,109,110,36,111,112,113,114,115,116,117,118,29],"update","update skills","for","pattern","domain","learnings","reusable","session","user","instructions","knowledge","repository","learn","create","sessions",{"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":125,"publishedAt":42},"01M699DPWHZ72B66P82EW31RNE","update-pr","Update the pull request for the current session. Use when the user wants to push new changes to an existing PR.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fupdate-pr\u002FSKILL.md",[],[104,126,127,29,84,128,106,36,111,112,129,130,131,132],"pr","update pr","Existing","push","pull","pull request","changes",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":42},"01M699DJMR6CE1MH5XCJZ0GFQ0","sync","Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fsync\u002FSKILL.md",[],[135,140,141,129,130,142,29,132,143,144,145,146,36,111,112,147],"SET","publish","rebase","latest","with","remote","upstream","branch",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":42},"01M699DGXHX6A2A72X57R6GGHJ","sync-upstream","Update a stale session branch by rebasing onto the latest origin. Use when the upstream has moved significantly and the session needs to catch up, resolving conflicts by preserving upstream changes and adapting session work to fit.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fsync-upstream\u002FSKILL.md",[],[146,135,155,156,29,157,158,132,143,159,160,161,162,36,111,147,163,104],"sync upstream","fit","catch","catch up","origin","conflicts","stale","up","work",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":42},"01M699DEXYFWDGW0BAXJ5QQ377","merge","Merge changes from the topic branch to the merge base branch. Use when the user wants to merge their session's work back to the base branch.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fmerge\u002FSKILL.md",[],[166,111,36,163,147,112,29,171,172,132],"back","base"]