session-orchestrator 3.21.0 → 3.22.0

package/skills/evolve/SKILL.md

@@ -248,8 +248,8 @@ Present extracted patterns to the user for confirmation. Use AskUserQuestion wit
 ```
 AskUserQuestion({
   questions: [{
-    question: "Which learnings should be saved?\n\nExtracted patterns from session history:",
-    header: "Evolve — Confirm Learnings",
+    question: "Which of the patterns extracted from this session's history should be saved?",
+    header: "Speichern?",
     options: [
       {
         label: "[type] subject",
@@ -455,19 +455,18 @@ Use AskUserQuestion with options:
 AskUserQuestion({
   questions: [{
     question: "What would you like to do with your learnings?",
-    header: "Evolve — Review",
+    header: "Learnings",
     options: [
-      { label: "Boost confidence", description: "Select learnings to boost (+0.15)" },
-      { label: "Reduce confidence", description: "Select learnings to reduce (-0.2)" },
-      { label: "Delete specific learnings", description: "Select learnings to remove" },
-      { label: "Extend expiry", description: "Reset expires_at by learning-expiry-days from now" },
-      { label: "Done — no changes", description: "Exit without changes" }
+      { label: "Confidence ändern", description: "Pick the learnings, then the direction: +0.15 or -0.2. Cheapest fix when a learning is merely mis-weighted." },
+      { label: "Ablauf verlängern", description: "Keeps a still-useful learning alive: its expiry date moves to today plus the configured window. Confidence is untouched." },
+      { label: "Delete specific learnings", description: "Takes the selected learnings out of the store. They are archived rather than shredded, but they stop influencing anything." },
+      { label: "Done — no changes", description: "Leaves the store exactly as it is and ends the review. Nothing is written." }
     ]
   }]
 })
 ```
 
-If user selects "Boost confidence", "Reduce confidence", "Delete specific learnings", or "Extend expiry", present a follow-up AskUserQuestion with `multiSelect: true` listing all learnings by `# | type | subject` so the user can select which ones to modify.
+If user selects "Confidence ändern", "Ablauf verlängern", or "Delete specific learnings", present a follow-up AskUserQuestion with `multiSelect: true` listing all learnings by `# | type | subject` so the user can select which ones to modify. For "Confidence ändern" the same follow-up also asks for the direction — **Boost** (+0.15) or **Reduce** (-0.2). Both operations are unchanged; only the point at which the direction is chosen moved, because a single AskUserQuestion accepts at most 4 options and the previous list had 5.
 
 > On Codex CLI where AskUserQuestion is unavailable, present as a numbered Markdown list.
 

package/skills/gitlab-ops/SKILL.md

@@ -9,7 +9,7 @@ model-preference-cursor: claude-sonnet-4-6
 description: >
   Use this skill when performing VCS operations on GitLab or GitHub repositories — creating, updating, or
   closing issues and MRs, applying label taxonomy, running `glab`/`gh` CLI commands, or resolving project
-  IDs dynamically. Acts as the single source of truth for CLI command syntax and label conventions;
+  paths dynamically. Acts as the single source of truth for CLI command syntax and label conventions;
   consuming skills reference this rather than duplicating logic. Triggers: "create a GitLab issue", "list
   open MRs", "apply priority label", "how do I resolve the project ID", "what's the carryover issue
   template". <example>Context: session-end needs to file a carryover issue for an incomplete task. user:
@@ -45,7 +45,7 @@ syntax inline. This skill is the single source of truth for all VCS operations.
 When a skill needs VCS operations, include this reference block in its instructions:
 
 > **VCS Reference:** Detect the VCS platform per the "VCS Auto-Detection" section of the gitlab-ops skill.
-> Use CLI commands per the "Common CLI Commands" section. For cross-project queries, see "Dynamic Project Resolution."
+> Use CLI commands per the "Common CLI Commands" section. For GitLab API operations, see "Canonical Project Identity."
 
 **Canonical commands:** All `glab` and `gh` command syntax — flags, output formats,
 pagination options — is defined in the "Common CLI Commands" section below. Consuming
@@ -57,34 +57,35 @@ command variant not listed there, add it to this file first, then reference it.
 - Any skill-specific *parameters* they pass to commands (e.g., label names, issue templates)
 - They should NOT include raw `glab`/`gh` invocations or detection snippets
 
-## Dynamic Project Resolution
+## Canonical Project Identity
 
-Never hardcode project IDs. Resolve them at runtime — and re-resolve live each session; never cache a project ID across sessions (a stale ID silently targets the wrong project on rename/fork/mirror-drift, and is the root cause behind the close-verification incident documented below).
+GitLab REST endpoints accept a URL-encoded `namespace/project` path. Select the GitLab host and project path explicitly; never derive a numeric project ID from `glab repo view`, search `projects?search=`, or use `:id` placeholders. Those forms can resolve through the ambient working directory or a stale search result and target another project after a rename, fork, or scaffold.
 
-### Current project
+Set the identity once per operation sequence and reuse the encoded identifier without encoding it again:
 
 ```bash
-# GitLab — get numeric project ID
-glab repo view -R <OWNER>/<REPO> --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])"
+GITLAB_HOST="<selected GitLab hostname>"
+GROUP_PATH="<selected group path>"
+PROJECT_NAME="<selected project name>"
+PROJECT_PATH="$GROUP_PATH/$PROJECT_NAME"
+ENCODED_PROJECT_PATH="$(node -e 'process.stdout.write(encodeURIComponent(process.argv[1]))' "$PROJECT_PATH")"
+```
 
-# GitHub — get owner/name identifier (gh repo takes the repo POSITIONALLY; it rejects -R)
-gh repo view --json nameWithOwner -q '.nameWithOwner'
+For a link target in another project, use the same path-first shape instead of a numeric ID:
+
+```bash
+TARGET_PROJECT_PATH="<target namespace>/<target project>"
+TARGET_ENCODED_PROJECT_PATH="$(node -e 'process.stdout.write(encodeURIComponent(process.argv[1]))' "$TARGET_PROJECT_PATH")"
 ```
 
-### Cross-project queries
+Pass `--hostname "$GITLAB_HOST"` to every `glab api` call. The endpoint itself then pins the project, including directly after creating a repository when the current directory does not yet identify the new project.
 
-When a skill needs to reference other projects (e.g., from `cross-repos` in Session Config):
+GitHub continues to use an `owner/repo` slug; `gh repo` takes it positionally and rejects `-R`:
 
 ```bash
-# GitLab — resolve project ID by name
-glab api "projects?search=<project-name>" | python3 -c "import json,sys; [print(p['id'], p['path_with_namespace']) for p in json.load(sys.stdin)]"
-
-# GitHub — resolve repo details
-gh api "repos/<owner>/<name>" --jq '.full_name'
+gh repo view --json nameWithOwner -q '.nameWithOwner'
 ```
 
-**Note:** Some API calls require numeric project IDs (GitLab) or `owner/repo` slugs (GitHub). Always resolve dynamically from the project name.
-
 ### Canonical enumeration pattern
 
 To enumerate ALL projects (or issues) in a group, a single page is never the whole result — paginate and guard against silent truncation:
@@ -93,7 +94,7 @@ To enumerate ALL projects (or issues) in a group, a single page is never the who
 # GitLab — paginate a group's projects, following x-next-page until empty
 page=1
 while [ -n "$page" ]; do
-  resp=$(glab api "groups/<group-id>/projects?include_subgroups=true&per_page=100&page=$page" --include)
+  resp=$(glab api --hostname "$GITLAB_HOST" "groups/<group-id>/projects?simple=true&include_subgroups=true&per_page=100&page=$page" --include)
   # parse the response body ($resp) for project ids/paths here, deduping by id.
   # Then advance by reading the `x-next-page` response header — an empty value
   # means this was the last page, so the loop exits (the guard above is what breaks).
@@ -146,13 +147,16 @@ done
 
 ## Issue Linking (`blocks` / `is_blocked_by`)
 
-GitLab's native issue-link types `blocks` and `is_blocked_by` (`glab api -X POST projects/:id/issues/:issue_iid/links -f link_type=blocks|is_blocked_by`) are a **Premium/Ultimate license feature**. On a Free/Core-tier GitLab instance this call returns **HTTP 403** — a license-gate signal, not an auth/permission failure. Do not retry with different credentials or escalate as an auth bug.
+GitLab's native issue-link types `blocks` and `is_blocked_by` (`glab api --silent --hostname "$GITLAB_HOST" -X POST "projects/${ENCODED_PROJECT_PATH}/issues/${ISSUE_IID}/links" -f target_project_id="$TARGET_ENCODED_PROJECT_PATH" -f target_issue_iid="$OTHER_ISSUE_IID" -f link_type="$LINK_TYPE"`) are a **Premium/Ultimate license feature**. Set `LINK_TYPE` to `blocks` or `is_blocked_by`; the target accepts an encoded project path, so no numeric project ID is needed. On a Free/Core-tier GitLab instance this call returns **HTTP 403** — a license-gate signal, not an auth/permission failure. Do not retry with different credentials or escalate as an auth bug.
 
 **Fallback (non-Premium instances):**
 1. **Use `relates_to` instead** — `link_type=relates_to` is available on every GitLab tier (no ordering semantics, just an unscoped relation). Same API shape, only the `link_type` value changes:
    ```bash
-   glab api -X POST "projects/:id/issues/:issue_iid/links" \
-     -f target_project_id=:id -f target_issue_iid=:other_iid -f link_type=relates_to
+   glab api --silent --hostname "$GITLAB_HOST" -X POST \
+     "projects/${ENCODED_PROJECT_PATH}/issues/${ISSUE_IID}/links" \
+     -f target_project_id="$TARGET_ENCODED_PROJECT_PATH" \
+     -f target_issue_iid="$OTHER_ISSUE_IID" \
+     -f link_type=relates_to
    ```
 2. **Document the blocking semantics in the issue body** — since `relates_to` carries no ordering meaning, add an explicit ordering note to both issues, e.g. `⚠ Ordering: erst #<blocker_iid>, dann dieses Issue — blocks-Link nicht verfügbar (non-Premium)`.
 3. **Recognize the 403 as a license signal, not an auth error** — before assuming a token/scope problem, try `relates_to` on the same project pair: if `relates_to` succeeds where `blocks`/`is_blocked_by` 403s, the license gate — not authentication — is the cause.
@@ -187,14 +191,14 @@ glab mr merge -R <OWNER>/<REPO> <MR_IID>                                   # Mer
 glab pipeline list -R <OWNER>/<REPO> --per-page 5                          # Recent pipelines
 glab pipeline status -R <OWNER>/<REPO> <ID>                                # Pipeline details
 
-# API (no --repo exists here — the endpoint path IS the target; pin the host with --hostname)
-glab api "projects/$(glab repo view -R <OWNER>/<REPO> --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")/issues?state=opened&per_page=50"
-glab api "projects/$(glab repo view -R <OWNER>/<REPO> --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")/milestones?state=active"
+# API (no --repo exists here — the encoded endpoint and explicit host identify the target)
+glab api --hostname "$GITLAB_HOST" "projects/${ENCODED_PROJECT_PATH}/issues?state=opened&per_page=50"
+glab api --hostname "$GITLAB_HOST" "projects/${ENCODED_PROJECT_PATH}/milestones?state=active"
 ```
 
 **Label update caveat (PUT-replaces, not additive):** `glab issue update --label` (and the underlying GitLab labels API) PUT-REPLACES the entire label set — it does not add to the existing set. To change a single label you must pass the FULL desired label list, or use the dedicated add/remove operations, which are themselves unreliable across `glab` versions. Preferred safe pattern: use `--label` (adds) together with `--unlabel` (removes) on `glab issue update` when your installed `glab` version supports both; otherwise read the current labels first, compute the full new set, and PUT once. The same PUT-replace semantics apply to `glab mr update --label`.
 
-**Close verification:** after `glab issue close <IID>`, always verify the close actually landed — re-read the issue (`glab issue view <IID>`) and confirm `state: closed` in the output. A stale/wrong project ID or a silent 404 can report local success while closing nothing; a documented incident closed 32 issues into the void this way (project ID pointed at the wrong project — see "Dynamic Project Resolution" above for the re-resolve-each-session rule that prevents it).
+**Close verification:** after `glab issue close <IID>`, always verify the close actually landed — re-read the issue (`glab issue view <IID>`) and confirm `state: closed` in the output. A stale or wrong project path, or a silent 404, can report local success while closing nothing; use the canonical project identity above for API operations rather than resolving a numeric ID.
 
 **Commit-body close-keyword footgun:** GitLab (and GitHub) auto-close an issue when a commit pushed to the default branch contains a close keyword — `close`/`closes`/`closed`/`fix`/`fixes`/`fixed`/`resolve`/`resolves`/`resolved` — followed by `#N` ANYWHERE in the commit body, not just the subject line. This fires even inside a negation ("does NOT close #N") — the platform pattern-matches the keyword + issue reference; it does not parse English negation, so the negation offers no protection. Rule: when a commit body needs to MENTION an issue without closing intent, always use a non-closing reference — `refs #N`, `part of #N`, `siehe #N` — never a close-keyword verb next to the number, negated or not.
 

package/skills/grill/SKILL.md

@@ -66,7 +66,7 @@ Walk the decision tree **one question at a time**. For each branch, in order:
 AskUserQuestion({
   questions: [{
     question: "Your code cancels whole Orders, but the PRD says a customer can cancel one line item. Which is the real model?",
-    header: "Cancellation Scope",
+    header: "Cancel scope",
     options: [
       { label: "Line-item cancellation (Recommended)", description: "Matches the PRD intent. Cost: new partial-refund path + Order stays open after one item is voided." },
       { label: "Whole-order only", description: "Matches today's code. Cost: contradicts the stated user story — re-scope the PRD." },
@@ -118,12 +118,12 @@ Per the user's configured behaviour, the grill ends with a hand-off and an OPTIO
 AskUserQuestion({
   questions: [{
     question: "Grill complete. How do you want to proceed?",
-    header: "Grill Hand-off",
+    header: "Hand-off",
     options: [
-      { label: "Write grill summary + hand off to /plan feature (Recommended)", description: "Persist resolved decisions to docs/specs/, then formalize into a PRD." },
-      { label: "Write grill summary only", description: "Keep the resolved decisions as a reference; no further step now." },
-      { label: "Hand off to /plan feature — no file", description: "Carry the resolved decisions straight into planning; nothing persisted." },
-      { label: "Done — no file, no hand-off", description: "The grilling itself was the value; leave no artifact." }
+      { label: "Summary + /plan feature (Recommended)", description: "Writes the resolved decisions to docs/specs/ (a folder of markdown notes), then hands them to planning. Cost: one file." },
+      { label: "Write grill summary only", description: "Same file, no planning step. The decisions keep, so you can hand them off later." },
+      { label: "Hand off to /plan feature — no file", description: "Carries the decisions straight into planning. They then live only in this conversation." },
+      { label: "Done — no file, no hand-off", description: "The grilling itself was the value. Nothing is written, nothing is handed on." }
     ],
     multiSelect: false
   }]

package/skills/grill/soul.md

@@ -76,6 +76,22 @@ This is the tightest of the orchestrator's budgets by design. A turn is structur
 - Shape: explain which tactic you are applying and why it bites here, name the branches of the decision tree you are deferring, define unfamiliar terms on first use.
 - Escalation: `expand <topic>` — see § Escalation above.
 
+### Register — how a sentence reads
+
+The budgets above set *how much* you say; the register sets *how*. It is
+defined once, in `skills/session-start/soul.md` § "Register — how a sentence
+reads", and binds here unchanged: the frame ("write for someone who knows this
+project but has not seen what you just saw"), the plain-words test with its
+five worked cases, and its precedence over § "Never traded for brevity" above.
+Read it there. It is not repeated here on purpose — the § Output Levels intro
+sentence already exists in four copies across the four souls with nothing
+checking their parity, and a fifth copied rule would drift the same way. A
+pointer cannot.
+
+Note the one place register and adversarial posture meet: a challenge is
+plainer, never softer. "Say it more simply" never becomes "say it less
+sharply" — the contradiction still lands, in shorter words.
+
 ### Companion dials
 
 Same file, same lookup, same fallback-to-default rule:

package/skills/memory-cleanup/SKILL.md

@@ -246,8 +246,8 @@ const peerWarning = wt.activePeer
 
 AskUserQuestion({
   questions: [{
-    question: `Stale auto-promoted worktree found: ${path.basename(wt.wtPath)} (age ${ageDays}d, branch=${wt.branch}).${peerWarning} Remove?`,
-    header: "Stale-Worktree",
+    question: `Auto-promoted worktree ${path.basename(wt.wtPath)} is ${ageDays}d old (branch ${wt.branch}).${peerWarning} Remove?`,
+    header: "Worktree",
     multiSelect: false,
     options: [
       {

package/skills/npm-publish/SKILL.md

@@ -7,7 +7,7 @@ description: Use when publishing this package to npm — a version release (npm
 
 # npm-publish — token auth, and the calls the script cannot make
 
-> **The release itself is `/release` → `scripts/release.mjs`.** That script mechanizes the whole sequence: version surfaces, CHANGELOG gate, drift sweep, tag/registry collision, CI, leakage gate, publish, tag-after-publish, push to both remotes, live-site poll. This skill does not restate it.
+> **The release itself is `/release` → `scripts/release.mjs`.** That script mechanizes the whole sequence: version surfaces, CHANGELOG gate, drift sweep, tag/registry collision, CI, leakage gate, publish, the target-confirmed npm receipt boundary, tag-after-receipt, push to both remotes, GitHub-release handling, and live-site poll. This skill does not restate it.
 >
 > What lives here is the half a script cannot own: the **token setup**, the **auth failure diagnosis**, and the **judgement calls** — which version, what a leak means, when to abort rather than repair.
 
@@ -39,7 +39,7 @@ The script gates mechanics. These three are yours, and it will not make them for
 
 **2. What a leak means when one is found.** A hit from the leakage gate is not a pattern to silence. Decide which of two it is: a real leak (fix `package.json` `files`, re-pack, re-check) or genuine over-matching (fix `LEAKAGE_PATTERNS` in `scripts/release.mjs` **with a test**). There is no third option, and neither is "publish anyway and clean it up in the next version" — an npm publish is not revocable, and unpublishing burns the version number permanently. Operator handling detail: `docs/distribution/npm-publish-checklist.md` § 3.
 
-**3. When to abort instead of repair.** Abort — do not patch forward — when the failure is upstream of the publish: a red preflight row, a lagging `github` mirror, CI not green on the exact commit, a dead token. These are cheap to fix and re-run from the top. Repair-in-place is only ever appropriate *after* a verified publish, where the version is already immutable: a missing GitHub release or a lagging site deploy can be reconciled, because npm already has the correct artifact. The dividing line is whether the registry has accepted the tarball — before that point, restart; after it, reconcile. `commands/release.md` § Abort criteria is the operative list.
+**3. When to abort instead of repair.** Abort — do not patch forward — when the failure is upstream of the target-confirmed npm receipt: a red preflight row, a lagging `github` mirror, CI not green on the exact commit, a dead token, or a publish that did not issue the target receipt. These are cheap to fix and re-run from the top. Repair-in-place is only appropriate *after* that receipt, where the version is already immutable: registry propagation, a missing GitHub release, or a lagging site deploy can be reconciled because npm already has the correct artifact. When `--publish` reports **Post-publish reconciliation required**, **do not rerun `--publish`**; repair the listed state directly. `commands/release.md` § Abort criteria is the operative list.
 
 ## Failure-mode table
 
@@ -48,13 +48,13 @@ The script gates mechanics. These three are yours, and it will not make them for
 | `E403 ... Two-factor authentication or granular access token with bypass 2fa enabled is required` — no OTP prompt | Account has no 2FA enrolled AND token (if any) lacks Bypass-2FA | Create granular token with all four requirements above, or enroll 2FA |
 | Same E403 despite a fresh token | Token created without the Bypass-2FA checkbox, or Read-only, or package-scoped on a first publish | Re-create: RW + All packages + Bypass-2FA |
 | `npm whoami` silent or non-zero | Token expired, or `.env.local` missing | Re-create the token; do not proceed — the preflight fails this row on purpose |
-| `E404` on `npm view` after publish | Registry propagation (rare, seconds) or publish actually failed | Re-check the publish output for `+ <name>@<version>` |
+| `E404` on `npm view` after a target-confirmed publish receipt | Registry propagation (rare, seconds) | Let the script finish its tag/push/GitHub/site tail, then reconcile the registry result; do **not** rerun `--publish` |
 | `ENEEDAUTH` | No login/token at all | Token flow above, or `npm login` |
 | OTP prompt appears but flow is non-interactive (`!`-prefix, script) | No TTY for the prompt | Use the token flow, or a real terminal |
 
 ## Post-publish — the human half
 
-`--publish` verifies the registry and polls the live site itself, and prints the rest. What still needs a person:
+`--publish` attempts registry verification and polls the live site itself. A target-confirmed receipt plus a delayed registry result is a reconciliation outcome, not a failed publish or a retry instruction. What still needs a person:
 
 1. **Rotate/delete the token** at https://www.npmjs.com/settings/<user>/tokens. A token that ever transited a conversation, a screenshot, or any log is burned — rotate immediately.
 2. **pi.dev gallery**: indexing is asynchronous — check https://pi.dev/packages later; do not block on it.

package/skills/peekaboo-driver/SKILL.md

@@ -96,10 +96,10 @@ For each `${PERM_NAME}` in `$MISSING`:
 ```
 AskUserQuestion({
   questions: [{
-    question: `${PERM_NAME} permission is required but not granted. Open System Settings > Privacy & Security > ${PERM_NAME}, enable the terminal entry, then confirm here.`,
-    header: `Missing Permission: ${PERM_NAME}`,
+    question: `${PERM_NAME} is not granted. Enable the terminal entry under System Settings > Privacy & Security, then confirm.`,
+    header: "Zugriff",
     options: [
-      { label: "Granted — continue (Recommended)", description: `I have enabled ${PERM_NAME} in System Settings.` },
+      { label: "Granted — continue (Recommended)", description: "I enabled the terminal entry in that pane — the driver then checks again and carries on if the grant took effect." },
       { label: "Skip this run", description: "Abort peekaboo-driver. Test-runner will record a framework-error finding." }
     ],
     multiSelect: false

package/skills/plan/SKILL.md

@@ -281,17 +281,17 @@ If any criterion is FAIL:
 2. Revise the affected PRD sections
 3. Re-submit to the reviewer
 
-Maximum 3 iterations. After 3 iterations with remaining issues, present them to the user via AskUserQuestion:
+Maximum 3 iterations. After 3 iterations with remaining issues, list the flagged points in plain text (they are context, not a choice), then ask via AskUserQuestion:
 
 ```
 AskUserQuestion({
   questions: [{
-    question: "The PRD reviewer flagged these remaining issues after 3 revision rounds:\n\n[list issues]\n\nHow do you want to proceed?",
+    question: "The reviewer still flags [N] points after 3 revision rounds. Proceed anyway?",
     header: "PRD Review",
     options: [
-      { label: "Accept as-is (Recommended)", description: "Issues are minor, proceed with current PRD." },
-      { label: "Manual edit", description: "I'll edit the PRD myself before continuing." },
-      { label: "Re-run review", description: "Try one more revision round." }
+      { label: "Accept as-is (Recommended)", description: "Three rounds did not close them, so a fourth probably will not. The flags then stay in the PRD and travel into the issues filed from it." },
+      { label: "Manual edit", description: "You edit the PRD yourself; the flow waits, then re-runs the reviewer on your version." },
+      { label: "Re-run review", description: "One more revision round. Cost: another reviewer pass, and the same points may come back unchanged." }
     ],
     multiSelect: false
   }]
@@ -300,16 +300,16 @@ AskUserQuestion({
 
 ### 5.3 User Review Gate
 
-After the reviewer passes (or user accepts), present the final PRD:
+After the reviewer passes (or user accepts), present the final PRD in plain text — path plus a short section summary — then ask:
 
 ```
 AskUserQuestion({
   questions: [{
-    question: "PRD is ready for your review. It has been saved to [path].\n\nPlease review the document and confirm.",
+    question: "Approve the PRD at [path]?",
     header: "PRD Approval",
     options: [
-      { label: "Approve PRD (Recommended)", description: "PRD looks good, proceed to issue creation." },
-      { label: "Request changes", description: "I have feedback — let me describe what to change." }
+      { label: "Approve PRD (Recommended)", description: "Nothing further is checked after this: approval commits the PRD to HEAD (Phase 5.5), then issue creation starts." },
+      { label: "Request changes", description: "Describe what to change; the PRD is rewritten and comes back here. No limit on rounds." }
     ],
     multiSelect: false
   }]
@@ -395,18 +395,20 @@ Assign labels from the standard taxonomy:
 
 ### 6.3 User Review
 
-Present the full issue structure via AskUserQuestion before creating anything:
+Present the full issue structure via AskUserQuestion before creating anything. The table is the text that is about to be filed, so it belongs in `preview` — not in the question:
 
 ```
 AskUserQuestion({
   questions: [{
-    question: "Proposed issue structure:\n\n**Epic:** [title]\n\n| # | Sub-Issue | Priority | Labels | Blocked By |\n|---|----------|----------|--------|------------|\n| 1 | [title]  | critical | [labels] | — |\n| 2 | [title]  | high     | [labels] | #1 |\n| ... | ... | ... | ... | ... |\n\nTotal: [N] issues. Confirm or adjust.",
-    header: "Issue Review",
+    question: "Create these [N] issues from the PRD?",
+    header: "Issues",
     options: [
-      { label: "Create all issues (Recommended)", description: "Proceed with the proposed structure." },
-      { label: "Adjust priorities", description: "I want to change some priorities before creating." },
-      { label: "Remove issues", description: "Some issues should not be created." },
-      { label: "Cancel", description: "Do not create any issues." }
+      { label: "Create all [N] (Recommended)",
+        description: "Priorities and blocked-by links come straight from the approved PRD. Cost: one API call per issue, ~1s apart.",
+        preview: "**Epic:** [title]\n\n| # | Sub-Issue | Priority | Labels | Blocked By |\n|---|----------|----------|--------|------------|\n| 1 | [title]  | critical | [labels] | — |\n| 2 | [title]  | high     | [labels] | #1 |\n| ... | ... | ... | ... | ... |" },
+      { label: "Adjust priorities", description: "Same [N] issues, different priority labels. Name them and this question comes back with the table updated." },
+      { label: "Remove issues", description: "Name the ones to drop; the rest are created unchanged." },
+      { label: "Cancel", description: "Nothing is created. The PRD stays committed, so Phase 6 can run again later." }
     ],
     multiSelect: false
   }]

package/skills/plan/mode-feature.md

@@ -127,7 +127,7 @@ Apply per gitlab-ops skill label taxonomy:
 
 ### User Review Gate
 
-Present the full issue structure via AskUserQuestion before creation:
+Present the full issue structure via the AskUserQuestion payload in `SKILL.md` § 6.3 — the issue table belongs in the option's `preview` field, not in the question text:
 
 - Epic title and description
 - Each sub-issue: title, priority, labels, dependency links

package/skills/plan/mode-new.md

@@ -38,7 +38,7 @@ Agent({ subagent_type: "Explore", description: "Check ecosystem for conflicts",
 3. **Target audience** — Options informed by market research agent. User selects or provides custom.
 4. **User-Story-Schicht** — "User-Story-Schicht für dieses Feature erzeugen?" Immer fragen (kein Audience-Heuristik-Gate). Drei Antwortoptionen: **Ja (Als/möchte/damit)** — klassische Persona-Story-Form; **Ja (job-story)** — job-story-Form ("When [situation], I want [motivation], so I can [outcome]"); **Nein** — byte-identisches Status-quo-Verhalten. Bei einer der beiden "Ja"-Optionen emittiert die PRD eine optionale ## User Stories Sektion (je Story ein ↳ AC-Pointer) in der gewählten Form; bei "Nein" wird die Sektion vollständig weggelassen.
 5. **Core problem being solved** — Open-ended. Claude suggests structure if answer is vague.
-6. **GitLab group** — Discover available groups dynamically. Run `ls $BASELINE_PATH/templates/` for project types, and check for a groups config in `$BASELINE_PATH/config/` or run `glab api "groups?per_page=100&min_access_level=10"` to discover GitLab groups — read each entry's `full_path` field. (`glab` has no `group` subcommand at all — invoking one exits 1 with `Unknown command "group"`.) Present findings via AskUserQuestion.
+6. **GitLab group** — Select the GitLab host explicitly, then discover available groups dynamically. Run `ls $BASELINE_PATH/templates/` for project types, and check for a groups config in `$BASELINE_PATH/config/` or run `glab api --hostname "$GITLAB_HOST" "groups?per_page=100&min_access_level=10"` to discover GitLab groups — read each entry's `full_path` field. (`glab` has no `group` subcommand at all — invoking one exits 1 with `Unknown command "group"`.) Present findings via AskUserQuestion.
 
 ### Wave 2 — Technical Details (5 questions, dynamic per archetype)
 
@@ -134,6 +134,12 @@ Map gathered answers to script input choices:
 # namespace in a separate variable — every later step addresses the project as
 # "<group-path>/<project>", and a numeric index there silently targets nothing.
 GROUP_PATH="$(...)"    # e.g., "products" — the full_path of the chosen group
+
+# These values identify the NEW project, not the directory in which this plan runs.
+# Select the host with the group; do not let glab infer it from an ambient remote.
+GITLAB_HOST="<selected GitLab hostname>"
+PROJECT_PATH="$GROUP_PATH/$PROJECT_NAME"
+ENCODED_PROJECT_PATH="$(node -e 'process.stdout.write(encodeURIComponent(process.argv[1]))' "$PROJECT_PATH")"
 (
   echo "$TYPE_CHOICE"    # e.g., "1" for nextjs-saas
   echo "$STYLE_CHOICE"   # e.g., "1" for vega (only if nextjs-saas)
@@ -145,10 +151,12 @@ GROUP_PATH="$(...)"    # e.g., "products" — the full_path of the chosen group
 
 ### Step 2: Verify success
 
-Check exit code. Confirm repo exists:
+Check the setup script exit code. Confirm the selected path exists without fetching a full REST project object:
 
 ```bash
-glab repo view "$GROUP_PATH/$PROJECT_NAME"
+glab api --hostname "$GITLAB_HOST" graphql \
+  -f query='query($fullPath: ID!) { project(fullPath: $fullPath) { fullPath } }' \
+  -f fullPath="$PROJECT_PATH" | jq -er '.data.project.fullPath'
 ```
 
 ### Step 3: Adjust visibility
@@ -157,27 +165,29 @@ If visibility is not `internal` (the default):
 
 ```bash
 # There is no `glab repo edit`, and `glab repo update` carries no --visibility
-# flag (its FLAGS are --archive/--defaultBranch/-d/--description). Go through the
-# API, addressing the project by its URL-encoded path — `projects/:id` resolves
-# from the CWD remote, which is the wrong project right after scaffolding.
-ENCODED="${GROUP_PATH}%2F${PROJECT_NAME}"
-glab api -X PUT "projects/${ENCODED}" -f visibility=private   # or visibility=public
-
-# Verify (this GET is the read-only proof the PUT landed). Note `glab api` has
-# no --jq flag — that is `gh api`'s. Pipe to jq instead.
-glab api "projects/${ENCODED}" | jq -r '.visibility'
+# flag (its FLAGS are --archive/--defaultBranch/-d/--description). The encoded
+# endpoint and explicit host target the new project independently of the CWD.
+glab api --silent --hostname "$GITLAB_HOST" -X PUT \
+  "projects/${ENCODED_PROJECT_PATH}" \
+  -f visibility=private   # or visibility=public
+
+# Fetch only the scalar needed to verify the mutation, never a full REST object.
+glab api --hostname "$GITLAB_HOST" graphql \
+  -f query='query($fullPath: ID!) { project(fullPath: $fullPath) { visibility } }' \
+  -f fullPath="$PROJECT_PATH" | jq -er '.data.project.visibility'
 ```
 
-> The GET path above is verified against glab 1.91.0; the PUT is the documented
-> GitLab API shape but was **not** executed during authoring (write operations
-> were out of scope). Confirm with the GET before relying on it.
+> The GraphQL verification query is read-only and requests only `visibility`; the
+> PUT's unused response is intentionally suppressed. Confirm the selected host and
+> path before running the mutation.
 
 For public/OSS, also configure GitHub mirror if applicable.
 
 ### Step 4: Set branch protection
 
 ```bash
-glab api -X PUT projects/:id/protected_branches \
+glab api --silent --hostname "$GITLAB_HOST" -X POST \
+  "projects/${ENCODED_PROJECT_PATH}/protected_branches" \
   -f name=main \
   -f push_access_level=30 \
   -f merge_access_level=30
@@ -282,7 +292,7 @@ Always use the `priority::<level>` format in VCS CLI commands, not P0/P1/P2/P3.
 
 ### Step 4: Present for user confirmation
 
-Use AskUserQuestion to present the full issue structure:
+Use the AskUserQuestion payload in `SKILL.md` § 6.3 verbatim — the issue table belongs in the option's `preview` field, not in the question text:
 
 - Epic title and description
 - Sub-issues with: title, priority, labels, dependency links
@@ -292,11 +302,11 @@ Use AskUserQuestion to present the full issue structure:
 
 ```bash
 # Create epic
-glab issue create -R "$GROUP_PATH/$PROJECT_NAME" --title "$EPIC_TITLE" --description "$EPIC_DESC" \
+glab issue create -R "https://${GITLAB_HOST}/${PROJECT_PATH}" --title "$EPIC_TITLE" --description "$EPIC_DESC" \
   --label "type:epic,priority::$PRIORITY" --milestone "$MILESTONE"
 
 # Create sub-issues
-glab issue create -R "$GROUP_PATH/$PROJECT_NAME" --title "$ISSUE_TITLE" --description "$ISSUE_DESC" \
+glab issue create -R "https://${GITLAB_HOST}/${PROJECT_PATH}" --title "$ISSUE_TITLE" --description "$ISSUE_DESC" \
   --label "type:feature,priority::$PRIORITY,status:ready,area:$AREA,appetite:$APPETITE"
 ```
 
@@ -305,10 +315,12 @@ glab issue create -R "$GROUP_PATH/$PROJECT_NAME" --title "$ISSUE_TITLE" --descri
 For issues with technical dependencies, set `blocks`/`is-blocked-by` relationships:
 
 ```bash
-# Issue #2 is blocked by Issue #1
-glab api -X POST projects/:id/issues/:issue2_iid/links \
-  -f target_project_id=:id \
-  -f target_issue_iid=:issue1_iid \
+# Issue #2 is blocked by Issue #1 in this project. An encoded project path is
+# valid for target_project_id, so no numeric project ID is needed.
+glab api --silent --hostname "$GITLAB_HOST" -X POST \
+  "projects/${ENCODED_PROJECT_PATH}/issues/${ISSUE_2_IID}/links" \
+  -f target_project_id="$ENCODED_PROJECT_PATH" \
+  -f target_issue_iid="$ISSUE_1_IID" \
   -f link_type=is_blocked_by
 ```
 

package/skills/plan/soul.md

@@ -69,6 +69,18 @@ The active level is `efficiency.output-level` in `~/.config/session-orchestrator
 - Shape: name the alternatives you rejected and why, spell out the appetite and the scope cuts, define unfamiliar terms on first use.
 - Escalation: `expand <topic>` — see § Escalation above.
 
+### Register — how a sentence reads
+
+The budgets above set *how much* you say; the register sets *how*. It is
+defined once, in `skills/session-start/soul.md` § "Register — how a sentence
+reads", and binds here unchanged: the frame ("write for someone who knows this
+project but has not seen what you just saw"), the plain-words test with its
+five worked cases, and its precedence over § "Never traded for brevity" above.
+Read it there. It is not repeated here on purpose — the § Output Levels intro
+sentence already exists in four copies across the four souls with nothing
+checking their parity, and a fifth copied rule would drift the same way. A
+pointer cannot.
+
 ### Companion dials
 
 Same file, same lookup, same fallback-to-default rule:

package/skills/reconcile/SKILL.md

@@ -243,12 +243,12 @@ For each batch (proposals sliced into groups of 4):
 ```
 AskUserQuestion({
   questions: [{
-    question: "Which rule proposals should be written to .claude/rules/?  (batch K of N)",
-    header: "Reconcile — Approve Rule Proposals",
+    question: "Batch K of N — which rule proposals should be written into .claude/rules/?",
+    header: "Regeln",
     options: [
       {
         label: "<slug>.md (confidence: 0.72)",
-        description: "Learning: <learningKey> | Path: .claude/rules/<slug>.md | <first 100 chars of rendered content>"
+        description: "From learning <learningKey>. Becomes a file under .claude/rules/ — where this repo keeps its rules. Text: <first 100 chars of rendered content>"
       },
       ...up to 4 options per batch...
       {