@cubis/foundry 0.3.82 → 0.3.83

package/workflows/workflows/agent-environment-setup/platforms/gemini/commands/security.toml

@@ -1,19 +1,84 @@
 description = "Run security-focused analysis and remediation planning with exploitability-first triage."
 prompt = '''
-Follow the /security workflow from .gemini/workflows/security.md.
+Execute the native projection of the /security workflow.
+
+Run security-focused analysis and remediation planning with exploitability-first triage.
 
 Execution contract:
 1. Treat route selection as already resolved by this command; do not begin with skill discovery.
 2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
 Attached skills:
 - Load these exact skill IDs first: `owasp-security-review`, `code-review`, `api-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `rust-best-practices`.
-- Local skill file hints if installed: `.gemini/skills/owasp-security-review/SKILL.md`, `.gemini/skills/code-review/SKILL.md`, `.gemini/skills/api-design/SKILL.md`, `.gemini/skills/typescript-best-practices/SKILL.md`, `.gemini/skills/javascript-best-practices/SKILL.md`, `.gemini/skills/python-best-practices/SKILL.md`, `.gemini/skills/golang-best-practices/SKILL.md`, `.gemini/skills/rust-best-practices/SKILL.md`.
+- Local skill file hints if installed: `.agents/skills/owasp-security-review/SKILL.md`, `.agents/skills/code-review/SKILL.md`, `.agents/skills/api-design/SKILL.md`, `.agents/skills/typescript-best-practices/SKILL.md`, `.agents/skills/javascript-best-practices/SKILL.md`, `.agents/skills/python-best-practices/SKILL.md`, `.agents/skills/golang-best-practices/SKILL.md`, `.agents/skills/rust-best-practices/SKILL.md`.
 - Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
-3. Confirm the request fits the workflow's "When to use" section.
+3. Confirm the request fits the workflow's "When to use" section before acting.
 4. Execute according to "Workflow steps" and apply "Context notes".
 5. Complete "Verification" checks and report concrete evidence.
-6. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to the researcher posture first.
+6. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to research first.
 7. For outside evidence: repo first, official docs next, Reddit/community only as labeled secondary evidence.
 
+Workflow source:
+# Security Workflow
+
+## When to use
+
+Use this for security audits, vulnerability assessments, threat modeling, or security-focused code review.
+
+## Routing
+
+- Primary specialist: `@security-auditor`
+- Offensive assessment: `@penetration-tester`
+- Domain support: `@backend-specialist`, `@frontend-specialist`
+- Verification support: `@validator`
+
+## Context notes
+
+- This workflow file, active platform rules, and selected agents or skills guide execution.
+- Attach the security scope, threat model, compliance requirements, and relevant code paths.
+
+## Skill Routing
+
+- Primary skills: `security-engineer`, `auth-architect`
+- Supporting skills (optional): `vulnerability-scanner`, `static-analysis`, `api-design`, `graphql-architect`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`, `rust-pro`
+- Start with `security-engineer` for OWASP methodology and threat modeling. Add `auth-architect` for authentication/authorization review. Add `vulnerability-scanner` for dependency scanning and CVE triage.
+
+## Workflow steps
+
+1. Define security scope and threat model.
+2. Map attack surface and identify input vectors.
+3. Assess code against OWASP Top 10 and relevant standards.
+4. Triage findings by exploitability (reachability × controllability × impact).
+5. Produce remediation plan with prioritized fixes.
+6. Verify remediations do not introduce new vulnerabilities.
+
+## Verification
+
+- All critical and high findings have remediation plans.
+- Remediation code reviewed for correctness.
+- No new vulnerabilities introduced by fixes.
+- Compliance requirements addressed if applicable.
+
+## Output Contract
+
+```yaml
+SECURITY_WORKFLOW_RESULT:
+  primary_agent: security-auditor
+  supporting_agents: [penetration-tester?, backend-specialist?, frontend-specialist?, validator?]
+  primary_skills: [security-engineer, auth-architect]
+  supporting_skills: [vulnerability-scanner?, static-analysis?, api-design?]
+  threat_model:
+    assets: [<string>]
+    threats: [<string>]
+    attack_surface: [<string>]
+  findings:
+    - severity: critical | high | medium | low
+      category: <owasp-category>
+      exploitability: <string>
+      remediation: <string>
+  compliance_notes: [<string>] | []
+  remaining_risks: [<string>] | []
+  follow_up_items: [<string>] | []
+```
+
 If command arguments are provided, treat them as additional user context.
 '''

package/workflows/workflows/agent-environment-setup/platforms/gemini/commands/spec.toml

@@ -1,19 +1,86 @@
 description = "Create or refresh a Git-tracked spec pack for non-trivial work, including acceptance criteria, traceability, architecture impact, and next-route handoff."
 prompt = '''
-Follow the /spec workflow from .gemini/workflows/spec.md.
+Execute the native projection of the /spec workflow.
+
+Create or refresh a Git-tracked spec pack for non-trivial work, including acceptance criteria, traceability, architecture impact, and next-route handoff.
 
 Execution contract:
 1. Treat route selection as already resolved by this command; do not begin with skill discovery.
 2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
 Attached skills:
 - Load these exact skill IDs first: `spec-driven-delivery`, `sadd`, `system-design`, `architecture-doc`, `deep-research`, `api-design`, `database-design`, `tech-doc`.
-- Local skill file hints if installed: `.gemini/skills/spec-driven-delivery/SKILL.md`, `.gemini/skills/sadd/SKILL.md`, `.gemini/skills/system-design/SKILL.md`, `.gemini/skills/architecture-doc/SKILL.md`, `.gemini/skills/deep-research/SKILL.md`, `.gemini/skills/api-design/SKILL.md`, `.gemini/skills/database-design/SKILL.md`, `.gemini/skills/tech-doc/SKILL.md`.
+- Local skill file hints if installed: `.agents/skills/spec-driven-delivery/SKILL.md`, `.agents/skills/sadd/SKILL.md`, `.agents/skills/system-design/SKILL.md`, `.agents/skills/architecture-doc/SKILL.md`, `.agents/skills/deep-research/SKILL.md`, `.agents/skills/api-design/SKILL.md`, `.agents/skills/database-design/SKILL.md`, `.agents/skills/tech-doc/SKILL.md`.
 - Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
-3. Confirm the request fits the workflow's "When to use" section.
+3. Confirm the request fits the workflow's "When to use" section before acting.
 4. Execute according to "Workflow steps" and apply "Context notes".
 5. Complete "Verification" checks and report concrete evidence.
-6. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to the researcher posture first.
+6. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to research first.
 7. For outside evidence: repo first, official docs next, Reddit/community only as labeled secondary evidence.
 
+Workflow source:
+# Spec Workflow
+
+## When to use
+
+Use this for non-trivial work that needs durable planning in Git before implementation: medium or large features, multi-step changes, cross-session work, migrations, risky refactors, or any request that needs explicit acceptance and traceability.
+
+## Routing
+
+- Primary coordinator: `@project-planner`
+- Traceability and requirements support: `@researcher`
+- Cross-domain coordination: `@orchestrator`
+- Documentation and structure support: `@documentation-writer`
+
+## Skill Routing
+
+- Primary skills: `spec-driven-delivery`, `sadd`
+- Supporting skills (optional): `system-design`, `architecture-doc`, `deep-research`, `api-design`, `database-design`, `tech-doc`
+- Start with `spec-driven-delivery` for the pack structure and handoff contract. Add `sadd` when mining requirements into testable assertions, `system-design` or `architecture-doc` when the spec changes structure, and `deep-research` only when repo-local evidence is insufficient.
+
+## Workflow steps
+
+1. Determine whether the task is non-trivial enough to justify a spec pack.
+2. Find an existing `docs/specs/<spec-id>/` pack or create a new stable `spec_id`.
+3. Write or refresh the spec pack with brief, acceptance, tasks, traceability, and handoff files.
+4. Record `architecture_impact`, `doc_impact`, and any required updates to `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, `ENGINEERING_RULES.md`, or `docs/foundation/TECH.md`. If the change adds new terms, update the `## Domain Glossary` in `docs/foundation/PRODUCT.md`. If the change introduces new crosscutting patterns or tech debt, flag updates needed in `docs/foundation/ARCHITECTURE.md`.
+5. Identify the next execution route and hand off without replanning the same work.
+
+## Context notes
+
+- Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist because they define the accepted product direction, architecture contract, and current state.
+- Prefer repo evidence first; escalate to `deep-research` only when freshness, public comparison, or explicit research requests require it.
+- Keep spec packs lean. Trivial one-step tasks should stay on the lightweight path with no new spec directory.
+
+## Verification
+
+- `spec_id` and `spec_root` are stable and explicit.
+- Acceptance criteria are testable and traceable.
+- Task dependencies form a valid execution order.
+- `architecture_impact`, `doc_impact`, and `traceability_status` are present.
+
+## Output Contract
+
+```yaml
+SPEC_WORKFLOW_RESULT:
+  primary_agent: project-planner
+  supporting_agents: [researcher?, orchestrator?, documentation-writer?]
+  primary_skills: [spec-driven-delivery, sadd]
+  supporting_skills: [system-design?, architecture-doc?, deep-research?, api-design?, database-design?, tech-doc?]
+  spec_id: <string>
+  spec_root: docs/specs/<spec-id>
+  architecture_impact:
+    summary: <string>
+    affects_structure: true | false
+    affects_design_system: true | false
+    affects_testing_strategy: true | false
+  doc_impact: none | tech | rules | both
+  traceability_status: complete | partial | blocked
+  documents:
+    created: [<path>] | []
+    updated: [<path>] | []
+  next_route: </create | /implement-track | /orchestrate | /architecture | direct>
+  gaps: [<string>] | []
+```
+
 If command arguments are provided, treat them as additional user context.
 '''

package/workflows/workflows/agent-environment-setup/platforms/gemini/commands/test.toml

@@ -1,19 +1,81 @@
 description = "Design and execute verification strategy aligned to user risk, release confidence, and regression evidence."
 prompt = '''
-Follow the /test workflow from .gemini/workflows/test.md.
+Execute the native projection of the /test workflow.
+
+Design and execute verification strategy aligned to user risk, release confidence, and regression evidence.
 
 Execution contract:
 1. Treat route selection as already resolved by this command; do not begin with skill discovery.
 2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
 Attached skills:
 - Load these exact skill IDs first: `unit-testing`, `integration-testing`, `playwright-interactive`, `observability`, `systematic-debugging`, `code-review`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `java-best-practices`.
-- Local skill file hints if installed: `.gemini/skills/unit-testing/SKILL.md`, `.gemini/skills/integration-testing/SKILL.md`, `.gemini/skills/playwright-interactive/SKILL.md`, `.gemini/skills/observability/SKILL.md`, `.gemini/skills/systematic-debugging/SKILL.md`, `.gemini/skills/code-review/SKILL.md`, `.gemini/skills/typescript-best-practices/SKILL.md`, `.gemini/skills/javascript-best-practices/SKILL.md`.
+- Local skill file hints if installed: `.agents/skills/unit-testing/SKILL.md`, `.agents/skills/integration-testing/SKILL.md`, `.agents/skills/playwright-interactive/SKILL.md`, `.agents/skills/observability/SKILL.md`, `.agents/skills/systematic-debugging/SKILL.md`, `.agents/skills/code-review/SKILL.md`, `.agents/skills/typescript-best-practices/SKILL.md`, `.agents/skills/javascript-best-practices/SKILL.md`.
 - Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
-3. Confirm the request fits the workflow's "When to use" section.
+3. Confirm the request fits the workflow's "When to use" section before acting.
 4. Execute according to "Workflow steps" and apply "Context notes".
 5. Complete "Verification" checks and report concrete evidence.
-6. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to the researcher posture first.
+6. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to research first.
 7. For outside evidence: repo first, official docs next, Reddit/community only as labeled secondary evidence.
 
+Workflow source:
+# Test Workflow
+
+## When to use
+
+Use this when writing new tests, improving coverage, debugging test failures, or designing a testing strategy.
+
+## Routing
+
+- Primary specialist: `@test-engineer`
+- Automation support: `@qa-automation-engineer`
+- Domain support: `@backend-specialist`, `@frontend-specialist`
+- Verification support: `@validator`
+
+## Context notes
+
+- This workflow file, active platform rules, and selected agents or skills guide execution.
+- Attach the code under test, existing test files, coverage reports, and any failing test output.
+
+## Skill Routing
+
+- Primary skills: `testing-patterns`, `webapp-testing`
+- Supporting skills (optional): `playwright-e2e`, `error-ux-observability`, `debugging-strategies`, `frontend-code-review`, `static-analysis`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`, `java-pro`
+- Start with `testing-patterns` for test strategy and architecture. Add `webapp-testing` for implementation. Add `playwright-e2e` for E2E automation. Add `error-ux-observability` for testing error states.
+
+## Workflow steps
+
+1. Assess current test coverage and identify gaps.
+2. Design test strategy (which layers, what to test, what to skip).
+3. Implement tests with clear arrange/act/assert structure.
+4. Run tests and verify they pass.
+5. Review coverage improvement and remaining gaps.
+
+## Verification
+
+- All new tests pass reliably (no flakiness).
+- Tests cover the identified risk areas.
+- Coverage metrics improved or maintained.
+- Test naming clearly describes the scenario being verified.
+
+## Output Contract
+
+```yaml
+TEST_WORKFLOW_RESULT:
+  primary_agent: test-engineer
+  supporting_agents: [qa-automation-engineer?, backend-specialist?, frontend-specialist?, validator?]
+  primary_skills: [testing-patterns, webapp-testing]
+  supporting_skills: [playwright-e2e?, error-ux-observability?, debugging-strategies?]
+  test_strategy:
+    unit: <number of tests>
+    integration: <number of tests>
+    e2e: <number of tests>
+  tests_written: [<test-file-path>]
+  coverage:
+    before: <percentage or description>
+    after: <percentage or description>
+  gaps_remaining: [<string>] | []
+  follow_up_items: [<string>] | []
+```
+
 If command arguments are provided, treat them as additional user context.
 '''

package/workflows/workflows/agent-environment-setup/platforms/gemini/commands/vercel.toml

@@ -1,19 +1,82 @@
 description = "Drive Vercel implementation and operations via vercel-expert with deployment, runtime, security, and observability guardrails."
 prompt = '''
-Follow the /vercel workflow from .gemini/workflows/vercel.md.
+Execute the native projection of the /vercel workflow.
+
+Drive Vercel implementation and operations via vercel-expert with deployment, runtime, security, and observability guardrails.
 
 Execution contract:
 1. Treat route selection as already resolved by this command; do not begin with skill discovery.
 2. Read `docs/foundation/PRODUCT.md`, `ENGINEERING_RULES.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order when they exist before non-trivial execution.
 Attached skills:
 - Load these exact skill IDs first: `nextjs`, `ci-cd-pipeline`, `performance-testing`, `react`, `frontend-design`, `javascript-best-practices`, `typescript-best-practices`.
-- Local skill file hints if installed: `.gemini/skills/nextjs/SKILL.md`, `.gemini/skills/ci-cd-pipeline/SKILL.md`, `.gemini/skills/performance-testing/SKILL.md`, `.gemini/skills/react/SKILL.md`, `.gemini/skills/frontend-design/SKILL.md`, `.gemini/skills/javascript-best-practices/SKILL.md`, `.gemini/skills/typescript-best-practices/SKILL.md`.
+- Local skill file hints if installed: `.agents/skills/nextjs/SKILL.md`, `.agents/skills/ci-cd-pipeline/SKILL.md`, `.agents/skills/performance-testing/SKILL.md`, `.agents/skills/react/SKILL.md`, `.agents/skills/frontend-design/SKILL.md`, `.agents/skills/javascript-best-practices/SKILL.md`, `.agents/skills/typescript-best-practices/SKILL.md`.
 - Treat the skill bundle as already resolved for this workflow. Do not start with route discovery.
-3. Confirm the request fits the workflow's "When to use" section.
+3. Confirm the request fits the workflow's "When to use" section before acting.
 4. Execute according to "Workflow steps" and apply "Context notes".
 5. Complete "Verification" checks and report concrete evidence.
-6. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to the researcher posture first.
+6. If freshness, public comparison, or explicit research needs appear, pause implementation and load `deep-research` or route to research first.
 7. For outside evidence: repo first, official docs next, Reddit/community only as labeled secondary evidence.
 
+Workflow source:
+# Vercel Workflow
+
+## When to use
+
+Use this for Vercel-specific deployment, configuration, runtime optimization, or platform operations.
+
+## Routing
+
+- Primary specialist: `@vercel-expert`
+- Infrastructure support: `@devops-engineer`
+- Verification support: `@test-engineer`
+
+## Context notes
+
+- This workflow file, active platform rules, and selected agents or skills guide execution.
+- Attach the Vercel project config, deployment target, and any specific Vercel feature requirements.
+
+## Skill Routing
+
+- Primary skills: `nextjs-developer`, `serverless-patterns`
+- Supporting skills (optional): `web-perf`, `react-expert`, `tailwind-patterns`, `nodejs-best-practices`, `typescript-pro`, `javascript-pro`
+- Start with `nextjs-developer` for Next.js on Vercel and `serverless-patterns` for runtime behavior. Add `web-perf` for performance optimization.
+
+## Workflow steps
+
+1. Assess deployment requirements and runtime selection (Edge vs Serverless vs Static).
+2. Configure project settings and environment variables.
+3. Set up deployment pipeline with preview deployments.
+4. Verify deployment health and performance.
+5. Configure monitoring and alerting.
+
+## Verification
+
+- Deployment successful with no build errors.
+- Runtime selection appropriate for each route.
+- Environment variables correctly configured per environment.
+- Preview deployments working for PRs.
+- Performance metrics within acceptable ranges.
+
+## Output Contract
+
+```yaml
+VERCEL_WORKFLOW_RESULT:
+  primary_agent: vercel-expert
+  supporting_agents: [devops-engineer?, test-engineer?]
+  primary_skills: [nextjs-developer, serverless-patterns]
+  supporting_skills: [web-perf?, react-expert?]
+  deployment:
+    project: <string>
+    runtime: <edge | serverless | static>
+    environment: <development | preview | production>
+    status: success | failure
+  configuration:
+    env_vars: [<string>]
+    domains: [<string>]
+    caching: <string>
+  monitoring: <string>
+  follow_up_items: [<string>] | []
+```
+
 If command arguments are provided, treat them as additional user context.
 '''

package/workflows/workflows/agent-environment-setup/platforms/gemini/rules/GEMINI.md

@@ -22,15 +22,14 @@ If any check fails, restart your reasoning.
 
 ## 1) Platform Paths
 
-| Asset        | Location               |
-| ------------ | ---------------------- |
-| Skills       | `.gemini/skills`       |
-| Agents       | `.gemini/agents`       |
-| Commands     | `.gemini/commands`     |
-| Rules        | `.gemini/GEMINI.md`    |
-| Extensions   | `.gemini/extensions`   |
+| Asset            | Location                 |
+| ---------------- | ------------------------ |
+| Commands         | `.gemini/commands`       |
+| Rules            | `.gemini/GEMINI.md`      |
+| Optional skill hints | `.agents/skills/*/SKILL.md` |
+| Extensions       | `.gemini/extensions`     |
 
-> **Gemini CLI note:** Skills use name+description frontmatter only. No `context:fork` or `allowed-tools`. Commands use TOML format. Use `activate_skill` for progressive skill disclosure.
+> **Gemini CLI note:** Foundry compiles both `/workflow` and `@agent` routes into TOML command files. Skills remain MCP-loaded guidance; local `.agents/skills` paths are hints only when present.
 
 ---
 
@@ -44,18 +43,18 @@ Execute this tree top-to-bottom. Stop at the **first match**. Never skip levels.
 ├─ [TRIVIAL] Single-step, obvious, reversible?
 │   → Execute directly. No routing. Stop.
 │
-├─ [EXPLICIT] User named a command, specialist, or exact skill?
+├─ [EXPLICIT] User named a command, /workflow, @agent, or exact skill?
 │   → Honor that route exactly. Stop.
 │
 ├─ [SINGLE-DOMAIN] Multi-step but contained in one specialty?
-│   → Load best-fit skill via activate_skill. Execute. Stop.
+│   → Run the matching command route. Execute. Stop.
 │
 ├─ [CROSS-DOMAIN] Spans 2+ specialties with real handoff needs?
-│   → Coordinate specialists sequentially. Stop.
+│   → Coordinate specialists through command routes or sequential posture shifts. Stop.
 │
 ├─ [UNRESOLVED] None of the above matched cleanly?
-│   → Check Skill Routing Matrix below.
-│   → If still unclear: ask user. Stop.
+│   → Call route_resolve MCP tool.
+│   → If still unclear: ONE narrow skill_search. Stop.
 │
 └─ [FAILED] All routes exhausted?
     → Ask user for a single clarifying constraint. Stop.
@@ -65,7 +64,7 @@ Execute this tree top-to-bottom. Stop at the **first match**. Never skip levels.
 
 - Never pre-load skills before route resolution.
 - If the user names an exact skill ID, run `skill_validate` on that ID before `route_resolve`.
-- Never chain multiple skill loads per request.
+- Never chain more than one `skill_search` per request.
 - Treat this file as **durable project memory** — not a per-task playbook.
 
 ---
@@ -74,9 +73,10 @@ Execute this tree top-to-bottom. Stop at the **first match**. Never skip levels.
 
 1. **Inspect repo/task locally first.** Always. No exceptions.
 2. Route resolution comes before any skill consideration.
-3. **After routing:** use `activate_skill` to load the matched skill.
-4. Skills use progressive disclosure — load references only when the task requires them.
-5. Do not pre-prime every task with a skill. Load only what the task clearly needs.
+3. **After routing:** if `route_resolve` returns `primarySkillHint` or `primarySkills`, load the first via `skill_validate` → `skill_get` before non-trivial execution.
+4. Use `.gemini/commands/*.toml` as the native execution surface for `/workflow` and `@agent` routes.
+5. Load MCP skill references only when the current step needs them.
+6. Do not pre-prime every task with a skill. Load only what the task clearly needs.
 
 ---
 

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

@@ -77,8 +77,12 @@ Load only what the current task requires.
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

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

@@ -72,8 +72,12 @@ Load on demand. Do not preload all reference files.
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

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

@@ -67,8 +67,12 @@ Provide complete pipeline configuration files with inline comments explaining no
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

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

@@ -61,8 +61,12 @@ When conducting a code review, provide:
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

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

@@ -76,8 +76,12 @@ No helper scripts are required for this skill right now. Keep execution in `SKIL
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/database-design/SKILL.md

@@ -70,8 +70,12 @@ Load on demand. Do not preload all reference files.
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/deep-research/SKILL.md

@@ -82,8 +82,12 @@ Use these when the task shape already matches.
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/django-drf/SKILL.md

@@ -61,8 +61,12 @@ No helper scripts are required for this skill right now. Keep execution in `SKIL
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/docker-compose-dev/SKILL.md

@@ -67,8 +67,12 @@ Provide complete `docker-compose.yml` and `Dockerfile` content with inline comme
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.

package/workflows/workflows/agent-environment-setup/platforms/gemini/skills/drizzle-orm/SKILL.md

@@ -74,8 +74,12 @@ No helper scripts are required for this skill right now. Keep execution in `SKIL
 
 ## Gemini Platform Notes
 
-- Use `activate_skill` to invoke skills by name from Gemini CLI or Gemini Code Assist.
-- Skill files are stored under `.gemini/skills/` in the project root.
-- Gemini does not support `context: fork` — all skill execution is inline.
+- Workflow and agent routes are compiled into `.gemini/commands/*.toml` TOML command files.
+- Commands use `{{args}}` for user input, `!{shell command}` for shell output, `@{file}` for file content.
+- Specialists are internal postures (modes of reasoning), not spawned subagent processes.
+- Gemini does not support `context: fork` — all skill execution is inline within the current session.
+- Skills are loaded via MCP when the Cubis Foundry MCP server is configured. Local `.agents/skills/` paths serve as hints.
 - User arguments are passed as natural language in the activation prompt.
-- Reference files are loaded relative to the skill directory under `.gemini/skills/<skill-id>/`.
+- Rules file: `.gemini/GEMINI.md`.
+- Reference files are loaded relative to the skill directory under `.agents/skills/<skill-id>/`.
+- MCP skill tools (`skill_search`, `skill_get`, `skill_validate`, `skill_get_reference`) are available when MCP is connected.