@starlein/paperclip-plugin-company-wizard 0.4.5 → 0.4.7

package/templates/modules/github-repo/docs/git-workflow.md

@@ -33,18 +33,72 @@ directory inside the repository. This must never be committed.
 - Committing `.paperclip/` pollutes history and can nest isolated worktrees inside the
   repo, which causes confusing git state for every agent.
 
-## Direct-to-Base-Ref Workflow
+## GitHub Push Authentication
+
+Paperclip injects the project secret `GH_TOKEN` into agent runs when the project env maps
+`GH_TOKEN` to the secret. Git does not use that variable automatically, and some sandboxed
+push subprocesses can drop environment variables exactly when Git asks its credential
+helper for credentials. Every GitHub-backed project must install a repository-local
+credential helper during foundation setup before the first push.
+
+Run this from the primary project workspace, never from inside an issue worktree:
+
+```bash
+git_common_dir="$(git rev-parse --git-common-dir)"
+helper="$git_common_dir/paperclip-gh-credential-helper.sh"
+cache="$git_common_dir/paperclip-gh-token-cache"
+
+cat > "$helper" <<'EOF'
+#!/bin/sh
+cache="$(dirname "$0")/paperclip-gh-token-cache"
+if [ -n "$GH_TOKEN" ]; then
+  ( umask 077; printf '%s' "$GH_TOKEN" > "$cache" ) 2>/dev/null
+fi
+if [ "$1" = "get" ]; then
+  token="$GH_TOKEN"
+  [ -z "$token" ] && [ -r "$cache" ] && token="$(cat "$cache" 2>/dev/null)"
+  [ -n "$token" ] && printf 'username=x-access-token\npassword=%s\n' "$token"
+fi
+exit 0
+EOF
+
+chmod 700 "$helper"
+[ -n "$GH_TOKEN" ] && ( umask 077; printf '%s' "$GH_TOKEN" > "$cache" )
+chmod 600 "$cache" 2>/dev/null || true
+git config --local credential.helper "$helper"
+```
+
+Rules:
+- Do not print, commit, or paste the token. The helper cache lives under Git's private
+  common directory, not in the worktree.
+- If `GH_TOKEN` is empty during setup, stop and ask the CEO/board to bind a writable
+  GitHub token as the project secret before continuing.
+- Re-run the setup after rotating the secret; the cache refreshes whenever `GH_TOKEN`
+  is present in a later agent run.
+- Verify the helper without exposing the token: `git config --local --get credential.helper`
+  should print the helper path, and `test -s "$(git rev-parse --git-common-dir)/paperclip-gh-token-cache"`
+  should succeed after a run where `GH_TOKEN` was injected.
+
+## PR Self-Merge Flow
+
+Use this flow when the **pr-review module is not active** (no Code Reviewer role, no executionPolicy review stages). You open a PR and merge it yourself — there is no external review gate, but all changes go through a PR so branch history is preserved and branch protection is respected. When PR review is active, use the PR workflow from `docs/pr-conventions.md` instead.
 
 1. Resolve the configured base ref from project workspace metadata or the issue's `heartbeat-context` before touching Git. Do not infer it from the current shell branch and do not rewrite it to `main`, `master`, or `origin/*`.
    - External repos: use the project/worktree `repoRef`, `defaultRef`, or `executionWorkspacePolicy.workspaceStrategy.baseRef` exactly as configured.
    - Fresh/local repos: use the configured local branch.
    - Only if no base ref is configured anywhere, detect the repository's default branch — see *Resolving the default branch* below. Never hard-code `main`.
 2. Pull/fetch latest from that base before editing.
-3. Make changes
-4. Run tests/linting locally if available
-5. Commit with conventional commit message
-6. Push to the matching configured base branch
-7. Verify CI passes (if configured)
+3. **Create a feature branch** from the base ref: `git checkout -b <branch-name> <base-ref>`. Never commit directly on the base branch. The branch name should reference the issue (e.g., `LEA-5-add-landing-hero`). If you are already on a correctly named feature branch, skip this step.
+4. **Verify you are on the feature branch** before making changes: `git branch --show-current` must print `<branch-name>`, not the base ref. If it prints the base ref name, you forgot step 3 — create the branch now.
+5. Make changes
+6. Run tests/linting locally if available
+7. Commit with conventional commit message
+8. **Verify the current branch one more time**, then push: `git push -u origin <branch-name>`. The branch name in the push command must match `git branch --show-current`. Never push the base ref as a feature branch — if `git branch --show-current` returns the base ref name, stop and create a feature branch first.
+9. Open a pull request against the base ref: write the PR body to a temp file, then `gh pr create --base <github-base-branch> --head <branch-name> --title "<type>: <description>" --body-file <file>`. Never inline `--body "..."` — a double-quoted shell string keeps `\n` literal (see *Posting PR Bodies & Comments* in `docs/pr-conventions.md`). Verify the PR base matches the configured base ref before merging.
+10. Merge the PR yourself: `gh pr merge <PR-number> --merge`. Do not wait for a reviewer if none is present. Confirm the PR is closed and the base branch updated before continuing. Never do a direct `git merge` + push to the base branch; always go through a PR.
+11. Clean up the feature branch: `git push origin --delete <branch-name>` (remote) and `git branch -d <branch-name>` (local).
+12. If the issue uses an isolated execution workspace (worktree), archive it from `heartbeat-context` after the merge is pushed.
+13. Verify CI passes on the base branch (if configured). If CI fails, fix immediately.
 
 ## Resolving the default branch
 
@@ -86,6 +140,11 @@ For a brand-new local repository there is no remote yet, so initialize on `main`
 - If Paperclip created an isolated execution workspace for this issue, close/archive it after the commit/PR has landed and before marking `done`. If cleanup is blocked or fails, leave the issue open with the exact cleanup blocker. If the issue is in the shared project workspace, do not invent isolated-worktree cleanup.
 - If no repository change is required, do not silently close as `done`: add an issue comment explaining why no code change was needed and escalate to the CEO for explicit decision.
 
+## Branch Safety
+
+- **Always work on a feature branch, never on the base branch.** Create the branch with `git checkout -b <branch-name> <base-ref>` before committing any changes. If you are resuming work on an existing issue, `git branch --show-current` should already show the feature branch name.
+- **Verify your branch before pushing.** Before running `git push -u origin <branch-name>`, confirm that `git branch --show-current` prints the feature branch name — not the base ref. If it prints the base ref, you are on the wrong branch: stop and create/switch to the feature branch first. Pushing the base ref as a feature branch corrupts upstream tracking and causes incorrect branch divergence reports.
+
 ## CI
 
 If the project has CI configured (e.g., GitHub Actions), always verify your push passes CI. If CI fails, fix it immediately — a broken base ref blocks everyone.

package/templates/modules/github-repo/module.meta.json

@@ -9,7 +9,7 @@
       "priority": "critical",
       "bootstrapPhase": "foundation",
       "labels": ["chore"],
-      "description": "Foundation setup: handle this before normal implementation issues. For a fresh repository, create the GitHub repository, initialize the local workspace with a README or bootstrap commit, add origin, push the default branch (`main` for a fresh repo), and record the repository URL. For an existing repository, verify the workspace has a reachable remote and a starter commit state, then determine the repository's default branch and confirm it is recorded as the project workspace `defaultRef`/`repoRef` so isolated worktrees branch from the correct base. The default branch is whatever `origin/HEAD` points at — name-agnostic (`main`, `master`, `trunk`, etc.); use it exactly as the remote advertises it (`git ls-remote --symref origin HEAD`). Only if the remote advertises no default HEAD, fall back to `main`, then `master`. Never assume `main` for an existing repo. Escalate to CEO if repo setup is missing instead of silently closing the issue. Before the first commit, ensure the repository's `.gitignore` ignores Paperclip's local state — add a `.paperclip/` entry (this is where Paperclip keeps per-issue git worktrees and workspace metadata inside the repo; committing it pollutes history and can nest worktrees inside the repo). Create `.gitignore` if it is missing. Branch protection is tracked separately by the pr-review module when that workflow is enabled."
+      "description": "Foundation setup: handle this before normal implementation issues. For a fresh repository, create the GitHub repository, initialize the local workspace with a README or bootstrap commit, add origin, push the default branch (`main` for a fresh repo), and record the repository URL. For an existing repository, verify the workspace has a reachable remote and a starter commit state, then determine the repository's default branch and confirm it is recorded as the project workspace `defaultRef`/`repoRef` so isolated worktrees branch from the correct base. The default branch is whatever `origin/HEAD` points at — name-agnostic (`main`, `master`, `trunk`, etc.); use it exactly as the remote advertises it (`git ls-remote --symref origin HEAD`). Only if the remote advertises no default HEAD, fall back to `main`, then `master`. Never assume `main` for an existing repo. Install the Paperclip GitHub credential helper from `docs/git-workflow.md` before the first push so `git push` uses the injected `GH_TOKEN` project secret even when sandboxed subprocesses strip environment variables at credential-lookup time. Escalate to CEO if repo setup or `GH_TOKEN` is missing instead of silently closing the issue. Before the first commit, ensure the repository's `.gitignore` ignores Paperclip's local state — add a `.paperclip/` entry (this is where Paperclip keeps per-issue git worktrees and workspace metadata inside the repo; committing it pollutes history and can nest worktrees inside the repo). Create `.gitignore` if it is missing. Branch protection is tracked separately by the pr-review module when that workflow is enabled."
     }
   ]
 }

package/templates/modules/market-analysis/agents/ux-researcher/skills/market-analysis.md

@@ -12,7 +12,7 @@ You own market research with a focus on user needs and behavior. This is your co
    - **Positioning**: Where the biggest user need gaps are
    - **Risks**: Adoption barriers, user switching costs, behavioral resistance
 3. Create follow-up issues for deeper research if needed:
-   - `POST /api/companies/{companyId}/issues` for user interview plans, usability benchmarks. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+   - `POST /api/companies/{companyId}/issues` for user interview plans, usability benchmarks. Include the active `projectId` (and `goalId` / `parentId` when applicable). For top-level issues (no `parentId`), also include `"executionWorkspaceSettings": { "mode": "isolated_workspace" }` so each gets its own worktree; subissues set `parentId` and omit it.
 4. Share findings by updating the assigned issue/document and assigning concrete follow-up actions to the Product Owner and CEO when needed; do not rely on generic @-mentions.
 
 ## Rules

package/templates/modules/market-analysis/skills/market-analysis.md

@@ -11,7 +11,7 @@ You own market research and competitive analysis. This informs the product roadm
    - **Positioning**: How do we differentiate? What's our unique value proposition?
    - **Risks**: Market risks, timing risks, adoption barriers
 3. Create follow-up issues for any strategic decisions needed:
-   - `POST /api/companies/{companyId}/issues` with findings that require input. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+   - `POST /api/companies/{companyId}/issues` with findings that require input. Include the active `projectId` (and `goalId` / `parentId` when applicable). For top-level issues (no `parentId`), also include `"executionWorkspaceSettings": { "mode": "isolated_workspace" }` so each gets its own worktree; subissues set `parentId` and omit it.
 4. Record summary in your daily notes
 
 ## Rules

package/templates/modules/pr-review/agents/devops/skills/infra-review.md

@@ -14,16 +14,14 @@ You review PRs for infrastructure impact, performance, security, and operational
 
 ## How to Review
 
-1. When you are the active participant of a review stage on an issue with a PR link, review the PR.
+1. When a PR changes deployments, configs, dependencies, or system behavior, review it for the infra concerns below.
 2. Focus on infrastructure, deployment, runtime security, observability, and rollback risk.
-3. Record your verdict through the normal issue update route for your review stage:
-   - **approved** if operationally sound
-   - **changes_requested** with specific concerns if not
-4. Optionally mirror the verdict as a GitHub PR comment — write it to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
+3. Post your verdict as an **advisory** GitHub PR comment — you are not a blocking review stage, so do not record a stage verdict (no `approved`/`changes_requested` on the issue's executionPolicy). Write the comment to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
+4. If you find a concern that should block the merge, flag it as **blocking-severity** in the comment and name who should act on it — for security issues (exposed secrets, critical vulnerabilities), that is the Security Engineer review stage when one exists, otherwise QA or the Code Reviewer merge gate — so a blocking reviewer can incorporate it into their verdict. You do not block the merge yourself.
 
 ## Rules
 
-- Security issues are always blockers — never approve PRs with exposed secrets or critical vulnerabilities.
-- Performance concerns are blockers only if they affect production. Flag others as suggestions.
-- Approve changes with no infrastructure impact without comment.
+- Flag security issues (exposed secrets, critical vulnerabilities) as blocking-severity in your advisory comment so the Security Engineer (or merge gate) acts on them; you do not yourself withhold a stage verdict. When a Security Engineer review stage exists, defer security blocking to it.
+- Performance concerns are blocking-severity only if they affect production; flag others as suggestions.
+- Comment only on changes with infrastructure impact.
 - If a change needs a migration or deployment step, ensure it's documented in the PR.

package/templates/modules/pr-review/agents/engineer/skills/pr-workflow.md

@@ -9,20 +9,38 @@ When this skill is active, you work in feature branches and open PRs instead of
    - external: `git fetch origin`, then branch from the configured base ref
    - local: update from the configured local branch
 3. Create branch from that base: `git checkout -b <prefix>-<N>/<short-description> <base-ref>`
-4. Make your changes, commit with Conventional Commits format
-5. Push branch: `git push -u origin <branch-name>`
-6. Open PR against the same resolved base: derive the GitHub base branch from the configured ref (for example, strip the remote prefix only when the ref is remote-tracking), write the body (PR Body Template in `docs/pr-conventions.md`) to a file, then `gh pr create --base <github-base-branch> --head <branch-name> --title "<type>: <description>" --body-file <file>`. Never inline `--body "..."` — a double-quoted shell string keeps `\n` literal and the PR renders as `text\ntext` (see *Posting PR Bodies & Comments*).
-7. Set the originating issue's `executionPolicy` to gate the merge on review, ending with the Code Reviewer as the merge gate:
+4. **Verify you are on the feature branch** before making changes: `git branch --show-current` must print your branch name, not the base ref. If it prints the base ref name, you forgot step 3 — create the branch now.
+5. Make your changes, commit with Conventional Commits format
+6. **Verify the current branch one more time**, then push: `git push -u origin <branch-name>`. The branch name in the push command must match `git branch --show-current`. Never push the base ref as a feature branch — if `git branch --show-current` returns the base ref name, stop and create a feature branch first.
+7. Open PR against the same resolved base: derive the GitHub base branch from the configured ref (for example, strip the remote prefix only when the ref is remote-tracking), write the body (PR Body Template in `docs/pr-conventions.md`) to a file, then `gh pr create --base <github-base-branch> --head <branch-name> --title "<type>: <description>" --body-file <file>`. Never inline `--body "..."` — a double-quoted shell string keeps `\n` literal and the PR renders as `text\ntext` (see *Posting PR Bodies & Comments*).
+8. **Register the PR as a Paperclip work product** so it is visible on the issue and board (creating it on GitHub alone does not surface it in Paperclip):
+   ```
+   POST /api/issues/{issueId}/work-products
+   Headers: Authorization: Bearer $PAPERCLIP_API_KEY, X-Paperclip-Run-Id: $PAPERCLIP_RUN_ID
+   {
+     "type": "pull_request",
+     "provider": "github",
+     "externalId": "<PR number>",
+     "url": "<full PR URL>",
+     "title": "<PR title>",
+     "status": "ready_for_review",
+     "isPrimary": true
+   }
+   ```
+   `title` and `url` are required (`url` must be the full PR URL). If the issue runs in an isolated worktree, also pass `"executionWorkspaceId"` from `heartbeat-context`. When the PR later merges, update it with `PATCH /api/work-products/{id}` and `"status": "merged"`.
+9. **Only if a code-reviewer is present on the team:** Set the originating issue's `executionPolicy` to gate the merge on review, ending with the Code Reviewer as the merge gate. If no code-reviewer is assigned to this company, skip steps 9–11 entirely and go directly to the self-merge path at step 12. Setting up executionPolicy stages without an eligible non-author merge gate will stall the issue permanently (`422 No eligible approval participant`).
    - One `review` stage with **QA** when a QA agent exists (test adequacy / executed verification).
    - One `review` stage with the **Security Engineer** only when the change is security-relevant (auth, secrets, input boundaries, crypto, dependencies, infra exposure).
-   - Additional `review` stages only for domain reviewers that should block this specific change.
-   - An `approval` stage with the **Product Owner** as participant (always) — the product sign-off.
-   - A final `approval` stage with the **Code Reviewer** as participant — the **merge gate**. The Code Reviewer is woken *last*, after every reviewer and the Product Owner have cleared, to satisfy the hard verification gate and merge the PR. If the team has no Code Reviewer, use another present non-author agent (e.g. DevOps, the Product Owner, or another engineer) — never yourself.
+   - Domain reviewers (UI Designer, UX Researcher, DevOps) are advisory — they post PR comments and may flag a concern for QA, the Security Engineer, or the merge gate to act on. They are never themselves a review stage.
+   - An `approval` stage with the **Product Owner** when a Product Owner is on the team — the product sign-off. If no Product Owner is present, omit this stage.
+   - A final `approval` stage with the **Code Reviewer** as participant — the **merge gate**. The Code Reviewer is woken *last*, after every reviewer and the Product Owner have cleared, to satisfy the hard verification gate and merge the PR. If the team has no Code Reviewer, do not set executionPolicy stages at all — use the self-merge path at step 12 instead.
    - **Never list yourself (the issue's executor) as a participant in any stage.** Paperclip excludes the original executor to prevent self-review; a stage whose only participant is you has no eligible participant and the issue stalls in `in_review` forever (`422 No eligible approval participant is configured for this issue`).
    - Resolve each role to its agentId first (look up active agents), then set the policy on the issue. Include the PR link in an issue comment so reviewers can find it.
-8. Move the originating issue to `in_review`.
-9. Wait for the issue to clear its review/approval stages. Each reviewer and the Product Owner records `approved` by PATCHing the issue toward `done`, or `changes_requested` by PATCHing it back to `in_progress`; Paperclip stores the reviewer/approver decision metadata on the issue. Verdicts may be mirrored as PR comments. A `changes_requested` routes the issue back to you — address it, push to the same branch, and that stage re-runs.
-10. You do not merge your own PR. The **Code Reviewer** (the non-author merge gate) lands it after every prior stage approves, satisfies the hard verification gate, and records the final `approved` that closes the issue to `done`. Your remaining job is to respond to `changes_requested`: when a stage routes the issue back to you (the `returnAssignee`), address the feedback, push to the same branch, and the routed stage re-runs.
+10. Move the originating issue to `in_review`.
+11. Wait for the issue to clear its review/approval stages. Each reviewer and the Product Owner records `approved` by PATCHing the issue toward `done`, or `changes_requested` by PATCHing it back to `in_progress`; Paperclip stores the reviewer/approver decision metadata on the issue. Verdicts may be mirrored as PR comments. A `changes_requested` routes the issue back to you — address it, push to the same branch, and that stage re-runs.
+12. **Merging the PR — two paths:**
+    - **Code Reviewer present (PR-Gate mode):** You do not merge your own PR. The Code Reviewer (the non-author merge gate) lands it after every prior stage approves, satisfies the hard verification gate (green CI or pasted test/build output), and records the final `approved` that closes the issue to `done`. Your job is to respond to `changes_requested`: when a stage routes the issue back to you, address the feedback, push to the same branch, and the stage re-runs.
+    - **No code-reviewer present (PR Self-Merge Flow):** You already skipped steps 9–11. Merge the PR yourself: `gh pr merge <N> --merge` once CI is green (or you have pasted test/build output if no CI). All other review roles (qa, product-owner, security-engineer, ui-designer, ux-researcher, devops) may leave advisory comments on the PR, but none block the merge — there are no executionPolicy stages. Update the Paperclip work product to `"status": "merged"` and archive any isolated worktree.
 
 ## Rules
 
@@ -30,9 +48,10 @@ When this skill is active, you work in feature branches and open PRs instead of
 - One PR per issue. Keep changes focused.
 - Always include `Closes [PREFIX-N]` in the PR body.
 - If a reviewer requests changes, address them, push to the same branch, and re-request review (the stage re-runs).
-- The Code Reviewer (the non-author merge gate) is the merge owner. You cannot merge your own PR — Paperclip excludes you (the executor) from every review/approval stage. Hand off cleanly by setting the policy correctly, not by merging yourself.
+- When a code-reviewer is present: the Code Reviewer is the merge owner; you cannot merge your own PR (Paperclip excludes the executor). When no code-reviewer is present: you are the merge owner; skip executionPolicy stages and merge via `gh pr merge <N> --merge` yourself.
 - Before creating a PR, verify the PR base matches the configured project/worktree base. If the base is wrong, retarget the PR before review.
-- **The merge gate must be the last stage, and it must be a non-author.** The Product Owner's `approval` is the product sign-off, not the final stage: if it were last, their verdict would auto-close the issue to `done` with the PR still open on GitHub. Append a final merge-gate `approval` stage for the **Code Reviewer** (or another present non-author agent) after the Product Owner's. Never make yourself the merge gate — Paperclip excludes the executor, so that stage stalls with `422 No eligible approval participant`.
+- **The merge gate must be the last stage, and it must be a non-author.** The Product Owner's `approval` is the product sign-off, not the final stage: if it were last, their verdict would auto-close the issue to `done` with the PR still open on GitHub. Append a final merge-gate `approval` stage for the **Code Reviewer** after the Product Owner's. Never make yourself the merge gate — Paperclip excludes the executor, so that stage stalls with `422 No eligible approval participant`. If no Code Reviewer is on the team, do not set executionPolicy stages; use the self-merge path instead.
 - Do not create separate child review issues and do not use @-mentions to request review; the executionPolicy stages are the governance signal.
 - Do not wait for GitHub-native approving reviews when all agents share the same GitHub credential; GitHub rejects self-approval. The Paperclip executionPolicy stages are the required signal unless a separate non-author GitHub reviewer credential is explicitly available.
 - Post-merge cleanup of any isolated execution workspace belongs to the merge-gate agent (they archive it from `heartbeat-context` when landing the PR). You only clean up your own worktree if you abandon a branch or the issue is cancelled before review. If this issue runs in the shared project workspace, do not invent isolated-worktree cleanup.
+- **Never push the base ref as if it were a feature branch.** Before `git push -u origin <branch-name>`, confirm that `git branch --show-current` matches `<branch-name>`. If it prints the base ref name instead, you are on the wrong branch — create or switch to the feature branch first.

package/templates/modules/pr-review/agents/product-owner/skills/product-review.md

@@ -1,6 +1,6 @@
 # Skill: Product Review
 
-You review PRs for intent alignment, scope discipline, and acceptance criteria. You are the final approver — you are the participant of the `approval` stage on the PR's issue, and your sign-off is the last gate before merge.
+You review PRs for intent alignment, scope discipline, and acceptance criteria. You are the product sign-off — the participant of the `approval` stage on the PR's issue immediately before the Code Reviewer merge gate. Your `approved` is required before the merge gate lands the PR, but you are not the final stage: the Code Reviewer's subsequent merge-gate approval is what closes the issue.
 
 ## Review Checklist
 
@@ -25,4 +25,5 @@ You review PRs for intent alignment, scope discipline, and acceptance criteria.
 - Every PR should trace back to an issue. If it doesn't, ask why.
 - Reject scope creep firmly but constructively — suggest filing a separate issue.
 - If acceptance criteria are ambiguous, clarify them before approving.
-- Your approval stage verdict is the final governance signal. Do not block only because GitHub rejects formal review submission from the shared PR-author credential — GitHub-native approval is optional unless a distinct non-author reviewer credential is explicitly available.
+- Your approval stage verdict is the product sign-off; the Code Reviewer's subsequent merge-gate approval is the final governance signal that closes the issue. Do not block only because GitHub rejects formal review submission from the shared PR-author credential — GitHub-native approval is optional unless a distinct non-author reviewer credential is explicitly available.
+- You are not a merge owner. If a Code Reviewer is absent and the team is using the PR Self-Merge Flow, the engineer merges the PR themselves; your role is advisory in that mode — post product concerns as PR comments, do not record a stage verdict.

package/templates/modules/pr-review/agents/ui-designer/skills/design-review.md

@@ -14,16 +14,14 @@ You review PRs for visual quality, brand consistency, and accessibility. When a
 
 ## How to Review
 
-1. When you are the active participant of a review stage on an issue with a PR link, review the PR.
+1. When a PR touches UI components, styles, or user-facing screens, review it for the design concerns below.
 2. Focus only on visual/design concerns — leave code logic to Code Reviewer and product scope to Product Owner.
-3. Record your verdict through the normal issue update route for your review stage:
-   - **approved** if visually sound
-   - **changes_requested** with specific, actionable feedback if not
-4. Optionally mirror the verdict as a GitHub PR comment — write it to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
+3. Post your verdict as an **advisory** GitHub PR comment — you are not a blocking review stage, so do not record a stage verdict (no `approved`/`changes_requested` on the issue's executionPolicy). Write the comment to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
+4. If you find a concern that should block the merge (e.g. a critical accessibility regression or a brand-violating change), flag it explicitly in the comment and name who should act on it — QA, the Security Engineer, or the Code Reviewer merge gate — so a blocking reviewer can incorporate it into their verdict. You do not block the merge yourself.
 
 ## Rules
 
 - Be specific — "the button should use `--color-primary`" beats "wrong color".
-- Approve changes that don't touch UI without comment — not every PR needs design review.
+- Comment only on changes that touch UI — not every PR needs design review.
 - If `docs/BRAND-IDENTITY.md` doesn't exist yet, note it but don't block the PR.
 - Screenshots or before/after comparisons strengthen feedback when possible.

package/templates/modules/pr-review/agents/ux-researcher/skills/ux-review.md

@@ -14,16 +14,14 @@ You review PRs for usability, user flow integrity, and alignment with user needs
 
 ## How to Review
 
-1. When you are the active participant of a review stage on an issue with a PR link, review the PR.
+1. When a PR changes user-facing behavior, interactions, or flows, review it for the UX concerns below.
 2. Focus only on UX and usability concerns — leave code logic to Code Reviewer and visuals to UI Designer.
-3. Record your verdict through the normal issue update route for your review stage:
-   - **approved** if usability is sound
-   - **changes_requested** with specific, actionable feedback if not
-4. Optionally mirror the verdict as a GitHub PR comment — write it to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
+3. Post your verdict as an **advisory** GitHub PR comment — you are not a blocking review stage, so do not record a stage verdict (no `approved`/`changes_requested` on the issue's executionPolicy). Write the comment to a Markdown file (open with a heading like `## ✅ Approved` or `## 🔄 Changes requested`, then the details) and run `gh pr comment <number> --body-file <file>`. Never use inline `--body "..."`: a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext`. See `docs/pr-conventions.md` → *Posting PR Bodies & Comments*.
+4. If you find a concern that should block the merge (e.g. a flow that traps users in a dead end), flag it explicitly in the comment and name who should act on it — QA, the Security Engineer, or the Code Reviewer merge gate — so a blocking reviewer can incorporate it into their verdict. You do not block the merge yourself.
 
 ## Rules
 
 - Ground feedback in user impact — "users might miss this because..." beats "I don't like this".
 - If `docs/USER-TESTING.md` exists, reference its findings where relevant. If it doesn't exist yet, ground feedback in the PR and existing app patterns instead.
-- Approve changes that don't affect user-facing behavior without comment.
+- Comment only on changes that affect user-facing behavior.
 - If the change introduces a new interaction pattern, flag it for consistency tracking.

package/templates/modules/pr-review/docs/pr-conventions.md

@@ -68,8 +68,8 @@ Review runs through the issue's native `executionPolicy` (stages), not separate
 3. **Engineer** sets the originating issue's `executionPolicy` stages, in order:
    - a `review` stage for **QA** when a QA agent is on the team (test adequacy / running the tests),
    - a `review` stage for the **Security Engineer** *only when the change is security-relevant* (auth, secrets, input boundaries, crypto, dependencies, infra exposure),
-   - an `approval` stage for the **Product Owner** (intent, scope, acceptance),
-   - a final `approval` stage for the **Code Reviewer** as the merge gate (a non-author — Paperclip excludes the issue's executor from every stage).
+   - an `approval` stage for the **Product Owner** when one is on the team (intent, scope, acceptance),
+   - a final `approval` stage for the **Code Reviewer** as the merge gate (a non-author — Paperclip excludes the issue's executor from every stage). When no Code Reviewer is on the team, do not set executionPolicy stages at all — use the PR Self-Merge Flow (the engineer opens the PR and merges via `gh pr merge <N> --merge`); other review roles may leave advisory comments but do not block.
    Resolve each role to its agentId. **Never list the issue's executor (the engineer who authored the work) as a participant in any stage** — the runtime excludes the original executor, so such a stage has no eligible participant and the issue stalls (`422 No eligible approval participant`).
 4. **Engineer** sets the issue to `in_review`.
 5. **QA** (when present) reviews and records `approved`/`changes_requested` through the normal issue update route with executed evidence (see *Merge Rules*), preserving the issue-level review audit trail.
@@ -82,8 +82,8 @@ Review runs through the issue's native `executionPolicy` (stages), not separate
 
 - **QA** (`review` stage, when present): the substantive gate. Test coverage, regression risk, and validation — backed by tests that actually ran.
 - **Security Engineer** (`review` stage, only when the change is security-relevant): probes the diff for injection, auth, secrets, crypto, dependency, and exposure issues.
-- **Product Owner** (`approval` stage): intent alignment, scope discipline, acceptance criteria.
-- **Code Reviewer** (`approval` stage, last): the merge gate and hard-gate backstop — a non-author who verifies and lands the PR. See *Merge Rules*.
+- **Product Owner** (`approval` stage, when present): intent alignment, scope discipline, acceptance criteria.
+- **Code Reviewer** (`approval` stage, last, when present): the merge gate and hard-gate backstop — a non-author who verifies and lands the PR. See *Merge Rules*. When no Code Reviewer is present, the engineer self-merges via `gh pr merge <N> --merge` and no executionPolicy stages are set.
 - **Domain reviewers** (advisory): optional, non-blocking comments on correctness, clarity, design, accessibility, UX. They never gate the merge.
 
 ## Merge Rules

package/templates/modules/pr-review/module.meta.json

@@ -25,7 +25,7 @@
         "approver": "product-owner",
         "mergeGate": "code-reviewer"
       },
-      "description": "Document and verify the PR workflow via the issue's executionPolicy. The merge gate is executed verification: with CI, builds must be green before merge; without CI, the merge-gate agent runs the test suite/build and pastes the output before merging. Stages: a review stage for QA when present, a review stage for the Security Engineer only on security-relevant changes, an approval stage for the Product Owner, and a final approval stage for the Code Reviewer as the merge gate (a non-author woken last to merge the PR before recording approval, which closes the issue). Never list the issue's executor/author as a participant in any stage — Paperclip excludes the original executor, so a stage whose only participant is the author has no eligible participant and the issue stalls (`422 No eligible approval participant is configured for this issue`); this is why the merge gate is the Code Reviewer (or another non-author), not the engineer. The merge gate must be the last stage so the Product Owner's approval does not auto-close the issue with the PR still open. Other domain reviewers add advisory, non-blocking comments. Optional branch protection may disable direct pushes, but do not require GitHub-native approving reviews unless the project has distinct non-author GitHub reviewer credentials."
+      "description": "Document and verify the PR workflow via the issue's executionPolicy. The merge gate is executed verification: with CI, builds must be green before merge; without CI, the merge-gate agent runs the test suite/build and pastes the output before merging. Stages: a review stage for QA when present, a review stage for the Security Engineer only on security-relevant changes, an approval stage for the Product Owner when present, and a final approval stage for the Code Reviewer as the merge gate (a non-author woken last to merge the PR before recording approval, which closes the issue). Never list the issue's executor/author as a participant in any stage — Paperclip excludes the original executor, so a stage whose only participant is the author has no eligible participant and the issue stalls (`422 No eligible approval participant is configured for this issue`); this is why the merge gate is the Code Reviewer (a non-author), not the engineer. The merge gate must be the last stage so the Product Owner's approval does not auto-close the issue with the PR still open. Other domain reviewers add advisory, non-blocking comments. Optional branch protection may disable direct pushes, but do not require GitHub-native approving reviews unless the project has distinct non-author GitHub reviewer credentials. When no code-reviewer role is present in the company, use PR-Self-Merge mode instead: the engineer opens the PR normally but skips executionPolicy stages entirely and merges via `gh pr merge <N> --merge` themselves. Other review roles (qa, product-owner, security-engineer, ui-designer, ux-researcher, devops) may leave advisory comments on the PR but do not block the merge. Never set up executionPolicy stages when there is no eligible non-author merge gate — the issue will stall with `422 No eligible approval participant`."
     }
   ]
 }

package/templates/modules/security-audit/skills/threat-model.md

@@ -12,7 +12,7 @@ You own threat modeling for the project. This identifies security risks before t
    - **Risk ratings**: Likelihood x Impact = Risk (Critical/High/Medium/Low)
    - **Mitigations**: Recommended controls for each threat
 3. Create follow-up issues for Critical and High risks:
-   - `POST /api/companies/{companyId}/issues` with specific remediation tasks. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+   - `POST /api/companies/{companyId}/issues` with specific remediation tasks. Include the active `projectId` (and `goalId` / `parentId` when applicable). For top-level issues (no `parentId`), also include `"executionWorkspaceSettings": { "mode": "isolated_workspace" }` so each gets its own worktree; subissues set `parentId` and omit it.
 4. Record summary in your daily notes
 
 ## Rules

package/templates/modules/stall-detection/agents/ceo/heartbeat-section.md

@@ -1,3 +1,3 @@
 ## Stall Detection Routine
 
-Do not scan for stalled work during a normal heartbeat. When you are assigned a routine-run issue titled like "Stall detection", use `skills/stall-detection.md`, then summarize findings on the routine issue and exit.
+Do not scan for stalled work during a normal heartbeat. When you are assigned a routine-run issue titled like "Stall detection", use `$AGENT_HOME/skills/stall-detection.md`, then summarize findings on the routine issue and exit.

package/templates/modules/tech-stack/skills/tech-stack.md

@@ -15,7 +15,7 @@ You own technology decisions. Evaluate options and document choices that align w
    - **Trade-offs**: What was considered and rejected, and why
    - **Dependencies**: Key libraries and their purposes
 4. Create setup issues if needed:
-   - `POST /api/companies/{companyId}/issues` for initial project scaffolding. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+   - `POST /api/companies/{companyId}/issues` for initial project scaffolding. Include the active `projectId` (and `goalId` / `parentId` when applicable). For top-level issues (no `parentId`), also include `"executionWorkspaceSettings": { "mode": "isolated_workspace" }` so each gets its own worktree; subissues set `parentId` and omit it.
 
 ## Rules
 

package/templates/modules/triage/skills/issue-triage.md

@@ -16,7 +16,7 @@ Use this only when the current assigned issue/routine asks for GitHub issue tria
    - Set priority P0-P3; P0 maps to urgent Paperclip priority.
    - Apply labels with `gh issue edit <number> --add-label "<type>,<priority>"`.
    - Respond to the reporter with acknowledgement, follow-up questions, or a polite close reason.
-   - For actionable issues, create a corresponding Paperclip issue via `POST /api/companies/{companyId}/issues`. Include GitHub issue URL/number, active `projectId`, and `goalId` / `parentId` when applicable.
+   - For actionable issues, create a corresponding Paperclip issue via `POST /api/companies/{companyId}/issues`. Include GitHub issue URL/number, active `projectId`, and `goalId` / `parentId` when applicable. For top-level issues (no `parentId`), also include `"executionWorkspaceSettings": { "mode": "isolated_workspace" }` so each gets its own worktree; subissues set `parentId` and omit it.
 4. Link bidirectionally: GitHub comment references the Paperclip issue, Paperclip issue references GitHub.
 5. Summarize triage results on the assigned triage issue/routine and mark it done.
 

package/templates/modules/user-testing/agents/qa/skills/user-testing.md

@@ -18,7 +18,7 @@ You are the QA engineer and user-facing quality is your core domain. You own tes
    - **Major**: Significant friction or confusion
    - **Minor**: Cosmetic or low-impact usability issues
 7. Create follow-up issues for critical and major findings:
-   - `POST /api/companies/{companyId}/issues` with finding details and reproduction steps. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+   - `POST /api/companies/{companyId}/issues` with finding details and reproduction steps. Include the active `projectId` (and `goalId` / `parentId` when applicable). For top-level issues (no `parentId`), also include `"executionWorkspaceSettings": { "mode": "isolated_workspace" }` so each gets its own worktree; subissues set `parentId` and omit it.
 8. Record summary in your daily notes
 
 ## Rules

package/templates/modules/user-testing/skills/user-testing.md

@@ -16,7 +16,7 @@ You own usability evaluations and user testing. This ensures the product meets r
    - **Major**: Significant friction or confusion
    - **Minor**: Cosmetic or low-impact usability issues
 6. Create follow-up issues for critical and major findings:
-   - `POST /api/companies/{companyId}/issues` with finding details and reproduction steps. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+   - `POST /api/companies/{companyId}/issues` with finding details and reproduction steps. Include the active `projectId` (and `goalId` / `parentId` when applicable). For top-level issues (no `parentId`), also include `"executionWorkspaceSettings": { "mode": "isolated_workspace" }` so each gets its own worktree; subissues set `parentId` and omit it.
 7. Record summary in your daily notes
 
 ## Rules

package/templates/modules/vision-workshop/agents/ceo/skills/vision-workshop.md

@@ -12,7 +12,7 @@ You own the company vision. Refine the initial goal into a strategic foundation
    - **Strategic milestones**: Ordered list of milestones that lead to the vision
    - **Non-goals**: What the company explicitly does NOT do (prevents scope creep)
 3. Create issues for the first milestone's deliverables:
-   - `POST /api/companies/{companyId}/issues` with milestone context. Include the active `projectId` (and `goalId` / `parentId` when applicable).
+   - `POST /api/companies/{companyId}/issues` with milestone context. Include the active `projectId` (and `goalId` / `parentId` when applicable). For top-level issues (no `parentId`), also include `"executionWorkspaceSettings": { "mode": "isolated_workspace" }` so each gets its own worktree; subissues set `parentId` and omit it.
 4. Share the vision doc with the team via daily notes
 
 ## Rules

package/templates/presets/repo-maintenance/preset.meta.json

@@ -35,7 +35,7 @@
           "id": "process-setup",
           "title": "Process Setup",
           "level": "team",
-          "description": "Establish PR review, issue triage, and release workflows. Done when branch protection configured, PR conventions documented, issue labels created, release process documented."
+          "description": "Establish PR review, issue triage, and release workflows. Done when PR workflow documented (branch requires PRs, no approval gate), issue labels created, release process documented."
         },
         {
           "id": "initial-sweep",
@@ -66,8 +66,8 @@
       "assignTo": "engineer"
     },
     {
-      "title": "Configure branch protection and PR workflow",
-      "description": "Set up branch protection on the default branch, require PR reviews, configure review conventions. Document in docs/pr-conventions.md.",
+      "title": "Configure PR workflow and branch protection",
+      "description": "Configure the PR workflow and set up branch protection on the default branch. Branch protection must require a PR before merging (no direct pushes to the base branch — set enforce_admins: true so the shared admin account cannot bypass the PR rule), but must NOT require GitHub-native approving reviews — all agents share one GitHub account and cannot formally approve their own PRs; the review gate lives in Paperclip's executionPolicy, not in GitHub. Use the exact gh api heredoc command from the git-workflow skill → Branch Protection Setup: `gh api repos/{owner}/{repo}/branches/{base}/protection --method PUT --input - <<'EOF'` with payload {\"required_status_checks\": null, \"enforce_admins\": true, \"required_pull_request_reviews\": {\"required_approving_review_count\": 0, \"dismiss_stale_reviews\": false}, \"restrictions\": null}. With required_approving_review_count: 0 the shared account can still open a PR and merge it with zero approvals, so the self-merge flow keeps working. Document PR conventions in docs/pr-conventions.md.",
       "priority": "high",
       "assignTo": "engineer"
     },

package/templates/roles/audio-designer/role.meta.json

@@ -7,8 +7,11 @@
   "description": "Owns audio production: sound effects, music, ambient soundscapes, and audio systems design. Creates audio using AI generation tools, code-based synthesis, and audio processing pipelines.",
   "reportsTo": "ceo",
   "enhances": [
-    "Takes over audio asset creation from Engineer (placeholder sounds → production audio)",
+    "Takes over audio asset creation from Engineer (placeholder sounds \u2192 production audio)",
     "Takes over audio direction definition from Game Designer",
     "Adds audio consistency review pass when pr-review module is active"
-  ]
+  ],
+  "adapter": {
+    "thinkingLevel": "auto"
+  }
 }

package/templates/roles/cmo/role.meta.json

@@ -12,6 +12,7 @@
     "Adds marketing review pass (with pr-review module)"
   ],
   "adapter": {
-    "model": "claude-sonnet-4-6"
+    "model": "claude-sonnet-4-6",
+    "thinkingLevel": "auto"
   }
 }

package/templates/roles/code-reviewer/AGENTS.md

@@ -15,16 +15,16 @@ You report to the CEO.
    - **Security**: Any injection, XSS, credential exposure, or OWASP risks?
    - **Style**: Consistent with existing codebase patterns?
    - **Simplicity**: Is there unnecessary complexity? Could it be simpler?
-6. Post your review as **advisory** feedback: write it to a Markdown file (start with a heading, e.g. `## 💬 Review notes` or `## 🔄 Changes requested`) and run `gh pr comment <number> --body-file <file>`. Never inline `--body "..."` — a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext` instead of formatted Markdown. Your review does not gate the merge — that gate is QA + CI (and the Security Engineer on security-relevant changes); do not submit a GitHub-native approving review, since all agents share one GitHub account.
+6. Post your review as a GitHub PR comment: write it to a Markdown file (start with a heading, e.g. `## 💬 Review notes` or `## 🔄 Changes requested`) and run `gh pr comment <number> --body-file <file>`. Never inline `--body "..."` — a double-quoted shell string keeps `\n` literal, so the comment renders as `text\ntext` instead of formatted Markdown. Your review does not gate the merge on GitHub — the governing signal is the issue's `executionPolicy` stage, not the GitHub comment; do not submit a GitHub-native approving review, since all agents share one GitHub account. Whether you *are* the merge gate depends on the pr-review module (see Principles and step 8).
 7. Post your verdict on the originating issue.
-8. Mark your issue as `done`.
+8. **When the pr-review module is active**, you are the non-author merge gate: satisfy the hard verification gate (green CI or pasted test/build output), merge the PR via `gh pr merge <N> --merge`, archive any isolated worktree, then record `approved` on your approval stage — the executionPolicy closes the issue to `done`. Never record `approved` before the merge has actually succeeded, and never leave the issue `done` with the PR still open. **Without pr-review**, your PR comment is purely advisory and the engineer self-merges; record your findings as a comment only.
 
 ## Principles
 
 - Be direct. Approve when good enough — don't bikeshed.
 - Flag security issues as blocking. Everything else is a suggestion unless it's clearly wrong.
 - Ask before guessing. If intent is unclear, ask on the issue rather than assuming.
-- Never merge PRs. That's the engineer's job.
+- When the pr-review module is active, you are the non-author merge gate: after all prior stages approve, satisfy the hard verification gate (green CI or pasted test/build output), then merge via `gh pr merge <N> --merge`, archive any isolated worktree, and record `approved` to close the issue. Without pr-review, the engineer self-merges.
 
 ## Safety Considerations
 

package/templates/roles/code-reviewer/role.meta.json

@@ -8,5 +8,8 @@
   "reportsTo": "ceo",
   "enhances": [
     "Adds code-quality review pass when pr-review module is active"
-  ]
+  ],
+  "adapter": {
+    "thinkingLevel": "auto"
+  }
 }

package/templates/roles/cto/role.meta.json

@@ -13,6 +13,7 @@
   ],
   "adapter": {
     "model": "claude-opus-4-6",
-    "effort": "high"
+    "effort": "high",
+    "thinkingLevel": "auto"
   }
 }

package/templates/roles/customer-success/role.meta.json

@@ -12,6 +12,7 @@
     "Adds customer-impact review pass when pr-review module is active"
   ],
   "adapter": {
-    "model": "claude-sonnet-4-6"
+    "model": "claude-sonnet-4-6",
+    "thinkingLevel": "auto"
   }
 }

package/templates/roles/devops/role.meta.json

@@ -12,6 +12,7 @@
     "Adds infrastructure review pass (with pr-review module)"
   ],
   "adapter": {
-    "model": "claude-sonnet-4-6"
+    "model": "claude-sonnet-4-6",
+    "thinkingLevel": "auto"
   }
 }

package/templates/roles/engineer/AGENTS.md

@@ -11,6 +11,7 @@ You implement coding tasks end-to-end: write and edit code, debug issues, add fo
 ## Working Rules
 
 - Work only on issues assigned to you or explicitly handed to you in comments.
+- If you have no assigned actionable work and there are unassigned `todo` issues that clearly match engineering, claim the highest-priority ready issue yourself, set it `in_progress`, and start in the same heartbeat. This is a fallback behind Product Owner push-assignment, not permission to reshuffle work owned by others.
 - Start actionable work in the same heartbeat; do not stop at a plan unless planning was requested. Leave durable progress with a clear next action. Use child issues for long or parallel delegated work instead of polling. Mark blocked work with owner and action. Respect budget, pause/cancel, approval gates, and company boundaries.
 - Make sure you know the success condition for each task. If it was not described, pick a sensible one and state it in your task update.
 - Run the smallest verification that proves the change. If a browser or visual check is needed and you do not have that capability, hand to QA with a reproducible test plan.
@@ -19,6 +20,7 @@ You implement coding tasks end-to-end: write and edit code, debug issues, add fo
 
 ## Collaboration and Handoffs
 
+- If the PR-review module or an issue `executionPolicy` is active, follow that review/approval flow exactly. Otherwise, when implementation is ready for review, move the issue to `in_review`, assign it to the Product Owner in the same heartbeat, and leave a comment with the change summary, verification, branch/commit details, and any risks. Never leave finished work in `in_review` assigned to yourself.
 - UX-facing changes -> route to the UI/UX designer for visual quality and flow review.
 - Security-sensitive changes (auth, crypto, secrets, permissions, adapter/tool access) -> route to the Security Engineer before merge.
 - Browser validation or user-facing verification -> route to QA with exact steps and expected results.

package/templates/roles/engineer/HEARTBEAT.md

@@ -35,7 +35,7 @@ Run this checklist on every heartbeat. The Paperclip skill is the source of trut
 - Upload or attach user-inspectable outputs as work products/artifacts/documents; local filesystem paths alone are not enough.
 - Use issue documents for long plans, specs, QA reports, security reviews, or hiring drafts; comments should summarize and link.
 - Handoffs should use assignment/status/executionPolicy and a concrete next action. Do not rely on generic @-mentions.
-- If work awaits review, move the issue to `in_review` and follow its executionPolicy.
+- If work awaits review, move the issue to `in_review`. When no executionPolicy is active, reassign to the Product Owner for acceptance review — never leave finished work in `in_review` assigned to yourself. When an executionPolicy is active, follow its review/approval stages.
 
 ## 6. Exit
 

package/templates/roles/engineer/role.meta.json

@@ -8,6 +8,7 @@
   "description": "Implements features, fixes bugs, writes tests, manages git workflow.",
   "reportsTo": "ceo",
   "adapter": {
-    "model": "claude-sonnet-4-6"
+    "model": "claude-sonnet-4-6",
+    "thinkingLevel": "auto"
   }
 }

package/templates/roles/game-artist/role.meta.json

@@ -7,8 +7,11 @@
   "description": "Owns visual art production: sprites, textures, tilesets, UI elements, and visual effects. Generates assets using AI image generation tools and code-based approaches (SVG, procedural generation, pixel art scripts).",
   "reportsTo": "ceo",
   "enhances": [
-    "Takes over art asset creation from Engineer (placeholder art → production art)",
+    "Takes over art asset creation from Engineer (placeholder art \u2192 production art)",
     "Takes over art style guide definition from Game Designer",
     "Adds visual consistency review pass when pr-review module is active"
-  ]
+  ],
+  "adapter": {
+    "thinkingLevel": "auto"
+  }
 }