@cubis/foundry 0.3.62 → 0.3.64

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 executing any workflow, check if a matching skill exists via `skill_search`; load with `skill_get` to prime context before the workflow runs (→ §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,9 +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. Run `skill_search <domain>` to find the best matching skill.
-2. If a strong match exists, load it with `skill_get <id>` before delegating.
-3. Include the loaded skill ID in the Decision Log for the routing decision.
+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 resolved route ID and validated skill IDs in the Decision Log.
 
 This ensures the specialist starts with accurate domain knowledge, not just role intent.
 
@@ -79,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.
 
@@ -90,33 +96,42 @@ The Foundry MCP server is the primary knowledge layer. Use tools decisively —
 
 | Prefix      | Tools                                                                                                | When to use                                                    |
 | ----------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
-| `skill_*`   | `skill_list_categories`, `skill_search`, `skill_browse_category`, `skill_get`, `skill_budget_report` | Domain expertise for any implementation, debug, or review task |
+| `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                                     |
 
-### Discovery Flow (Mandatory Order)
+### Validated Skill Flow (Mandatory Order)
 
-Stop at the earliest step that gives enough signal. Do not jump ahead.
+Stop at the earliest step that gives enough signal. Do not jump ahead or front-load skill discovery.
 
-1. `skill_list_categories` — run once per session if domain is unknown; see what exists
-2. `skill_search <keyword>` — fast keyword match across all skills; always try this first
-3. `skill_browse_category <category>` — explore if search is too broad or returns 0 results
-4. `skill_get <id>` — load full skill content; only when committed to using it
-5. `skill_budget_report` — verify token cost internally; do not emit budget details unless requested
+1. Inspect the codebase/task locally first; do not start with `skill_search`
+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>`
+7. Use `skill_list_categories` or `skill_browse_category` only as fallback when targeted search fails
+8. Use `skill_budget_report` internally only when the user explicitly asks for context accounting
 
 ### Postman Intent Trigger (Required)
 
 When user intent includes Postman workflows (for example: workspace, collection, environment, runCollection, monitor, mock, or "run Postman tests"):
 
-1. Run `skill_search "postman"` first.
-2. If `postman` skill exists, load `skill_get "postman"` before workflow/agent routing.
-3. Prefer Postman MCP tools (`postman.*`) over Newman/CLI fallback unless the user explicitly asks for fallback.
-4. If `--postman` was installed but `postman` skill cannot be found, report installation drift and suggest reinstall with `cbx workflows install ... --postman`.
+1. Validate `postman` directly with `skill_validate "postman"` when the exact skill ID is known.
+2. If validation fails and local grounding is still insufficient, run a narrow `skill_search "postman"` and validate the selected exact ID.
+3. Load `skill_get "postman"` with `includeReferences:false` before workflow/agent routing.
+4. Prefer Postman MCP tools (`postman.*`) over Newman/CLI fallback unless the user explicitly asks for fallback.
+5. If `--postman` was installed but `postman` skill cannot be found, report installation drift and suggest reinstall with `cbx workflows install ... --postman`.
 
 **Hard rules:**
 
-- Never call `skill_get` without a prior `skill_search` or `skill_browse_category`
-- 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 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 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
 - If `skill_search` returns 0 results, try `skill_browse_category`, then fall back to built-in knowledge
 
@@ -125,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                             |
@@ -146,12 +162,23 @@ After `skill_get`, include at most one short line:
 
 Do not append budget tables or token summaries unless the user explicitly asks.
 
+### Reference Files (Required When Relevant)
+
+Reference markdown files are first-class skill context, but they must be loaded selectively.
+
+1. Use `skill_validate` to see `availableReferences` for the exact skill
+2. Start with `skill_get(..., includeReferences:false)` to load only the core skill body
+3. If the skill points to a reference or the task clearly needs sidecar detail, load one file with `skill_get_reference`
+4. Only load another reference if the first one still leaves a concrete gap
+
 
 ### Anti-Patterns (Never Do These)
 
 - Loading skills speculatively "just in case" they might be useful
-- Calling `skill_get` before running `skill_search` or `skill_browse_category`
+- Calling `skill_get` before `skill_validate`
 - Using partial or guessed skill IDs in `skill_get`
+- Treating `skill_search` results as an implicit final selection
+- Starting a task with `skill_list_categories` or broad catalog browsing
 - Publishing verbose budget fields (`full_catalog_est_tokens`, `loaded_est_tokens`, etc.) in responses
 - Re-emitting the ctx stamp multiple times within a single response
 - Treating workflow IDs as skill IDs in any MCP tool call
@@ -243,66 +270,27 @@ Selection policy:
 <!-- cbx:workflows:auto:end -->
 
 <!-- cbx:mcp:auto:start version=1 -->
-## Cubis Foundry MCP Tool Catalog (auto-managed)
-
-The Foundry MCP server provides progressive-disclosure skill discovery and integration management tools.
-
-### Skill Vault
-
-- **123** skills across **22** categories
-- Estimated full catalog: ~109,067 tokens
-
-Categories:
-- `ai`: 1 skill(s)
-- `api`: 3 skill(s)
-- `architecture`: 3 skill(s)
-- `backend`: 14 skill(s)
-- `data`: 4 skill(s)
-- `design`: 6 skill(s)
-- `devops`: 20 skill(s)
-- `documentation`: 3 skill(s)
-- `frontend`: 9 skill(s)
-- `game-dev`: 1 skill(s)
-- `general`: 26 skill(s)
-- `localization`: 1 skill(s)
-- `marketing`: 2 skill(s)
-- `mobile`: 7 skill(s)
-- `observability`: 1 skill(s)
-- `payments`: 1 skill(s)
-- `performance`: 2 skill(s)
-- `practices`: 5 skill(s)
-- `saas`: 1 skill(s)
-- `security`: 4 skill(s)
-- `testing`: 6 skill(s)
-- `tooling`: 3 skill(s)
-
-### Built-in Tools
-
-**Skill Discovery:**
-- `skill_list_categories`: List all skill categories available in the vault. Returns category names and skill counts.
-- `skill_browse_category`: Browse skills within a specific category. Returns skill IDs and short descriptions.
-- `skill_search`: Search skills by keyword. Matches against skill IDs and descriptions.
-- `skill_get`: Get full content of a specific skill by ID. Returns SKILL.md content and referenced files.
-- `skill_budget_report`: Report estimated context/token budget for selected and loaded skills.
-
-**Postman Integration:**
-- `postman_get_mode`: Get current Postman MCP mode from cbx_config.
-- `postman_set_mode`: Set Postman MCP mode in cbx_config.
-- `postman_get_status`: Get Postman integration status and active profile.
-
-**Stitch Integration:**
-- `stitch_get_mode`: Get Stitch MCP mode from cbx_config.
-- `stitch_set_profile`: Switch active Stitch profile in cbx_config.
-- `stitch_get_status`: Get Stitch integration status and active profile.
-
-### Skill Discovery Flow
-
-Use progressive disclosure to minimize context usage:
-1. `skill_list_categories` → see available categories and counts
-2. `skill_browse_category` → browse skills in a category with short descriptions
-3. `skill_search` → search by keyword across all skills
-4. `skill_get` → load full content of a specific skill (only tool that reads full content)
-5. `skill_budget_report` → check token usage for selected/loaded skills; use result to emit the § Context Budget Tracking stamp
+## Cubis Foundry MCP (auto-managed)
+
+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_*`
+
+### Validated Skill Flow
+
+1. Inspect the repo/task locally first. Do not start with `skill_search`.
+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

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

@@ -2,8 +2,6 @@
 name: "code-reviewer"
 description: "Use when reviewing pull requests, conducting code quality audits, or identifying security vulnerabilities. Invoke for PR reviews, code quality checks, refactoring suggestions."
 ---
-
-
 # Code Reviewer
 
 ## Overview
@@ -82,9 +80,3 @@ Code review report should include:
 ## Knowledge Reference
 
 SOLID, DRY, KISS, YAGNI, design patterns, OWASP Top 10, language idioms, testing patterns
-
-## Related Powers
-
-- **Security Reviewer** - Deep security analysis
-- **Test Master** - Test quality assessment
-- **Architecture Designer** - Design review