@cubis/foundry 0.3.83 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/copilot/prompts/design-refresh.prompt.md

@@ -0,0 +1,67 @@
+# Workflow Prompt: /design-refresh
+
+Refresh design state and implementation surfaces after product direction, design tokens, or major UI structure changes.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `frontend-design`, `frontend-design-core`, `frontend-design-system`, `frontend-design-style-selector`, `frontend-design-screen-brief`, `stitch-design-system`, `tech-doc`.
+- Local skill file hints if installed: `.github/skills/frontend-design/SKILL.md`, `.github/skills/frontend-design-core/SKILL.md`, `.github/skills/frontend-design-system/SKILL.md`, `.github/skills/frontend-design-style-selector/SKILL.md`, `.github/skills/frontend-design-screen-brief/SKILL.md`, `.github/skills/stitch-design-system/SKILL.md`, `.github/skills/tech-doc/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# Design Refresh Workflow
+
+## When to use
+
+Use when the product direction changed and the design system, overlays, or Stitch mirror need a coordinated refresh.
+
+## Agent Chain
+
+`explorer` -> `planner` -> `implementer` -> `reviewer`
+
+## Routing
+
+1. **Explore**: `@explorer` finds the current design docs, overlays, and implementation surfaces touched by the direction change.
+2. **Plan**: `@planner` decides what must be refreshed and what can stay stable.
+3. **Implement**: `@implementer` updates canonical design state, overlays, and compatibility mirrors.
+4. **Review**: `@reviewer` checks that the refreshed design state is coherent and ready for downstream implementation.
+
+## Skill Routing
+
+- Primary skills: `frontend-design`, `frontend-design-core`, `frontend-design-system`
+- Supporting skills (optional): `frontend-design-style-selector`, `frontend-design-screen-brief`, `stitch-design-system`, `tech-doc`
+
+## Context notes
+
+- Provide what changed in product direction or UI structure and which downstream surfaces are now stale.
+- This route refreshes design state; it should not silently skip dependent overlays or the Stitch mirror.
+
+## Workflow steps
+
+1. Explorer finds the current design docs, overlays, and implementation surfaces touched by the direction change.
+2. Planner decides what must be refreshed and what can stay stable.
+3. Implementer updates canonical design state, overlays, and compatibility mirrors.
+4. Reviewer checks that the refreshed design state is coherent and ready for downstream implementation.
+
+## Verification
+
+- Canonical design state and overlays are updated together.
+- Downstream design consumers are told what changed.
+- Stitch compatibility artifacts are refreshed only from canonical state.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: implementer
+  supporting_agents: [explorer, planner, reviewer]
+  refreshed_artifacts: [<path>]
+  stitch_mirror_updated: <true|false>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/copilot/prompts/design-screen.prompt.md

@@ -0,0 +1,76 @@
+# Workflow Prompt: /design-screen
+
+Resolve the design engine first, produce a high-signal screen brief, then optionally hand off to Stitch or implementation.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `frontend-design`, `frontend-design-core`, `frontend-design-style-selector`, `frontend-design-screen-brief`, `frontend-design-mobile-patterns`, `stitch-prompt-enhancement`, `stitch-design-system`, `stitch-design-orchestrator`, `frontend-design-implementation-handoff`, `stitch-implementation-handoff`.
+- Local skill file hints if installed: `.github/skills/frontend-design/SKILL.md`, `.github/skills/frontend-design-core/SKILL.md`, `.github/skills/frontend-design-style-selector/SKILL.md`, `.github/skills/frontend-design-screen-brief/SKILL.md`, `.github/skills/frontend-design-mobile-patterns/SKILL.md`, `.github/skills/stitch-prompt-enhancement/SKILL.md`, `.github/skills/stitch-design-system/SKILL.md`, `.github/skills/stitch-design-orchestrator/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# Design Screen Workflow
+
+## When to use
+
+Use when the task is about shaping a concrete page or screen, especially before Stitch generation or Flutter/mobile implementation.
+
+## Agent Chain
+
+`explorer` -> `planner` -> `implementer`
+
+## Routing
+
+1. **Explore**: `@explorer` reads the current product context, UI patterns, and any existing design state.
+2. **Plan**: `@planner` chooses the applicable design overlays and decides whether Stitch is needed.
+3. **Implement**: `@implementer` resolves the design state, writes the screen brief, and only then performs Stitch or implementation handoff work.
+
+## Skill Routing
+
+- Primary skills: `frontend-design`, `frontend-design-core`, `frontend-design-style-selector`, `frontend-design-screen-brief`
+- Supporting skills (optional): `frontend-design-mobile-patterns`, `stitch-prompt-enhancement`, `stitch-design-system`, `stitch-design-orchestrator`, `frontend-design-implementation-handoff`, `stitch-implementation-handoff`
+
+## Stitch Gate
+
+Do not call Stitch until:
+
+1. `frontend-design` has run
+2. the canonical design state exists or is refreshed in the same run
+3. the screen brief is ready
+4. Stitch status/tool discovery succeeds
+
+## Context notes
+
+- Provide the product goal, target platform, and whether the screen is greenfield, a redesign, or a targeted edit.
+- This route can end in either a screen brief, a Stitch call, or direct implementation handoff depending on scope.
+
+## Workflow steps
+
+1. Explorer surveys the relevant product surface and existing design state.
+2. Planner resolves the applicable canonical design state and overlays.
+3. Implementer writes the screen brief and decides whether the next step is Stitch or direct implementation.
+4. If Stitch is used, the implementer follows the Stitch gate and hands the final artifact into implementation.
+
+## Verification
+
+- The brief is concrete enough for implementation or Stitch.
+- The route explains whether the next step is direct implementation or Stitch.
+- Stitch is never the first design step.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: implementer
+  supporting_agents: [explorer, planner]
+  screen_briefs: [<path-or-label>]
+  stitch_used: <true|false>
+  design_state_inputs: [<path>]
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/copilot/prompts/design-system.prompt.md

@@ -0,0 +1,67 @@
+# Workflow Prompt: /design-system
+
+Establish or refresh canonical design state, token language, overlays, and Stitch compatibility before implementation.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `frontend-design`, `frontend-design-core`, `frontend-design-style-selector`, `frontend-design-system`, `frontend-design-mobile-patterns`, `stitch-design-system`, `tech-doc`.
+- Local skill file hints if installed: `.github/skills/frontend-design/SKILL.md`, `.github/skills/frontend-design-core/SKILL.md`, `.github/skills/frontend-design-style-selector/SKILL.md`, `.github/skills/frontend-design-system/SKILL.md`, `.github/skills/frontend-design-mobile-patterns/SKILL.md`, `.github/skills/stitch-design-system/SKILL.md`, `.github/skills/tech-doc/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# Design System Workflow
+
+## When to use
+
+Use when the project needs a durable design foundation before screen generation or implementation.
+
+## Agent Chain
+
+`explorer` -> `planner` -> `implementer`
+
+## Routing
+
+1. **Explore**: `@explorer` reads current UI code, tokens, brand cues, and platform constraints.
+2. **Plan**: `@planner` chooses the design direction and the required design-state files.
+3. **Implement**: `@implementer` writes or refreshes `docs/foundation/DESIGN.md`, overlays, and the Stitch mirror when needed.
+
+## Skill Routing
+
+- Primary skills: `frontend-design`, `frontend-design-core`, `frontend-design-style-selector`, `frontend-design-system`
+- Supporting skills (optional): `frontend-design-mobile-patterns`, `stitch-design-system`, `tech-doc`
+
+## Context notes
+
+- Provide the target product surface, intended audience, and any existing brand or token constraints.
+- This route should refresh canonical design state before downstream screen generation or implementation.
+
+## Workflow steps
+
+1. Explorer surveys the current UI code, tokens, and existing design documents.
+2. Planner chooses the visual direction and identifies which canonical docs or overlays need refresh.
+3. Implementer writes or updates `docs/foundation/DESIGN.md`, overlays, and the Stitch mirror when needed.
+4. The route returns the refreshed design state and the next recommended design or implementation step.
+
+## Verification
+
+- `docs/foundation/DESIGN.md` exists and is coherent.
+- Overlays exist only when scoped detail is actually needed.
+- `.stitch/DESIGN.md` is synchronized when Stitch work is in scope.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: implementer
+  supporting_agents: [explorer, planner]
+  design_artifacts: [docs/foundation/DESIGN.md]
+  overlays_updated: [<path>] | []
+  stitch_mirror_updated: <true|false>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/copilot/prompts/implement.prompt.md

@@ -0,0 +1,89 @@
+# Workflow Prompt: /implement
+
+End-to-end feature implementation: explore, plan, implement, test, review, and optionally run the Stitch UI sequence for design-first screen generation.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `api-design`, `typescript-best-practices`, `spec-driven-delivery`, `system-design`, `unit-testing`, `integration-testing`, `playwright-interactive`, `code-review`, `owasp-security-review`, `frontend-design`, `stitch-prompt-enhancement`, `stitch-design-orchestrator`, `stitch-design-system`, `stitch-implementation-handoff`.
+- Local skill file hints if installed: `.github/skills/api-design/SKILL.md`, `.github/skills/typescript-best-practices/SKILL.md`, `.github/skills/spec-driven-delivery/SKILL.md`, `.github/skills/system-design/SKILL.md`, `.github/skills/unit-testing/SKILL.md`, `.github/skills/integration-testing/SKILL.md`, `.github/skills/playwright-interactive/SKILL.md`, `.github/skills/code-review/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# Implement Workflow
+
+## When to use
+
+Use for building new features, refactors, documentation refreshes, onboarding tasks, or post-design implementation work that needs the full lifecycle: planning, implementation, testing, and review.
+
+## Agent Chain
+
+`explorer` -> `planner` -> `implementer` -> `tester` -> `reviewer`
+
+## Routing
+
+1. **Explore**: `@explorer` maps the code area and existing patterns when the task is non-trivial.
+2. **Plan**: `@planner` reads the requirements and existing code, then produces an implementation plan.
+3. **Implement**: `@implementer` executes the plan, writing production-quality code.
+4. **Test**: `@tester` writes and runs tests verifying the implementation.
+5. **Review**: `@reviewer` performs quality and security review, then approves or requests changes.
+
+## Skill Routing
+
+- Primary skills: `api-design`, `typescript-best-practices`
+- Supporting skills (optional): `spec-driven-delivery`, `system-design`, `unit-testing`, `integration-testing`, `playwright-interactive`, `code-review`, `owasp-security-review`, `frontend-design`, `stitch-prompt-enhancement`, `stitch-design-orchestrator`, `stitch-design-system`, `stitch-implementation-handoff`
+
+## Context notes
+
+- Provide the feature requirements, acceptance criteria, and any design constraints.
+- Implementer follows existing codebase patterns and conventions.
+- Use this workflow for doc-only or refactor-heavy work when you want one coordinated pass instead of separate routes.
+- If the task is primarily about shaping a screen, design system, or Stitch prompt, prefer `/design-screen` or `/design-system` first and return here only for implementation/handoff.
+
+## Stitch UI mode
+
+Use `/implement` only after `/design-screen` or `/design-system` resolved the design state and the work now needs implementation or implementation handoff.
+
+1. Load `frontend-design` first, starting with `visual-direction` and `design-tokens`.
+2. Load `stitch-prompt-enhancement` before any Stitch tool call.
+3. If `docs/foundation/DESIGN.md` is missing, stale, or the work spans multiple screens, run `stitch-design-system` and mirror the result to `.stitch/DESIGN.md`.
+4. Verify `stitch_get_status`, `mcp_gateway_status`, and `stitch_list_enabled_tools`.
+5. Reuse an existing Stitch project when the work belongs to the same app or feature line. Call `list_projects` before `create_project`, and call `list_screens` before deciding whether the next step is a fresh generation or an edit.
+6. Choose the smallest Stitch tool path: `generate_screen_from_text`, `edit_screens`, `generate_variants`, or design-system tools only when the design system itself is the task.
+7. Default to `GEMINI_3_1_PRO` for complex or multi-screen UI work. Use `GEMINI_3_FLASH` only for speed-first drafts or narrow edits.
+8. Surface Stitch suggestions before retrying. Allow at most two automatic retries with backoff.
+9. If a Stitch generation call times out, check `list_screens` before treating it as failed.
+10. Fetch the final artifact with `get_screen`, then run `stitch-implementation-handoff` before normal implementation, test, and review.
+
+## Workflow steps
+
+1. Explorer maps the relevant code and patterns when the request is not trivial.
+2. Planner analyzes requirements and produces a structured implementation plan.
+3. Implementer executes the plan step by step, verifying compilation after each change.
+4. Tester writes tests for the new code and runs the relevant test suite.
+5. Reviewer evaluates code quality, patterns, correctness, and security.
+6. If changes are requested, implementer applies fixes and the cycle repeats from step 4.
+
+## Verification
+
+- All planned changes implemented and code compiles without errors.
+- Tests pass and cover the new functionality.
+- Code review approved with no critical findings.
+- For Stitch UI mode, design context is resolved before generation and the final implementation reuses repo-native components and tokens.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: implementer
+  supporting_agents: [explorer, planner, tester, reviewer]
+  changed_artifacts: [<path>]
+  tests_status: <pass|fail>
+  review_status: <approve|request_changes>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/copilot/prompts/loop.prompt.md

@@ -0,0 +1,74 @@
+# Workflow Prompt: /loop
+
+Bounded autonomous iteration: run a task loop with explicit completion criteria, validation gates, and a hard iteration cap.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `kaizen-iteration`, `system-design`, `prompt-engineering`, `unit-testing`, `code-review`, `systematic-debugging`.
+- Local skill file hints if installed: `.github/skills/kaizen-iteration/SKILL.md`, `.github/skills/system-design/SKILL.md`, `.github/skills/prompt-engineering/SKILL.md`, `.github/skills/unit-testing/SKILL.md`, `.github/skills/code-review/SKILL.md`, `.github/skills/systematic-debugging/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# Loop Workflow
+
+## When to use
+
+Use when a task needs repeated attempt, validation, and correction until it satisfies a clear completion contract. This workflow is explicit and bounded. It must never start implicitly.
+
+## Agent Chain
+
+`orchestrator` -> delegates to `planner`, `implementer`, `tester`, and `reviewer` as needed
+
+## Routing
+
+1. **Scope**: `@orchestrator` turns the request into a bounded loop with a task, completion criteria, max iterations, and validation command.
+2. **Plan**: `@planner` defines the first pass and stop conditions when the task is not already obvious.
+3. **Execute**: `@implementer` applies the next increment.
+4. **Validate**: `@tester` runs the required check or suite.
+5. **Review**: `@reviewer` confirms the output is acceptable.
+6. **Repeat**: `@orchestrator` decides whether another iteration is needed or the loop should stop.
+
+## Skill Routing
+
+- Primary skills: `kaizen-iteration`, `system-design`
+- Supporting skills (optional): `prompt-engineering`, `unit-testing`, `code-review`, `systematic-debugging`
+
+## Context notes
+
+- Require explicit `--task`, `--completion-criteria`, and `--max-iterations` when the loop is started.
+- Keep each iteration small and evidence-based.
+- Stop when the completion criteria are met, validation fails repeatedly, or the iteration cap is reached.
+
+## Workflow steps
+
+1. Define the bounded task, completion criteria, and validation command.
+2. Run one implementation increment.
+3. Validate the increment.
+4. Review the result against the completion criteria.
+5. Repeat only if the loop still has room and the criteria are not satisfied.
+6. Persist the result, evidence, and final status.
+
+## Verification
+
+- Completion criteria are explicit before the first iteration.
+- Validation is run at least once per iteration.
+- The loop stops at or before the configured iteration cap.
+- Final output includes evidence, stop reason, and any follow-up items.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: orchestrator
+  loop_status: <complete|blocked|stopped|failed>
+  iteration_count: <number>
+  completion_criteria_met: <boolean>
+  validation_status: <pass|fail>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/copilot/prompts/mobile-qa.prompt.md

@@ -0,0 +1,74 @@
+# Workflow Prompt: /mobile-qa
+
+Run charter-driven mobile QA through Android MCP first, capture deterministic evidence, and use ADB only as explicit fallback.
+
+Execution contract:
+1. Treat route selection as already resolved by this command; do not begin with skill discovery.
+2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
+Attached skills:
+- Load these exact skill IDs first: `flutter-mobile-qa`, `integration-testing`, `code-review`.
+- Local skill file hints if installed: `.github/skills/flutter-mobile-qa/SKILL.md`, `.github/skills/integration-testing/SKILL.md`, `.github/skills/code-review/SKILL.md`.
+- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
+3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+4. Route to the workflow's primary specialist and only add supporting specialists when needed.
+5. If freshness or public comparison matters, run `deep-research` before implementation and use official docs as primary evidence.
+6. Return actions taken, verification evidence, and any gaps.
+
+Workflow source:
+# Mobile QA Workflow
+
+## When to use
+
+Use when validating a real mobile flow on Android and the main outcome is execution evidence, not test-suite authoring.
+
+## Agent Chain
+
+`explorer` -> `tester` -> `reviewer`
+
+## Routing
+
+1. **Explore**: `@explorer` confirms the app target, charter inputs, Android MCP availability, and any APK/device prerequisites.
+2. **Test**: `@tester` runs the mobile QA charter, captures screenshots/UI trees/logs, and applies the fallback rule only when needed.
+3. **Review**: `@reviewer` checks whether the evidence actually proves pass, fail, or blocked status.
+
+## Skill Routing
+
+- Primary skills: `flutter-mobile-qa`
+- Supporting skills (optional): `integration-testing`, `code-review`
+
+## Context notes
+
+- Provide the charter path, package or APK target, and whether ADB fallback is allowed.
+- This route is for live QA execution and evidence capture, not generalized suite authoring.
+## Runtime contract
+
+- Prefer Android MCP as the primary execution path.
+- Allow direct ADB only when the operator explicitly enables fallback.
+- Save artifacts under `artifacts/mobile-qa/`.
+- Stop after one controlled retry and report evidence.
+
+## Workflow steps
+
+1. Confirm the charter, package target, and environment readiness.
+2. Run the Android MCP-driven QA flow and capture baseline evidence.
+3. Execute each charter step and persist screenshots, UI trees, and logs.
+4. If Android MCP is unavailable and fallback is allowed, run the bounded ADB fallback path.
+5. Review the evidence and summarize pass/fail/blocked findings.
+
+## Verification
+
+- The charter ran against the intended package or APK.
+- Evidence exists for baseline state and any failure.
+- The final report states which provider executed the run.
+
+## Output Contract
+
+```yaml
+WORKFLOW_RESULT:
+  primary_agent: tester
+  supporting_agents: [explorer, reviewer]
+  provider_used: <android-mcp|adb>
+  artifacts: [<path>]
+  blocked_reasons: [<string>] | []
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/copilot/prompts/plan.prompt.md

@@ -1,13 +1,13 @@
 # Workflow Prompt: /plan
 
-Build a decision-complete implementation plan with interfaces, failure modes, and acceptance criteria.
+Research a codebase and produce a structured implementation plan. Explore first, then design.
 
 Execution contract:
 1. Treat route selection as already resolved by this command; do not begin with skill discovery.
 2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
 Attached skills:
-- Load these exact skill IDs first: `system-design`, `api-design`, `database-design`, `deep-research`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, `skill-creator`.
-- Local skill file hints if installed: `.github/skills/system-design/SKILL.md`, `.github/skills/api-design/SKILL.md`, `.github/skills/database-design/SKILL.md`, `.github/skills/deep-research/SKILL.md`, `.github/skills/mcp-server-builder/SKILL.md`, `.github/skills/tech-doc/SKILL.md`, `.github/skills/prompt-engineering/SKILL.md`, `.github/skills/skill-creator/SKILL.md`.
+- Load these exact skill IDs first: `spec-driven-delivery`, `system-design`, `deep-research`.
+- Local skill file hints if installed: `.github/skills/spec-driven-delivery/SKILL.md`, `.github/skills/system-design/SKILL.md`, `.github/skills/deep-research/SKILL.md`.
 - Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
 3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
 4. Route to the workflow's primary specialist and only add supporting specialists when needed.
@@ -19,70 +19,47 @@ Workflow source:
 
 ## When to use
 
-Use this when starting a new feature, project, or significant change that needs a structured implementation plan before coding begins.
+Use when you need to understand a codebase area and create an actionable implementation plan before writing code. Best for architecture decisions, feature scoping, and implementation planning.
 
-## Routing
+## Agent Chain
 
-- Primary coordinator: `@project-planner`
-- Architecture support: `@orchestrator`
-- Domain validation: `@backend-specialist`, `@frontend-specialist`, `@database-architect`
+`explorer` -> `planner` -> `orchestrator`
 
-## Context notes
+## Routing
 
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach the feature request, problem statement, constraints, and any existing design documents.
-- Read `ENGINEERING_RULES.md` first and `docs/foundation/TECH.md` next when they exist before finalizing a non-trivial plan. Also check `docs/foundation/PRODUCT.md` for domain glossary and `docs/foundation/ARCHITECTURE.md` for crosscutting concerns and dependency rules.
-- Reuse an existing `docs/specs/<spec-id>/` pack when the change already has one instead of creating a parallel planning track.
+1. **Explore**: `@explorer` surveys the relevant codebase area - maps files, reads key modules, identifies patterns and constraints.
+2. **Plan**: `@planner` takes exploration findings and produces a structured implementation plan with steps, testing criteria, and risks.
+3. **Return**: `@orchestrator` receives the plan for delegation or approval.
 
 ## Skill Routing
 
-- Primary skills: `system-design`, `api-design`
-- Supporting skills (optional): `database-design`, `deep-research`, `mcp-server-builder`, `openai-docs`, `prompt-engineering`, `skill-creator`
-- Start with `system-design` for system design and `api-design` for API contracts. Add `database-design` when data modeling is central, `deep-research` when fresh external knowledge or public comparison is needed.
+- Primary skills: `spec-driven-delivery`, `system-design`
+- Supporting skills (optional): `deep-research`
+
+## Context notes
+
+- Provide the task requirements, constraints, and any relevant background.
+- The planner will record project-level observations to memory for future reference.
 
 ## Workflow steps
 
-1. Clarify scope, success criteria, and constraints.
-2. Research existing patterns and dependencies, starting in-repo and escalating to `deep-research` only when outside evidence is required.
-3. Decompose into tasks with ownership and dependencies.
-4. Define interfaces, contracts, and failure modes.
-5. Produce acceptance criteria for each milestone.
-6. Record `architecture_impact`, `doc_impact`, and `traceability_status` when the work is non-trivial.
-7. Identify risks, unknowns, and mitigation strategies.
+1. Explorer reads the task requirements and identifies relevant codebase areas.
+2. Explorer produces a structured findings report (key files, architecture, observations).
+3. Planner takes findings and produces an implementation plan (goal, steps, tests, risks).
+4. Orchestrator reviews the plan and routes to implementation or requests revisions.
 
 ## Verification
 
-- Every task has an owner, acceptance criteria, and verification approach.
-- Dependencies form a valid DAG with no cycles.
-- Risk assessment covers top 3 failure scenarios.
-- Plan reviewed against existing codebase conventions.
+- Plan references actual file paths and patterns from the codebase.
+- Implementation steps are specific enough to execute without ambiguity.
+- Testing criteria and risks are identified.
 
 ## Output Contract
 
 ```yaml
-PLAN_WORKFLOW_RESULT:
-  primary_agent: project-planner
-  supporting_agents: [orchestrator?, backend-specialist?, frontend-specialist?, database-architect?]
-  primary_skills: [system-design, api-design]
-  supporting_skills: [database-design?, deep-research?, mcp-server-builder?]
-  spec_id: <string> | null
-  spec_root: docs/specs/<spec-id> | null
-  plan:
-    scope_summary: <string>
-    tasks:
-      - id: <task-id>
-        description: <string>
-        owner: <agent-name>
-        dependencies: [<task-id>]
-        acceptance_criteria: [<string>]
-    interfaces: [<string>]
-    risks: [<string>]
-    milestones: [<string>]
-  architecture_impact:
-    summary: <string>
-    affects_structure: true | false
-    affects_design_system: true | false
-  doc_impact: none | tech | rules | both
-  traceability_status: complete | partial | blocked
+WORKFLOW_RESULT:
+  primary_agent: planner
+  supporting_agents: [explorer]
+  plan_sections: [goal, context, design_decisions, implementation_steps, testing_criteria, risks]
   follow_up_items: [<string>] | []
 ```