@cubis/foundry 0.3.63 → 0.3.64

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

@@ -6,6 +6,7 @@ Use this prompt with the matching workflow file:
 - Workflow: ../copilot/workflows/vercel.md
 
 Execution contract:
-1. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
-2. Route to the workflow's primary specialist and only add supporting specialists when needed.
-3. Return actions taken, verification evidence, and any gaps.
+1. Treat route selection as already resolved by this prompt; do not begin with skill discovery.
+2. Apply workflow sections in order: When to use, Workflow steps, Context notes, Verification.
+3. Route to the workflow's primary specialist and only add supporting specialists when needed.
+4. Return actions taken, verification evidence, and any gaps.

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

@@ -7,8 +7,9 @@ This `AGENTS.md` exists for cross-tool compatibility (for example Codex/Cursor s
 
 - Workflows: `.github/copilot/workflows`
 - Agents: `.github/agents`
-- Skills: `.github/skills`
+- Skills: `.github/skills` (installed by default; keep routing workflow-first and sidecar loading on-demand)
 - Prompt files: `.github/prompts`
+- MCP (preferred): `.vscode/mcp.json`
 - Rules file (project): `.github/copilot-instructions.md`
 
 ## Startup Transparency (Minimal)
@@ -24,13 +25,15 @@ Rules:
 3. Keep progress updates to one short sentence.
 4. For pure Q&A replies, skip the status line.
 
-## 2) Workflow-First Contract
+## 2) Route-First Workflow Contract
 
-1. If the user explicitly requests a slash command, run that workflow first.
+1. If the user explicitly requests a workflow prompt or slash command, route through the matching `.github/prompts/workflow-*.prompt.md` and `.github/copilot/workflows/*.md` first.
 2. Otherwise choose the best workflow by intent from `.github/copilot/workflows` and reuse `.github/prompts/workflow-*.prompt.md` when available.
 3. For cross-domain tasks, use `/orchestrate` and `@orchestrator`.
-4. Keep one primary workflow; use others only as supporting references.
-5. Before loading any skill, inspect the repo/task locally first. Use MCP skill tools only when the user names a skill explicitly or local grounding still leaves the domain unclear (→ §6 MCP Skill Engine).
+4. Resolve explicit `@agent` mentions before skill discovery and treat workflows/agents as route primitives, not skills.
+5. On Copilot, the primary route surface is workflow prompts/workflow files plus `@agent-name`. Do not treat `$workflow-*` or `$agent-*` as the primary route surface here; those are Codex compatibility aliases.
+6. Keep one primary workflow; use others only as supporting references.
+7. Before loading any skill, inspect the repo/task locally first. Use MCP skill tools only when the user names a skill explicitly or route resolution still leaves the domain unclear (→ §6 MCP Skill Engine).
 
 ## 3) Request Classifier
 
@@ -69,11 +72,11 @@ Use the best specialist first:
 
 Before handing off to any specialist agent, prime context with the relevant domain skill (→ §6 MCP Skill Engine):
 
-1. Validate user-named exact skills with `skill_validate <id>` before loading them.
-2. If the domain is still unclear after local grounding, run one narrow `skill_search <domain>` and then validate the chosen exact ID with `skill_validate <id>`.
+1. Resolve the workflow or custom agent first with `route_resolve <intent>`.
+2. Prime only the mapped primary skills for that route. If the route is still unresolved after local grounding, run one narrow `skill_search <domain>` and then validate the chosen exact ID with `skill_validate <id>`.
 3. Load the core skill with `skill_get <id>` using `includeReferences:false` by default.
 4. Pull one sidecar markdown file at a time with `skill_get_reference` when the skill or task requires it.
-5. Include the validated skill ID in the Decision Log for the routing decision.
+5. Include the resolved route ID and validated skill IDs in the Decision Log.
 
 This ensures the specialist starts with accurate domain knowledge, not just role intent.
 
@@ -82,6 +85,7 @@ This ensures the specialist starts with accurate domain knowledge, not just role
 When authoring custom Copilot assets, keep frontmatter schema compatible:
 
 1. Skill files in `.github/skills/<id>/SKILL.md` must use supported top-level keys only.
+   This directory is installed by default, but workflows and agents remain the primary route surfaces on Copilot Stable.
 2. Agent files in `.github/agents/*.md` must use supported top-level keys only.
 3. If unsupported keys are detected, reinstall with overwrite to auto-normalize.
 
@@ -93,7 +97,8 @@ The Foundry MCP server is the primary knowledge layer. Use tools decisively —
 
 | Prefix      | Tools                                                                                                | When to use                                                    |
 | ----------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
-| `skill_*`   | `skill_list_categories`, `skill_search`, `skill_validate`, `skill_browse_category`, `skill_get`, `skill_get_reference`, `skill_budget_report` | Domain expertise for implementation, debug, or review without loading the full catalog |
+| `route_*`   | `route_resolve`                                                                                       | Resolve workflows and custom agents before any skill loading   |
+| `skill_*`   | `skill_list_categories`, `skill_search`, `skill_validate`, `skill_browse_category`, `skill_get`, `skill_get_reference`, `skill_budget_report` | Domain expertise for implementation, debug, or review after the route is known |
 | `postman_*` | `postman_get_mode`, `postman_set_mode`, `postman_get_status`                                         | API testing or Postman configuration tasks                     |
 | `stitch_*`  | `stitch_get_mode`, `stitch_set_profile`, `stitch_get_status`                                         | Stitch data pipeline tasks                                     |
 
@@ -102,8 +107,8 @@ The Foundry MCP server is the primary knowledge layer. Use tools decisively —
 Stop at the earliest step that gives enough signal. Do not jump ahead or front-load skill discovery.
 
 1. Inspect the codebase/task locally first; do not start with `skill_search`
-2. If the user names an exact skill ID, call `skill_validate <id>` directly
-3. Otherwise, if local grounding still leaves the domain unclear, run one narrow `skill_search <keyword>`
+2. Resolve explicit workflows, custom agents, or free-text route intent with `route_resolve <intent>`
+3. If the route is still unresolved and local grounding leaves the domain unclear, run one narrow `skill_search <keyword>`
 4. Validate the selected exact skill ID with `skill_validate <id>` before any load
 5. Load only the core `SKILL.md` with `skill_get <id>` and `includeReferences:false`
 6. Load at most one sidecar markdown file at a time with `skill_get_reference <id> <path>`
@@ -124,7 +129,8 @@ When user intent includes Postman workflows (for example: workspace, collection,
 
 - Never call `skill_get` from fuzzy search output without first validating the exact ID via `skill_validate`
 - Never skip local repo inspection and jump straight to `skill_search`
-- Never call `skill_get` with a workflow ID — `workflow-*` are routes, not skills; keep workflow mentions in workflow decisions (`/workflow`) and keep skill logs skill-only
+- Never use `skill_search` to discover workflows or custom agents
+- Never call `skill_get` with a workflow or agent ID — routes are not skills; keep workflow mentions in workflow decisions (`/workflow`) and keep skill logs skill-only
 - Never call `skill_get` with `includeReferences:true` by default in agent workflows
 - Never bulk-load sibling/reference markdown files when one targeted `skill_get_reference` will do
 - Never reload a skill already loaded this session — reuse content already in context
@@ -135,6 +141,7 @@ When user intent includes Postman workflows (for example: workspace, collection,
 | Request type                                   | Skills to load via `skill_get`                                  |
 | ---------------------------------------------- | --------------------------------------------------------------- |
 | Q&A / explanation                              | None — answer from knowledge; load only if user explicitly asks |
+| Skill creation / skill maintenance             | `skill-authoring` first; add at most one supporting skill       |
 | Single-domain implementation, debug, or review | 1 primary + 1 supporting (max)                                  |
 | Multi-domain / orchestration                   | 1 per distinct domain, hard cap at 3                            |
 | User explicitly names a skill                  | Always load it — overrides all caps                             |
@@ -270,6 +277,7 @@ Keep MCP context lazy and exact. Do not front-load the skill catalog.
 
 ### Compact Tool Map
 
+- Route tools: `route_resolve`
 - Skill tools: `skill_search`, `skill_validate`, `skill_get`, `skill_get_reference`, `skill_budget_report`
 - Fallback browsing only: `skill_list_categories`, `skill_browse_category`
 - Config tools: `postman_*`, `stitch_*`
@@ -277,12 +285,13 @@ Keep MCP context lazy and exact. Do not front-load the skill catalog.
 ### Validated Skill Flow
 
 1. Inspect the repo/task locally first. Do not start with `skill_search`.
-2. If the user names an exact skill, run `skill_validate` directly. Otherwise use one narrow `skill_search` only if local grounding still leaves the domain unclear.
-3. Always run `skill_validate` on the exact selected ID before `skill_get`.
-4. Call `skill_get` with `includeReferences:false` by default.
-5. Load at most one sidecar markdown file at a time with `skill_get_reference`.
-6. Use `skill_list_categories` or `skill_browse_category` only as fallback when targeted search fails.
-7. Never print catalog counts or budget details unless the user asks.
+2. Resolve explicit workflows, agents, or free-text route intent with `route_resolve` before loading any skills.
+3. If the route is still unresolved and local grounding leaves the domain unclear, use one narrow `skill_search`.
+4. Always run `skill_validate` on the exact selected ID before `skill_get`.
+5. Call `skill_get` with `includeReferences:false` by default.
+6. Load at most one sidecar markdown file at a time with `skill_get_reference`.
+7. Use `skill_list_categories` or `skill_browse_category` only as fallback when targeted search fails.
+8. Never print catalog counts or budget details unless the user asks.
 
 ### Connection
 

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

@@ -6,8 +6,9 @@ This file defines mandatory behavior for GitHub Copilot projects installed via `
 
 - Workflows: `.github/copilot/workflows`
 - Agents: `.github/agents`
-- Skills: `.github/skills`
+- Skills: `.github/skills` (installed by default; keep routing workflow-first and sidecar loading on-demand)
 - Prompt files: `.github/prompts`
+- MCP (preferred): `.vscode/mcp.json`
 - Rules file (project): `.github/copilot-instructions.md`
 
 ## Startup Transparency (Minimal)
@@ -23,13 +24,15 @@ Rules:
 3. Keep progress updates to one short sentence.
 4. For pure Q&A replies, skip the status line.
 
-## 2) Workflow-First Contract
+## 2) Route-First Workflow Contract
 
-1. If the user explicitly requests a slash command, run that workflow first.
+1. If the user explicitly requests a workflow prompt or slash command, route through the matching `.github/prompts/workflow-*.prompt.md` and `.github/copilot/workflows/*.md` first.
 2. Otherwise choose the best workflow by intent from `.github/copilot/workflows` and reuse `.github/prompts/workflow-*.prompt.md` when available.
 3. For cross-domain tasks, use `/orchestrate` and `@orchestrator`.
-4. Keep one primary workflow; use others only as supporting references.
-5. Before loading any skill, inspect the repo/task locally first. Use MCP skill tools only when the user names a skill explicitly or local grounding still leaves the domain unclear (→ §6 MCP Skill Engine).
+4. Resolve explicit `@agent` mentions before skill discovery and treat workflows/agents as route primitives, not skills.
+5. On Copilot, the primary route surface is workflow prompts/workflow files plus `@agent-name`. Do not treat `$workflow-*` or `$agent-*` as the primary route surface here; those are Codex compatibility aliases.
+6. Keep one primary workflow; use others only as supporting references.
+7. Before loading any skill, inspect the repo/task locally first. Use MCP skill tools only when the user names a skill explicitly or route resolution still leaves the domain unclear (→ §6 MCP Skill Engine).
 
 ## 3) Request Classifier
 
@@ -68,11 +71,11 @@ Use the best specialist first:
 
 Before handing off to any specialist agent, prime context with the relevant domain skill (→ §6 MCP Skill Engine):
 
-1. Validate user-named exact skills with `skill_validate <id>` before loading them.
-2. If the domain is still unclear after local grounding, run one narrow `skill_search <domain>` and then validate the chosen exact ID with `skill_validate <id>`.
+1. Resolve the workflow or custom agent first with `route_resolve <intent>`.
+2. Prime only the mapped primary skills for that route. If the route is still unresolved after local grounding, run one narrow `skill_search <domain>` and then validate the chosen exact ID with `skill_validate <id>`.
 3. Load the core skill with `skill_get <id>` using `includeReferences:false` by default.
 4. Pull one sidecar markdown file at a time with `skill_get_reference` when the skill or task requires it.
-5. Include the validated skill ID in the Decision Log for the routing decision.
+5. Include the resolved route ID and validated skill IDs in the Decision Log.
 
 This ensures the specialist starts with accurate domain knowledge, not just role intent.
 
@@ -81,6 +84,7 @@ This ensures the specialist starts with accurate domain knowledge, not just role
 When authoring custom Copilot assets, keep frontmatter schema compatible:
 
 1. Skill files in `.github/skills/<id>/SKILL.md` must use supported top-level keys only.
+   This directory is installed by default, but workflows and agents remain the primary route surfaces on Copilot Stable.
 2. Agent files in `.github/agents/*.md` must use supported top-level keys only.
 3. If unsupported keys are detected, reinstall with overwrite to auto-normalize.
 
@@ -92,7 +96,8 @@ The Foundry MCP server is the primary knowledge layer. Use tools decisively —
 
 | Prefix      | Tools                                                                                                | When to use                                                    |
 | ----------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
-| `skill_*`   | `skill_list_categories`, `skill_search`, `skill_validate`, `skill_browse_category`, `skill_get`, `skill_get_reference`, `skill_budget_report` | Domain expertise for implementation, debug, or review without loading the full catalog |
+| `route_*`   | `route_resolve`                                                                                       | Resolve workflows and custom agents before any skill loading   |
+| `skill_*`   | `skill_list_categories`, `skill_search`, `skill_validate`, `skill_browse_category`, `skill_get`, `skill_get_reference`, `skill_budget_report` | Domain expertise for implementation, debug, or review after the route is known |
 | `postman_*` | `postman_get_mode`, `postman_set_mode`, `postman_get_status`                                         | API testing or Postman configuration tasks                     |
 | `stitch_*`  | `stitch_get_mode`, `stitch_set_profile`, `stitch_get_status`                                         | Stitch data pipeline tasks                                     |
 
@@ -101,8 +106,8 @@ The Foundry MCP server is the primary knowledge layer. Use tools decisively —
 Stop at the earliest step that gives enough signal. Do not jump ahead or front-load skill discovery.
 
 1. Inspect the codebase/task locally first; do not start with `skill_search`
-2. If the user names an exact skill ID, call `skill_validate <id>` directly
-3. Otherwise, if local grounding still leaves the domain unclear, run one narrow `skill_search <keyword>`
+2. Resolve explicit workflows, custom agents, or free-text route intent with `route_resolve <intent>`
+3. If the route is still unresolved and local grounding leaves the domain unclear, run one narrow `skill_search <keyword>`
 4. Validate the selected exact skill ID with `skill_validate <id>` before any load
 5. Load only the core `SKILL.md` with `skill_get <id>` and `includeReferences:false`
 6. Load at most one sidecar markdown file at a time with `skill_get_reference <id> <path>`
@@ -123,7 +128,8 @@ When user intent includes Postman workflows (for example: workspace, collection,
 
 - Never call `skill_get` from fuzzy search output without first validating the exact ID via `skill_validate`
 - Never skip local repo inspection and jump straight to `skill_search`
-- Never call `skill_get` with a workflow ID — `workflow-*` are routes, not skills; keep workflow mentions in workflow decisions (`/workflow`) and keep skill logs skill-only
+- Never use `skill_search` to discover workflows or custom agents
+- Never call `skill_get` with a workflow or agent ID — routes are not skills; keep workflow mentions in workflow decisions (`/workflow`) and keep skill logs skill-only
 - Never call `skill_get` with `includeReferences:true` by default in agent workflows
 - Never bulk-load sibling/reference markdown files when one targeted `skill_get_reference` will do
 - Never reload a skill already loaded this session — reuse content already in context
@@ -134,6 +140,7 @@ When user intent includes Postman workflows (for example: workspace, collection,
 | Request type                                   | Skills to load via `skill_get`                                  |
 | ---------------------------------------------- | --------------------------------------------------------------- |
 | Q&A / explanation                              | None — answer from knowledge; load only if user explicitly asks |
+| Skill creation / skill maintenance             | `skill-authoring` first; add at most one supporting skill       |
 | Single-domain implementation, debug, or review | 1 primary + 1 supporting (max)                                  |
 | Multi-domain / orchestration                   | 1 per distinct domain, hard cap at 3                            |
 | User explicitly names a skill                  | Always load it — overrides all caps                             |
@@ -269,6 +276,7 @@ Keep MCP context lazy and exact. Do not front-load the skill catalog.
 
 ### Compact Tool Map
 
+- Route tools: `route_resolve`
 - Skill tools: `skill_search`, `skill_validate`, `skill_get`, `skill_get_reference`, `skill_budget_report`
 - Fallback browsing only: `skill_list_categories`, `skill_browse_category`
 - Config tools: `postman_*`, `stitch_*`
@@ -276,12 +284,13 @@ Keep MCP context lazy and exact. Do not front-load the skill catalog.
 ### Validated Skill Flow
 
 1. Inspect the repo/task locally first. Do not start with `skill_search`.
-2. If the user names an exact skill, run `skill_validate` directly. Otherwise use one narrow `skill_search` only if local grounding still leaves the domain unclear.
-3. Always run `skill_validate` on the exact selected ID before `skill_get`.
-4. Call `skill_get` with `includeReferences:false` by default.
-5. Load at most one sidecar markdown file at a time with `skill_get_reference`.
-6. Use `skill_list_categories` or `skill_browse_category` only as fallback when targeted search fails.
-7. Never print catalog counts or budget details unless the user asks.
+2. Resolve explicit workflows, agents, or free-text route intent with `route_resolve` before loading any skills.
+3. If the route is still unresolved and local grounding leaves the domain unclear, use one narrow `skill_search`.
+4. Always run `skill_validate` on the exact selected ID before `skill_get`.
+5. Call `skill_get` with `includeReferences:false` by default.
+6. Load at most one sidecar markdown file at a time with `skill_get_reference`.
+7. Use `skill_list_categories` or `skill_browse_category` only as fallback when targeted search fails.
+8. Never print catalog counts or budget details unless the user asks.
 
 ### Connection
 

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

@@ -1,20 +1,7 @@
 ---
 name: "accessibility"
-displayName: "Accessibility Expert"
 description: "Ensure Flutter apps meet WCAG 2.1 AA standards with proper semantics, focus management, and screen reader support"
-keywords:
-  [
-    "accessibility",
-    "a11y",
-    "wcag",
-    "semantics",
-    "screen reader",
-    "focus",
-    "contrast",
-    "flutter accessibility",
-  ]
 ---
-
 # Accessibility Expert
 
 ## Overview
@@ -91,13 +78,15 @@ SizedBox(
 4. **Color Contrast**: Text must have 4.5:1 contrast ratio (3:1 for large text)
 5. **Screen Reader**: Test with TalkBack (Android) and VoiceOver (iOS)
 
-## Steering Files
+## References
+
+Load detailed guidance only when needed.
 
-Load detailed guidance:
-- `a11y_checklist.md` - Complete accessibility checklist for reviews
+| File | Load when |
+| --- | --- |
+| `references/a11y_checklist.md` | Running an accessibility review or validating a widget/screen against the full checklist |
 
 ## Templates
 
 - `focus_form` - Form with proper focus management
 - `semantics_icon_button` - Icon button with semantic labels
-

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

@@ -1,11 +1,13 @@
 ---
 name: "api-designer"
-description: "Use when designing REST or GraphQL APIs, creating OpenAPI specifications, or planning API architecture. Invoke for resource modeling, versioning strategies, pagination patterns, error handling standards."
+description: "Use when defining or reviewing external API contracts, OpenAPI specifications, resource models, pagination, versioning, or error response standards. Do not use for pure database design, implementation-only handler work, or framework-specific backend setup."
 ---
-
-
 # API Designer
 
+# CHANGED: description — added a sharper trigger boundary and explicit non-goals — reduces false-positive invocation.
+# CHANGED: references section — normalized to explicit Load When guidance with platform-safe relative paths — prevents speculative sidecar loading.
+# CHANGED: related powers cleanup — removed power-era section — keeps this skill canonical and platform-safe.
+
 ## Overview
 
 Senior API architect with expertise in designing scalable, developer-friendly REST and GraphQL APIs with comprehensive OpenAPI specifications.
@@ -25,6 +27,12 @@ You are a senior API designer with 10+ years of experience creating intuitive, s
 - Planning authentication flows
 - Documenting API contracts
 
+## When Not to Use This Skill
+
+- Pure database schema, indexing, or migration work without an API contract change
+- Framework-only implementation tasks such as wiring handlers, middleware, or DI containers
+- Internal refactors that do not change request/response contracts
+
 ## Core Workflow
 
 1. **Analyze domain** - Understand business requirements, data models, client needs
@@ -33,7 +41,7 @@ You are a senior API designer with 10+ years of experience creating intuitive, s
 4. **Specify contract** - Create OpenAPI 3.1 spec with complete documentation
 5. **Plan evolution** - Design versioning, deprecation, backward compatibility
 
-## Available Steering Files
+## References
 
 Load detailed guidance on-demand:
 
@@ -84,11 +92,3 @@ When designing APIs, provide:
 ## Knowledge Reference
 
 REST architecture, OpenAPI 3.1, GraphQL, HTTP semantics, JSON:API, HATEOAS, OAuth 2.0, JWT, RFC 7807 Problem Details, API versioning patterns, pagination strategies, rate limiting, webhook design, SDK generation
-
-## Related Powers
-
-- **GraphQL Architect** - GraphQL-specific API design
-- **FastAPI Expert** - Python API implementation
-- **NestJS Expert** - TypeScript API implementation
-- **Spring Boot Engineer** - Java API implementation
-- **Security Reviewer** - API security assessment

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

@@ -1,9 +1,7 @@
 ---
 name: api-patterns
 description: API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination.
-allowed-tools: Read, Write, Edit, Glob, Grep
 ---
-
 # API Patterns
 
 > API design principles and decision-making for 2025.
@@ -19,16 +17,16 @@ allowed-tools: Read, Write, Edit, Glob, Grep
 
 | File | Description | When to Read |
 |------|-------------|--------------|
-| `api-style.md` | REST vs GraphQL vs tRPC decision tree | Choosing API type |
-| `rest.md` | Resource naming, HTTP methods, status codes | Designing REST API |
-| `response.md` | Envelope pattern, error format, pagination | Response structure |
-| `graphql.md` | Schema design, when to use, security | Considering GraphQL |
-| `trpc.md` | TypeScript monorepo, type safety | TS fullstack projects |
-| `versioning.md` | URI/Header/Query versioning | API evolution planning |
-| `auth.md` | JWT, OAuth, Passkey, API Keys | Auth pattern selection |
-| `rate-limiting.md` | Token bucket, sliding window | API protection |
-| `documentation.md` | OpenAPI/Swagger best practices | Documentation |
-| `security-testing.md` | OWASP API Top 10, auth/authz testing | Security audits |
+| `references/api-style.md` | REST vs GraphQL vs tRPC decision tree | Choosing API type |
+| `references/rest.md` | Resource naming, HTTP methods, status codes | Designing REST API |
+| `references/response.md` | Envelope pattern, error format, pagination | Response structure |
+| `references/graphql.md` | Schema design, when to use, security | Considering GraphQL |
+| `references/trpc.md` | TypeScript monorepo, type safety | TS fullstack projects |
+| `references/versioning.md` | URI/Header/Query versioning | API evolution planning |
+| `references/auth.md` | JWT, OAuth, Passkey, API Keys | Auth pattern selection |
+| `references/rate-limiting.md` | Token bucket, sliding window | API protection |
+| `references/documentation.md` | OpenAPI/Swagger best practices | Documentation |
+| `references/security-testing.md` | OWASP API Top 10, auth/authz testing | Security audits |
 
 ---
 
@@ -78,4 +76,3 @@ Before designing an API:
 | Script | Purpose | Command |
 |--------|---------|---------|
 | `scripts/api_validator.py` | API endpoint validation | `python scripts/api_validator.py <project_path>` |
-

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/app-builder/SKILL.md

@@ -1,9 +1,7 @@
 ---
 name: app-builder
 description: Main application building orchestrator. Creates full-stack applications from natural language requests. Determines project type, selects tech stack, coordinates agents.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent
 ---
-
 # App Builder - Application Building Orchestrator
 
 > Analyzes user's requests, determines tech stack, plans structure, and coordinates agents.
@@ -14,11 +12,11 @@ allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent
 
 | File | Description | When to Read |
 |------|-------------|--------------|
-| `project-detection.md` | Keyword matrix, project type detection | Starting new project |
-| `tech-stack.md` | 2026 default stack, alternatives | Choosing technologies |
-| `agent-coordination.md` | Agent pipeline, execution order | Coordinating multi-agent work |
-| `scaffolding.md` | Directory structure, core files | Creating project structure |
-| `feature-building.md` | Feature analysis, error handling | Adding features to existing project |
+| `references/project-detection.md` | Keyword matrix, project type detection | Starting new project |
+| `references/tech-stack.md` | 2026 default stack, alternatives | Choosing technologies |
+| `references/agent-coordination.md` | Agent pipeline, execution order | Coordinating multi-agent work |
+| `references/scaffolding.md` | Directory structure, core files | Creating project structure |
+| `references/feature-building.md` | Feature analysis, error handling | Adding features to existing project |
 | `templates/SKILL.md` | **Project templates** | Scaffolding new project |
 
 ---

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/app-builder/templates/SKILL.md

@@ -1,9 +1,7 @@
 ---
 name: templates
 description: Project scaffolding templates for new applications. Use when creating new projects from scratch. Contains 12 templates for various tech stacks.
-allowed-tools: Read, Glob, Grep
 ---
-
 # Project Templates
 
 > Quick-start templates for scaffolding new projects.

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

@@ -6,7 +6,6 @@ metadata:
   replaced_by: architecture-designer
   removal_target: v0.6.0
 ---
-
 # Architecture
 
 ## Compatibility Alias

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

@@ -2,8 +2,6 @@
 name: "architecture-designer"
 description: "Use when designing new system architecture, reviewing existing designs, or making architectural decisions. Invoke for system design, architecture review, design patterns, ADRs, scalability planning."
 ---
-
-
 # Architecture Designer
 
 ## Overview
@@ -75,9 +73,3 @@ When designing architecture, provide:
 ## Knowledge Reference
 
 Distributed systems, microservices, event-driven architecture, CQRS, DDD, CAP theorem, cloud platforms (AWS, GCP, Azure), containers, Kubernetes, message queues, caching, database design
-
-## Related Powers
-
-- **Fullstack Guardian** - Implementing designs
-- **DevOps Engineer** - Infrastructure implementation
-- **Secure Code Guardian** - Security architecture

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/ask-questions-if-underspecified/SKILL.md

@@ -2,7 +2,6 @@
 name: ask-questions-if-underspecified
 description: Clarify requirements before implementing. Use when serious doubts arise.
 ---
-
 # Ask Questions If Underspecified
 
 ## When to Use

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/bash-linux/SKILL.md

@@ -1,9 +1,7 @@
 ---
 name: bash-linux
 description: Bash/Linux terminal patterns. Critical commands, piping, error handling, scripting. Use when working on macOS or Linux systems.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
 ---
-
 # Bash Linux Patterns
 
 > Essential patterns for Bash on Linux/macOS.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/behavioral-modes/SKILL.md

@@ -1,9 +1,7 @@
 ---
 name: behavioral-modes
 description: AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type.
-allowed-tools: Read, Glob, Grep
 ---
-
 # Behavioral Modes - Adaptive AI Operating Modes
 
 ## Purpose
@@ -217,7 +215,7 @@ Modern architectures optimized for agent-to-agent collaboration:
 
 ### 2. 🗺️ PLAN-EXECUTE-CRITIC (PEC)
 Cyclic mode transitions for high-complexity tasks:
-1. **Planner:** Decomposes the task into atomic steps (`task.md`).
+1. **Planner:** Decomposes the task into atomic steps (task handoff or planning artifact).
 2. **Executor:** Performs the actual coding (`IMPLEMENT`).
 3. **Critic:** Reviews the code, performs security and performance checks (`REVIEW`).
 

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

@@ -1,9 +1,7 @@
 ---
 name: brainstorming
 description: Socratic questioning protocol + user communication. MANDATORY for complex requests, new features, or unclear requirements. Includes progress reporting and error handling.
-allowed-tools: Read, Glob, Grep
 ---
-
 # Brainstorming & Communication Protocol
 
 > **MANDATORY:** Use for complex/vague requests, new features, updates.
@@ -34,7 +32,7 @@ allowed-tools: Read, Glob, Grep
 
 ## 🧠 Dynamic Question Generation
 
-**⛔ NEVER use static templates.** Read `dynamic-questioning.md` for principles.
+**⛔ NEVER use static templates.** Read `references/dynamic-questioning.md` for principles.
 
 ### Core Principles
 
@@ -73,7 +71,7 @@ allowed-tools: Read, Glob, Grep
 **If Not Specified:** [Default + rationale]
 ```
 
-**For detailed domain-specific question banks and algorithms**, see: `dynamic-questioning.md`
+**For detailed domain-specific question banks and algorithms**, see: `references/dynamic-questioning.md`
 
 ---
 

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/changelog-generator/SKILL.md

@@ -2,7 +2,6 @@
 name: changelog-generator
 description: Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
 ---
-
 # Changelog Generator
 
 This skill transforms technical git commits into polished, user-friendly changelogs that your customers and users will actually understand and appreciate.

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

@@ -1,11 +1,7 @@
 ---
 name: clean-code
 description: Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments
-allowed-tools: Read, Write, Edit
-version: 2.0
-priority: CRITICAL
 ---
-
 # Clean Code - Pragmatic AI Coding Standards
 
 > **CRITICAL SKILL** - Be **concise, direct, and solution-focused**.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/cli-developer/SKILL.md

@@ -1,23 +1,7 @@
 ---
 name: "cli-developer"
-displayName: "CLI Developer"
 description: "Build intuitive, cross-platform CLI tools with argument parsing, interactive prompts, progress indicators, and shell completions across Node.js, Python, and Go"
-keywords:
-  [
-    "cli",
-    "command-line",
-    "terminal",
-    "argument parsing",
-    "shell completion",
-    "interactive prompt",
-    "progress bar",
-    "commander",
-    "click",
-    "typer",
-    "cobra",
-  ]
 ---
-
 # CLI Developer
 
 ## Overview
@@ -109,8 +93,8 @@ mycli                           # Root command
 
 | File                 | Load When                                                    |
 | -------------------- | ------------------------------------------------------------ |
-| `design-patterns.md` | Command hierarchy, flags, config layers, plugin architecture |
-| `node-cli.md`        | Commander, Yargs, Inquirer, Chalk, Ora                       |
-| `python-cli.md`      | Typer, Click, argparse, Rich, questionary                    |
-| `go-cli.md`          | Cobra, Viper, Bubble Tea, progress bars                      |
-| `ux-patterns.md`     | Progress indicators, colors, help text, error messages       |
+| `references/design-patterns.md` | Command hierarchy, flags, config layers, plugin architecture |
+| `references/node-cli.md`        | Commander, Yargs, Inquirer, Chalk, Ora                       |
+| `references/python-cli.md`      | Typer, Click, argparse, Rich, questionary                    |
+| `references/go-cli.md`          | Cobra, Viper, Bubble Tea, progress bars                      |
+| `references/ux-patterns.md`     | Progress indicators, colors, help text, error messages       |

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

@@ -2,8 +2,6 @@
 name: "code-documenter"
 description: "Use when adding docstrings, creating API documentation, or building documentation sites. Invoke for OpenAPI/Swagger specs, JSDoc, doc portals, tutorials, user guides."
 ---
-
-
 # Code Documenter
 
 ## Overview
@@ -81,7 +79,3 @@ Depending on the task, provide:
 ## Knowledge Reference
 
 Google/NumPy/Sphinx docstrings, JSDoc, OpenAPI 3.0/3.1, AsyncAPI, gRPC/protobuf, FastAPI, Django, NestJS, Express, GraphQL, Docusaurus, MkDocs, VitePress, Swagger UI, Redoc, Stoplight
-
-## Related Powers
-
-**Spec Miner** - Informs from code analysis | **Fullstack Guardian** - Documents during implementation | **Code Reviewer** - Checks documentation quality

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

@@ -6,7 +6,6 @@ metadata:
   replaced_by: code-reviewer
   removal_target: v0.6.0
 ---
-
 # Code Review Checklist
 
 ## Compatibility Alias