@cubis/foundry 0.3.76 → 0.3.78

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

@@ -0,0 +1,82 @@
+---
+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: `the project-planner posture`
+- Documentation support: `the documentation-writer posture`
+- Research support: `the researcher posture`
+- Domain validation: `the backend-specialist posture`, `the frontend-specialist posture`, `the database-architect posture`
+
+## 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>] | []
+```
+
+> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.

package/workflows/workflows/agent-environment-setup/platforms/gemini/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/gemini/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/gemini/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/gemini/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,6 +61,10 @@ 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/gemini/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,6 +71,7 @@ MIGRATE_WORKFLOW_RESULT:
   verification:
     tests_passed: true | false
     performance_impact: <string>
+  doc_impact: none | tech | rules | both
   follow_up_items: [<string>] | []
 ```
 

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/mobile.md

@@ -20,6 +20,7 @@ Use this for mobile app development, Flutter architecture, Stitch-driven mobile
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach platform targets (iOS, Android, both), Flutter version, and relevant screen/feature context.
+- Read `ENGINEERING_RULES.md` and `TECH.md` before implementing non-trivial mobile work so screens and features follow the declared architecture and design-system rules.
 
 ## Skill Routing
 
@@ -35,6 +36,7 @@ Use this for mobile app development, Flutter architecture, Stitch-driven mobile
 3. Implement with consideration for iOS/Android differences.
 4. Write widget and integration tests.
 5. Review for platform-specific edge cases and UX conventions.
+6. Set `doc_impact` if the feature changes navigation, shared UI rules, or mobile architecture conventions.
 
 ## Verification
 
@@ -62,6 +64,7 @@ MOBILE_WORKFLOW_RESULT:
   platform_notes:
     ios: [<string>] | []
     android: [<string>] | []
+  doc_impact: none | tech | rules | both
   follow_up_items: [<string>] | []
 ```
 

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/onboard.md

@@ -27,12 +27,13 @@ Use this when joining a new project, exploring an unfamiliar codebase, or prepar
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Provide the repo URL, focus areas, and any specific questions to answer during onboarding.
+- Read `ENGINEERING_RULES.md` first and `TECH.md` next when present so onboarding distinguishes the intended contract from current implementation reality.
 
 ## Skill Routing
 
-- Primary skills: `architecture-doc`, `system-design`
+- Primary skills: `deep-research`, `system-design`
 - Supporting skills (optional): `system-design`, `database-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`
-- Start with `architecture-doc` for systematic exploration and `system-design` for architecture mapping. Add `system-design` for undocumented systems.
+- Start with `deep-research` for systematic exploration and `system-design` for architecture mapping. Add `system-design` for undocumented systems. Prefer repo evidence first; use external sources only when setup or dependency behavior cannot be confirmed locally.
 
 ## Workflow steps
 
@@ -55,7 +56,7 @@ Use this when joining a new project, exploring an unfamiliar codebase, or prepar
 ONBOARD_WORKFLOW_RESULT:
   primary_agent: researcher
   supporting_agents: [code-archaeologist?, backend-specialist?, frontend-specialist?]
-  primary_skills: [architecture-doc, system-design]
+  primary_skills: [deep-research, system-design]
   supporting_skills: [system-design?, database-design?]
   project_overview:
     purpose: <string>

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/orchestrate.md

@@ -20,12 +20,13 @@ Use this when a task spans multiple domains (backend + frontend, security + infr
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the full task description, constraints, acceptance criteria, and relevant context when starting.
+- Read `ENGINEERING_RULES.md` and `TECH.md` before decomposing non-trivial work, then reuse any existing `docs/specs/<spec-id>/` pack as the handoff source of truth.
 
 ## Skill Routing
 
 - Primary skills: `system-design`, `api-design`
-- Supporting skills (optional): `database-design`, `architecture-doc`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, `skill-creator`
-- Start with `system-design` for system design coordination and `api-design` for integration contracts. Add supporting skills based on the coordination challenge.
+- Supporting skills (optional): `database-design`, `deep-research`, `mcp-server-builder`, `tech-doc`, `prompt-engineering`, `skill-creator`
+- Start with `system-design` for system design coordination and `api-design` for integration contracts. Add `deep-research` before implementation when the coordination challenge depends on fresh external facts or public comparison.
 
 ## Workflow steps
 
@@ -34,7 +35,8 @@ Use this when a task spans multiple domains (backend + frontend, security + infr
 3. Delegate each task to the best specialist agent with full context.
 4. Validate each deliverable against acceptance criteria via independent validation.
 5. Iterate on failed validations with specific feedback (max 3 iterations).
-6. Integrate outputs, verify cross-task consistency, and report results.
+6. Surface `doc_impact` when the coordinated work changes architecture, boundaries, scale, or the design system.
+7. Integrate outputs, verify cross-task consistency, and report results.
 
 ## Verification
 
@@ -51,6 +53,8 @@ ORCHESTRATE_WORKFLOW_RESULT:
   supporting_agents: [<specialist-agents-used>]
   primary_skills: [system-design, api-design]
   supporting_skills: [<supporting-skills-used>]
+  spec_id: <string> | null
+  spec_root: docs/specs/<spec-id> | null
   task_count: <number>
   completed: <number>
   failed: <number>
@@ -61,6 +65,7 @@ ORCHESTRATE_WORKFLOW_RESULT:
       iterations: <number>
       validation_evidence: <string>
   integration_status: clean | conflicts_resolved | issues_remaining
+  doc_impact: none | tech | rules | both
   remaining_risks: [<string>] | []
   follow_up_actions: [<string>] | []
 ```

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/plan.md

@@ -4,7 +4,6 @@ description: "Build a decision-complete implementation plan with interfaces, fai
 triggers:
   [
     "plan",
-    "spec",
     "design",
     "roadmap",
     "acceptance",
@@ -32,21 +31,24 @@ Use this when starting a new feature, project, or significant change that needs
 
 - 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 `TECH.md` next when they exist before finalizing a non-trivial plan.
+- Reuse an existing `docs/specs/<spec-id>/` pack when the change already has one instead of creating a parallel planning track.
 
 ## Skill Routing
 
 - Primary skills: `system-design`, `api-design`
-- Supporting skills (optional): `database-design`, `architecture-doc`, `mcp-server-builder`, `tech-doc`, `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, `architecture-doc` when external knowledge is needed.
+- Supporting skills (optional): `database-design`, `deep-research`, `mcp-server-builder`, `tech-doc`, `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.
 
 ## Workflow steps
 
 1. Clarify scope, success criteria, and constraints.
-2. Research existing patterns and dependencies.
+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. Identify risks, unknowns, and mitigation strategies.
+6. Record `architecture_impact`, `doc_impact`, and `traceability_status` when the work is non-trivial.
+7. Identify risks, unknowns, and mitigation strategies.
 
 ## Verification
 
@@ -62,7 +64,9 @@ 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?, architecture-doc?, mcp-server-builder?]
+  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:
@@ -74,6 +78,12 @@ PLAN_WORKFLOW_RESULT:
     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
   follow_up_items: [<string>] | []
 ```
 

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/refactor.md

@@ -20,6 +20,7 @@ Use this when improving code structure, reducing tech debt, or modularizing with
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the target code, pain points, and any constraints on what can change.
+- Read `ENGINEERING_RULES.md` and `TECH.md` first so behavior-preserving structure changes do not drift from the accepted architecture contract.
 
 ## Skill Routing
 
@@ -34,6 +35,7 @@ Use this when improving code structure, reducing tech debt, or modularizing with
 3. Apply one refactoring at a time with behavior preservation.
 4. Verify behavior unchanged after each step.
 5. Document the improved structure and any conventions established.
+6. Set `doc_impact` when the refactor changes project structure, module boundaries, or design-system conventions.
 
 ## Verification
 
@@ -57,6 +59,7 @@ REFACTOR_WORKFLOW_RESULT:
   quality_improvement:
     complexity_before: <string>
     complexity_after: <string>
+  doc_impact: none | tech | rules | both
   tests_added: [<test-file-path>] | []
   follow_up_items: [<string>] | []
 ```

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/release.md

@@ -20,6 +20,7 @@ Use this when preparing a release, deploying to production, or managing a rollou
 
 - This workflow file, active platform rules, and selected agents or skills guide execution.
 - Attach the release scope, version number, changelog draft, and deployment target.
+- Read `ENGINEERING_RULES.md` and `TECH.md` before release if the shipped changes touched architecture, scaling assumptions, or design-system rules.
 
 ## Skill Routing
 
@@ -35,6 +36,7 @@ Use this when preparing a release, deploying to production, or managing a rollou
 4. Execute staged rollout with health checks at each stage.
 5. Verify production health post-deployment.
 6. Document rollback procedure and post-release status.
+7. Set `doc_impact` if the release includes architecture-affecting work that should refresh the managed docs.
 
 ## Verification
 
@@ -61,6 +63,7 @@ RELEASE_WORKFLOW_RESULT:
     stages_completed: [<string>]
     health_checks: [<string>]
   rollback_plan: <string>
+  doc_impact: none | tech | rules | both
   follow_up_items: [<string>] | []
 ```
 

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/spec.md

@@ -0,0 +1,81 @@
+---
+command: "/spec"
+description: "Create or refresh a Git-tracked spec pack for non-trivial work, including acceptance criteria, traceability, architecture impact, and next-route handoff."
+triggers:
+  [
+    "spec",
+    "sdd",
+    "source of truth",
+    "traceability",
+    "acceptance criteria",
+    "openspec",
+    "requirements",
+    "architecture impact",
+  ]
+---
+
+# Spec Workflow
+
+## When to use
+
+Use this for non-trivial work that needs durable planning in Git before implementation: medium or large features, multi-step changes, cross-session work, migrations, risky refactors, or any request that needs explicit acceptance and traceability.
+
+## Routing
+
+- Primary coordinator: `the project-planner posture`
+- Traceability and requirements support: `the researcher posture`
+- Cross-domain coordination: `the orchestrator posture`
+- Documentation and structure support: `the documentation-writer posture`
+
+## Skill Routing
+
+- Primary skills: `spec-driven-delivery`, `sadd`
+- Supporting skills (optional): `system-design`, `architecture-doc`, `deep-research`, `api-design`, `database-design`, `tech-doc`
+- Start with `spec-driven-delivery` for the pack structure and handoff contract. Add `sadd` when mining requirements into testable assertions, `system-design` or `architecture-doc` when the spec changes structure, and `deep-research` only when repo-local evidence is insufficient.
+
+## Workflow steps
+
+1. Determine whether the task is non-trivial enough to justify a spec pack.
+2. Find an existing `docs/specs/<spec-id>/` pack or create a new stable `spec_id`.
+3. Write or refresh the spec pack with brief, acceptance, tasks, traceability, and handoff files.
+4. Record `architecture_impact`, `doc_impact`, and any required updates to `ENGINEERING_RULES.md` or `TECH.md`.
+5. Identify the next execution route and hand off without replanning the same work.
+
+## Context notes
+
+- Read `ENGINEERING_RULES.md` first and `TECH.md` next when they exist because they define the accepted architecture contract and current state.
+- Prefer repo evidence first; escalate to `deep-research` only when freshness, public comparison, or explicit research requests require it.
+- Keep spec packs lean. Trivial one-step tasks should stay on the lightweight path with no new spec directory.
+
+## Verification
+
+- `spec_id` and `spec_root` are stable and explicit.
+- Acceptance criteria are testable and traceable.
+- Task dependencies form a valid execution order.
+- `architecture_impact`, `doc_impact`, and `traceability_status` are present.
+
+## Output Contract
+
+```yaml
+SPEC_WORKFLOW_RESULT:
+  primary_agent: project-planner
+  supporting_agents: [researcher?, orchestrator?, documentation-writer?]
+  primary_skills: [spec-driven-delivery, sadd]
+  supporting_skills: [system-design?, architecture-doc?, deep-research?, api-design?, database-design?, tech-doc?]
+  spec_id: <string>
+  spec_root: docs/specs/<spec-id>
+  architecture_impact:
+    summary: <string>
+    affects_structure: true | false
+    affects_design_system: true | false
+    affects_testing_strategy: true | false
+  doc_impact: none | tech | rules | both
+  traceability_status: complete | partial | blocked
+  documents:
+    created: [<path>] | []
+    updated: [<path>] | []
+  next_route: </create | /implement-track | /orchestrate | /architecture | direct>
+  gaps: [<string>] | []
+```
+
+> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.

package/workflows/workflows/agent-environment-setup/shared/agents/backend-specialist.md

@@ -4,7 +4,7 @@ description: Backend specialist for API contracts, service logic, schema-aware b
 tools: Read, Grep, Glob, Bash, Edit, Write
 model: inherit
 maxTurns: 25
-skills: api-designer, api-patterns, architecture-designer, auth-architect, database-skills, database-design, database-optimizer, drizzle-expert, firebase, microservices-architect, nodejs-best-practices, nestjs-expert, fastapi-expert, graphql-architect, stripe-best-practices, serverless-patterns, i18n-localization, typescript-pro, javascript-pro, python-pro, golang-pro, java-pro, csharp-pro, kotlin-pro, rust-pro, php-pro, ruby-pro
+skills: api-design, api-patterns, system-design, auth-architect, database-design, database-design, database-optimizer, drizzle-expert, firebase, microservices-architect, nodejs-best-practices, nestjs-expert, fastapi-expert, graphql-architect, stripe-best-practices, serverless-patterns, i18n-localization, typescript-pro, javascript-pro, python-pro, golang-pro, java-pro, csharp-pro, kotlin-pro, rust-pro, php-pro, ruby-pro
 handoffs:
   - agent: "test-engineer"
     title: "Test Backend"
@@ -20,10 +20,10 @@ Build backend systems that stay correct under production pressure.
 
 - Do not call `skill_search` for any skill in the pre-declared list when the task clearly falls into that domain.
 - Load one primary skill first based on the dominant concern:
-  - `api-designer` for API contract shape, versioning, or endpoint design
+  - `api-design` for API contract shape, versioning, or endpoint design
   - `api-patterns` for REST/RPC conventions and HTTP semantics
   - `auth-architect` for authentication, authorization, session, RBAC, or SSO flows
-  - `database-skills` for schema design, query optimization, or migration planning
+  - `database-design` for schema design, query optimization, or migration planning
   - `nestjs-expert` for NestJS-specific module, provider, or decorator patterns
   - `fastapi-expert` for FastAPI route, dependency injection, or Pydantic model patterns
   - `graphql-architect` for GraphQL schema, resolver, or subscription design
@@ -40,10 +40,10 @@ Load on demand. Do not preload all references.
 
 | File                      | Load when                                                                    |
 | ------------------------- | ---------------------------------------------------------------------------- |
-| `api-designer`            | Designing new API contracts, versioning, or endpoint shape.                  |
+| `api-design`            | Designing new API contracts, versioning, or endpoint shape.                  |
 | `api-patterns`            | REST/RPC conventions, HTTP status codes, or pagination patterns.             |
 | `auth-architect`          | Auth flows, token management, session design, or access control.             |
-| `database-skills`         | Schema design, query optimization, or migration strategy.                    |
+| `database-design`         | Schema design, query optimization, or migration strategy.                    |
 | `nestjs-expert`           | NestJS modules, providers, guards, interceptors, or decorators.              |
 | `fastapi-expert`          | FastAPI routes, middleware, Pydantic models, or async patterns.              |
 | `graphql-architect`       | GraphQL schema design, resolvers, or subscription patterns.                  |

package/workflows/workflows/agent-environment-setup/shared/agents/database-architect.md

@@ -4,7 +4,7 @@ description: Expert database architect for schema design, query optimization, mi
 tools: Read, Grep, Glob, Bash, Edit, Write
 model: inherit
 maxTurns: 25
-skills: architecture-designer, database-skills, database-design, database-optimizer, drizzle-expert, postgres, mysql, sqlite, mongodb, redis, supabase, firebase, vitess, neki, typescript-pro, javascript-pro, python-pro, golang-pro, java-pro, php-pro, ruby-pro
+skills: system-design, database-design, database-design, database-optimizer, drizzle-expert, postgres, mysql, sqlite, mongodb, redis, supabase, firebase, vitess, neki, typescript-pro, javascript-pro, python-pro, golang-pro, java-pro, php-pro, ruby-pro
 handoffs:
   - agent: "backend-specialist"
     title: "Implement Schema Changes"
@@ -22,7 +22,7 @@ Design and operate data systems that stay correct, performant, and evolvable und
 - Load one primary skill first based on the dominant concern:
   - `database-design` for schema normalization, entity modeling, or relationship design
   - `database-optimizer` for query performance, index strategy, or execution plan analysis
-  - `database-skills` for cross-cutting database operations and migration patterns
+  - `database-design` for cross-cutting database operations and migration patterns
   - `drizzle-expert` for Drizzle ORM schema, queries, or TypeScript-first database access
   - `postgres` / `mysql` / `sqlite` / `mongodb` / `redis` for engine-specific patterns
   - `supabase` / `firebase` / `vitess` / `neki` for platform-specific database behavior
@@ -37,7 +37,7 @@ Load on demand. Do not preload all references.
 | -------------------- | --------------------------------------------------------------------------- |
 | `database-design`    | Schema normalization, entity relationships, or data modeling decisions.     |
 | `database-optimizer` | Query performance, index strategy, or EXPLAIN analysis.                     |
-| `database-skills`    | Cross-cutting operations, migration patterns, or general database guidance. |
+| `database-design`    | Cross-cutting operations, migration patterns, or general database guidance. |
 | `drizzle-expert`     | Drizzle ORM schema definitions, queries, or migrations.                     |
 | `postgres`           | PostgreSQL-specific features, extensions, or tuning.                        |
 | `mysql`              | MySQL-specific features, replication, or optimization.                      |

package/workflows/workflows/agent-environment-setup/shared/agents/orchestrator.md

@@ -5,7 +5,7 @@ tools: Read, Grep, Glob, Bash, Write, Edit
 model: inherit
 maxTurns: 30
 memory: project
-skills: architecture-designer, api-designer, database-skills, deep-research, mcp-builder, openai-docs, prompt-engineer, skill-creator, typescript-pro, javascript-pro, python-pro
+skills: system-design, api-design, database-design, deep-research, mcp-server-builder, openai-docs, prompt-engineering, skill-creator, typescript-pro, javascript-pro, python-pro
 handoffs:
   - agent: "validator"
     title: "Validate Results"
@@ -31,8 +31,8 @@ Your only permitted actions:
 
 ## Skill Loading Contract
 
-- Do not call `skill_search` for `architecture-designer`, `api-designer`, `database-skills`, `deep-research`, `mcp-builder`, `openai-docs`, `prompt-engineer`, or `skill-creator` when the task is clearly multi-stream coordination, planning, architecture design, contract design, research, or skill package work.
-- Use `architecture-designer` when the coordination problem is really a design tradeoff problem, `api-designer` when integration contracts are the coordination bottleneck, `database-skills` when the shared dependency is a data-model or migration concern, `deep-research` when the coordination risk is stale or conflicting external information, `mcp-builder` for MCP-specific streams, `openai-docs` for OpenAI-doc verification streams, `prompt-engineer` for instruction-quality streams, and `skill-creator` when the coordinated changes are in skills, mirrors, routing, or packaging.
+- Do not call `skill_search` for `system-design`, `api-design`, `database-design`, `deep-research`, `mcp-server-builder`, `openai-docs`, `prompt-engineering`, or `skill-creator` when the task is clearly multi-stream coordination, planning, architecture design, contract design, research, or skill package work.
+- Use `system-design` when the coordination problem is really a design tradeoff problem, `api-design` when integration contracts are the coordination bottleneck, `database-design` when the shared dependency is a data-model or migration concern, `deep-research` when the coordination risk is stale or conflicting external information, `mcp-server-builder` for MCP-specific streams, `openai-docs` for OpenAI-doc verification streams, `prompt-engineering` for instruction-quality streams, and `skill-creator` when the coordinated changes are in skills, mirrors, routing, or packaging.
 - Prefer platform-native delegation features when available, but keep the orchestration contract stable even when execution stays in a single track.
 - Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed by the current coordination step.
 
@@ -42,13 +42,13 @@ Load on demand. Do not preload all references.
 
 | File                    | Load when                                                                                                 |
 | ----------------------- | --------------------------------------------------------------------------------------------------------- |
-| `architecture-designer` | Coordination depends on resolving system design or interface tradeoffs first.                             |
-| `api-designer`          | The critical shared dependency is an API contract or integration boundary.                                |
-| `database-skills`       | The coordination risk centers on schema, migration, data ownership, or engine choice.                     |
+| `system-design` | Coordination depends on resolving system design or interface tradeoffs first.                             |
+| `api-design`          | The critical shared dependency is an API contract or integration boundary.                                |
+| `database-design`       | The coordination risk centers on schema, migration, data ownership, or engine choice.                     |
 | `deep-research`         | External sources, latest information, or public-repo comparisons are blocking confident execution.        |
-| `mcp-builder`           | One stream is MCP server design, tool shape, or transport selection.                                      |
+| `mcp-server-builder`           | One stream is MCP server design, tool shape, or transport selection.                                      |
 | `openai-docs`           | One stream needs current OpenAI docs or version-specific behavior verification.                           |
-| `prompt-engineer`       | One stream is repairing prompts, agent rules, or instruction quality.                                     |
+| `prompt-engineering`       | One stream is repairing prompts, agent rules, or instruction quality.                                     |
 | `skill-creator`         | The coordinated work includes creating, repairing, or adapting skill packages across generated platforms. |
 
 ## When to Use
@@ -158,7 +158,8 @@ ANTI-LAZINESS:
 5. **Iterate, don't accept mediocrity** — if output is incomplete or wrong, re-delegate with feedback.
 6. **Track progress visibly** — maintain a task list showing status of each work item.
 7. **Fail fast on blockers** — if a dependency is missing or a task is stuck after 3 iterations, escalate.
-8. **Synthesize at the end** — combine outputs with concrete actions, risks, and verification evidence.
+8. **Route research explicitly** — when freshness or public comparison matters, delegate to `@researcher` or load `deep-research` before implementation.
+9. **Synthesize at the end** — combine outputs with concrete actions, risks, and verification evidence.
 
 ## Anti-Patterns to Prevent
 

package/workflows/workflows/agent-environment-setup/shared/agents/penetration-tester.md

@@ -22,7 +22,7 @@ triggers:
 tools: Read, Grep, Glob, Bash
 model: inherit
 maxTurns: 25
-skills: security-engineer, vulnerability-scanner, auth-architect, api-designer, typescript-pro, javascript-pro, python-pro, golang-pro, rust-pro
+skills: security-engineer, vulnerability-scanner, auth-architect, api-design, typescript-pro, javascript-pro, python-pro, golang-pro, rust-pro
 handoffs:
   - agent: "security-auditor"
     title: "Review Findings"
@@ -39,7 +39,7 @@ Map attack surfaces, validate exploitability, and provide actionable remediation
   - `security-engineer` for OWASP methodology, threat modeling, and secure architecture review
   - `vulnerability-scanner` for dependency scanning, SAST/DAST tooling, and CVE assessment
   - `auth-architect` for authentication bypass, privilege escalation, or session hijacking analysis
-  - `api-designer` for API security review, input validation gaps, or rate limiting assessment
+  - `api-design` for API security review, input validation gaps, or rate limiting assessment
 - Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed.
 
 ## Skill References
@@ -49,7 +49,7 @@ Map attack surfaces, validate exploitability, and provide actionable remediation
 | `security-engineer`     | OWASP methodology, threat modeling, or secure architecture review. |
 | `vulnerability-scanner` | Dependency scanning, SAST/DAST analysis, or CVE assessment.        |
 | `auth-architect`        | Auth bypass, privilege escalation, or session hijacking analysis.  |
-| `api-designer`          | API security gaps, input validation, or rate limiting review.      |
+| `api-design`          | API security gaps, input validation, or rate limiting review.      |
 
 ## Operating Stance