Automated Sync from main to stable

.agents/skills/build-openshell-mxc-windows/SKILL.md

@@ -215,8 +215,8 @@ compatibility under emulation is not part of these tasks. The aggregate
 commands above on an ARM64 host.
 
 The repository-wide `mise run pre-commit` task is also supported on Windows.
-Run `rust:lockfiles:check`, `sdk:ts:ci`, `go:ci`, and `test:e2e-parity` through
-the Windows-aware tasks when validating those surfaces. Do not count the Go
+Run `rust:lockfiles:check`, `sdk:ts:ci`, and `go:ci` through the Windows-aware
+tasks when validating those surfaces. Do not count the Go
 Windows ARM64 race-detector exclusion or POSIX permission-bit skips as security
 coverage. SDK test dependencies must remain at their lockfile versions.
 Its Rust check, Clippy, and test dependencies enter the same MSVC environment
@@ -265,7 +265,7 @@ MXC on Windows. Each other `compute-driver-*` feature installs its own Windows
 rejection stub without linking that driver crate. The default
 `in-tree-compute-drivers` alias enables all five features. An MXC-only build
 uses `--no-default-features --features compute-driver-mxc` (add `telemetry`
-and `bundled-z3` as needed).
+and `openshell-server/prebuilt-z3` as needed).
 
 | Driver | Windows build behavior | Runtime behavior |
 |---|---|---|

.agents/skills/create-github-issue/SKILL.md

@@ -19,15 +19,15 @@ This project uses YAML form issue templates. When creating issues, match the tem
 
 ### Bug Reports
 
-Do not add a type label automatically. The body must include a **User Story**, **Problem Statement**, **Impact / Why This Matters**, and **Acceptance Criteria**, followed by bug-specific reproduction steps and environment details. Logs are optional and must be concise and redacted. Apply area or topic labels only when they are clearly known.
+Do not add a type label automatically. Confirm that the human operator personally uses OpenShell and directly encountered the problem or needs the feature for a specific use case. If that first-hand attestation or concrete use case is missing, ask for it before creating the issue. Frame the issue entirely in terms of OpenShell. The body must include a **User Story**, **Problem Statement**, **Impact / Why This Matters**, and **Acceptance Criteria**, followed by bug-specific reproduction steps using only OpenShell deployments and environment details. Do not install third-party tools to demonstrate reproducibility. Logs are optional and must be concise and redacted. If the issue suggests a change to configuration, CLI, SDK, or other user experience, include a notional example of the proposed interaction for human review. Inspect current repository labels before applying any; use only labels whose meaning is clear.
 
 ```bash
 gh issue create \
   --title "bug: <concise description>" \
   --body "$(cat <<'EOF'
 ## User Story
 
-As a <persona>, I want <capability or outcome>, so that <benefit or impact>.
+I use OpenShell for <specific use case>. I directly encountered or need <specific behavior> so that <outcome>.
 
 ## Problem Statement
 
@@ -52,26 +52,28 @@ As a <persona>, I want <capability or outcome>, so that <benefit or impact>.
 - OS: <os>
 - Runtime, deployment, or integration: <relevant details>
 
+## Suggested UX (if applicable)
+
+<Notional OpenShell CLI, configuration, SDK, or other interaction>
+
 ## Logs
 
-```
-<optional minimal, redacted output>
-```
+<Optional minimal, redacted output>
 EOF
 )"
 ```
 
 ### Feature Requests
 
-Do not add a type label automatically. The body must include a **User Story**, **Problem Statement**, **Impact / Why This Matters**, **Proposed Design**, **Acceptance Criteria**, and **Alternatives Considered**. The proposed design should define the user-facing workflow and externally observable behavior without prescribing internal implementation. Agent investigation is optional. Apply area or topic labels only when they are clearly known.
+Do not add a type label automatically. Confirm that the human operator personally uses OpenShell and directly encountered the problem or needs the feature for a specific use case. If that first-hand attestation or concrete use case is missing, ask for it before creating the issue. Frame the issue entirely in terms of OpenShell. The body must include a **User Story**, **Problem Statement**, **Impact / Why This Matters**, **Proposed Design**, **Acceptance Criteria**, and **Alternatives Considered**. The proposed design should define the user-facing workflow and externally observable behavior without prescribing internal implementation. Agent investigation is optional. If the issue suggests a change to configuration, CLI, SDK, or other user experience, include a notional example of the proposed interaction for human review. Inspect current repository labels before applying any; use only labels whose meaning is clear.
 
 ```bash
 gh issue create \
   --title "feat: <concise description>" \
   --body "$(cat <<'EOF'
 ## User Story
 
-As a <persona>, I want <capability or outcome>, so that <benefit or impact>.
+I use OpenShell for <specific use case>. I directly encountered or need <specific behavior> so that <outcome>.
 
 ## Problem Statement
 
@@ -85,13 +87,17 @@ As a <persona>, I want <capability or outcome>, so that <benefit or impact>.
 
 <The desired user-facing workflow and externally observable behavior, without prescribing internal implementation>
 
+## Suggested UX (if applicable)
+
+<Notional OpenShell CLI, configuration, SDK, or other interaction>
+
 ## Acceptance Criteria
 
 - [ ] <specific, observable outcome>
 
 ## Alternatives Considered
 
-<Other user-facing workflows or behaviors considered and why this approach best satisfies the user story>
+<Other OpenShell workflows considered, including relevant middleware, interceptors, providers, or other extension points, and why the proposal better serves the use case. Prefer an applicable extension when it satisfies the use case; running another service alone is not a reason to dismiss it.>
 
 ## Agent Investigation
 
@@ -102,12 +108,16 @@ EOF
 
 ### Tasks
 
-For internal tasks that don't fit bug/feature templates:
+For internal tasks that do not fit bug/feature templates, still obtain the operator's first-hand OpenShell use case before creating the issue:
 
 ```bash
 gh issue create \
   --title "<type>: <description>" \
   --body "$(cat <<'EOF'
+## User Story
+
+<I personally use OpenShell for this specific case and directly need this work because...>
+
 ## Description
 
 <Clear description of the work>
@@ -125,7 +135,7 @@ EOF
 
 GitHub built-in issue types (`Bug`, `Feature`, `Task`) should come from the matching issue template when possible, or be set manually afterward. Do not try to emulate them through labels.
 
-Creating an issue does not accept it or queue agent work. Agents never apply `state:accepted`, the `roadmap` label, add issues to the roadmap project, or apply `agent:plan-requested` or `agent:implementation-requested`. Community issues proceed through `triage-issue`; a human accepts technically validated work with `state:accepted` or roadmap placement. The request labels queue work for unattended agents. A user may instead direct an agent to a specific issue; the agent warns about missing expected workflow labels and continues with the requested phase without changing them.
+Creating an issue does not accept it. Inspect the repository’s current `state:*` labels and follow its triage → validation → human acceptance process. Agents may assess facts, but only humans decide whether to accept work or place it on the roadmap. A direct user request authorizes the requested planning or implementation phase without changing issue disposition.
 
 ## Useful Options
 
@@ -150,5 +160,5 @@ Created issue [#123](https://github.com/OWNER/REPO/issues/123)
 
 Use the issue number to:
 
-- Reference in commits: `git commit -m "Fix validation error (fixes #123)"`
-- Create a branch following project convention: `<issue-number>-<description>/<username>`
+- Reference in signed-off Conventional Commits: `git commit --signoff -m "fix(cli): validate empty requests (fixes #123)"`
+- Create a branch following project convention: `<type>/<issue-id>-<short-description>/<github-username>`, where `<type>` is a Conventional Commits type.

.agents/skills/create-github-pr/SKILL.md

@@ -13,7 +13,7 @@ Create pull requests on GitHub using the `gh` CLI.
 
 - The `gh` CLI must be authenticated (`gh auth status`)
 - You must have commits on a branch that's pushed to the remote
-- For issue-backed work, the branch should follow `<issue-number>-<description>/<username>`. Exempt issue-less changes may use `<description>/<username>`.
+- Every PR must close an existing issue. The branch should follow `<type>/<issue-id>-<short-description>/<github-username>`.
 
 ## Before Creating a PR
 
@@ -30,13 +30,11 @@ deployment docs.
 
 Use the `sync-agent-infra` skill's maintenance map to identify related skill updates when the branch changes behavior, commands, or development workflows. Run its full consistency check when the branch adds, removes, or renames skills or crates; changes workflow relationships or skill coverage; modifies issue or PR templates; or changes agent cross-references. Resolve any drift before creating the PR.
 
-### Run Pre-commit Checks
+### Verify the Affected Areas
 
-Run the local pre-commit task before opening a PR:
+Use the verification guidance in `CONTRIBUTING.md` to select checks for the changed files and behavior. Guidance, skills, and template changes need applicable Markdown, YAML, link, and consistency checks. Run Rust or SDK suites when those components or their dependencies can be affected. Shared APIs, schemas, dependencies, and build changes may require broader checks even when component source files are unchanged.
 
-```bash
-mise run pre-commit
-```
+`mise run ci` and `mise run pre-commit` are broad convenience tasks, not blanket PR prerequisites. Broaden validation only for a concrete remaining risk or failed check, and report what actually ran.
 
 ### Verify Branch State
 
@@ -49,21 +47,13 @@ Before creating a PR, verify:
    git branch --show-current
    ```
 
-2. **Branch follows naming convention** - Use `<issue-number>-<description>/<initials>` for issue-backed work or `<description>/<initials>` for an exempt issue-less change.
+2. **Branch follows naming convention** - Use `<type>/<issue-id>-<short-description>/<github-username>`, where `<type>` is a Conventional Commits type.
 
    ```bash
-   # Example: 1234-add-pagination/jd
+   # Example: feat/1234-add-pagination/johntmyers
    git branch --show-current
    ```
 
-3. **Consider squashing commits** - For cleaner history, squash related commits before pushing:
-
-   ```bash
-   # Squash last N commits into one
-   git reset --soft HEAD~N
-   git commit -m "feat(component): description"
-   ```
-
 ### Push Your Branch
 
 Ensure your branch is pushed to the remote:
@@ -116,19 +106,25 @@ gh pr create --title "PR title" --body "PR description"
 
 ### Link to an Issue
 
-Features, user-visible behavior changes, public API changes, architecture changes, and multi-PR efforts must link an accepted issue. Use `Closes #<issue-number>` in the body to auto-close the issue when merged:
+Every PR must close its own issue. Verify that the issue exists, remains open, and covers the PR scope. Use `Closes #<issue-number>` in the body so merge closes it:
 
 ```bash
 gh pr create \
-  --title "Fix validation error for empty requests" \
-  --body "Closes #123
+  --title "fix(cli): validate empty requests" \
+  --body "## Summary
 
-## Summary
-- Added validation for empty request bodies
-- Returns 400 instead of 500"
+Validate empty request bodies.
+
+## Related Issue
+
+Closes #123
+
+## Changes
+
+- Return 400 instead of 500"
 ```
 
-Small documentation fixes, mechanical maintenance, and obvious localized bug fixes may omit a separate issue when the PR contains enough context to review the decision and implementation together. In that case, write `No issue required: <brief reason>` in the Related Issue section. Do not use this exception for security fixes; follow `SECURITY.md`.
+If the work needs multiple PRs, create a separate closable issue for each PR. A higher-level tracking issue may link the component issues, but no PR should close that tracking issue until all its work is complete. Follow `SECURITY.md` for vulnerability disclosure. First-time external contributors must be vouched before their PRs are accepted; the vouch check may close unvouched PRs. Check the current vouch process before opening a PR for an external contributor.
 
 ### Create as Draft
 
@@ -138,12 +134,6 @@ For work-in-progress that's not ready for review:
 gh pr create --draft --title "WIP: New feature"
 ```
 
-### With Labels
-
-```bash
-gh pr create --title "Title" --label "area:cli" --label "topic:security"
-```
-
 ### Target a Different Branch
 
 Default target is `main`. To target a different branch:
@@ -161,15 +151,15 @@ PR descriptions must follow the project's [PR template](.github/PULL_REQUEST_TEM
 <!-- 1-3 sentences: what this PR does and why -->
 
 ## Related Issue
-<!-- Fixes #NNN / Closes #NNN, or "No issue required: <reason>" for an exempt change -->
+<!-- Closes #NNN; this issue covers the scope of this PR -->
 
 ## Changes
 <!-- Bullet list of key changes -->
 
 ## Testing
 <!-- What testing was done? -->
-- [ ] `mise run pre-commit` passes
-- [ ] Unit tests added/updated
+- [ ] Checks appropriate to the affected code and behavior pass
+- [ ] Unit tests added/updated (if applicable)
 - [ ] E2E tests added/updated (if applicable)
 
 ## Checklist
@@ -201,7 +191,7 @@ Closes #456
 
 ## Testing
 
-- [x] `mise run pre-commit` passes
+- [x] Relevant CLI format, lint, and unit checks pass
 - [x] Unit tests added/updated
 - [ ] E2E tests added/updated (if applicable)