@cubis/foundry 0.3.76 → 0.3.78

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/evals/evals.json

@@ -0,0 +1,56 @@
+[
+  {
+    "name": "latest-capability-verification",
+    "description": "Validate that the skill performs repo-first research, prioritizes official documentation, labels secondary evidence, and recommends a next route.",
+    "prompt": "Research whether the latest official Claude Code hook surface supports reinforcing route honoring before implementation. Start with the current repo state, then use official docs if needed. If community sources add useful practical context, include them but label them appropriately. End with the next workflow, agent, or skill we should use.",
+    "assertions": [
+      {
+        "id": "repo-first",
+        "description": "Starts with repo or local evidence before using external sources."
+      },
+      {
+        "id": "official-first",
+        "description": "Treats official docs or upstream sources as the primary evidence."
+      },
+      {
+        "id": "secondary-labeled",
+        "description": "Labels any Reddit or community evidence as secondary rather than authoritative."
+      },
+      {
+        "id": "gaps-called-out",
+        "description": "States any unresolved gaps, conflicts, or unknowns."
+      },
+      {
+        "id": "next-route",
+        "description": "Ends with a concrete recommended next route."
+      }
+    ]
+  },
+  {
+    "name": "tool-comparison",
+    "description": "Validate that the skill compares options with a clear frame, ties findings back to repo impact, and produces a decision-ready output.",
+    "prompt": "Compare whether our CLI should keep enforcement in Gemini command wrappers only or also add Claude hook templates. Use the repo state first, then official docs for current platform capabilities, and include community evidence only if it adds implementation nuance. Finish with a recommendation and the next route to take.",
+    "assertions": [
+      {
+        "id": "comparison-frame",
+        "description": "Defines concrete comparison axes such as repo impact, enforcement surface, and maintenance cost."
+      },
+      {
+        "id": "repo-impact",
+        "description": "Connects each option back to the current repo or bundle behavior."
+      },
+      {
+        "id": "fact-vs-inference",
+        "description": "Separates verified facts from inference or interpretation."
+      },
+      {
+        "id": "decision-oriented",
+        "description": "Produces a recommendation or explicit defer condition."
+      },
+      {
+        "id": "no-research-sprawl",
+        "description": "Keeps the answer structured instead of turning into an unfiltered dump of sources."
+      }
+    ]
+  }
+]

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/examples/01-latest-docs-check.md

@@ -0,0 +1,12 @@
+# Example: Latest Docs Check
+
+## User Request
+
+> Research whether Claude Code hooks can reinforce route honoring before we add new workflow rules.
+
+## Expected Shape
+
+1. Inspect the repo's current Claude rule and hook support first.
+2. Verify the current official Claude docs for hooks, event names, and config format.
+3. Separate those verified facts from any community commentary about hook effectiveness.
+4. End with the recommended next route, for example `@researcher` continuing the research or `/create` applying the validated hook template changes.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/examples/02-ecosystem-comparison.md

@@ -0,0 +1,12 @@
+# Example: Ecosystem Comparison
+
+## User Request
+
+> Compare whether our CLI should keep Gemini command enforcement only, or add another platform-native hook layer for Claude as well.
+
+## Expected Shape
+
+1. Start with repo constraints and current platform bundle behavior.
+2. Compare the official platform capabilities using primary docs.
+3. Add any useful community evidence as clearly labeled secondary input.
+4. Produce a recommendation tied to the repo: which platform gets which enforcement surface, and why.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/examples/03-research-to-implementation-handoff.md

@@ -0,0 +1,12 @@
+# Example: Research To Implementation Handoff
+
+## User Request
+
+> Research the latest Codex, Claude, and Gemini MCP behavior, then tell me the next route to update our workflow rules safely.
+
+## Expected Shape
+
+1. Gather repo evidence first.
+2. Verify current official docs for each platform.
+3. Summarize verified facts, secondary evidence, and gaps.
+4. End with a precise next route such as `/plan` for a policy change or `skill-creator` for skill/rule packaging work.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/references/comparison-checklist.md

@@ -0,0 +1,57 @@
+# Comparison Checklist
+
+Use this when evaluating tools, frameworks, APIs, or platforms.
+
+## 1. Scope the Comparison
+
+Define:
+
+- what is being compared
+- whether the comparison is about implementation fit, operational cost, or product capability
+- what time horizon matters: immediate migration, medium-term maintenance, or long-term platform fit
+
+## 2. Compare on Stable Axes
+
+Use a short set of dimensions:
+
+- integration fit with the current repo
+- maturity and maintenance signal
+- official documentation quality
+- configuration complexity
+- ecosystem and tooling support
+- operational constraints
+- migration cost
+
+Do not compare on vague criteria like "better DX" without concrete evidence.
+
+## 3. Capture Repo Impact
+
+Tie each option back to the current codebase:
+
+- what code would change
+- which workflows or agents would own the work
+- what risks are specific to this repo
+- whether new MCP tools or skills would be required
+
+## 4. Separate Product Claims from Team Constraints
+
+An option can be technically stronger and still be a worse fit for the repo.
+
+Keep these separate:
+
+- product capability
+- ecosystem quality
+- team familiarity
+- migration blast radius
+- existing architecture constraints
+
+## 5. Decision Frame
+
+Finish with one of:
+
+- recommend option A
+- recommend option B
+- defer decision pending one missing verification
+- keep current approach because switching cost outweighs gain
+
+If the evidence is mixed, say what would change the recommendation.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/references/research-output.md

@@ -0,0 +1,69 @@
+# Research Output Contract
+
+## Required Sections
+
+### 1. Research question
+
+State:
+
+- the exact topic
+- why research was necessary
+- whether freshness or public comparison mattered
+- the decision this research is meant to support
+
+### 2. Verified facts
+
+List the strongest findings first.
+
+For each fact:
+
+- state the claim in one sentence
+- cite the source class: repo, official docs, upstream repo, standard
+- include the relevant link or file path
+- include date/version when it matters
+
+### 3. Secondary / community evidence
+
+Only include this when it adds signal the primary sources did not provide.
+
+For each item:
+
+- label it as secondary evidence
+- state what practical signal it adds
+- avoid presenting it as settled fact
+
+### 4. Gaps / unknowns
+
+Document:
+
+- unresolved conflicts
+- missing official confirmation
+- assumptions that still need validation
+- risks if the team proceeds anyway
+
+### 5. Recommended next route
+
+Research should end with one clear recommendation:
+
+- direct execution
+- a specific workflow like `/plan` or `/create`
+- a specialist like `@researcher` or `@frontend-specialist`
+- an exact skill like `stitch` or `deep-research`
+
+Keep this recommendation concrete enough that the next step does not need another routing pass.
+
+## Compression Rules
+
+- Prefer 5 strong findings over 20 weak ones.
+- Do not paste long quotes from docs when a citation plus summary will do.
+- If multiple sources say the same thing, summarize once and cite the strongest source.
+- If research found nothing reliable, say that directly.
+
+## Handoff Pattern
+
+When handing off to implementation or planning, include:
+
+- the decision summary
+- the highest-confidence constraints
+- the unresolved risks
+- the next route to take

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/deep-research/references/source-ladder.md

@@ -0,0 +1,81 @@
+# Source Ladder
+
+## Goal
+
+Use the smallest amount of external research that still produces a decision-ready answer. Keep the evidence traceable and ordered by trust.
+
+## 1. Repo / Local Evidence First
+
+Start by inspecting:
+
+- application code and tests
+- README files and internal docs
+- generated workflow or skill assets
+- lockfiles, config files, and package manifests
+- existing integration code and migration history
+
+If the repo already answers the question, stop there. Do not browse externally just because web research feels safer.
+
+## 2. Primary External Sources
+
+Use these next:
+
+- official vendor docs
+- upstream repositories and release notes
+- standards bodies and reference specs
+- maintainer-authored examples
+
+Prefer sources that expose:
+
+- exact feature names
+- current version constraints
+- config formats
+- dates or changelog context
+
+When the topic is time-sensitive, capture the date you verified the source and the version or doc page involved.
+
+## 3. Secondary / Community Sources
+
+Use these only after primary evidence:
+
+- Reddit threads
+- issue comments
+- independent blog posts
+- forum discussions
+- third-party comparison articles
+
+Community evidence is useful for:
+
+- practical gotchas
+- migration pain points
+- missing-doc workarounds
+- real-world adoption patterns
+
+Community evidence is not enough on its own for authoritative claims about product behavior, supported configuration, or security guarantees.
+
+## 4. Conflict Handling
+
+When sources disagree:
+
+1. Prefer repo evidence for the current codebase state.
+2. Prefer official docs over community claims for product behavior.
+3. Prefer newer dated material when the sources cover the same feature.
+4. If the conflict remains unresolved, report it as a gap instead of guessing.
+
+## 5. Evidence Labels
+
+Use these labels in research output:
+
+- **Verified fact** — backed by repo evidence or a primary source
+- **Secondary evidence** — backed only by community or indirect sources
+- **Inference** — reasoned conclusion not directly stated by a source
+- **Gap** — could not be verified confidently
+
+## 6. Stop Conditions
+
+Stop researching when:
+
+- the decision is already clear
+- new sources only repeat the same point
+- the remaining uncertainty is small and clearly documented
+- the task should move into implementation or planning

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/skills_index.json

@@ -193,6 +193,38 @@
       "databases"
     ]
   },
+  {
+    "id": "deep-research",
+    "package_id": "deep-research",
+    "catalog_id": "deep-research",
+    "kind": "skill",
+    "name": "deep-research",
+    "canonical": true,
+    "canonical_id": "deep-research",
+    "deprecated": false,
+    "replaced_by": null,
+    "aliases": [],
+    "category": "core-operating",
+    "layer": "core-operating",
+    "maturity": "incubating",
+    "tier": "experimental",
+    "tags": [
+      "core-operating",
+      "deep",
+      "deep research",
+      "deep-research",
+      "research"
+    ],
+    "path": ".claude/skills/deep-research/SKILL.md",
+    "description": "Use when investigating latest vendor behavior, comparing tools or platforms, verifying claims beyond the repo, or gathering external evidence before implementation.",
+    "triggers": [
+      "deep-research",
+      "deep research",
+      "deep",
+      "research",
+      "core-operating"
+    ]
+  },
   {
     "id": "django-drf",
     "package_id": "django-drf",
@@ -1689,6 +1721,40 @@
       "core-operating"
     ]
   },
+  {
+    "id": "spec-driven-delivery",
+    "package_id": "spec-driven-delivery",
+    "catalog_id": "spec-driven-delivery",
+    "kind": "skill",
+    "name": "spec-driven-delivery",
+    "canonical": true,
+    "canonical_id": "spec-driven-delivery",
+    "deprecated": false,
+    "replaced_by": null,
+    "aliases": [],
+    "category": "workflow-specialists",
+    "layer": "workflow-specialists",
+    "maturity": "incubating",
+    "tier": "experimental",
+    "tags": [
+      "delivery",
+      "driven",
+      "spec",
+      "spec driven delivery",
+      "spec-driven-delivery",
+      "workflow-specialists"
+    ],
+    "path": ".claude/skills/spec-driven-delivery/SKILL.md",
+    "description": "Use when turning a non-trivial request into a Git-tracked spec pack, maintaining traceability during execution, and updating specs before code when requirements or architecture change.",
+    "triggers": [
+      "spec-driven-delivery",
+      "spec driven delivery",
+      "spec",
+      "driven",
+      "delivery",
+      "workflow-specialists"
+    ]
+  },
   {
     "id": "spring-boot",
     "package_id": "spring-boot",

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/spec-driven-delivery/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: spec-driven-delivery
+description: Use when turning a non-trivial request into a Git-tracked spec pack, maintaining traceability during execution, and updating specs before code when requirements or architecture change.
+---
+
+# Spec-Driven Delivery
+
+## Purpose
+
+Create and maintain a lightweight source of truth for non-trivial work. This skill turns requirements, decisions, acceptance criteria, and architecture impact into a spec pack under the `docs/specs/<spec-id>/` workspace area, then keeps that pack aligned as implementation evolves.
+
+## When to Use
+
+- Planning a medium or large feature before implementation
+- Capturing acceptance criteria, traceability, and architecture impact in Git
+- Reusing or refreshing an existing spec pack for a follow-up change
+- Bridging native plan-mode output into durable project documents
+- Keeping implementation, verification, and documentation aligned across sessions
+
+## Instructions
+
+1. **Classify the task first** because trivial work should not pay spec overhead. Use this skill only when the task is multi-step, cross-session, cross-domain, risky, or likely to change architecture, testing strategy, or team coordination.
+2. **Look for an existing spec pack before creating a new one** because duplicate specs create drift. Reuse the closest matching spec directory when the current request extends an active initiative.
+3. **Create a stable `spec_id` and spec root** because the same identifier should survive planning, execution, review, and follow-up changes.
+4. **Write the minimum viable pack** because the goal is durable coordination, not bureaucracy. Keep the brief, acceptance, tasks, traceability, and handoff documents concise and testable.
+5. **Use `sadd` when turning requirements into assertions** because spec quality depends on extracting testable behavior instead of leaving requirements vague.
+6. **Record architecture impact explicitly** because implementation must stay aligned with the project architecture contract and current-state tech map. Mark whether the change affects architecture style, module boundaries, dependency rules, design system, deployment shape, or testing strategy.
+7. **Update the spec before implementation changes behavior** because traceability breaks when code changes first and docs lag behind.
+8. **Keep the task graph execution-ready** because `/implement-track` and `/orchestrate` should be able to act on the spec without replanning. Every task should have ownership, dependencies, acceptance criteria, and a verification path.
+9. **Route external research through `deep-research`** because repo-first planning still needs disciplined escalation when freshness or public comparison matters.
+10. **Emit a clear next route** because spec work usually hands off into `/create`, `/implement-track`, `/orchestrate`, or `/architecture`.
+11. **Report `doc_impact` and `traceability_status`** because feature work should surface whether the architecture contract or tech map must be refreshed at the end.
+12. **Keep the pack alive during execution** because a stale spec is worse than none. Update acceptance, tasks, and traceability when scope or constraints change.
+
+## Output Format
+
+Deliver:
+
+1. **Spec summary** — `spec_id`, `spec_root`, goal, scope, and why spec mode is warranted
+2. **Acceptance and traceability state** — requirements, open gaps, and `traceability_status`
+3. **Execution-ready plan** — tasks, owners, dependencies, and verification checkpoints
+4. **Architecture and doc impact** — `architecture_impact` plus `doc_impact`
+5. **Recommended next route** — exact workflow, agent, or skill to continue from the spec
+
+## References
+
+| File | Load when |
+| --- | --- |
+| `../sadd/SKILL.md` | Need requirement mining, GIVEN-WHEN-THEN specs, or traceability patterns. |
+| `../architecture-doc/SKILL.md` | Need ADRs, system boundaries, or architecture-document structure. |
+| `../deep-research/SKILL.md` | Need repo-first research escalation or evidence labeling rules. |
+
+## Examples
+
+| File | Use when |
+| --- | --- |
+| `../sadd/references/spec-mining.md` | Turning loose requirements into testable spec entries. |
+| `../sadd/references/coverage-mapping.md` | Building a traceability matrix that links specs, tests, and code. |
+
+## Claude Platform Notes
+
+- Use `$ARGUMENTS` to access user-provided arguments passed when the skill is invoked.
+- Reference skill-local files with `${CLAUDE_SKILL_DIR}/references/<file>` for portable paths.
+- When `context: fork` is set, the skill runs in an isolated subagent context; the `agent` field names the fork target.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available for dynamic skill discovery and loading.
+- Use `allowed-tools` in frontmatter to restrict tool access for security-sensitive skills.

package/workflows/workflows/agent-environment-setup/platforms/claude/workflows/architecture.md

@@ -0,0 +1,80 @@
+---
+command: "/architecture"
+description: "Refresh the project architecture contract and current-state map in ENGINEERING_RULES.md and TECH.md with explicit structure, design-system, testing, and flow guidance."
+triggers:
+  [
+    "architecture",
+    "design system",
+    "adr",
+    "clean architecture",
+    "system map",
+    "app structure",
+    "technical governance",
+    "flow diagram",
+  ]
+---
+
+# Architecture Workflow
+
+## When to use
+
+Use this when the task is to declare, refresh, or validate the project architecture contract and current-state map, especially after structure changes, scale changes, design-system changes, migrations, or major feature additions.
+
+## Routing
+
+- Primary coordinator: `@project-planner`
+- Documentation support: `@documentation-writer`
+- Research support: `@researcher`
+- Domain validation: `@backend-specialist`, `@frontend-specialist`, `@database-architect`
+
+## Skill Routing
+
+- Primary skills: `architecture-doc`, `system-design`, `tech-doc`, `frontend-design`
+- Supporting skills (optional): `api-design`, `database-design`, `sadd`, `deep-research`
+- Load the four primary skills directly for this workflow. Add `api-design` or `database-design` when service or data boundaries are central, `sadd` when tying the architecture update to an active spec pack, and `deep-research` only when outside evidence is required.
+
+## Workflow steps
+
+1. Inspect the repo first and read `ENGINEERING_RULES.md` followed by `TECH.md` if they exist.
+2. Determine the current architecture style, module boundaries, design-system source of truth, and testing strategy from the codebase.
+3. Update only the managed architecture sections in `ENGINEERING_RULES.md` and `TECH.md`.
+4. Add or refresh Mermaid diagrams and flow narratives inside `TECH.md` when they clarify system behavior.
+5. Record whether the update was driven by a broader spec and whether future implementation must follow newly declared rules.
+
+## Context notes
+
+- This workflow is route-fixed and skill-fixed: do not start with `route_resolve` or `skill_search`.
+- `ENGINEERING_RULES.md` is normative. `TECH.md` is descriptive. Keep them aligned but not redundant.
+- Preserve manual content outside the managed architecture sections.
+- Mark non-applicable sections explicitly instead of silently omitting them.
+
+## Verification
+
+- Managed architecture sections exist in both target docs.
+- Architecture style, dependency rules, and design-system guidance are explicit.
+- `TECH.md` includes flow text and at least one Mermaid diagram when the repo has meaningful flow complexity.
+- The update records `doc_impact` and whether future feature work must refresh the docs again.
+
+## Output Contract
+
+```yaml
+ARCHITECTURE_WORKFLOW_RESULT:
+  primary_agent: project-planner
+  supporting_agents: [documentation-writer?, researcher?, backend-specialist?, frontend-specialist?, database-architect?]
+  primary_skills: [architecture-doc, system-design, tech-doc, frontend-design]
+  supporting_skills: [api-design?, database-design?, sadd?, deep-research?]
+  managed_targets:
+    rules_doc: ENGINEERING_RULES.md
+    tech_doc: TECH.md
+  files_updated: [ENGINEERING_RULES.md, TECH.md]
+  architecture_contract:
+    style: <string>
+    dependency_rules: [<string>]
+    design_system_source: <string>
+  technical_snapshot:
+    topology: [<string>]
+    flows: [<string>]
+    diagrams: [<string>] | []
+  doc_impact: rules | tech | both
+  next_actions: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/claude/workflows/backend.md

@@ -36,6 +36,7 @@ Use this for backend architecture, API design, service implementation, or Postma
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach API specifications, schema diagrams, Postman collections, and relevant service code.
+- Read `ENGINEERING_RULES.md` and `TECH.md` before changing service boundaries or shared backend structure.
 
 ## Skill Routing
 
@@ -50,6 +51,7 @@ Use this for backend architecture, API design, service implementation, or Postma
 3. Implement backend logic with proper error handling and validation.
 4. Write integration tests covering happy path and error cases.
 5. Review for security, performance, and reliability.
+6. Set `doc_impact` if the change alters service boundaries, shared contracts, or operational shape.
 
 ## Verification
 
@@ -74,6 +76,7 @@ BACKEND_WORKFLOW_RESULT:
   implementation:
     files_changed: [<path>]
     tests_added: [<path>]
+  doc_impact: none | tech | rules | both
   verification:
     checks_run: [<command-or-test>]
     evidence: [<string>]

package/workflows/workflows/agent-environment-setup/platforms/claude/workflows/create.md

@@ -22,6 +22,7 @@ Use this for net-new implementation after design is stable.
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach logs, screenshots, failing output, and relevant paths when context is incomplete.
+- Read `ENGINEERING_RULES.md` first and `TECH.md` next for non-trivial work so new code follows the declared architecture and design-system rules.
 
 ## Skill Routing
 
@@ -35,7 +36,8 @@ Use this for net-new implementation after design is stable.
 1. Confirm target files and contracts.
 2. Implement smallest coherent increment.
 3. Validate behavior with focused tests.
-4. Capture remaining gaps and follow-ups.
+4. Capture `doc_impact` when the feature changes architecture, boundaries, scale, or design-system rules.
+5. Capture remaining gaps and follow-ups.
 
 ## Verification
 
@@ -55,6 +57,7 @@ CREATE_WORKFLOW_RESULT:
     summary: <string>
     changed_artifacts: [<path-or-artifact>]
   behavioral_impact: [<string>]
+  doc_impact: none | tech | rules | both
   verification:
     checks_run: [<command-or-test>]
     evidence: [<string>]

package/workflows/workflows/agent-environment-setup/platforms/claude/workflows/database.md

@@ -20,6 +20,7 @@ Use this for schema design, query optimization, migration planning, or database
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach existing schema, migration history, query patterns, and performance requirements.
+- Read `ENGINEERING_RULES.md` and `TECH.md` before changing data ownership, persistence boundaries, or shared schema conventions.
 
 ## Skill Routing
 
@@ -34,6 +35,7 @@ Use this for schema design, query optimization, migration planning, or database
 3. Plan migration with rollback strategy.
 4. Optimize queries and indexes for known access patterns.
 5. Validate data integrity constraints.
+6. Set `doc_impact` if the change alters data boundaries, core entities, or persistence patterns that future work should follow.
 
 ## Verification
 
@@ -57,6 +59,7 @@ DATABASE_WORKFLOW_RESULT:
   query_optimization:
     queries_reviewed: <number>
     indexes_recommended: [<string>] | []
+  doc_impact: none | tech | rules | both
   integrity_checks: [<string>]
   follow_up_items: [<string>] | []
 ```

package/workflows/workflows/agent-environment-setup/platforms/claude/workflows/implement-track.md

@@ -20,6 +20,8 @@ Use this for large-scale implementation work that spans multiple sessions or mil
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the implementation plan, milestone definitions, and acceptance criteria per milestone.
+- Reuse `docs/specs/<spec-id>/` when present instead of maintaining a separate progress source of truth.
+- Read `ENGINEERING_RULES.md` first and `TECH.md` next before starting milestone execution.
 
 ## Skill Routing
 
@@ -33,7 +35,7 @@ Use this for large-scale implementation work that spans multiple sessions or mil
 2. Execute current milestone with focused implementation.
 3. Run quality gate validation at milestone completion.
 4. Update progress tracking and capture status.
-5. Adjust remaining plan based on learnings.
+5. Adjust remaining plan, spec traceability, and doc refresh needs based on learnings.
 6. Proceed to next milestone or report completion.
 
 ## Verification
@@ -59,5 +61,9 @@ IMPLEMENT_TRACK_WORKFLOW_RESULT:
       validation_evidence: <string>
   overall_progress: <percentage>
   scope_changes: [<string>] | []
+  spec_id: <string> | null
+  spec_root: docs/specs/<spec-id> | null
+  traceability_status: complete | partial | blocked
+  doc_impact: none | tech | rules | both
   follow_up_items: [<string>] | []
 ```

package/workflows/workflows/agent-environment-setup/platforms/claude/workflows/migrate.md

@@ -28,6 +28,7 @@ Use this for technology migrations, framework upgrades, dependency updates, or m
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the migration target, current versions, breaking change lists, and impact assessment.
+- Read `ENGINEERING_RULES.md` and `TECH.md` first because migrations often change accepted patterns and current-state architecture at the same time.
 
 ## Skill Routing
 
@@ -42,7 +43,8 @@ Use this for technology migrations, framework upgrades, dependency updates, or m
 3. Plan incremental migration steps with rollback points.
 4. Execute migration one step at a time with verification.
 5. Update tests and documentation for new patterns.
-6. Verify full system behavior after migration complete.
+6. Set `doc_impact` when the migration changes architecture, deployment shape, boundaries, or design-system rules.
+7. Verify full system behavior after migration complete.
 
 ## Verification
 
@@ -69,5 +71,6 @@ MIGRATE_WORKFLOW_RESULT:
   verification:
     tests_passed: true | false
     performance_impact: <string>
+  doc_impact: none | tech | rules | both
   follow_up_items: [<string>] | []
 ```