@cubis/foundry 0.3.82 → 0.3.83

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

@@ -1,73 +0,0 @@
----
-command: "/orchestrate"
-description: "Coordinate multiple specialists to solve cross-cutting tasks with explicit ownership, validation gates, and repeat-until-good iteration."
-triggers: ["orchestrate", "coordinate", "multi-area", "cross-team", "handoff"]
----
-
-# Orchestrate Workflow
-
-## When to use
-
-Use this when a task spans multiple domains (backend + frontend, security + infrastructure, etc.) and requires coordinated specialist work with validation between steps.
-
-## Routing
-
-- Primary coordinator: `the orchestrator posture`
-- Specialist routing determined by task decomposition — delegates to `the backend-specialist posture`, `the frontend-specialist posture`, `the database-architect posture`, `the security-auditor posture`, `the ci-cd-pipeline posture`, `the test-engineer posture`, `the mobile-developer posture`, or other specialist agents as needed.
-- Validation support: `the validator posture`
-
-## Context notes
-
-- 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 `docs/foundation/TECH.md` before decomposing non-trivial work. Check `docs/foundation/TECH.md` for build/validation commands and `docs/foundation/PRODUCT.md` for domain glossary. 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`, `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
-
-1. Decompose the task into discrete work items with acceptance criteria.
-2. Identify dependencies and determine execution order (DAG).
-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. 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
-
-- Each task validated independently against its acceptance criteria.
-- Cross-task consistency check after integration.
-- Run any applicable automated tests or checks.
-- Final validation pass on combined result.
-
-## Output Contract
-
-```yaml
-ORCHESTRATE_WORKFLOW_RESULT:
-  primary_agent: orchestrator
-  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>
-  tasks:
-    - id: <task-id>
-      agent: <agent-name>
-      status: completed | failed | skipped
-      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>] | []
-```
-
-> **Codex note:** Prefer native Codex delegation when the host exposes it. Otherwise follow AGENTS.md specialist postures inline while keeping the same routing and verification contract.

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

@@ -1,90 +0,0 @@
----
-command: "/plan"
-description: "Build a decision-complete implementation plan with interfaces, failure modes, and acceptance criteria."
-triggers:
-  [
-    "plan",
-    "design",
-    "roadmap",
-    "acceptance",
-    "brainstorm",
-    "idea",
-    "options",
-    "tradeoff",
-    "approach",
-  ]
----
-
-# Plan Workflow
-
-## When to use
-
-Use this when starting a new feature, project, or significant change that needs a structured implementation plan before coding begins.
-
-## Routing
-
-- Primary coordinator: `the project-planner posture`
-- Architecture support: `the orchestrator posture`
-- Domain validation: `the backend-specialist posture`, `the frontend-specialist posture`, `the database-architect posture`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach the feature request, problem statement, constraints, and any existing design documents.
-- Read `ENGINEERING_RULES.md` first and `docs/foundation/TECH.md` next when they exist before finalizing a non-trivial plan. Also check `docs/foundation/PRODUCT.md` for domain glossary and `docs/foundation/ARCHITECTURE.md` for crosscutting concerns and dependency rules.
-- Reuse an existing `docs/specs/<spec-id>/` pack when the change already has one instead of creating a parallel planning track.
-
-## Skill Routing
-
-- Primary skills: `system-design`, `api-design`
-- 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, starting in-repo and escalating to `deep-research` only when outside evidence is required.
-3. Decompose into tasks with ownership and dependencies.
-4. Define interfaces, contracts, and failure modes.
-5. Produce acceptance criteria for each milestone.
-6. Record `architecture_impact`, `doc_impact`, and `traceability_status` when the work is non-trivial.
-7. Identify risks, unknowns, and mitigation strategies.
-
-## Verification
-
-- Every task has an owner, acceptance criteria, and verification approach.
-- Dependencies form a valid DAG with no cycles.
-- Risk assessment covers top 3 failure scenarios.
-- Plan reviewed against existing codebase conventions.
-
-## Output Contract
-
-```yaml
-PLAN_WORKFLOW_RESULT:
-  primary_agent: project-planner
-  supporting_agents: [orchestrator?, backend-specialist?, frontend-specialist?, database-architect?]
-  primary_skills: [system-design, api-design]
-  supporting_skills: [database-design?, deep-research?, mcp-server-builder?]
-  spec_id: <string> | null
-  spec_root: docs/specs/<spec-id> | null
-  plan:
-    scope_summary: <string>
-    tasks:
-      - id: <task-id>
-        description: <string>
-        owner: <agent-name>
-        dependencies: [<task-id>]
-        acceptance_criteria: [<string>]
-    interfaces: [<string>]
-    risks: [<string>]
-    milestones: [<string>]
-  architecture_impact:
-    summary: <string>
-    affects_structure: true | false
-    affects_design_system: true | false
-  doc_impact: none | tech | rules | both
-  traceability_status: complete | partial | blocked
-  follow_up_items: [<string>] | []
-```
-
-> **Codex note:** Prefer native Codex delegation when the host exposes it. Otherwise follow AGENTS.md specialist postures inline while keeping the same routing and verification contract.

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

@@ -1,67 +0,0 @@
----
-command: "/refactor"
-description: "Improve maintainability while preserving behavior through incremental safe refactoring."
-triggers: ["refactor", "cleanup", "maintainability", "debt", "modularize"]
----
-
-# Refactor Workflow
-
-## When to use
-
-Use this when improving code structure, reducing tech debt, or modularizing without changing behavior.
-
-## Routing
-
-- Primary specialist: `the code-archaeologist posture`
-- Domain support: `the backend-specialist posture`, `the frontend-specialist posture`
-- Verification support: `the test-engineer posture`, `the validator posture`
-
-## 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: `code-review`, `system-design`
-- Supporting skills (optional): `unit-testing`, `system-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`
-- Start with `code-review` for automated code quality assessment. Add `system-design` for modernization patterns. Add `unit-testing` 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: [code-review, system-design]
-  supporting_skills: [unit-testing?, 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>] | []
-```
-
-> **Codex note:** Prefer native Codex delegation when the host exposes it. Otherwise follow AGENTS.md specialist postures inline while keeping the same routing and verification contract.

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

@@ -1,70 +0,0 @@
----
-command: "/release"
-description: "Prepare and execute release with rollout guardrails, verification, and rollback plan."
-triggers: ["release", "deploy", "rollout", "ship", "go-live"]
----
-
-# Release Workflow
-
-## When to use
-
-Use this when preparing a release, deploying to production, or managing a rollout.
-
-## Routing
-
-- Primary coordinator: `the ci-cd-pipeline posture`
-- Release verification: `the test-engineer posture`, `the validator posture`
-- Documentation: `the documentation-writer posture`
-
-## 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-pipeline`, `git-workflow`
-- Supporting skills (optional): `tech-doc`, `ci-cd-pipeline`, `observability`, `kubernetes-deploy`, `observability`, `ci-cd-pipeline`, `typescript-best-practices`, `javascript-best-practices`
-- Start with `ci-cd-pipeline` for deployment automation and `git-workflow` for release branching. Add `tech-doc` 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: ci-cd-pipeline
-  supporting_agents: [test-engineer?, validator?, documentation-writer?]
-  primary_skills: [ci-cd-pipeline, git-workflow]
-  supporting_skills: [tech-doc?, ci-cd-pipeline?, observability?]
-  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>] | []
-```
-
-> **Codex note:** Prefer native Codex delegation when the host exposes it. Otherwise follow AGENTS.md specialist postures inline while keeping the same routing and verification contract.

package/workflows/workflows/agent-environment-setup/platforms/codex/workflows/review.md

@@ -1,66 +0,0 @@
----
-command: "/review"
-description: "Run a strict review for bugs, regressions, accessibility issues, security risk, and code quality with prioritized findings."
-triggers: ["review", "audit", "pr", "quality", "security review"]
----
-
-# Review Workflow
-
-## When to use
-
-Use this for code review, PR review, or quality audit of existing code changes.
-
-## Routing
-
-- Primary specialist: `the frontend-specialist posture` (for frontend code) or `the backend-specialist posture` (for backend code)
-- Security review: `the security-auditor posture`
-- Quality validation: `the validator posture`
-- Verification support: `the test-engineer posture`
-
-## 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: `code-review`, `code-review`, `unit-testing`
-- Supporting skills (optional): `owasp-security-review`, `owasp-security-review`, `performance-testing`, `react`, `nextjs`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`
-- Start with `code-review` for UI code or `code-review` for backend code. Add `unit-testing` when evaluating test quality. Add `owasp-security-review` 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: [code-review?, code-review?, unit-testing?]
-  supporting_skills: [owasp-security-review?, owasp-security-review?, performance-testing?]
-  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>] | []
-```
-
-> **Codex note:** Prefer native Codex delegation when the host exposes it. Otherwise follow AGENTS.md specialist postures inline while keeping the same routing and verification contract.

package/workflows/workflows/agent-environment-setup/platforms/codex/workflows/security.md

@@ -1,69 +0,0 @@
----
-command: "/security"
-description: "Run security-focused analysis and remediation planning with exploitability-first triage."
-triggers: ["security", "vulnerability", "owasp", "auth", "hardening"]
----
-
-# Security Workflow
-
-## When to use
-
-Use this for security audits, vulnerability assessments, threat modeling, or security-focused code review.
-
-## Routing
-
-- Primary specialist: `the security-auditor posture`
-- Offensive assessment: `the penetration-tester posture`
-- Domain support: `the backend-specialist posture`, `the frontend-specialist posture`
-- Verification support: `the validator posture`
-
-## 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: `owasp-security-review`, `owasp-security-review`
-- Supporting skills (optional): `owasp-security-review`, `code-review`, `api-design`, `api-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `rust-best-practices`
-- Start with `owasp-security-review` for OWASP methodology and threat modeling. Add `owasp-security-review` for authentication/authorization review. Add `owasp-security-review` 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: [owasp-security-review, owasp-security-review]
-  supporting_skills: [owasp-security-review?, code-review?, 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>] | []
-```
-
-> **Codex note:** Prefer native Codex delegation when the host exposes it. Otherwise follow AGENTS.md specialist postures inline while keeping the same routing and verification contract.

package/workflows/workflows/agent-environment-setup/platforms/codex/workflows/test.md

@@ -1,66 +0,0 @@
----
-command: "/test"
-description: "Design and execute verification strategy aligned to user risk, release confidence, and regression evidence."
-triggers: ["test", "verify", "coverage", "qa", "regression"]
----
-
-# Test Workflow
-
-## When to use
-
-Use this when writing new tests, improving coverage, debugging test failures, or designing a testing strategy.
-
-## Routing
-
-- Primary specialist: `the test-engineer posture`
-- Automation support: `the qa-automation-engineer posture`
-- Domain support: `the backend-specialist posture`, `the frontend-specialist posture`
-- Verification support: `the validator posture`
-
-## 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: `unit-testing`, `integration-testing`
-- Supporting skills (optional): `playwright-interactive`, `observability`, `systematic-debugging`, `code-review`, `code-review`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `java-best-practices`
-- Start with `unit-testing` for test strategy and architecture. Add `integration-testing` for implementation. Add `playwright-interactive` for E2E automation. Add `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: [unit-testing, integration-testing]
-  supporting_skills: [playwright-interactive?, observability?, systematic-debugging?]
-  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>] | []
-```
-
-> **Codex note:** Prefer native Codex delegation when the host exposes it. Otherwise follow AGENTS.md specialist postures inline while keeping the same routing and verification contract.

package/workflows/workflows/agent-environment-setup/platforms/codex/workflows/vercel.md

@@ -1,76 +0,0 @@
----
-command: "/vercel"
-description: "Drive Vercel implementation and operations via vercel-expert with deployment, runtime, security, and observability guardrails."
-triggers:
-  [
-    "vercel",
-    "deployment",
-    "preview",
-    "edge",
-    "functions",
-    "domains",
-    "vercel cli",
-  ]
----
-
-# Vercel Workflow
-
-## When to use
-
-Use this for Vercel-specific deployment, configuration, runtime optimization, or platform operations.
-
-## Routing
-
-- Primary specialist: `the vercel-expert posture`
-- Infrastructure support: `the ci-cd-pipeline posture`
-- Verification support: `the test-engineer posture`
-
-## 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`, `ci-cd-pipeline`
-- Supporting skills (optional): `performance-testing`, `react`, `frontend-design`, `javascript-best-practices`, `typescript-best-practices`, `javascript-best-practices`
-- Start with `nextjs` for Next.js on Vercel and `ci-cd-pipeline` for runtime behavior. Add `performance-testing` 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: [ci-cd-pipeline?, test-engineer?]
-  primary_skills: [nextjs, ci-cd-pipeline]
-  supporting_skills: [performance-testing?, react?]
-  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>] | []
-```
-
-> **Codex note:** Prefer native Codex delegation when the host exposes it. Otherwise follow AGENTS.md specialist postures inline while keeping the same routing and verification contract.

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

@@ -1,18 +0,0 @@
-# Workflow Prompt: /accessibility
-
-Run a structured accessibility audit on web UI code with WCAG 2.2 AA compliance checks, ARIA validation, keyboard navigation testing, and screen reader verification.
-
-Use this prompt with the matching workflow file:
-- Workflow: ../copilot/workflows/accessibility.md
-
-Execution contract:
-1. Treat route selection as already resolved by this prompt; 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`, `frontend-design`, `performance-testing`, `react`, `nextjs`, `playwright-interactive`, `typescript-best-practices`, `javascript-best-practices`.
-- Local skill file hints if installed: `.github/skills/code-review/SKILL.md`, `.github/skills/frontend-design/SKILL.md`, `.github/skills/performance-testing/SKILL.md`, `.github/skills/react/SKILL.md`, `.github/skills/nextjs/SKILL.md`, `.github/skills/playwright-interactive/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.

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

@@ -1,18 +0,0 @@
-# Workflow Prompt: /architecture
-
-Refresh the core project foundation docs in docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md, and ADR scaffolds with explicit structure, product context, testing, and flow guidance.
-
-Use this prompt with the matching workflow file:
-- Workflow: ../copilot/workflows/architecture.md
-
-Execution contract:
-1. Treat route selection as already resolved by this prompt; do not begin with skill discovery.
-2. Read `docs/foundation/PRODUCT.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: `architecture-doc`, `system-design`, `tech-doc`, `frontend-design`, `api-design`, `database-design`, `sadd`, `deep-research`.
-- Local skill file hints if installed: `.github/skills/architecture-doc/SKILL.md`, `.github/skills/system-design/SKILL.md`, `.github/skills/tech-doc/SKILL.md`, `.github/skills/frontend-design/SKILL.md`, `.github/skills/api-design/SKILL.md`, `.github/skills/database-design/SKILL.md`, `.github/skills/sadd/SKILL.md`, `.github/skills/deep-research/SKILL.md`.
-- Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
-3. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
-4. Route to the workflow's primary specialist and only add supporting specialists when needed.
-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.

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

@@ -1,18 +0,0 @@
-# Workflow Prompt: /backend
-
-Drive backend architecture, API operations, and Postman-oriented execution with API, data, and reliability focus.
-
-Use this prompt with the matching workflow file:
-- Workflow: ../copilot/workflows/backend.md
-
-Execution contract:
-1. Treat route selection as already resolved by this prompt; do not begin with skill discovery.
-2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
-Attached skills:
-- Load these exact skill IDs first: `api-design`, `javascript-best-practices`, `owasp-security-review`, `database-design`, `nestjs`, `fastapi`, `microservices-design`, `drizzle-orm`, `stripe-integration`, `ci-cd-pipeline`, `frontend-design`, `typescript-best-practices`, `python-best-practices`, `golang-best-practices`.
-- Local skill file hints if installed: `.github/skills/api-design/SKILL.md`, `.github/skills/javascript-best-practices/SKILL.md`, `.github/skills/owasp-security-review/SKILL.md`, `.github/skills/database-design/SKILL.md`, `.github/skills/nestjs/SKILL.md`, `.github/skills/fastapi/SKILL.md`, `.github/skills/microservices-design/SKILL.md`, `.github/skills/drizzle-orm/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.

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

@@ -1,18 +0,0 @@
-# Workflow Prompt: /create
-
-Implement feature work with minimal blast radius and clear verification checkpoints.
-
-Use this prompt with the matching workflow file:
-- Workflow: ../copilot/workflows/create.md
-
-Execution contract:
-1. Treat route selection as already resolved by this prompt; 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: `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `java-best-practices`, `csharp-best-practices`, `kotlin-best-practices`, `rust-best-practices`, `php-best-practices`, `expo-app`, `swift-best-practices`, `api-design`, `nestjs`, `fastapi`, `drizzle-orm`, `database-design`, `mcp-server-builder`, `stitch`, `react`, `nextjs`, `frontend-design`, `performance-testing`, `skill-creator`, `stripe-integration`, `ci-cd-pipeline`.
-- Local skill file hints if installed: `.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/java-best-practices/SKILL.md`, `.github/skills/csharp-best-practices/SKILL.md`, `.github/skills/kotlin-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.