@cubis/foundry 0.3.81 → 0.3.83

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

@@ -0,0 +1,76 @@
+# Workflow Prompt: /refactor
+
+Improve maintainability while preserving behavior through incremental safe refactoring.
+
+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: `code-review`, `system-design`, `unit-testing`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`.
+- Local skill file hints if installed: `.github/skills/code-review/SKILL.md`, `.github/skills/system-design/SKILL.md`, `.github/skills/unit-testing/SKILL.md`, `.github/skills/typescript-best-practices/SKILL.md`, `.github/skills/javascript-best-practices/SKILL.md`, `.github/skills/python-best-practices/SKILL.md`, `.github/skills/golang-best-practices/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:
+# Refactor Workflow
+
+## When to use
+
+Use this when improving code structure, reducing tech debt, or modularizing without changing behavior.
+
+## Routing
+
+- Primary specialist: `@code-archaeologist`
+- Domain support: `@backend-specialist`, `@frontend-specialist`
+- Verification support: `@test-engineer`, `@validator`
+
+## Context notes
+
+- 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 `docs/foundation/TECH.md` first so behavior-preserving structure changes do not drift from the accepted architecture contract. Check `docs/foundation/ARCHITECTURE.md` for `## Dependency Rules` and `## Crosscutting Concerns` before restructuring.
+
+## Skill Routing
+
+- Primary skills: `static-analysis`, `legacy-modernizer`
+- Supporting skills (optional): `testing-patterns`, `system-design`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`
+- Start with `static-analysis` for automated code quality assessment. Add `legacy-modernizer` for modernization patterns. Add `testing-patterns` when refactoring needs test coverage to proceed safely.
+
+## Workflow steps
+
+1. Map the current structure and identify refactoring targets.
+2. Ensure adequate test coverage before modifying (add tests if needed).
+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
+
+- All existing tests pass after each refactoring step.
+- No behavioral changes introduced (unless explicitly intended).
+- Code quality metrics improved (complexity, coupling, cohesion).
+- New tests added for any gaps discovered during refactoring.
+
+## Output Contract
+
+```yaml
+REFACTOR_WORKFLOW_RESULT:
+  primary_agent: code-archaeologist
+  supporting_agents: [backend-specialist?, frontend-specialist?, test-engineer?, validator?]
+  primary_skills: [static-analysis, legacy-modernizer]
+  supporting_skills: [testing-patterns?, system-design?]
+  refactoring_summary:
+    targets: [<string>]
+    changes_applied: [<string>]
+    behavior_preserved: true | false
+  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/copilot/prompts/release.prompt.md

@@ -0,0 +1,79 @@
+# Workflow Prompt: /release
+
+Prepare and execute release with rollout guardrails, verification, and rollback plan.
+
+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: `ci-cd-pipeline`, `git-workflow`, `tech-doc`, `observability`, `kubernetes-deploy`, `typescript-best-practices`, `javascript-best-practices`.
+- Local skill file hints if installed: `.github/skills/ci-cd-pipeline/SKILL.md`, `.github/skills/git-workflow/SKILL.md`, `.github/skills/tech-doc/SKILL.md`, `.github/skills/observability/SKILL.md`, `.github/skills/kubernetes-deploy/SKILL.md`, `.github/skills/typescript-best-practices/SKILL.md`, `.github/skills/javascript-best-practices/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:
+# Release Workflow
+
+## When to use
+
+Use this when preparing a release, deploying to production, or managing a rollout.
+
+## Routing
+
+- Primary coordinator: `@devops-engineer`
+- Release verification: `@test-engineer`, `@validator`
+- Documentation: `@documentation-writer`
+
+## Context notes
+
+- 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 `docs/foundation/TECH.md` before release if the shipped changes touched architecture, scaling assumptions, or design-system rules. Check `docs/foundation/TECH.md` for `## Build And Validation` and `## CI CD Pipeline` steps to verify the release pipeline.
+
+## Skill Routing
+
+- Primary skills: `ci-cd-pipelines`, `git-workflow`
+- Supporting skills (optional): `changelog-generator`, `devops-engineer`, `sre-engineer`, `docker-kubernetes`, `observability`, `serverless-patterns`, `typescript-pro`, `javascript-pro`
+- Start with `ci-cd-pipelines` for deployment automation and `git-workflow` for release branching. Add `changelog-generator` for release notes.
+
+## Workflow steps
+
+1. Finalize scope — confirm all changes are merged and tested.
+2. Generate changelog and release notes.
+3. Prepare deployment artifacts and configuration.
+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
+
+- All tests pass on release branch/tag.
+- Changelog accurately reflects changes.
+- Deployment artifacts built and verified.
+- Production health confirmed after rollout.
+- Rollback procedure tested or documented.
+
+## Output Contract
+
+```yaml
+RELEASE_WORKFLOW_RESULT:
+  primary_agent: devops-engineer
+  supporting_agents: [test-engineer?, validator?, documentation-writer?]
+  primary_skills: [ci-cd-pipelines, git-workflow]
+  supporting_skills: [changelog-generator?, devops-engineer?, sre-engineer?]
+  release:
+    version: <string>
+    changelog: <string>
+    artifacts: [<string>]
+  deployment:
+    strategy: <staged | canary | blue-green | direct>
+    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/copilot/prompts/review.prompt.md

@@ -0,0 +1,75 @@
+# Workflow Prompt: /review
+
+Run a strict review for bugs, regressions, accessibility issues, security risk, and code quality with prioritized findings.
+
+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: `code-review`, `unit-testing`, `owasp-security-review`, `performance-testing`, `react`, `nextjs`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`.
+- Local skill file hints if installed: `.github/skills/code-review/SKILL.md`, `.github/skills/unit-testing/SKILL.md`, `.github/skills/owasp-security-review/SKILL.md`, `.github/skills/performance-testing/SKILL.md`, `.github/skills/react/SKILL.md`, `.github/skills/nextjs/SKILL.md`, `.github/skills/typescript-best-practices/SKILL.md`, `.github/skills/javascript-best-practices/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:
+# Review Workflow
+
+## When to use
+
+Use this for code review, PR review, or quality audit of existing code changes.
+
+## Routing
+
+- Primary specialist: `@frontend-specialist` (for frontend code) or `@backend-specialist` (for backend code)
+- Security review: `@security-auditor`
+- Quality validation: `@validator`
+- Verification support: `@test-engineer`
+
+## Context notes
+
+- This workflow file, active platform rules, and selected agents or skills guide execution.
+- Attach the PR diff, changed files, or specific code paths to review.
+
+## Skill Routing
+
+- Primary skills: `frontend-code-review`, `static-analysis`, `testing-patterns`
+- Supporting skills (optional): `security-engineer`, `vulnerability-scanner`, `web-perf`, `react-expert`, `nextjs-developer`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`
+- Start with `frontend-code-review` for UI code or `static-analysis` for backend code. Add `testing-patterns` when evaluating test quality. Add `security-engineer` for security-sensitive changes.
+
+## Workflow steps
+
+1. Understand the intent and scope of the changes.
+2. Review for correctness — logic bugs, edge cases, and regressions.
+3. Review for security — input validation, auth, secrets exposure.
+4. Review for accessibility — WCAG compliance, keyboard navigation, screen readers.
+5. Review for performance — unnecessary re-renders, N+1 queries, bundle impact.
+6. Prioritize findings by severity and provide actionable feedback.
+
+## Verification
+
+- Each finding has severity, location, and suggested fix.
+- Findings prioritized: critical > high > medium > low.
+- Positive observations noted alongside issues.
+- Reviewed against codebase conventions.
+
+## Output Contract
+
+```yaml
+REVIEW_WORKFLOW_RESULT:
+  primary_agent: <frontend-specialist | backend-specialist>
+  supporting_agents: [security-auditor?, validator?, test-engineer?]
+  primary_skills: [frontend-code-review?, static-analysis?, testing-patterns?]
+  supporting_skills: [security-engineer?, vulnerability-scanner?, web-perf?]
+  findings:
+    - severity: critical | high | medium | low
+      category: correctness | security | accessibility | performance | style
+      location: <file:line>
+      description: <string>
+      suggestion: <string>
+  overall_assessment: approve | request_changes | reject
+  positive_observations: [<string>] | []
+  follow_up_items: [<string>] | []
+```

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

@@ -0,0 +1,78 @@
+# Workflow Prompt: /security
+
+Run security-focused analysis and remediation planning with exploitability-first triage.
+
+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: `owasp-security-review`, `code-review`, `api-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `rust-best-practices`.
+- Local skill file hints if installed: `.github/skills/owasp-security-review/SKILL.md`, `.github/skills/code-review/SKILL.md`, `.github/skills/api-design/SKILL.md`, `.github/skills/typescript-best-practices/SKILL.md`, `.github/skills/javascript-best-practices/SKILL.md`, `.github/skills/python-best-practices/SKILL.md`, `.github/skills/golang-best-practices/SKILL.md`, `.github/skills/rust-best-practices/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:
+# Security Workflow
+
+## When to use
+
+Use this for security audits, vulnerability assessments, threat modeling, or security-focused code review.
+
+## Routing
+
+- Primary specialist: `@security-auditor`
+- Offensive assessment: `@penetration-tester`
+- Domain support: `@backend-specialist`, `@frontend-specialist`
+- Verification support: `@validator`
+
+## Context notes
+
+- This workflow file, active platform rules, and selected agents or skills guide execution.
+- Attach the security scope, threat model, compliance requirements, and relevant code paths.
+
+## Skill Routing
+
+- Primary skills: `security-engineer`, `auth-architect`
+- Supporting skills (optional): `vulnerability-scanner`, `static-analysis`, `api-design`, `graphql-architect`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`, `rust-pro`
+- Start with `security-engineer` for OWASP methodology and threat modeling. Add `auth-architect` for authentication/authorization review. Add `vulnerability-scanner` for dependency scanning and CVE triage.
+
+## Workflow steps
+
+1. Define security scope and threat model.
+2. Map attack surface and identify input vectors.
+3. Assess code against OWASP Top 10 and relevant standards.
+4. Triage findings by exploitability (reachability × controllability × impact).
+5. Produce remediation plan with prioritized fixes.
+6. Verify remediations do not introduce new vulnerabilities.
+
+## Verification
+
+- All critical and high findings have remediation plans.
+- Remediation code reviewed for correctness.
+- No new vulnerabilities introduced by fixes.
+- Compliance requirements addressed if applicable.
+
+## Output Contract
+
+```yaml
+SECURITY_WORKFLOW_RESULT:
+  primary_agent: security-auditor
+  supporting_agents: [penetration-tester?, backend-specialist?, frontend-specialist?, validator?]
+  primary_skills: [security-engineer, auth-architect]
+  supporting_skills: [vulnerability-scanner?, static-analysis?, api-design?]
+  threat_model:
+    assets: [<string>]
+    threats: [<string>]
+    attack_surface: [<string>]
+  findings:
+    - severity: critical | high | medium | low
+      category: <owasp-category>
+      exploitability: <string>
+      remediation: <string>
+  compliance_notes: [<string>] | []
+  remaining_risks: [<string>] | []
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/{antigravity/workflows/spec.md → copilot/prompts/spec.prompt.md}

@@ -1,19 +1,20 @@
----
-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",
-  ]
----
-
+# Workflow Prompt: /spec
+
+Create or refresh a Git-tracked spec pack for non-trivial work, including acceptance criteria, traceability, architecture impact, and next-route handoff.
+
+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: `spec-driven-delivery`, `sadd`, `system-design`, `architecture-doc`, `deep-research`, `api-design`, `database-design`, `tech-doc`.
+- Local skill file hints if installed: `.github/skills/spec-driven-delivery/SKILL.md`, `.github/skills/sadd/SKILL.md`, `.github/skills/system-design/SKILL.md`, `.github/skills/architecture-doc/SKILL.md`, `.github/skills/deep-research/SKILL.md`, `.github/skills/api-design/SKILL.md`, `.github/skills/database-design/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:
 # Spec Workflow
 
 ## When to use
@@ -22,10 +23,10 @@ Use this for non-trivial work that needs durable planning in Git before implemen
 
 ## Routing
 
-- Primary coordinator: `.agent/agents/project-planner`
-- Traceability and requirements support: `.agent/agents/researcher`
-- Cross-domain coordination: `.agent/agents/orchestrator`
-- Documentation and structure support: `.agent/agents/documentation-writer`
+- Primary coordinator: `@project-planner`
+- Traceability and requirements support: `@researcher`
+- Cross-domain coordination: `@orchestrator`
+- Documentation and structure support: `@documentation-writer`
 
 ## Skill Routing
 
@@ -38,7 +39,7 @@ Use this for non-trivial work that needs durable planning in Git before implemen
 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 `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, `ENGINEERING_RULES.md`, or `docs/foundation/TECH.md`.
+4. Record `architecture_impact`, `doc_impact`, and any required updates to `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, `ENGINEERING_RULES.md`, or `docs/foundation/TECH.md`. If the change adds new terms, update the `## Domain Glossary` in `docs/foundation/PRODUCT.md`. If the change introduces new crosscutting patterns or tech debt, flag updates needed in `docs/foundation/ARCHITECTURE.md`.
 5. Identify the next execution route and hand off without replanning the same work.
 
 ## Context notes
@@ -77,5 +78,3 @@ SPEC_WORKFLOW_RESULT:
   next_route: </create | /implement-track | /orchestrate | /architecture | direct>
   gaps: [<string>] | []
 ```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.

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

@@ -0,0 +1,75 @@
+# Workflow Prompt: /test
+
+Design and execute verification strategy aligned to user risk, release confidence, and regression evidence.
+
+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: `unit-testing`, `integration-testing`, `playwright-interactive`, `observability`, `systematic-debugging`, `code-review`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `java-best-practices`.
+- Local skill file hints if installed: `.github/skills/unit-testing/SKILL.md`, `.github/skills/integration-testing/SKILL.md`, `.github/skills/playwright-interactive/SKILL.md`, `.github/skills/observability/SKILL.md`, `.github/skills/systematic-debugging/SKILL.md`, `.github/skills/code-review/SKILL.md`, `.github/skills/typescript-best-practices/SKILL.md`, `.github/skills/javascript-best-practices/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:
+# Test Workflow
+
+## When to use
+
+Use this when writing new tests, improving coverage, debugging test failures, or designing a testing strategy.
+
+## Routing
+
+- Primary specialist: `@test-engineer`
+- Automation support: `@qa-automation-engineer`
+- Domain support: `@backend-specialist`, `@frontend-specialist`
+- Verification support: `@validator`
+
+## Context notes
+
+- This workflow file, active platform rules, and selected agents or skills guide execution.
+- Attach the code under test, existing test files, coverage reports, and any failing test output.
+
+## Skill Routing
+
+- Primary skills: `testing-patterns`, `webapp-testing`
+- Supporting skills (optional): `playwright-e2e`, `error-ux-observability`, `debugging-strategies`, `frontend-code-review`, `static-analysis`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`, `java-pro`
+- Start with `testing-patterns` for test strategy and architecture. Add `webapp-testing` for implementation. Add `playwright-e2e` for E2E automation. Add `error-ux-observability` for testing error states.
+
+## Workflow steps
+
+1. Assess current test coverage and identify gaps.
+2. Design test strategy (which layers, what to test, what to skip).
+3. Implement tests with clear arrange/act/assert structure.
+4. Run tests and verify they pass.
+5. Review coverage improvement and remaining gaps.
+
+## Verification
+
+- All new tests pass reliably (no flakiness).
+- Tests cover the identified risk areas.
+- Coverage metrics improved or maintained.
+- Test naming clearly describes the scenario being verified.
+
+## Output Contract
+
+```yaml
+TEST_WORKFLOW_RESULT:
+  primary_agent: test-engineer
+  supporting_agents: [qa-automation-engineer?, backend-specialist?, frontend-specialist?, validator?]
+  primary_skills: [testing-patterns, webapp-testing]
+  supporting_skills: [playwright-e2e?, error-ux-observability?, debugging-strategies?]
+  test_strategy:
+    unit: <number of tests>
+    integration: <number of tests>
+    e2e: <number of tests>
+  tests_written: [<test-file-path>]
+  coverage:
+    before: <percentage or description>
+    after: <percentage or description>
+  gaps_remaining: [<string>] | []
+  follow_up_items: [<string>] | []
+```

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

@@ -0,0 +1,76 @@
+# Workflow Prompt: /vercel
+
+Drive Vercel implementation and operations via vercel-expert with deployment, runtime, security, and observability guardrails.
+
+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: `nextjs`, `ci-cd-pipeline`, `performance-testing`, `react`, `frontend-design`, `javascript-best-practices`, `typescript-best-practices`.
+- Local skill file hints if installed: `.github/skills/nextjs/SKILL.md`, `.github/skills/ci-cd-pipeline/SKILL.md`, `.github/skills/performance-testing/SKILL.md`, `.github/skills/react/SKILL.md`, `.github/skills/frontend-design/SKILL.md`, `.github/skills/javascript-best-practices/SKILL.md`, `.github/skills/typescript-best-practices/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:
+# Vercel Workflow
+
+## When to use
+
+Use this for Vercel-specific deployment, configuration, runtime optimization, or platform operations.
+
+## Routing
+
+- Primary specialist: `@vercel-expert`
+- Infrastructure support: `@devops-engineer`
+- Verification support: `@test-engineer`
+
+## Context notes
+
+- This workflow file, active platform rules, and selected agents or skills guide execution.
+- Attach the Vercel project config, deployment target, and any specific Vercel feature requirements.
+
+## Skill Routing
+
+- Primary skills: `nextjs-developer`, `serverless-patterns`
+- Supporting skills (optional): `web-perf`, `react-expert`, `tailwind-patterns`, `nodejs-best-practices`, `typescript-pro`, `javascript-pro`
+- Start with `nextjs-developer` for Next.js on Vercel and `serverless-patterns` for runtime behavior. Add `web-perf` for performance optimization.
+
+## Workflow steps
+
+1. Assess deployment requirements and runtime selection (Edge vs Serverless vs Static).
+2. Configure project settings and environment variables.
+3. Set up deployment pipeline with preview deployments.
+4. Verify deployment health and performance.
+5. Configure monitoring and alerting.
+
+## Verification
+
+- Deployment successful with no build errors.
+- Runtime selection appropriate for each route.
+- Environment variables correctly configured per environment.
+- Preview deployments working for PRs.
+- Performance metrics within acceptable ranges.
+
+## Output Contract
+
+```yaml
+VERCEL_WORKFLOW_RESULT:
+  primary_agent: vercel-expert
+  supporting_agents: [devops-engineer?, test-engineer?]
+  primary_skills: [nextjs-developer, serverless-patterns]
+  supporting_skills: [web-perf?, react-expert?]
+  deployment:
+    project: <string>
+    runtime: <edge | serverless | static>
+    environment: <development | preview | production>
+    status: success | failure
+  configuration:
+    env_vars: [<string>]
+    domains: [<string>]
+    caching: <string>
+  monitoring: <string>
+  follow_up_items: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/platforms/copilot/rules/copilot-instructions.md

@@ -24,7 +24,6 @@ If any check fails, restart your reasoning.
 
 | Asset                    | Location                                 |
 | ------------------------ | ---------------------------------------- |
-| Workflows                | `.github/copilot/workflows`              |
 | Agents                   | `.github/agents`                         |
 | Skills                   | `.github/skills`                         |
 | Prompt files             | `.github/prompts`                        |

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/api-design/SKILL.md

@@ -82,8 +82,12 @@ Load only what the current task requires.
 
 ## Copilot Platform Notes
 
-- Skill files are stored under `.github/prompts/` (prompt files) and `.github/instructions/` (instruction files).
-- Copilot does not support subagent spawning — all skill guidance executes within the current conversation context.
+- Custom agents are defined in `.github/agents/*.md` with YAML frontmatter: `name`, `description`, `tools`, `model`, `handoffs`.
+- Agent `handoffs` field enables guided workflow transitions (e.g., `@project-planner` → `@orchestrator`).
+- Skill files are stored under `.github/skills/` (skill markdown) and `.github/prompts/` (prompt files).
+- Path-scoped instructions in `.github/instructions/*.instructions.md` provide file-pattern-targeted guidance via `applyTo` frontmatter.
 - User arguments are provided as natural language input in the prompt, not through a `$ARGUMENTS` variable.
-- Frontmatter keys `context`, `agent`, and `allowed-tools` are not supported; guidance is advisory only.
+- Frontmatter keys `context: fork` and `allowed-tools` are not natively supported; guidance is advisory.
 - Reference files can be included via `#file:references/<name>.md` syntax in Copilot Chat.
+- MCP configuration lives in `.vscode/mcp.json`. MCP skill tools are available when configured.
+- Rules file: `.github/copilot-instructions.md` — broad and stable, not task-specific.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/architecture-doc/SKILL.md

@@ -77,8 +77,12 @@ Load on demand. Do not preload all reference files.
 
 ## Copilot Platform Notes
 
-- Skill files are stored under `.github/prompts/` (prompt files) and `.github/instructions/` (instruction files).
-- Copilot does not support subagent spawning — all skill guidance executes within the current conversation context.
+- Custom agents are defined in `.github/agents/*.md` with YAML frontmatter: `name`, `description`, `tools`, `model`, `handoffs`.
+- Agent `handoffs` field enables guided workflow transitions (e.g., `@project-planner` → `@orchestrator`).
+- Skill files are stored under `.github/skills/` (skill markdown) and `.github/prompts/` (prompt files).
+- Path-scoped instructions in `.github/instructions/*.instructions.md` provide file-pattern-targeted guidance via `applyTo` frontmatter.
 - User arguments are provided as natural language input in the prompt, not through a `$ARGUMENTS` variable.
-- Frontmatter keys `context`, `agent`, and `allowed-tools` are not supported; guidance is advisory only.
+- Frontmatter keys `context: fork` and `allowed-tools` are not natively supported; guidance is advisory.
 - Reference files can be included via `#file:references/<name>.md` syntax in Copilot Chat.
+- MCP configuration lives in `.vscode/mcp.json`. MCP skill tools are available when configured.
+- Rules file: `.github/copilot-instructions.md` — broad and stable, not task-specific.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/ci-cd-pipeline/SKILL.md

@@ -72,8 +72,12 @@ Provide complete pipeline configuration files with inline comments explaining no
 
 ## Copilot Platform Notes
 
-- Skill files are stored under `.github/prompts/` (prompt files) and `.github/instructions/` (instruction files).
-- Copilot does not support subagent spawning — all skill guidance executes within the current conversation context.
+- Custom agents are defined in `.github/agents/*.md` with YAML frontmatter: `name`, `description`, `tools`, `model`, `handoffs`.
+- Agent `handoffs` field enables guided workflow transitions (e.g., `@project-planner` → `@orchestrator`).
+- Skill files are stored under `.github/skills/` (skill markdown) and `.github/prompts/` (prompt files).
+- Path-scoped instructions in `.github/instructions/*.instructions.md` provide file-pattern-targeted guidance via `applyTo` frontmatter.
 - User arguments are provided as natural language input in the prompt, not through a `$ARGUMENTS` variable.
-- Frontmatter keys `context`, `agent`, and `allowed-tools` are not supported; guidance is advisory only.
+- Frontmatter keys `context: fork` and `allowed-tools` are not natively supported; guidance is advisory.
 - Reference files can be included via `#file:references/<name>.md` syntax in Copilot Chat.
+- MCP configuration lives in `.vscode/mcp.json`. MCP skill tools are available when configured.
+- Rules file: `.github/copilot-instructions.md` — broad and stable, not task-specific.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/code-review/SKILL.md

@@ -66,8 +66,12 @@ When conducting a code review, provide:
 
 ## Copilot Platform Notes
 
-- Skill files are stored under `.github/prompts/` (prompt files) and `.github/instructions/` (instruction files).
-- Copilot does not support subagent spawning — all skill guidance executes within the current conversation context.
+- Custom agents are defined in `.github/agents/*.md` with YAML frontmatter: `name`, `description`, `tools`, `model`, `handoffs`.
+- Agent `handoffs` field enables guided workflow transitions (e.g., `@project-planner` → `@orchestrator`).
+- Skill files are stored under `.github/skills/` (skill markdown) and `.github/prompts/` (prompt files).
+- Path-scoped instructions in `.github/instructions/*.instructions.md` provide file-pattern-targeted guidance via `applyTo` frontmatter.
 - User arguments are provided as natural language input in the prompt, not through a `$ARGUMENTS` variable.
-- Frontmatter keys `context`, `agent`, and `allowed-tools` are not supported; guidance is advisory only.
+- Frontmatter keys `context: fork` and `allowed-tools` are not natively supported; guidance is advisory.
 - Reference files can be included via `#file:references/<name>.md` syntax in Copilot Chat.
+- MCP configuration lives in `.vscode/mcp.json`. MCP skill tools are available when configured.
+- Rules file: `.github/copilot-instructions.md` — broad and stable, not task-specific.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/csharp-best-practices/SKILL.md

@@ -81,8 +81,12 @@ No helper scripts are required for this skill right now. Keep execution in `SKIL
 
 ## Copilot Platform Notes
 
-- Skill files are stored under `.github/prompts/` (prompt files) and `.github/instructions/` (instruction files).
-- Copilot does not support subagent spawning — all skill guidance executes within the current conversation context.
+- Custom agents are defined in `.github/agents/*.md` with YAML frontmatter: `name`, `description`, `tools`, `model`, `handoffs`.
+- Agent `handoffs` field enables guided workflow transitions (e.g., `@project-planner` → `@orchestrator`).
+- Skill files are stored under `.github/skills/` (skill markdown) and `.github/prompts/` (prompt files).
+- Path-scoped instructions in `.github/instructions/*.instructions.md` provide file-pattern-targeted guidance via `applyTo` frontmatter.
 - User arguments are provided as natural language input in the prompt, not through a `$ARGUMENTS` variable.
-- Frontmatter keys `context`, `agent`, and `allowed-tools` are not supported; guidance is advisory only.
+- Frontmatter keys `context: fork` and `allowed-tools` are not natively supported; guidance is advisory.
 - Reference files can be included via `#file:references/<name>.md` syntax in Copilot Chat.
+- MCP configuration lives in `.vscode/mcp.json`. MCP skill tools are available when configured.
+- Rules file: `.github/copilot-instructions.md` — broad and stable, not task-specific.