litclaude-ai 0.3.10 → 0.3.11

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## 0.3.11 - 2026-06-21 — native goal/workflow/team route hardening
+
+- Add honest native `/goal` binding guidance with degraded-mode `BLOCKED:` fallback when Claude Code exposes no supported programmatic goal surface.
+- Add safe natural-language workflow/team routes (`lit workflow`, `lit ultracode`, `lit team`) with disabled-surface gates and no phantom launch/spawn claims.
+- Preserve slash/path false-positive protections and natural-language `lit start work` handoff safety.
+
 ## 0.3.10 - 2026-06-20 — build-decision gate and reuse self-review
 
 - Add a pre-write minimum-first build-decision gate and a necessity/reuse self-review to the

package/README.md

@@ -9,7 +9,7 @@
 </p>
 <p align="center">
   <img src="https://img.shields.io/badge/npm-litclaude--ai-cb3837" />
-  <img src="https://img.shields.io/badge/version-0.3.10-2ea44f" />
+  <img src="https://img.shields.io/badge/version-0.3.11-2ea44f" />
   <img src="https://img.shields.io/badge/Claude%20Code-plugin-blueviolet" />
   <img src="https://img.shields.io/badge/license-MIT-blue" />
 </p>
@@ -22,13 +22,12 @@
 > `litclaude@litclaude-ai`, so normal `claude` launches can load the
 > LitClaude skills and hooks without a long `--plugin-dir` command.
 
-This checkout is prepared as `litclaude-ai@0.3.10` for personal install
+This checkout is prepared as `litclaude-ai@0.3.11` for personal install
 convenience. The repo can remain quiet; preparing npm package metadata here does
 not imply public repo promotion, marketplace publication, or advertisement.
-Future package releases still require explicit user approval. The v0.3.10
-release materials preserve the v0.3.8 skill-depth work and add Claude-native
-hook activation, prompt/mode contract, safe mode-transition, primary-order, and
-installer permission-preference discipline.
+Future package releases still require explicit user approval. The v0.3.11
+release materials preserve the v0.3.10 build-decision gate and add honest native
+goal binding attempts plus workflow/team setup gates while retaining installer permission-preference discipline.
 
 ## Features
 
@@ -43,6 +42,12 @@ installer permission-preference discipline.
 - **v0.2.2 Dynamic workflow hardening** - adds stricter subagent assignment
   contracts, `start-work-next`, context-pressure resume guidance, precise
   mutated-file detection, and richer `workflow-check --json` readiness checks
+- **v0.3.10 build-decision gate** - a minimum-first check that runs before the
+  language gate and prefers the standard library, a native feature, or an
+  installed dependency over hand-rolled code, with a reuse review after writing
+- **v0.3.11 native route hardening** - `lit goal` / `lit workflow` / `lit team`
+  routes attempt native Claude surfaces honestly, report degraded mode when a
+  host trigger is unavailable, and avoid phantom goal/workflow/team success
 - **5-lane review** - `/review-work` checks goal/constraint verification,
   hands-on QA execution, code quality, security, and local-first context mining
 - **Native goal guidance** - LIT context points Claude toward `/goal` or
@@ -95,7 +100,7 @@ directory, the normal install command works:
 
 ```bash
 cd /tmp
-npx --yes litclaude-ai@0.3.10 install
+npx --yes litclaude-ai@0.3.11 install
 ```
 
 Validate the installed plugin:
@@ -108,7 +113,7 @@ The installer also sets Claude Code's `statusLine` command to the packaged
 LitClaude HUD. A typical no-color render starts like:
 
 ```text
-[🔥LITCLAUDE v0.3.10] | O4.8 │ ctx [▎░░] 9%/1000k │ 5h [▏░] 4% ↻2h15m │ 1w [▊░] 35% ↻3d6h │ git main +3 ✓
+[🔥LITCLAUDE v0.3.11] | O4.8 │ ctx [▎░░] 9%/1000k │ 5h [▏░] 4% ↻2h15m │ 1w [▊░] 35% ↻3d6h │ git main +3 ✓
 ```
 
 The `↻` suffix is a compact rate-limit reset countdown. It is separated from
@@ -194,6 +199,12 @@ lit plan <what you want planned>
 lit review <scope to review>
 lit research <research question>
 lit goal <outcome and criteria>
+lit workflow <parallel or delegated objective>
+lit dynamic workflow <parallel or delegated objective>
+lit ultracode <parallel or delegated objective>
+lit team <collaborative objective>
+lit team mode <collaborative objective>
+lit teammates <collaborative objective>
 lit start work <approved plan>
 $lit-plan <what you want planned>
 /lit-plan <what you want planned>
@@ -223,28 +234,39 @@ execution, then the matching skill and agent instructions steer Claude toward
 test-first work, native goal handling, manual QA evidence, cleanup receipts, and
 explicit approval before future release steps.
 
-LitClaude does not auto-type `/goal` or send slash command text for you.
-Instead, the hook and LIT skills add run-context guidance: use Claude Code's
-native goal surface when available, inspect `get_goal`, call `create_goal` only
-when no matching goal is active, and reserve `update_goal` for verified
-completion or a genuine blocker. When goal tools are unavailable or not exposed,
-LitClaude keeps the local evidence ledger authoritative and may suggest an
-exact `/goal <completion condition>` before long execution without repeatedly
-printing fallback chatter.
+LitClaude attempts native goal binding first, but it does not auto-type `/goal`
+or send slash command text for you. The observed Claude Code hook surface can
+add context or block a prompt; it does not expose a supported run-slash-command
+channel. So the hook and LIT skills inspect for future `get_goal`,
+`create_goal`, and `update_goal` tools when available, avoid clobbering a
+different active goal without explicit replacement, and otherwise return an
+explicit `BLOCKED:` degraded-mode note instead of claiming success. In degraded
+mode, LitClaude keeps the durable `litgoal` ledger authoritative and may suggest
+one exact `/goal <completion condition>` or `claude -p "/goal <completion
+condition>"` for the native user surface.
 For large independent work, LitClaude applies the same principle to Claude
-Code's available orchestration surfaces: when `Workflow` is exposed and the task
-is broad, risky, parallel, or long-running, LitClaude **proposes a Dynamic
-workflow and calls the `Workflow` tool once you opt in**. The tool can fan out
-many subagents and spend a large token budget, so it asks first — this opt-in
-gate (not a host limitation) is why a Dynamic workflow only starts after the
-proposal. When isolated edits need a model-facing worktree lane, use
-`EnterWorktree`. If only the CLI surface is available for a fresh isolated lane,
-use `claude --worktree <short-name> --tmux`.
+Code's available orchestration surfaces: `lit workflow`, `lit dynamic workflow`,
+and `lit ultracode` prefer current `ultracode` or explicit “run a workflow” /
+“use a workflow” wording, not casual mentions. If `Workflow` is exposed and the
+task is broad, risky, parallel, or long-running, LitClaude **proposes a Dynamic
+workflow and calls the `Workflow` tool once you opt in**. If
+`CLAUDE_CODE_DISABLE_WORKFLOWS=1` is set, LitClaude reports the setup gate and
+falls back to normal planning/subagent delegation. When isolated edits need a
+model-facing worktree lane, use `EnterWorktree`. If only the CLI surface is
+available for a fresh isolated lane, use `claude --worktree <short-name> --tmux`.
+
+Native agent teams are experimental and setup-gated. `lit team`, `lit team
+mode`, and `lit teammates` steer Claude to spawn named teammates only when
+`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is enabled and the user approves the
+roles, file-scope boundaries, acceptance criteria, wait instructions, and final
+synthesis. Optional display setup is `claude --teammate-mode auto` or
+`"teammateMode": "auto"`; if the env gate is absent, LitClaude says so and
+offers subagent/Dynamic workflow fallback without pretending teammates launched.
 
 For v0.2.2 Dynamic workflow hardening, `/dynamic-workflow` is the consolidated
-bootstrap route for broad delegated work. It keeps `/goal` user-controlled,
-checks model-facing goal tools when exposed, asks for an exact fallback
-`/goal <completion condition>` when needed, and maps subagent delegation to
+bootstrap route for broad delegated work. It attempts native goal binding when a
+supported goal tool surface exists, reports degraded `BLOCKED:` mode when it
+does not, keeps `/goal` user-controlled, and maps subagent delegation to
 `prometheus-planner`, `boulder-executor`, `oracle-verifier`, `qa-runner`,
 `quality-reviewer`, and `librarian-researcher`. Child assignments are expected
 to start with `TASK:` and include `DELIVERABLE`, `SCOPE`, and `VERIFY`, so

package/README_ko-KR.md

@@ -9,7 +9,7 @@
 </p>
 <p align="center">
   <img src="https://img.shields.io/badge/npm-litclaude--ai-cb3837" />
-  <img src="https://img.shields.io/badge/version-0.3.10-2ea44f" />
+  <img src="https://img.shields.io/badge/version-0.3.11-2ea44f" />
   <img src="https://img.shields.io/badge/Claude%20Code-plugin-blueviolet" />
   <img src="https://img.shields.io/badge/license-MIT-blue" />
 </p>
@@ -26,13 +26,12 @@
 > 설치되므로, 매번 긴 `--plugin-dir` 없이 일반 `claude` 실행에서
 > LitClaude skill과 hook을 불러올 수 있습니다.
 
-현재 checkout은 `litclaude-ai@0.3.10` 배포 준비용으로 정리되어 있습니다. 목적은
+현재 checkout은 `litclaude-ai@0.3.11` 배포 준비용으로 정리되어 있습니다. 목적은
 다른 PC에서도 빠르게 설치하기 위한 개인용 package metadata를 갖추는 것입니다.
 npm package metadata를 준비했다고 해서 홍보, 공개 저장소 운영, Claude
 marketplace 등록을 의미하지는 않습니다. 새 버전 배포는 항상 별도의 명시적
-승인 후에 진행합니다. v0.3.10 release material은 v0.3.8 skill-depth 작업을
-보존하고, Claude-native hook activation, prompt/mode contract, safe
-mode-transition, primary-order, installer permission preference discipline을
+승인 후에 진행합니다. v0.3.11 release material은 v0.3.10 build-decision
+gate를 보존하고, native goal binding 시도와 workflow/team setup gate를
 추가합니다.
 
 ## 기능
@@ -48,6 +47,12 @@ mode-transition, primary-order, installer permission preference discipline을
 - **v0.2.2 Dynamic workflow hardening** - 더 엄격한 subagent assignment
   contract, `start-work-next`, context-pressure resume guidance, 정확한
   mutated-file 감지, 강화된 `workflow-check --json` readiness check를 추가
+- **v0.3.10 build-decision gate** - language gate 앞에서 minimum-first check를
+  돌려 표준 라이브러리·네이티브 기능·이미 설치된 의존성을 직접 작성보다 먼저
+  쓰게 하고, 작성 후 reuse review를 추가
+- **v0.3.11 native route hardening** - `lit goal` / `lit workflow` / `lit team`
+  route가 Claude native surface를 정직하게 시도하고, host trigger가 없으면
+  degraded mode를 보고하며 가짜 goal/workflow/team 성공을 피함
 - **5-lane review** - `/review-work`가 goal/constraint verification,
   hands-on QA execution, code quality, security, local-first context mining을
   한 번에 점검
@@ -100,7 +105,7 @@ checkout을 먼저 해석해서 `sh: litclaude-ai: command not found`로 실패
 
 ```bash
 cd /tmp
-npx --yes litclaude-ai@0.3.10 install
+npx --yes litclaude-ai@0.3.11 install
 ```
 
 설치 상태를 확인합니다.
@@ -113,7 +118,7 @@ installer는 Claude Code의 `statusLine` command도 packaged LitClaude HUD로
 설정합니다. 색상을 제거한 예시는 다음처럼 시작합니다.
 
 ```text
-[🔥LITCLAUDE v0.3.10] | O4.8 │ ctx [▎░░] 9%/1000k │ 5h [▏░] 4% ↻2h15m │ 1w [▊░] 35% ↻3d6h │ git main +3 ✓
+[🔥LITCLAUDE v0.3.11] | O4.8 │ ctx [▎░░] 9%/1000k │ 5h [▏░] 4% ↻2h15m │ 1w [▊░] 35% ↻3d6h │ git main +3 ✓
 ```
 
 `↻` 표시는 rate-limit reset까지 남은 시간을 짧게 보여주는 countdown입니다.

package/RELEASE_CHECKLIST.md

@@ -1,13 +1,12 @@
 # LitClaude Release Checklist
 
-Status: `litclaude-ai@0.3.10` is the current release candidate — a Claude-native
-hook activation and mode-discipline parity pass based on LitOpenCode v0.1.17.
-It routes natural `lit` prompts by mode, blocks natural-language start-work with
-a safe handoff, reinforces planning/execution/review/research/goal contracts,
-documents primary role order, and records installer permission preferences
-without copying OpenCode-only permission objects.
-`package.json` is aligned to `0.3.10`, and
-`plugins/litclaude/.claude-plugin/plugin.json` is aligned to `0.3.10`.
+Status: `litclaude-ai@0.3.11` is the current release candidate — a Claude-native
+goal/workflow/team route-hardening pass. It attempts native goal binding
+honestly, reports degraded `BLOCKED:` mode when Claude exposes no supported
+programmatic goal trigger, gates Dynamic workflow and native agent-team routes,
+and preserves safe natural-language start-work handoff behavior.
+`package.json` is aligned to `0.3.11`, and
+`plugins/litclaude/.claude-plugin/plugin.json` is aligned to `0.3.11`.
 
 This release carries the v0.2.2 Dynamic workflow hardening surfaces:
 `/dynamic-workflow`, `workflow-check --json`, native `/goal` fallback guidance,
@@ -56,8 +55,8 @@ No npm publication is required for this track.
 Before requesting publication approval, confirm these artifacts from the current
 checkout:
 
-- `package.json` version is `0.3.10`.
-- `plugins/litclaude/.claude-plugin/plugin.json` version is `0.3.10`.
+- `package.json` version is `0.3.11`.
+- `plugins/litclaude/.claude-plugin/plugin.json` version is `0.3.11`.
 - `plugins/litclaude/commands/dynamic-workflow.md` documents subagent delegation.
 - `node bin/litclaude-ai.js workflow-check --json` reports `status: pass`.
 - `node bin/litclaude-ai.js workflow-check --json` reports

package/docs/agents.md

@@ -3,6 +3,14 @@
 LitClaude agents map the LitClaude team workflow into Claude Code subagents
 with bounded responsibilities.
 
+Native Claude Code agent teams are separate from these plugin subagents. The
+natural routes `lit team`, `lit team mode`, and `lit teammates` are setup-gated
+by `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`; when enabled, LitClaude asks Claude
+to spawn approved teammates with roles, file-scope boundaries, acceptance
+criteria, wait instructions, and synthesis. Optional display setup is
+`claude --teammate-mode auto` or `"teammateMode": "auto"`. When the env gate is
+absent, use the subagent/Dynamic workflow routes below.
+
 Primary order:
 
 1. `lit-loop` — the default execution-loop skill for direct, evidence-driven work.

package/docs/hooks.md

@@ -24,6 +24,12 @@ lit plan
 lit review
 lit research
 lit goal
+lit workflow
+lit dynamic workflow
+lit ultracode
+lit team
+lit team mode
+lit teammates
 lit start work
 $lit-plan
 $lit-loop
@@ -44,24 +50,38 @@ returns a `BLOCKED:` handoff that tells the user to run `/start-work` or
 `/litclaude:start-work` with the approved plan, because a prompt hook cannot
 switch Claude Code agents.
 
-LitClaude follows the LitClaude goal pattern as model-facing run context, not
-as slash-command injection. If Claude Code exposes the native goal surface, the
+LitClaude follows the LitClaude goal pattern as an honest native-binding attempt,
+not as slash-command injection. If Claude Code exposes native goal tools, the
 guidance tells Claude to inspect `get_goal`, call `create_goal` only when no
 matching goal is active, and delay `update_goal` until verified completion or a
-genuine blocker. It may also point Claude toward the user-visible `/goal`
-surface, but it does not auto-type `/goal` or send slash command text.
+genuine blocker. The hook also refuses to clobber a different active goal
+without explicit replacement.
 
-If goal tools are unavailable or not exposed in the running Claude Code session,
-the hook context keeps the local evidence ledger authoritative. It may suggest
-`/goal <completion condition>` before long execution, but it should not repeat
-fallback chatter on every LIT turn.
+Source-backed capability note: the observed `UserPromptSubmit` hook surface can
+add `additionalContext` or block; it cannot replace the prompt or run another
+slash command. If goal tools are unavailable or not exposed in the running
+Claude Code session, the hook returns explicit `BLOCKED:` / degraded-mode
+guidance, does not claim native goal success, keeps the local `litgoal` evidence
+ledger authoritative, and may suggest `/goal <completion condition>` or
+`claude -p "/goal <completion condition>"` for the native user surface.
 
 For broad work, the same context ports the LitClaude model-facing principle to
-Claude Code's exposed orchestration surfaces: if `Workflow` is available,
-propose it first and call the `Workflow` tool only after user opt-in or existing
-session permission, binding every lane to evidence and cleanup. If isolated edits need a model-facing worktree lane, use
-`EnterWorktree`; when only the CLI surface is available, the actionable launch
-form is `claude --worktree <short-name> --tmux`.
+Claude Code's exposed orchestration surfaces: `lit workflow`, `lit dynamic
+workflow`, and `lit ultracode` prefer current `ultracode` or explicit “run a
+workflow” / “use a workflow” wording, not casual mentions. If `Workflow` is
+available, propose it first and call the `Workflow` tool only after user opt-in
+or existing session permission, binding every lane to evidence and cleanup. If
+`CLAUDE_CODE_DISABLE_WORKFLOWS=1` is set, report the setup gate and fall back to
+normal LitClaude planning/subagent delegation. If isolated edits need a
+model-facing worktree lane, use `EnterWorktree`; when only the CLI surface is
+available, the actionable launch form is `claude --worktree <short-name> --tmux`.
+
+For native agent teams, `lit team`, `lit team mode`, and `lit teammates` are
+setup-gated by `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`. When enabled, steer
+Claude to spawn named teammates only after user approval, with roles, file-scope
+boundaries, acceptance criteria, wait instructions, and final synthesis. When
+disabled, say so and offer subagent/Dynamic workflow fallback. Optional display
+setup is `claude --teammate-mode auto` or `"teammateMode": "auto"`.
 
 `/dynamic-workflow` and `$dynamic-workflow` are the v0.2.2 consolidated route
 for that behavior. They load `/litclaude:dynamic-workflow` / `Skill(lit-loop)`,

package/docs/migration.md

@@ -55,18 +55,22 @@ manual `--plugin-dir` launch commands, or a remote Claude marketplace entry.
 
 ## Goal And Dynamic Workflow Parity
 
-Reference goal integration is model-facing guidance around goal tools; it does
-not type a `/goal` slash command for the user. LitClaude mirrors that contract:
-lit hook context and lit skills mention Claude Code's native goal surface, ask
-Claude to inspect `get_goal`, create a goal with `create_goal` only when no
-matching active goal exists, and defer `update_goal` until the evidence gate has
-passed or a real blocker is recorded.
+Reference goal integration is an honest native-binding attempt around goal
+tools; it does not type a `/goal` slash command for the user. LitClaude mirrors
+that contract: lit hook context and lit skills mention Claude Code's native goal
+surface, ask Claude to inspect `get_goal`, create a goal with `create_goal` only
+when no matching active goal exists, refuse to clobber a different active goal
+without explicit replacement, and defer `update_goal` until the evidence gate
+has passed or a real blocker is recorded.
 
 Current Claude Code sessions may not expose model-facing goal tools to the
-model. When goal tools are unavailable or not exposed, LitClaude should not
-pretend the native goal was bound. It keeps the local evidence ledger
-authoritative and may suggest `/goal <completion condition>` before
-long-running lit execution without repeatedly printing fallback chatter.
+model. The observed hook output schema can add context or block; it cannot run
+another slash command. When goal tools are unavailable or not exposed, LitClaude
+returns explicit `BLOCKED:` / degraded-mode guidance, should not pretend the
+native goal was bound, keeps the local evidence ledger authoritative, and may
+suggest `/goal <completion condition>` or `claude -p "/goal <completion
+condition>"` before long-running lit execution without repeatedly printing
+fallback chatter.
 
 When the user explicitly chooses Claude Code `/goal`, that native session goal
 remains user-visible and user-controlled. LitClaude does not auto-type
@@ -76,10 +80,11 @@ execution, bind each lane to criteria and evidence, and use `EnterWorktree` for
 isolated model-facing worktree lanes. When only the CLI surface is available,
 the concrete isolated-lane launch form is `claude --worktree <short-name> --tmux`.
 
-`/dynamic-workflow`, `$dynamic-workflow`, and `/litclaude:dynamic-workflow`
-consolidate that behavior into one route. The route keeps `/goal`
-user-controlled, calls model-facing goal tools only when exposed, and maps
-subagent delegation to `prometheus-planner`, `boulder-executor`,
+`/dynamic-workflow`, `$dynamic-workflow`, `lit workflow`, `lit dynamic
+workflow`, `lit ultracode`, and `/litclaude:dynamic-workflow` consolidate that
+behavior into one route. The route keeps `/goal` user-controlled, calls
+model-facing goal tools only when exposed, reports `CLAUDE_CODE_DISABLE_WORKFLOWS=1`
+as a setup gate, and maps subagent delegation to `prometheus-planner`, `boulder-executor`,
 `oracle-verifier`, `qa-runner`, `quality-reviewer`, and `librarian-researcher`.
 Child assignments use `TASK:`, `DELIVERABLE`, `SCOPE`, and `VERIFY`;
 `workflow-check --json` now verifies both subagent reliability and command/hook
@@ -93,6 +98,14 @@ Long `$start-work` runs can also use `litclaude-ai start-work-next --json` to
 recover the active plan, ledger path, and first unchecked top-level task from
 local `.litclaude` state after a compacted or interrupted session.
 
+Native agent teams remain experimental and disabled unless
+`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is present. The natural routes `lit
+team`, `lit team mode`, and `lit teammates` steer Claude to request approved
+teammates with roles, boundaries, acceptance criteria, wait, and synthesis; when
+the env gate is absent, LitClaude falls back to subagents or Dynamic workflow.
+Optional display setup is `claude --teammate-mode auto` or `"teammateMode":
+"auto"`.
+
 ## Review And Litgoal Parity
 
 The workflow parity surface is local-first and evidence-bound. It does not imply

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "litclaude-ai",
-  "version": "0.3.10",
+  "version": "0.3.11",
   "description": "Claude Code-native workflow distribution.",
   "type": "module",
   "bin": {

package/plugins/litclaude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "litclaude",
   "description": "Claude Code-native workflow plugin.",
-  "version": "0.3.10",
+  "version": "0.3.11",
   "author": {
     "name": "LitClaude contributors"
   },

package/plugins/litclaude/bin/litclaude-hook.js

@@ -6,6 +6,7 @@ import { extractMutatedFilePaths } from "../lib/mutated-file-paths.mjs";
 import { litgoalGoalsPath } from "../lib/litgoal/paths.mjs";
 import { readLitgoalState } from "../lib/litgoal/state.mjs";
 import { evaluateAutoloop, readAutoloopState, writeAutoloopState } from "../lib/litgoal/autoloop.mjs";
+import { buildNativeGoalBindingGuidance, normalizeGoalObjective } from "../lib/native-goal-binding.mjs";
 
 const eventName = process.argv[2] ?? "";
 
@@ -49,6 +50,7 @@ const compoundWordBoundary = /^[A-Za-z0-9_-]$/u;
 const triggerByToken = {
   "deep-interview": { command: "/litclaude:deep-interview", skill: "Skill(deep-interview)", discipline: "deep-interview" },
   "dynamic-workflow": { command: "/litclaude:dynamic-workflow", skill: "Skill(lit-loop)", discipline: "dynamic-workflow" },
+  "agent-team": { command: "/litclaude:lit-loop", skill: "Skill(lit-loop)", discipline: "agent-team" },
   "lit-plan": { command: "/litclaude:lit-plan", skill: "Skill(lit-plan)", discipline: "lit-plan" },
   "lit-loop": { command: "/litclaude:lit-loop", skill: "Skill(lit-loop)", discipline: "lit-loop" },
   "start-work": { command: "/litclaude:start-work", skill: "Skill(start-work)", discipline: "start-work" },
@@ -66,6 +68,7 @@ const modeContracts = {
   litgoal: "Mode contract: litgoal binds one outcome-shaped objective plus checkable criteria, each with scenario, real surface, and observable evidence.",
   "deep-interview": "Mode contract: deep-interview clarifies vague requirements before planning or implementation, without inventing acceptance criteria.",
   "dynamic-workflow": "Mode contract: dynamic-workflow is opt-in orchestration for broad, risky, parallel, or long-running work; propose it first and only call Workflow after user opt-in or existing session permission.",
+  "agent-team": "Mode contract: agent-team is setup-gated native Claude Code teammate orchestration. Spawn teammates only when experimental teams are enabled and the user approves roles, scope boundaries, acceptance criteria, wait, and synthesis instructions.",
 };
 
 const withoutCode = (text) => text.replace(/```[\s\S]*?```/gu, " ").replace(/`[^`]*`/gu, " ");
@@ -132,12 +135,17 @@ const findDollarCommandTrigger = (raw) => {
 
 const hasLitTrigger = (raw) => containsCompoundBoundedWord(raw, "lit") || containsCompoundBoundedWord(raw, "litwork");
 
+const hasExplicitWorkflowRoute = (normalized) => /\blit(?:work)?\s+(?:dynamic\s+workflow|workflow|ultracode)\b/u.test(normalized);
+const hasExplicitTeamRoute = (normalized) => /\blit(?:work)?\s+(?:team(?:\s+mode)?|teammates)\b/u.test(normalized);
+
 const findNaturalLitTrigger = (prompt) => {
   const raw = rawTriggerText(prompt);
   if (containsSlashCommandMention(raw)) return undefined;
   if (!hasLitTrigger(raw)) return undefined;
 
   const normalized = normalizedTriggerText(prompt);
+  if (hasExplicitTeamRoute(normalized)) return { ...triggerByToken["agent-team"], source: "natural-language" };
+  if (hasExplicitWorkflowRoute(normalized)) return { ...triggerByToken["dynamic-workflow"], source: "natural-language" };
   if (containsPlainWord(normalized, "review")) return { ...triggerByToken["review-work"], source: "natural-language" };
   if (containsPlainWord(normalized, "start") && containsPlainWord(normalized, "work")) {
     return { ...triggerByToken["start-work"], source: "natural-language", safetyBlock: true };
@@ -161,7 +169,34 @@ const isDiagnosticLiteralPrompt = (prompt) =>
   && /do not inspect or modify files/iu.test(prompt)
   && /reply with exactly one line/iu.test(prompt);
 
-const litworkContext = ({ command, skill, discipline, softConfirm, safetyBlock, source }) => [
+const objectiveTail = (prompt) => {
+  const raw = withoutCode(prompt);
+  const match = /\blit(?:work)?\b\s*(.*)$/isu.exec(raw);
+  return normalizeGoalObjective(match?.[1] ?? raw);
+};
+
+const goalBindingContext = ({ discipline, prompt, activeGoal }) => {
+  if (!["lit-loop", "lit-plan", "litgoal", "dynamic-workflow"].includes(discipline)) return [];
+  return [buildNativeGoalBindingGuidance({ objective: objectiveTail(prompt), activeGoal }).message];
+};
+
+const workflowGateContext = (discipline) => {
+  if (discipline !== "dynamic-workflow") return [];
+  if (process.env.CLAUDE_CODE_DISABLE_WORKFLOWS === "1") {
+    return ["Dynamic workflow setup gate: CLAUDE_CODE_DISABLE_WORKFLOWS=1 is set, so do not claim a native workflow launch. Fallback to normal LitClaude planning/subagent delegation unless the user re-enables Claude Code workflows."];
+  }
+  return ["Dynamic workflow native trigger guidance: prefer current Claude Code `ultracode` or explicit `run a workflow` / `use a workflow` wording; do not rely on casual bare workflow mentions or hook-injected text to launch orchestration. If the Workflow tool is visible, call it only after opt-in or existing permission, and never claim a workflow started until Claude Code confirms it."];
+};
+
+const teamGateContext = (discipline) => {
+  if (discipline !== "agent-team") return [];
+  if (process.env.CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS === "1") {
+    return ["Native agent team guidance: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 is enabled. Ask Claude to spawn named teammates only after user approval, with security, QA, architecture, or other requested roles; assign file-scope boundaries, acceptance criteria, wait instructions, and final synthesis. Do not claim teammates spawned until Claude Code confirms the spawn."];
+  }
+  return ["Native agent team setup gate: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 is not set, so do not claim a teammate launch. To enable native teams, launch with `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude --teammate-mode auto` or set `env.CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` plus optional `teammateMode: auto`; fallback to subagent delegation or Dynamic workflow meanwhile."];
+};
+
+const litworkContext = ({ command, skill, discipline, softConfirm, safetyBlock, source }, input) => [
   ...(safetyBlock
     ? ["BLOCKED: Natural-language start-work activation cannot switch the active Claude Code agent. Run `/start-work` (or `/litclaude:start-work`) with the approved plan so Claude Code can use the correct execution surface; do not continue implementation from this prompt hook."]
     : []),
@@ -172,10 +207,12 @@ const litworkContext = ({ command, skill, discipline, softConfirm, safetyBlock,
   modeContracts[discipline],
   `Activation source: ${source ?? "legacy"}. Slash commands and slash-command mentions are handled by Claude Code's native command surface and do not activate this prompt hook. Code spans, code fences, substrings, and compound tokens are ignored. Secret-bearing prompt material is never persisted raw; record only redacted summaries and evidence paths in durable state.`,
   "Use evidence-bound planning, tests, manual QA, and cleanup receipts.",
-  "Native goal binding (read this first): Claude Code's /goal (v2.1.139+) is a USER-TYPED slash command that sets an autonomous completion condition — a hook or skill CANNOT invoke it, and Claude Code currently exposes NO model-facing goal tools. So the real path is: when a goal is worth binding, propose a concrete, ready-to-paste /goal <completion condition> for the user, and keep driving the LitClaude evidence ledger meanwhile.",
-  "Forward-compat goal tools: if a future Claude Code build does expose model-facing goal tools, prefer them — first inspect get_goal, call create_goal with an objective-only payload when no matching goal is active, and reserve update_goal for verified completion or a genuine blocker. These are unavailable / not exposed today, so the /goal proposal above is the actual mechanism.",
-  "Do not auto-type or inject the user's slash commands; LitClaude does not auto-type /goal — treat /goal as Claude Code's native user surface, not as prompt text for this hook to send.",
+  ...goalBindingContext({ discipline, prompt: input.prompt, activeGoal: input.native_goal ?? input.active_goal ?? input.goal }),
+  "Forward-compat goal tools: if a future Claude Code build exposes model-facing goal tools, prefer them — first inspect get_goal, call create_goal only when no matching goal is active, and reserve update_goal for verified completion or a genuine blocker. If they are unavailable, report degraded mode and keep durable litgoal evidence authoritative.",
+  "Do not auto-type or inject the user's slash commands; treat /goal as Claude Code's native user surface, not as prompt text for this hook to send.",
   "Dynamic workflow integration: when Claude Code exposes the Workflow tool and the task is broad, risky, parallel, or long-running, briefly propose a Dynamic workflow and call the Workflow tool once the user opts in (or when the session already permits orchestration) before serial execution, binding each lane to explicit criteria, artifacts, and cleanup receipts. The Workflow tool can fan out many subagents and spend a large token budget, so it requires explicit user opt-in — surface the proposal, do not launch it silently. This opt-in gate (not a host limitation) is why a Dynamic workflow only starts after you offer it.",
+  ...workflowGateContext(discipline),
+  ...teamGateContext(discipline),
   "Dynamic worktree integration: when Claude Code exposes EnterWorktree and isolated edits are needed, use EnterWorktree for the selected lane; otherwise use or recommend claude --worktree <short-name> --tmux. Never mutate unrelated user state.",
   "Subagent delegation: route planning to litclaude:prometheus-planner, implementation to litclaude:boulder-executor, verification to litclaude:oracle-verifier, hands-on QA to litclaude:qa-runner, code/security review to litclaude:quality-reviewer, and local-first research to litclaude:librarian-researcher when Claude Code subagents or Dynamic workflow lanes are available. LitClaude subagents are exposed under the litclaude: namespace, so pass the exact namespaced id (e.g. litclaude:boulder-executor) as the Agent/Task tool subagent_type, not the bare name.",
   "Subagent reliability: each child assignment starts with TASK: and includes DELIVERABLE, SCOPE, and VERIFY; use short wait cycles, treat timeouts as no-update signals, and fallback only after a missing deliverable, acknowledgement-only reply, or BLOCKED: report.",
@@ -200,7 +237,7 @@ switch (eventName) {
       const systemMessage = trigger.discipline === "deep-interview"
         ? `LitClaude deep-interview engaged (${trigger.discipline} guidance injected).`
         : `🔥 LITBURN IGNITED 🔥 — LitClaude lit hook active: ${trigger.discipline} guidance injected.`;
-      writeContext(litworkContext(trigger), systemMessage);
+      writeContext(litworkContext(trigger, input), systemMessage);
     } else {
       writeContext("LitClaude prompt hook checked: no workflow activation.");
     }

package/plugins/litclaude/commands/dynamic-workflow.md

@@ -6,15 +6,21 @@ argument-hint: '<objective>'
 Use the `lit-loop` skill for the user's current objective, with this
 Dynamic-workflow bootstrap first.
 
-1. Inspect native goal state when model-facing tools are exposed: call
-   `get_goal`, call `create_goal` only when no matching active goal exists, and
-   reserve `update_goal` for verified completion or a genuine blocker. If only
-   the user-visible goal surface is available, ask for one exact
-   `/goal <completion condition>` instead of claiming LitClaude set it.
+1. Attempt native goal binding honestly: inspect native goal state when
+   model-facing tools are exposed, call `get_goal`, call `create_goal` only when
+   no matching active goal exists, and reserve `update_goal` for verified
+   completion or a genuine blocker. Do not clobber a different active goal
+   without explicit replacement. If only the user-visible goal surface is
+   available, report `BLOCKED:` / degraded mode and ask for one exact
+   `/goal <completion condition>` or `claude -p "/goal <completion condition>"`
+   instead of claiming LitClaude set it.
 2. Run `litclaude-ai workflow-check --json` when the package CLI is available.
    Treat a failing check as BLOCKED until the missing route, command, or
    subagent delegation surface is fixed.
-3. For broad, risky, parallel, or long-running work, briefly propose a Dynamic
+3. For broad, risky, parallel, or long-running work, prefer current `ultracode`
+   or explicit “run a workflow” / “use a workflow” wording. If
+   `CLAUDE_CODE_DISABLE_WORKFLOWS=1` is set, report the setup gate and fall back
+   to normal LitClaude planning/subagents. Otherwise briefly propose a Dynamic
    workflow and call the `Workflow` tool once the user opts in (or when the
    session already permits orchestration). The tool can fan out many subagents
    and spend a large token budget, so it needs explicit user opt-in — surface

package/plugins/litclaude/commands/litgoal.md

@@ -23,8 +23,12 @@ litclaude litgoal steer --kind scope --note "<what changed and why>" --json
 ```
 
 The ledger lives under `.litclaude/litgoal/` unless test environment variables
-override it. Bind work to native goal tools when they are available; when goal
-tools are unavailable, record clear criteria and evidence in the local ledger.
+override it. Attempt native binding through goal tools when they are available:
+inspect `get_goal`, call `create_goal` only when no matching active goal exists,
+and avoid clobbering a different active goal without explicit replacement. When
+goal tools are unavailable, return explicit `BLOCKED:` / degraded-mode wording
+instead of claiming native success, and record clear criteria and evidence in
+the local ledger.
 For broad goal execution, use Dynamic workflow when Claude Code exposes it, and
 use `claude --worktree <short-name> --tmux` only when isolated worktree
 execution is needed.

package/plugins/litclaude/lib/native-goal-binding.mjs

@@ -0,0 +1,53 @@
+const MAX_OBJECTIVE_CHARS = 180;
+
+const secretPatterns = [
+  /sk-[A-Za-z0-9_-]{20,}/gu,
+  /(?:api[_-]?key|token|secret|password)\s*=\s*\S+/giu,
+];
+
+const normalizeSpaces = (value) => value.replace(/\s+/gu, " ").trim();
+
+export const normalizeGoalObjective = (value) => {
+  if (typeof value !== "string") return "";
+  const cleaned = value
+    .split(/\r?\n/gu)
+    .filter((line) => !line.trimStart().startsWith("/"))
+    .join(" ");
+  const redacted = secretPatterns.reduce(
+    (text, pattern) => text.replace(pattern, "[REDACTED]"),
+    cleaned,
+  );
+  return normalizeSpaces(redacted).slice(0, MAX_OBJECTIVE_CHARS).trim();
+};
+
+const canonical = (value) => normalizeGoalObjective(value).toLowerCase();
+
+const activeGoalObjective = (activeGoal) => {
+  if (!activeGoal || typeof activeGoal !== "object") return "";
+  return normalizeGoalObjective(activeGoal.objective ?? activeGoal.goal ?? activeGoal.text ?? "");
+};
+
+export const buildNativeGoalBindingGuidance = ({ objective, activeGoal } = {}) => {
+  const normalizedObjective = normalizeGoalObjective(objective);
+  const activeObjective = activeGoalObjective(activeGoal);
+  const activeStatus = typeof activeGoal?.status === "string" ? activeGoal.status.toLowerCase() : "";
+
+  if (!normalizedObjective) {
+    return {
+      status: "blocked-missing-objective",
+      message: "Native goal binding attempt: BLOCKED: missing objective. Provide one outcome-shaped objective with checkable evidence; keep the durable `litgoal` ledger authoritative until Claude Code exposes a supported programmatic goal surface.",
+    };
+  }
+
+  if (activeObjective && (!activeStatus || activeStatus === "active") && canonical(activeObjective) !== canonical(normalizedObjective)) {
+    return {
+      status: "blocked-conflict",
+      message: `Native goal binding attempt: BLOCKED: active native goal differs (${activeObjective}). LitClaude will not clobber it without explicit replacement; use Claude Code's user-visible /goal replacement flow or provide explicit replacement approval. Keep the durable \`litgoal\` ledger authoritative meanwhile.`,
+    };
+  }
+
+  return {
+    status: "blocked-unavailable",
+    message: "Native goal binding attempt: BLOCKED: native `/goal` not programmatically bound. Evidence: the supported UserPromptSubmit hook surface can add context or block, but does not expose a run-slash-command channel; this session exposes no callable get_goal/create_goal/update_goal tools to LitClaude. I will not claim host goal activation. To bind Claude Code's native user surface, paste `/goal <completion condition>` in the session, or run `claude -p \"/goal <completion condition>\"` in a non-interactive flow. Until then, keep the durable `litgoal` ledger authoritative for objective, criteria, evidence, checkpoints, and blockers.",
+  };
+};

package/plugins/litclaude/skills/lit-loop/SKILL.md

@@ -59,28 +59,40 @@ When uncertain, treat the task as HEAVY.
 
 ## Native Goal + Dynamic Workflow
 
-Claude Code's `/goal` (v2.1.139+) is a **user-typed slash command** that sets an autonomous
-completion condition; a hook or skill **cannot invoke it**, and Claude Code exposes no
-model-facing goal tools today. Bind goals like this:
-
-- When a goal is worth binding, **propose a concrete, ready-to-paste `/goal <completion
-  condition>`** for the user, and keep driving the local evidence ledger meanwhile. LitClaude
-  must not auto-type or send `/goal` text.
+Attempt native goal binding first. Claude Code's `/goal` (v2.1.139+) is the
+native user surface, but the observed hook/skill surface cannot run another
+slash command and this session may expose no model-facing goal tools. Bind goals
+like this:
+
+- If model-facing tools are exposed, inspect `get_goal`, call `create_goal` only
+  when no matching active goal exists, avoid clobbering a different active goal
+  without explicit replacement, and call `update_goal` only after every success
+  criterion has evidence or the work is genuinely blocked.
+- When goal tools are unavailable, report explicit `BLOCKED:` / degraded mode,
+  **propose a concrete, ready-to-paste `/goal <completion condition>`** or
+  `claude -p "/goal <completion condition>"` for the user, and keep driving the
+  local evidence ledger meanwhile. LitClaude must not auto-type or send `/goal`
+  text or claim native activation without observed evidence.
 - Forward-compat only: if a future Claude Code build exposes model-facing goal tools, prefer
-  them — call `get_goal`, call `create_goal` only when no matching active goal exists, and call
-  `update_goal` only after every success criterion has evidence or the work is genuinely blocked.
-- While model-facing goal tools are not exposed (the case today), the local litgoal ledger is the
-  durable record; surface the `/goal` proposal for long-running goals and don't spam fallback status.
+  them according to the no-clobber rule above.
+- While model-facing goal tools are not exposed, the local litgoal ledger is the
+  durable record; surface the degraded-mode note once for long-running goals and
+  don't spam fallback status.
 
 Dynamic workflow orchestration is the right tool for broad, risky, parallel, or
-long-running work: briefly **propose a Dynamic workflow and call `Workflow`
-once the user opts in** (or when the session already permits orchestration)
-instead of merely mentioning it. The `Workflow` tool can fan out many subagents
-and spend a large token budget, so it needs explicit user opt-in — this opt-in
-gate, not a host limitation, is why a Dynamic workflow only starts after you
-offer it. Dynamic worktree isolation is mandatory for risky edit lanes: call
-`EnterWorktree` when exposed. If only the CLI surface is available, use or
-recommend `claude --worktree <short-name> --tmux`.
+long-running work: prefer current `ultracode` or explicit “run a workflow” /
+“use a workflow” wording, respect `CLAUDE_CODE_DISABLE_WORKFLOWS=1`, then briefly
+**propose a Dynamic workflow and call `Workflow` once the user opts in** (or when
+the session already permits orchestration) instead of merely mentioning it. The
+`Workflow` tool can fan out many subagents and spend a large token budget, so it
+needs explicit user opt-in. Native agent teams are setup-gated by
+`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`; if enabled, ask Claude to spawn
+approved teammates with roles, acceptance criteria, wait, and synthesis; if not,
+fall back to subagents/Dynamic workflow. Optional display setup is
+`claude --teammate-mode auto` or `"teammateMode": "auto"`. Dynamic worktree
+isolation is mandatory for risky edit lanes: call `EnterWorktree` when exposed.
+If only the CLI surface is available, use or recommend `claude --worktree
+<short-name> --tmux`.
 
 ## Subagent Assignment Contract
 

package/plugins/litclaude/skills/lit-plan/SKILL.md

@@ -135,20 +135,29 @@ exploration found no conflicts; log the skip explicitly.
 
 ## Native Goal + Dynamic Workflow
 
-Include native goal handling. Claude Code's `/goal` (v2.1.139+) is a **user-typed slash command**,
-not a model-facing tool, and a hook/skill **cannot invoke it**:
-
-- Include an exact, ready-to-paste `/goal <completion condition>` line in the plan for the user to
-  run — this is the real way to bind the native goal — plus a quiet local ledger for tracking.
-- Forward-compat only: if a future Claude Code build exposes model-facing goal tools, call
-  `get_goal`, create with `create_goal` only when no matching active goal exists, and delay
-  `update_goal` until verified completion or a real blocker. These goal tools are not exposed today.
+Include native goal handling as an honest binding attempt. Claude Code's
+`/goal` (v2.1.139+) is the native user surface, but the observed hook/skill
+surface cannot run another slash command and model-facing goal tools may be
+unavailable:
+
+- If goal tools are exposed, call `get_goal`, create with `create_goal` only
+  when no matching active goal exists, avoid clobbering a different active goal
+  without explicit replacement, and delay `update_goal` until verified
+  completion or a real blocker.
+- If goal tools are unavailable, include explicit `BLOCKED:` / degraded-mode
+  wording plus an exact, ready-to-paste `/goal <completion condition>` or
+  `claude -p "/goal <completion condition>"` line for the user, plus a quiet
+  local ledger for tracking.
 - Do not auto-type or send `/goal` text from a skill, and never claim native activation without evidence.
 
 For broad, risky, parallel, or long-running implementation, include Dynamic workflow
 and Dynamic worktree instructions:
 
+- prefer current `ultracode` or explicit “run a workflow” / “use a workflow” wording
+- report `CLAUDE_CODE_DISABLE_WORKFLOWS=1` as a setup gate when present
 - call `Workflow` when Claude Code exposes it
+- for native teams, require `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`, user-approved roles,
+  acceptance criteria, wait, and synthesis; otherwise fall back to subagents/workflows
 - call `EnterWorktree` for isolated model-facing edit lanes when available
 - otherwise recommend `claude --worktree <short-name> --tmux` for explicit
   operator-managed isolation

package/plugins/litclaude/skills/litgoal/SKILL.md

@@ -56,18 +56,24 @@ Represent every litgoal run as:
 
 ### Binding the native Claude Code goal
 
-Claude Code's `/goal` (v2.1.139+) is a **user-typed slash command** that sets an autonomous
-completion condition; it is **not a model-facing tool**, and a hook or skill **cannot invoke
-it**. So when this skill activates, derive the objective into a crisp completion condition and
-**offer the user a ready-to-paste `/goal <completion condition>`** (e.g. ``/goal all litgoal
-criteria pass and `litclaude litgoal status` shows complete``). Then keep the durable record in
-the local litgoal ledger. Never auto-type `/goal`, never claim slash-command activation without
-evidence, and never mark a goal complete until the local litgoal criteria have passed.
-
-Forward-compat only: if a future Claude Code build exposes model-facing goal tools, inspect
-`get_goal` before creating a new active goal, use `create_goal` for the objective, and
-`update_goal` only on verified completion. These are not exposed today — the `/goal` proposal is
-the actual mechanism.
+Claude Code's `/goal` (v2.1.139+) is the native user surface, but the observed
+hook/skill surface cannot run another slash command and model-facing goal tools
+may be unavailable. So when this skill activates, attempt native binding only
+through supported tools: inspect `get_goal`, use `create_goal` only when no
+matching active goal exists, avoid clobbering a different active goal without
+explicit replacement, and use `update_goal` only on verified completion or a
+real blocker. If goal tools are unavailable, report explicit `BLOCKED:` /
+degraded mode, derive the objective into a crisp completion condition, and
+**offer the user a ready-to-paste `/goal <completion condition>`** or
+`claude -p "/goal <completion condition>"` (e.g. ``/goal all litgoal criteria
+pass and `litclaude litgoal status` shows complete``). Then keep the durable
+record in the local litgoal ledger. Never auto-type `/goal`, never claim
+slash-command activation without evidence, and never mark a goal complete until
+the local litgoal criteria have passed.
+
+Forward-compat rule: if a future Claude Code build exposes model-facing goal
+tools, use them according to the no-clobber sequence above. Otherwise, the
+degraded-mode `/goal` proposal plus durable ledger is the honest mechanism.
 
 ### Autoloop — a plugin-controlled `/goal`-equivalent (no `/goal` typing)
 

package/plugins/litclaude/skills/start-work/SKILL.md

@@ -57,26 +57,35 @@ ledger entry. The tier ratchets up only — never downgrade.
 
 ## Native Goal + Dynamic Workflow
 
-Before the first checkbox, bind the native goal. Claude Code's `/goal` (v2.1.139+) is a
-**user-typed slash command**, not a model-facing tool, and a hook/skill **cannot invoke it**:
-
-- For a long plan, offer the user one ready-to-paste `/goal <plan completion condition>` line —
-  this is the real way to bind the native session goal — and keep the Boulder/ledger discipline.
-- Forward-compat only: if a future Claude Code build exposes model-facing goal tools, call
-  `get_goal` if exposed, `create_goal` with the plan objective only when no matching active goal
-  exists, and `update_goal` only after all top-level checkboxes and final gates are complete (or
-  when the plan is genuinely blocked). These are not exposed today.
+Before the first checkbox, attempt native goal binding honestly. Claude Code's
+`/goal` (v2.1.139+) is the native user surface, but the observed hook/skill
+surface cannot run another slash command and model-facing goal tools may be
+unavailable:
+
+- If goal tools are exposed, call `get_goal` if exposed, `create_goal` with the
+  plan objective only when no matching active goal exists, avoid clobbering a
+  different active goal without explicit replacement, and `update_goal` only
+  after all top-level checkboxes and final gates are complete (or when the plan
+  is genuinely blocked).
+- If goal tools are unavailable, report explicit `BLOCKED:` / degraded mode and
+  offer the user one ready-to-paste `/goal <plan completion condition>` line or
+  `claude -p "/goal <plan completion condition>"`, then keep the Boulder/ledger
+  discipline.
 - Do not auto-type or send `/goal` text from a skill; if the user invokes `/goal`, respect it.
 
 If model-facing goal tools are absent (the case today), continue with Boulder/ledger discipline.
 If goal tools are not exposed, do not print repeated fallback status; just keep
 the plan ledger accurate and continue with verified evidence.
 
-For broad, risky, or parallel checkbox waves, use Dynamic workflow orchestration
-and call `Workflow` when exposed. Use Dynamic worktree isolation with
-`EnterWorktree` for isolated model-facing edit lanes when available. When
-only the CLI path is available, use or recommend
-`claude --worktree <short-name> --tmux`.
+For broad, risky, or parallel checkbox waves, prefer current `ultracode` or
+explicit “run a workflow” / “use a workflow” wording, respect
+`CLAUDE_CODE_DISABLE_WORKFLOWS=1`, use Dynamic workflow orchestration, and call `Workflow`
+when exposed. Native agent teams require
+`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`; if enabled, ask for approved teammate
+roles, boundaries, acceptance criteria, wait, and synthesis, otherwise fall back
+to subagents/workflows. Use Dynamic worktree isolation with `EnterWorktree` for
+isolated model-facing edit lanes when available. When only the CLI path is
+available, use or recommend `claude --worktree <short-name> --tmux`.
 
 ## Subagent Assignment Contract