Sidebar 2.0: sync with next, implement sticky selected-node ancestors, deep review fixes

.agents/skills/handle-pr-comments/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: handle-pr-comments
+description: Triage and resolve GitHub PR review comments one by one, interactively. Use when the user asks to handle, address, respond to, or resolve PR review comments, or mentions reviewer feedback on a pull request.
+---
+
+# Handle PR Comments
+
+Evaluate review comments on the PR (from the current branch, or a PR number/URL if given). For each unresolved comment: summarize the feedback, suggest a resolution, ask the user how to resolve it, apply their choice, commit if needed, and resolve the thread.
+
+1. **Find the PR.** Use the given number/URL, else derive it from the current branch (`gh pr view`). Stop if no PR exists.
+
+2. **Fetch unresolved review threads** via the GraphQL `reviewThreads` field on the pull request — request each thread's `id`, `isResolved`, `isOutdated`, `path`, `line`, and comments. Filter to `isResolved == false`. (Use GraphQL, not REST: only it exposes thread `id`s and resolution state.)
+
+3. **Loop one comment at a time.** For each: (a) summarize the feedback + file/line, reading surrounding code; (b) suggest a concrete fix; (c) ask via AskQuestion with options — apply suggested fix / apply a different fix / reply only / skip; (d) apply the choice; (e) if applicable, summarize what was changed and ask whether to commit; (f) resolve the thread via the GraphQL `resolveReviewThread` mutation. 
+
+4. **Report** an overview of what was changed, committed, replied to, skipped, and resolved. Include links.
+
+## Notes
+
+- Handle real-user comments before addressing AI agents' (Copilot, CodeRabbit).
+- Group duplicate comments; when the same/similar issue is mentioned multiple times, handle them all at once.
+- Make a separate commit for each change.

.agents/skills/open-pr/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: open-pr
+description: Opens a pull request from the current branch using the PR template. Use when the user asks to open a PR, create a pull request, or invokes /open-pr.
+allowed-tools: Bash, Read, AskQuestion
+---
+
+# Open Pull Request
+
+Opens a draft PR from the current branch following Storybook conventions.
+
+## Workflow
+
+### 1. Gather context
+
+Run in parallel: `git status`, `git diff`, `git log --oneline <base>...HEAD` (after step 2), `git branch -vv`.
+
+Push first if needed: `git push -u origin HEAD`.
+
+### 2. Detect base branch
+
+```bash
+git fetch origin
+bash .agents/skills/open-pr/scripts/detect-base-branch.sh
+```
+
+Detects base in order: tracked upstream → reflog checkout source → closest `origin/*` ancestor (fewest commits from branch tip to HEAD). Supports telescoped/stacked PRs off feature branches, not only `next`/`main`. Skips branches at the same commit as HEAD. Tie-break: feature branch over trunk, then `next` over `main`. Falls back to `next`. Tell the user the result.
+
+### 3. Ask for labels
+
+Use **AskQuestion** for three questions. Options from `.github/PULL_REQUEST_TEMPLATE.md`:
+
+| Question | Options |
+| -------- | ------- |
+| CI label | `ci:normal`, `ci:merged`, `ci:daily` |
+| QA label | `qa:needed`, `qa:skip` |
+| Type label | `bug`, `maintenance`, `dependencies`, `build`, `cleanup`, `documentation`, `feature request`, `BREAKING CHANGE`, `other` |
+
+Verify the available labels with the PR template.
+
+### 4. Draft title and body
+
+**Title:** `[Area]: [Description]` — see the `pr` skill for format and examples.
+
+**Body:** Read `.github/PULL_REQUEST_TEMPLATE.md`. Copy it **exactly** (keep all HTML comments). Fill in:
+
+- `Closes #` when an issue is linked
+- **What I did**
+- Testing checkboxes and mandatory manual-testing steps (or state why none is needed)
+- Documentation checkboxes when applicable
+- Leave maintainer checklist items unchecked
+
+### 5. Create the PR
+
+```bash
+gh pr create \
+  --draft \
+  --base "<detected-base>" \
+  --title "<Area>: <Description>" \
+  --body "$(cat <<'EOF'
+<FILLED_TEMPLATE>
+EOF
+)" \
+  --assignee @me \
+  --label "<type>,<ci>,<qa>"
+```
+
+### 6. Report and offer canary
+
+Share the PR URL. Then **AskQuestion**: "Do you want to create a canary release for this PR?"
+
+- **Yes** — run `/canary <PR_NUMBER>` and report workflow status
+- **No** — stop
+
+## Notes
+
+- Always draft; always assign `@me`.
+- For canary details after publishing, see the `canary` skill.

.agents/skills/open-pr/scripts/detect-base-branch.sh

@@ -0,0 +1,137 @@
+#!/usr/bin/env bash
+# Pick the remote branch the current branch most likely forked from.
+# Supports telescoped/stacked PRs by scanning all origin/* ancestors.
+set -euo pipefail
+
+current_branch=$(git branch --show-current)
+head_tip=$(git rev-parse HEAD)
+best=""
+min_commits=999999
+best_is_feature=0
+
+is_trunk() {
+  case "$1" in
+    main | next) return 0 ;;
+    *) return 1 ;;
+  esac
+}
+
+normalize_branch_name() {
+  local name=$1
+  name=${name#origin/}
+  name=${name#remotes/origin/}
+  echo "${name}"
+}
+
+branch_exists_on_origin() {
+  git rev-parse --verify "origin/$1" >/dev/null 2>&1
+}
+
+is_valid_base() {
+  local branch=$1
+  local ref="origin/${branch}"
+
+  [ "${branch}" != "${current_branch}" ] || return 1
+  branch_exists_on_origin "${branch}" || return 1
+
+  local branch_tip
+  branch_tip=$(git rev-parse "${ref}")
+  [ "${branch_tip}" != "${head_tip}" ] || return 1
+  git merge-base --is-ancestor "${ref}" HEAD 2>/dev/null
+}
+
+commit_count_since() {
+  git rev-list --count "origin/$1..HEAD"
+}
+
+consider() {
+  local branch=$1
+  local commit_count=$2
+
+  if ! is_valid_base "${branch}"; then
+    return
+  fi
+
+  local is_feature=0
+  is_trunk "${branch}" || is_feature=1
+
+  if [ -z "${best}" ]; then
+    best=${branch}
+    min_commits=${commit_count}
+    best_is_feature=${is_feature}
+    return
+  fi
+
+  if [ "${commit_count}" -lt "${min_commits}" ]; then
+    best=${branch}
+    min_commits=${commit_count}
+    best_is_feature=${is_feature}
+    return
+  fi
+
+  if [ "${commit_count}" -gt "${min_commits}" ]; then
+    return
+  fi
+
+  # Tie: prefer telescoped parent over trunk, then next over main.
+  if [ "${best_is_feature}" -eq 0 ] && [ "${is_feature}" -eq 1 ]; then
+    best=${branch}
+    best_is_feature=${is_feature}
+    return
+  fi
+
+  if [ "${best_is_feature}" -eq 1 ] && [ "${is_feature}" -eq 0 ]; then
+    return
+  fi
+
+  if [ "${branch}" = "next" ]; then
+    best=${branch}
+    best_is_feature=${is_feature}
+  fi
+}
+
+try_explicit_base() {
+  local branch=$1
+  branch=$(normalize_branch_name "${branch}")
+  consider "${branch}" "$(commit_count_since "${branch}")"
+}
+
+# 1. Tracked upstream (set when branching with -u or --track)
+if upstream=$(git rev-parse --abbrev-ref '@{upstream}' 2>/dev/null); then
+  try_explicit_base "${upstream}"
+fi
+
+# 2. Reflog: most recent branch we checked out from
+if [ -z "${best}" ]; then
+  while IFS= read -r line; do
+    if [[ ${line} =~ checkout:\ moving\ from\ (.+)\ to\ ${current_branch} ]]; then
+      try_explicit_base "${BASH_REMATCH[1]}"
+      break
+    fi
+    if [[ ${line} =~ branch:\ Created\ from\ (.+) ]]; then
+      try_explicit_base "${BASH_REMATCH[1]}"
+      break
+    fi
+  done < <(git reflog show --format='%gs' "${current_branch}" 2>/dev/null || true)
+fi
+
+# 3. Scan all origin/* branches — closest strict ancestor wins
+while IFS= read -r ref; do
+  branch=${ref#origin/}
+
+  if [ "${branch}" = "HEAD" ] || [ "${branch}" = "${current_branch}" ]; then
+    continue
+  fi
+
+  if ! is_valid_base "${branch}"; then
+    continue
+  fi
+
+  consider "${branch}" "$(commit_count_since "${branch}")"
+done < <(git for-each-ref --format='%(refname:short)' refs/remotes/origin/)
+
+if [ -z "${best}" ]; then
+  best="next"
+fi
+
+echo "${best}"

.agents/skills/pr/SKILL.md

@@ -41,16 +41,54 @@ Add these labels to the PR:
 - `ci:daily` - daily sandbox set; use this when changes affect prerelease sandboxes or sandboxes pinned to a framework or React version other than latest
 - `ci:docs` - documentation-only changes (use with `documentation` category)
 
+**QA (required, pick one):**
+
+Tells the release team whether manual QA is needed before the next minor release.
+
+- `qa:needed` — a human must manually verify this PR at release time
+- `qa:skip` — no per-PR manual QA needed at release time
+
+Heuristics:
+
+- User explicitly asked for manual QA before release → `qa:needed`
+- Part of a larger project that gets holistic QA (not per-PR) → `qa:skip`
+- Touches paths, filesystem, or anything that could break on Windows → `qa:needed`
+- Complex change spanning multiple areas that must work together → `qa:needed`
+- Small change in central/shared code with high side-effect risk (e.g. layout CSS in shared UI) → `qa:needed`
+- Simple, straightforward change → `qa:skip`
+- Unsure → ask the user whether manual QA before minor release is necessary
+
 ## PR body
 
 Read `.github/PULL_REQUEST_TEMPLATE.md` from the repository root.
 
 Copy that template **EXACTLY**, including all HTML comments (`<!-- ... -->`). Fill in the relevant sections based on the changes, but keep all comments intact.
 
+### Manual testing (required)
+
+The **Manual testing** section is mandatory — never leave it empty. Write steps for a separate maintainer, not a log of how you tested.
+
+Each step should be:
+
+- Clear and easy to follow
+- Copy-pasteable shell commands where applicable
+- Explicit about what behavior to inspect (expected outcome, not just "check it works")
+- Linked to specific stories for UI changes, or to build artifacts when relevant
+- Lists areas most likely to regress and worth extra scrutiny
+
+**Verify your own steps first** — run through them locally before opening the PR.
+
+When useful, link to published Chromatic Storybooks (CI must finish first; links won't work immediately after opening the PR):
+
+- Internal UI: `https://<branch>--635781f3500dd2c49e189caf.chromatic.com/?path=/story/<story_id>`
+- React Vite TS: `https://<branch>--630511d655df72125520f051.chromatic.com/?path=/story/<story_id>`
+
+Replace `<branch>` with Chromatic's normalized slug (special chars → dashes, e.g. `feature/foo` → `feature-foo`) and `<story_id>` with the story path (e.g. `example-button--primary`).
+
 ## Command
 
 Always create PRs in draft mode:
 
 ```bash
-gh pr create --draft --title "<Area>: <Description>" --body "<FILLED_TEMPLATE>" --label "<category>,<ci>"
+gh pr create --draft --title "<Area>: <Description>" --body "<FILLED_TEMPLATE>" --label "<category>,<ci>,<qa>"
 ```

.agents/skills/rebuild-restart-storybook/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: rebuild-restart-storybook
+description: Rebuild and restart the internal Storybook UI after changes to internal Storybook code (core, addons, frameworks, renderers, libs, etc.), then optionally display a UI review. Use after editing any package in the Storybook monorepo's code/ directory, or when the user asks to rebuild and/or restart Storybook.
+allowed-tools: Bash, Read
+---
+
+# Rebuild and Restart Storybook
+
+After making changes to internal Storybook code (core, addons or otherwise), follow this workflow.
+
+## Step 1: Ask whether to rebuild and restart (in case of model invocation)
+
+Unless the user explicitly ran `/rebuild-restart-storybook`, ask the user whether they want to rebuild and restart Storybook. If they decline, stop here.
+
+## Step 2: Determine modified packages
+
+Build a space-separated list of the monorepo packages that were modified in the conversation. For each modified package, find its Nx project name in the `project.json` file in that package's directory (the `name` field), not the `package.json` name.
+
+For example, if `code/addons/review` and `code/addons/vitest` were modified, the list is `addon-review addon-vitest`.
+
+## Step 3: Run the build and start commands in sequence
+
+Run these in the `code` directory, in order. Substitute `<extra packages>` with the list from Step 2.
+
+```bash
+rm -rf node_modules/.cache
+yarn
+yarn build storybook <extra packages>
+```
+
+Then, run in the background:
+
+```bash
+NODE_OPTIONS="--preserve-symlinks" yarn storybook:ui --no-open
+```
+
+### Handle an occupied port
+
+A Storybook may already be running. If the port is occupied, cancel the start, kill the old process to free the port, then start Storybook again.
+
+## Step 4: Provide the URL and ask about a review
+
+Once Storybook has started, give the user the URL. Then ask whether they want to display a review.
+
+## Step 5: Display the review
+
+If the user wants a review, use Storybook's `display-review` MCP tool to create a UI review of relevant stories. Pick a set of stories related to the entirety of the conversation so far.
+
+If there are no relevant stories because no UI elements were touched, ask the user what they would like to see a review for.