@cubis/foundry 0.3.63 → 0.3.65

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

@@ -2,7 +2,6 @@
 name: postman
 description: Automate API testing and collection management with Postman MCP using full-mode defaults and workspace-aware execution.
 ---
-
 # Postman MCP Skill
 
 Use this skill when you need Postman workspace, collection, environment, or run operations through MCP.
@@ -15,11 +14,17 @@ References:
 ## MCP-First Rule
 
 - Prefer Postman MCP tools for all Postman operations.
-- Accept both dynamic naming styles from clients:
-  - dotted: `postman.<tool>`
-  - alias: `postman_<tool>`
+- Use direct Postman server tools for actual Postman cloud work:
+  - direct server: `postman.<tool>`
+  - client-wrapped direct server: `mcp__postman__<tool>`
+- Treat Foundry `postman_*` tools as config helpers only:
+  - `postman_get_status`
+  - `postman_get_mode`
+  - `postman_set_mode`
 - Never default to raw Postman REST JSON payloads, Newman, or Postman CLI when MCP tools are available.
-- Do not use Newman/Postman CLI fallback unless the user explicitly asks for fallback.
+- Do not use `postman.runMonitor` as an automatic fallback after `postman.runCollection` timeout or failure.
+- Only use monitor execution when the user explicitly asks for monitor-based cloud execution, scheduled monitoring, or monitor validation.
+- Recommend Postman CLI as the default secondary path when direct MCP execution fails.
 - If required Postman MCP tools are unavailable, report discovery/remediation steps first.
 
 ## Setup Baseline
@@ -36,16 +41,21 @@ References:
 ## Preflight
 
 1. Read Postman status first:
-   - Call `postman_get_status`.
+   - Call `postman_get_status` for mode/default-workspace/config state.
 2. Ensure mode is `full`:
    - If not, call `postman_set_mode` with `mode: full`.
 3. Discover upstream tools:
-   - Confirm required tools exist before execution (for example workspaces/collections/runs).
+   - Confirm required direct Postman server tools exist before execution (for example workspaces/collections/runs).
 
 Execution rule:
-- For Postman requests, call MCP tools directly (`postman.*` or `postman_*`) instead of drafting manual JSON or curl payloads.
+- For Postman requests, call the direct Postman server (`postman.<tool>` or `mcp__postman__<tool>`) instead of Foundry `postman_*` config tools.
 - If the user asks for API payload examples, provide them only as supplemental documentation after MCP execution guidance.
 
+Quota-safe rule:
+- If `postman.runCollection` times out or fails, stop and classify the error before choosing any fallback.
+- Never auto-convert a collection run failure into `postman.runMonitor`.
+- Recommend Postman CLI first for repeatable local reruns.
+
 ## Default Workspace Policy
 
 Resolve workspace in this order:
@@ -76,6 +86,30 @@ When a Postman tool requires a workspace argument, always pass the resolved work
 
 ## Failure Handling
 
+### Error Classification
+
+Classify failures before suggesting any fallback:
+
+- `limitBreachedError` or "breached monitoring usage limit":
+  - monitor quota exhaustion
+  - do not retry monitor runs
+  - recommend local Postman CLI execution
+  - tell the user to check the Postman monitoring usage dashboard
+- `429` or rate-limit response:
+  - Postman API rate limiting
+  - recommend backoff and a lower request burst
+  - do not reinterpret it as monitor quota
+- collection run timeout without quota/rate-limit signal:
+  - direct MCP runtime or tool timeout
+  - do not auto-convert to a monitor run
+  - recommend Postman CLI or a smaller-scope rerun
+
+### Quota Notes
+
+- Monitor usage is separate from Postman API rate limits.
+- Monitor usage is plan/billing usage and is consumed by request count, region count, and auth requests.
+- Monitor runtime caps are separate from monitor quota and do not imply quota remains available.
+
 If dynamic Postman tools are missing:
 
 1. Verify env alias expected by config is set.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/postman/references/troubleshooting.md

@@ -28,3 +28,42 @@ Use alias tools (`postman_<tool>`) when dotted names are filtered by client UI.
 ## Missing API key at startup
 
 Expected behavior: tool names can still come from cached catalog; tool calls fail with explicit auth error until env alias is set.
+
+## Quota-safe execution
+
+Preferred path:
+
+1. Use direct Postman MCP collection execution first (`postman.runCollection` or equivalent).
+2. If that fails, stop and classify the error.
+3. Recommend Postman CLI as the safe default secondary path.
+4. Use monitor execution only when the user explicitly asks for monitor-based cloud execution.
+
+Do not auto-fallback from `runCollection` to `runMonitor`.
+
+## Error classification
+
+### `limitBreachedError` or "breached monitoring usage limit"
+
+- This is monitor quota exhaustion, not generic API failure.
+- Do not retry monitor runs.
+- Do not reinterpret it as an MCP auth issue.
+- Tell the user to check Postman monitoring usage and billing-period reset in the Postman dashboard.
+- Recommend Postman CLI as the next execution path.
+
+### `429` or rate-limited API response
+
+- This is Postman API rate limiting.
+- Reduce request burst, add backoff, and retry later.
+- Do not treat it as monitor quota exhaustion.
+
+### `runCollection` timeout without quota/rate-limit signal
+
+- Treat this as direct MCP/runtime timeout.
+- Do not auto-convert to monitor execution.
+- Recommend Postman CLI or a smaller-scope rerun.
+
+## Monitor usage facts
+
+- Monitor usage is separate from Postman API RPM limits.
+- Monitor usage is consumed by request count, region count, and auth requests.
+- Monitor runtime caps are separate from monitor quota and do not imply usage remains available.

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

@@ -1,9 +1,7 @@
 ---
 name: powershell-windows
 description: PowerShell Windows patterns. Critical pitfalls, operator syntax, error handling.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
 ---
-
 # PowerShell Windows Patterns
 
 > Critical patterns and pitfalls for Windows PowerShell.

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

@@ -1,19 +1,18 @@
 ---
 name: "prompt-engineer"
-displayName: "Prompt Engineer"
 description: "Design and optimize LLM prompts with chain-of-thought, few-shot learning, and evaluation frameworks"
-keywords: ["prompt", "llm", "ai", "chain-of-thought", "few-shot", "evaluation", "gpt", "claude"]
 ---
-
 # Prompt Engineer
 
 ## When to Load Steering Files
 
-- Prompt patterns (zero-shot, few-shot, CoT) → `prompt-patterns.md`
-- Optimization techniques → `prompt-optimization.md`
-- Evaluation frameworks → `evaluation-frameworks.md`
-- Structured outputs (JSON, function calling) → `structured-outputs.md`
-- System prompt design → `system-prompts.md`
+| File | Load when |
+| --- | --- |
+| `references/prompt-patterns.md` | Choosing zero-shot, few-shot, chain-of-thought, or decomposition patterns. |
+| `references/prompt-optimization.md` | Iterating on failures, reducing ambiguity, or tightening prompts for latency/cost. |
+| `references/evaluation-frameworks.md` | Building prompt test cases, eval loops, or regression checks. |
+| `references/structured-outputs.md` | Designing JSON outputs, schema-constrained outputs, or tool/function calling prompts. |
+| `references/system-prompts.md` | Defining durable system prompts, role constraints, or behavioral guardrails. |
 
 ## Core Workflow
 

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

@@ -6,7 +6,6 @@ metadata:
   replaced_by: python-pro
   removal_target: v0.6.0
 ---
-
 # Python Patterns
 
 ## Compatibility Alias

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

@@ -9,7 +9,6 @@ metadata:
   stack: "python"
   baseline: "Python 3.14"
 ---
-
 # Python Pro
 
 ## When to use
@@ -18,6 +17,12 @@ metadata:
 - Migrating legacy Python to typed and testable architecture.
 - Implementing async I/O with predictable behavior.
 
+## When not to use
+
+- Frontend-only tasks with no Python runtime involved.
+- Database-only tuning or migration work with no Python code change.
+- Tiny shell-first automation where Python adds unnecessary packaging/runtime cost.
+
 ## Core workflow
 
 1. Establish interpreter/runtime constraints.
@@ -41,6 +46,18 @@ metadata:
 - Keep I/O async and CPU work isolated where needed.
 - Treat free-threaded mode as opt-in until dependencies are validated.
 
+## Debugging and observability
+
+- Preserve exception context and structured log fields at service boundaries.
+- Reproduce async bugs with deterministic fixtures before widening scope.
+- Use profiling and trace tooling before speculative concurrency changes.
+
+## Performance and reliability
+
+- Set timeout/retry budgets explicitly for external I/O.
+- Isolate CPU-heavy work from event loops or request handlers.
+- Keep dependency and packaging state reproducible with `pyproject.toml` tooling.
+
 ## Avoid
 
 - Untyped public APIs in shared modules.
@@ -49,8 +66,10 @@ metadata:
 
 ## Reference files
 
-- `references/type-system.md`
-- `references/async-patterns.md`
-- `references/testing.md`
-- `references/packaging.md`
-- `references/standard-library.md`
+| File | Load when |
+| --- | --- |
+| `references/type-system.md` | Typing strategy, protocols, generics, or boundary models need detail. |
+| `references/async-patterns.md` | Async I/O, task groups, or cancellation semantics need detail. |
+| `references/testing.md` | Pytest strategy, fixtures, or concurrency-safe tests are needed. |
+| `references/packaging.md` | Packaging, dependency layout, or toolchain reproducibility is in scope. |
+| `references/standard-library.md` | Standard-library-first options need review before adding dependencies. |

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

@@ -8,7 +8,6 @@ metadata:
   domain: "frontend"
   role: "review-checklist"
 ---
-
 # React Best Practices
 
 ## Purpose

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

@@ -9,7 +9,6 @@ metadata:
   stack: "react"
   baseline: "React 19"
 ---
-
 # React Expert
 
 ## Scope

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/react-expert/references/migration-class-to-modern.md

@@ -924,7 +924,7 @@ export default async function UserProfile({ params }: { params: { id: string } }
 - SEO-critical content? → Server Component
 - Large dependencies? → Server Component (smaller client bundle)
 
-See reference: `react-expert/references/server-components.md`
+See reference: [server-components.md](server-components.md)
 
 ---
 

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/red-team-tactics/SKILL.md

@@ -1,9 +1,7 @@
 ---
 name: red-team-tactics
 description: Red team tactics principles based on MITRE ATT&CK. Attack phases, detection evasion, reporting.
-allowed-tools: Read, Glob, Grep
 ---
-
 # Red Team Tactics
 
 > Adversary simulation principles based on MITRE ATT&CK framework.

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

@@ -1,10 +1,7 @@
 ---
 name: "refactor"
-displayName: "Refactor - OneUp HR"
 description: "Migrate legacy code to new architecture while maintaining behavior"
-keywords: ["refactor", "migrate", "clean", "improve", "legacy", "architecture"]
 ---
-
 # Refactor - OneUp HR
 
 ## Migration Patterns

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

@@ -1,20 +1,7 @@
 ---
 name: "riverpod-3"
-displayName: "Riverpod 3 Expert"
 description: "Riverpod 3 best practices for codegen, UI interaction boundaries, caching, paging, lifecycle, and testing"
-keywords:
-  [
-    "riverpod",
-    "riverpod 3",
-    "flutter",
-    "state management",
-    "asyncnotifier",
-    "codegen",
-    "keepalive",
-    "testing",
-  ]
 ---
-
 # Riverpod 3 Expert
 
 ## Overview
@@ -125,19 +112,25 @@ Avoid keepAlive for:
 
 ## Steering Files
 
-- `loop-avoidance.md` - Loop diagnostics and safe patterns
-- `minimal-rebuild.md` - `select`, widget splitting, item-level providers
-- `provider-layout.md` - Generic provider organization and boundaries
-- `refresh-cache-paging.md` - Refresh/paging/cache recipes
-- `testing.md` - ProviderContainer and widget test patterns
+| File | Load when |
+| --- | --- |
+| `references/loop-avoidance.md` | Diagnosing provider loops, invalidation storms, or notifier recursion. |
+| `references/minimal-rebuild.md` | Reducing rebuilds with `select`, widget splitting, or item-level providers. |
+| `references/provider-layout.md` | Organizing provider boundaries, layers, and ownership. |
+| `references/refresh-cache-paging.md` | Designing refresh, cache TTL, paging, or stale-while-revalidate flows. |
+| `references/testing.md` | Writing `ProviderContainer` or widget tests for Riverpod behavior. |
 
 ## Examples
 
-- `attendance_paging.md` - Complete paging example
-- `profile_edit.md` - Form workflow example
+| File | Load when |
+| --- | --- |
+| `examples/attendance_paging.md` | You need a concrete paginated list example. |
+| `examples/profile_edit.md` | You need a form/editing workflow example. |
 
 ## Templates
 
-- `cache_policy.dart` - TTL helper for repository cache policy
-- `paged_controller.dart` - Cursor/page-based infinite list controller
-- `riverpod_controller_test` - Provider/controller test template
+| File | Load when |
+| --- | --- |
+| `templates/cache_policy.dart.md` | Creating a TTL helper for repository caching. |
+| `templates/paged_controller.dart.md` | Bootstrapping a cursor/page-based controller. |
+| `templates/riverpod_controller_test.md` | Starting a provider/controller test template. |

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

@@ -6,7 +6,6 @@ metadata:
   replaced_by: rust-pro
   removal_target: v0.6.0
 ---
-
 # Rust Engineer
 
 ## Compatibility Alias

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

@@ -9,7 +9,6 @@ metadata:
   stack: "rust"
   baseline: "Rust stable 1.91"
 ---
-
 # Rust Pro
 
 ## When to use
@@ -18,6 +17,12 @@ metadata:
 - Solving ownership/lifetime design problems.
 - Optimizing memory safety and runtime performance together.
 
+## When not to use
+
+- Browser/frontend-only work with no Rust component.
+- Database-only tuning without Rust service or library changes.
+- Small scripts where shell or existing project tooling is the intended path.
+
 ## Core workflow
 
 1. Define ownership and error model first.
@@ -42,6 +47,24 @@ metadata:
 - Keep borrow scopes tight to improve readability and compile times.
 - Separate transport DTOs from domain types.
 
+## Debugging and observability
+
+- Prefer reproducible failing tests and `tracing` instrumentation before redesigning ownership or async structure.
+- Make task cancellation, retries, and error chains visible in logs/telemetry.
+- Use `cargo test`, `clippy`, and targeted benchmarks to isolate regressions.
+
+## Performance and reliability
+
+- Keep async flows cancellation-safe and backpressure-aware.
+- Measure allocations, lock contention, and tail latency before unsafe or low-level tuning.
+- Bound work queues and connection pools explicitly.
+
+## References
+
+| File | Load when |
+| --- | --- |
+| `references/operational-baseline.md` | You need service-level guardrails for async, errors, tracing, and test discipline. |
+
 ## Avoid
 
 - Premature `unsafe` optimization.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/rust-pro/references/operational-baseline.md

@@ -0,0 +1,9 @@
+## Operational baseline
+
+Load when: async service safety, tracing, error handling, or release guardrails need explicit guidance.
+
+- Keep error chains actionable and visible in logs/traces.
+- Use `cargo fmt`, `clippy`, and focused tests as a release baseline.
+- Make cancellation, queue bounds, and backpressure explicit.
+- Treat `unsafe` as an exception with documented invariants.
+- Profile before low-level optimization.

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

@@ -2,7 +2,6 @@
 name: "saas-builder"
 description: "Build or review production-ready multi-tenant SaaS systems on AWS serverless architecture with React + TypeScript frontend, tenant-isolated DynamoDB data models, JWT/RBAC authorization, Stripe subscriptions, and usage-based billing. Use for SaaS architecture design, implementation planning, API/Lambda patterns, billing workflows, and tenant isolation audits."
 ---
-
 # SaaS Builder
 
 Implement multi-tenant SaaS systems with serverless-first architecture, strict tenant isolation, and billing-grade data handling.

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

@@ -1,13 +1,7 @@
 ---
 name: sarif-parsing
 description: Parse, analyze, and process SARIF (Static Analysis Results Interchange Format) files. Use when reading security scan results, aggregating findings from multiple tools, deduplicating alerts, extracting specific vulnerabilities, or integrating SARIF data into CI/CD pipelines.
-allowed-tools:
-  - Bash
-  - Read
-  - Glob
-  - Grep
 ---
-
 # SARIF Parsing Best Practices
 
 You are a SARIF parsing expert. Your role is to help users effectively read, analyze, and process SARIF files from static analysis tools.

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

@@ -12,7 +12,6 @@ metadata:
   output-format: code
   related-skills: fullstack-guardian, security-reviewer, architecture-designer
 ---
-
 # Secure Code Guardian
 
 Security-focused developer specializing in writing secure code and preventing vulnerabilities.

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

@@ -2,8 +2,6 @@
 name: "security-reviewer"
 description: "Use when conducting security audits, reviewing code for vulnerabilities, or analyzing infrastructure security. Invoke for SAST scans, penetration testing, DevSecOps practices, cloud security reviews."
 ---
-
-
 # Security Reviewer
 
 ## Overview
@@ -73,11 +71,3 @@ Provide: (1) Executive summary with risk, (2) Findings table with severity count
 ## Knowledge Reference
 
 OWASP Top 10, CWE, Semgrep, Bandit, ESLint Security, gosec, npm audit, gitleaks, trufflehog, CVSS scoring, nmap, Burp Suite, sqlmap, Trivy, Checkov, HashiCorp Vault, AWS Security Hub, CIS benchmarks, SOC2, ISO27001
-
-## Related Powers
-
-- **Secure Code Guardian** - Implementing fixes
-- **Code Reviewer** - General code review
-- **DevOps Engineer** - Security in CI/CD
-- **Cloud Architect** - Cloud security architecture
-- **Kubernetes Specialist** - Container security

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

@@ -4,20 +4,7 @@ description: Run Semgrep static analysis scan on a codebase using parallel subag
   detects and uses Semgrep Pro for cross-file analysis when available. Use when asked to scan
   code for vulnerabilities, run a security audit with Semgrep, find bugs, or perform
   static analysis. Spawns parallel workers for multi-language codebases and triage.
-allowed-tools:
-  - Bash
-  - Read
-  - Glob
-  - Grep
-  - Write
-  - Task
-  - AskUserQuestion
-  - TaskCreate
-  - TaskList
-  - TaskUpdate
-  - WebFetch
 ---
-
 # Semgrep Security Scan
 
 Run a complete Semgrep scan with automatic language detection, parallel execution via Task subagents, and parallel triage. Automatically uses Semgrep Pro for cross-file taint analysis when available.

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

@@ -1,9 +1,7 @@
 ---
 name: seo-fundamentals
 description: SEO fundamentals, E-E-A-T, Core Web Vitals, and Google algorithm principles.
-allowed-tools: Read, Glob, Grep
 ---
-
 # SEO Fundamentals
 
 > Principles for search engine visibility.

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

@@ -6,7 +6,6 @@ metadata:
   replaced_by: sre-engineer
   removal_target: v0.6.0
 ---
-
 # Server Management
 
 ## Compatibility Alias

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

@@ -0,0 +1,74 @@
+---
+name: "skill-authoring"
+description: "Use when creating a new Foundry skill or updating an existing one: scaffolding SKILL.md, fixing metadata, wiring references and scripts, removing legacy power files, and making the package work across Codex, Antigravity, Copilot, Cursor, and Windsurf. Do not use for prompt tuning without a skill package change or for editing only one generated mirror."
+metadata:
+  provenance:
+    source: "https://github.com/anthropics/skills/tree/main/skills/skill-creator"
+    snapshot: "Adapted from the local Codex system skill on 2026-03-06"
+  maintenance: "Pinned snapshot; refresh manually when upstream changes are intentionally adopted."
+---
+# Skill Authoring
+
+## Overview
+
+Use this skill to create or repair Foundry skills from the canonical source layer. It is adapted from Anthropic's `skill-creator`, but rewritten for Foundry's cross-platform model and packaging rules.
+
+## When to Use
+
+- Creating a new skill under `workflows/skills/<id>`
+- Updating `name`, `description`, `metadata`, or `compatibility` in `SKILL.md`
+- Repairing broken `references/`, `steering/`, or `templates/` links
+- Replacing legacy power-file patterns with canonical skill packaging
+- Adapting a skill so its generated Codex, Antigravity, Copilot, Cursor, and Windsurf bundles stay valid
+- Adding or updating helper scripts that make a skill deterministic and reusable
+
+## When Not to Use
+
+- Pure prompt tuning with no skill package changes
+- Editing only a generated mirror when the canonical source is unchanged
+- General feature work that should route to an implementation, review, or domain skill instead
+
+## Core Workflow
+
+1. Clarify the trigger boundary and package scope with concrete examples.
+2. Edit the canonical skill only. Never hand-edit platform mirrors first.
+3. Keep `SKILL.md` concise and move variant detail into one-level-deep sidecar files.
+4. Add scripts only when they remove repetition or make execution more reliable.
+5. Validate frontmatter, links, sidecar content, and platform packaging before finishing.
+6. Regenerate mirrors and rule assets, then verify the skill is discoverable and readable at runtime.
+
+## Foundry Skill Contract
+
+- Required file: `SKILL.md`
+- Optional folders: `references/`, `steering/`, `templates/`, `scripts/`, `assets/`
+- Keep only `SKILL.md` at the skill root. Do not leave extra top-level markdown files.
+- Use relative paths from the skill root, not platform-specific absolute paths.
+- Reference files must be loaded selectively with explicit `Load when` guidance.
+- Do not ship legacy power files in canonical or platform-facing skill bundles.
+- Canonical metadata can stay richer, but platform mirrors are generated and sanitized automatically.
+
+## References
+
+Load on demand. Do not preload all reference files.
+
+| File | Load when |
+| --- | --- |
+| `references/foundry-platform-parity.md` | Adapting a skill for Codex, Antigravity, Copilot, Cursor, or Windsurf packaging and metadata rules. |
+| `references/foundry-skill-checklist.md` | Verifying naming, frontmatter, sidecars, routing, and validation before shipping a skill update. |
+
+## Helper Scripts
+
+Load or run only when the task needs them.
+
+| File | Load when |
+| --- | --- |
+| `scripts/init_skill.py` | Scaffolding a new canonical skill directory and starter `SKILL.md`. |
+| `scripts/quick_validate.py` | Checking frontmatter, broken markdown references, empty sidecars, and packaging safety for a skill directory. |
+
+## Rules
+
+- Prefer one canonical skill package that generates clean mirrors on every platform.
+- Keep references one level deep from `SKILL.md`.
+- Never bulk-load `references/` or `steering/`; pick only the file needed for the current step.
+- If a task is clearly about skill creation or maintenance, load this skill directly instead of starting with `skill_search`.
+- When cross-platform behavior changes, verify the generated outputs instead of assuming canonical text alone is enough.

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/skill-authoring/references/foundry-platform-parity.md

@@ -0,0 +1,50 @@
+# Foundry Platform Parity
+
+Use this reference when a skill has to work cleanly across generated platform bundles.
+
+## Canonical Authoring Rule
+
+- Author the real skill only under `workflows/skills/<id>`.
+- Generated mirrors are derived artifacts, not the source of truth.
+- If a mirror looks wrong, fix the canonical skill or the generator, then regenerate.
+
+## Packaging Rules
+
+- Keep `SKILL.md` as the only top-level markdown entry file.
+- Place sidecars under `references/`, `steering/`, or `templates/`.
+- Do not keep `POWER.md` in canonical skills or mirrored bundles.
+- Keep links relative to the skill root so the same content survives mirror relocation.
+
+## Platform Notes
+
+### Codex
+
+- Full canonical skill content is mirrored into `.agents/skills`.
+- Compatibility wrappers may exist for workflows and agents, but skills remain normal packages.
+
+### Antigravity
+
+- Skills are mirrored into `.agent/skills`.
+- Route-first rule text still expects the same `SKILL.md` plus selective sidecar loading.
+
+### Copilot
+
+- Copilot-facing skills must keep only supported frontmatter keys after sanitization.
+- The canonical skill may keep richer `metadata`, but the generated mirror should rely on Foundry's sanitization rather than hand-authored Copilot-only fields.
+- Workspace MCP should stay in `.vscode/mcp.json`.
+
+### Cursor and Windsurf
+
+- These mirrors follow the same filtered bundle rules as Copilot.
+- Duplicate top-level markdown files and stale sidecars will show up here too if the canonical package is sloppy.
+
+## Metadata Guidance
+
+- Required everywhere: `name`, `description`
+- Allowed canonical extensions: `license`, `allowed-tools`, `metadata`, `compatibility`
+- Keep the trigger boundary in `description` sharp enough that route-first loading can direct-load the skill when intent is obvious.
+
+## Routing Guidance
+
+- Do not create platform-specific aliases just to shadow a built-in skill.
+- If a built-in name collides with a Foundry skill, prefer a distinct canonical ID and route authoring intent to it explicitly.