@cubis/foundry 0.3.81 → 0.3.83

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

@@ -1,69 +0,0 @@
----
-command: "/security"
-description: "Run security-focused analysis and remediation planning with exploitability-first triage."
-triggers: ["security", "vulnerability", "owasp", "auth", "hardening"]
----
-
-# Security Workflow
-
-## When to use
-
-Use this for security audits, vulnerability assessments, threat modeling, or security-focused code review.
-
-## Routing
-
-- Primary specialist: `the security-auditor posture`
-- Offensive assessment: `the penetration-tester posture`
-- Domain support: `the backend-specialist posture`, `the frontend-specialist posture`
-- Verification support: `the validator posture`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach the security scope, threat model, compliance requirements, and relevant code paths.
-
-## Skill Routing
-
-- Primary skills: `owasp-security-review`, `owasp-security-review`
-- Supporting skills (optional): `owasp-security-review`, `code-review`, `api-design`, `api-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `rust-best-practices`
-- Start with `owasp-security-review` for OWASP methodology and threat modeling. Add `owasp-security-review` for authentication/authorization review. Add `owasp-security-review` for dependency scanning and CVE triage.
-
-## Workflow steps
-
-1. Define security scope and threat model.
-2. Map attack surface and identify input vectors.
-3. Assess code against OWASP Top 10 and relevant standards.
-4. Triage findings by exploitability (reachability × controllability × impact).
-5. Produce remediation plan with prioritized fixes.
-6. Verify remediations do not introduce new vulnerabilities.
-
-## Verification
-
-- All critical and high findings have remediation plans.
-- Remediation code reviewed for correctness.
-- No new vulnerabilities introduced by fixes.
-- Compliance requirements addressed if applicable.
-
-## Output Contract
-
-```yaml
-SECURITY_WORKFLOW_RESULT:
-  primary_agent: security-auditor
-  supporting_agents: [penetration-tester?, backend-specialist?, frontend-specialist?, validator?]
-  primary_skills: [owasp-security-review, owasp-security-review]
-  supporting_skills: [owasp-security-review?, code-review?, api-design?]
-  threat_model:
-    assets: [<string>]
-    threats: [<string>]
-    attack_surface: [<string>]
-  findings:
-    - severity: critical | high | medium | low
-      category: <owasp-category>
-      exploitability: <string>
-      remediation: <string>
-  compliance_notes: [<string>] | []
-  remaining_risks: [<string>] | []
-  follow_up_items: [<string>] | []
-```
-
-> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.

package/workflows/workflows/agent-environment-setup/platforms/gemini/workflows/spec.md

@@ -1,81 +0,0 @@
----
-command: "/spec"
-description: "Create or refresh a Git-tracked spec pack for non-trivial work, including acceptance criteria, traceability, architecture impact, and next-route handoff."
-triggers:
-  [
-    "spec",
-    "sdd",
-    "source of truth",
-    "traceability",
-    "acceptance criteria",
-    "openspec",
-    "requirements",
-    "architecture impact",
-  ]
----
-
-# 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: `the project-planner posture`
-- Traceability and requirements support: `the researcher posture`
-- Cross-domain coordination: `the orchestrator posture`
-- Documentation and structure support: `the documentation-writer posture`
-
-## 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`.
-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>] | []
-```
-
-> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.

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

@@ -1,66 +0,0 @@
----
-command: "/test"
-description: "Design and execute verification strategy aligned to user risk, release confidence, and regression evidence."
-triggers: ["test", "verify", "coverage", "qa", "regression"]
----
-
-# Test Workflow
-
-## When to use
-
-Use this when writing new tests, improving coverage, debugging test failures, or designing a testing strategy.
-
-## Routing
-
-- Primary specialist: `the test-engineer posture`
-- Automation support: `the qa-automation-engineer posture`
-- Domain support: `the backend-specialist posture`, `the frontend-specialist posture`
-- Verification support: `the validator posture`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach the code under test, existing test files, coverage reports, and any failing test output.
-
-## Skill Routing
-
-- Primary skills: `unit-testing`, `integration-testing`
-- Supporting skills (optional): `playwright-interactive`, `observability`, `systematic-debugging`, `code-review`, `code-review`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`, `java-best-practices`
-- Start with `unit-testing` for test strategy and architecture. Add `integration-testing` for implementation. Add `playwright-interactive` for E2E automation. Add `observability` for testing error states.
-
-## Workflow steps
-
-1. Assess current test coverage and identify gaps.
-2. Design test strategy (which layers, what to test, what to skip).
-3. Implement tests with clear arrange/act/assert structure.
-4. Run tests and verify they pass.
-5. Review coverage improvement and remaining gaps.
-
-## Verification
-
-- All new tests pass reliably (no flakiness).
-- Tests cover the identified risk areas.
-- Coverage metrics improved or maintained.
-- Test naming clearly describes the scenario being verified.
-
-## Output Contract
-
-```yaml
-TEST_WORKFLOW_RESULT:
-  primary_agent: test-engineer
-  supporting_agents: [qa-automation-engineer?, backend-specialist?, frontend-specialist?, validator?]
-  primary_skills: [unit-testing, integration-testing]
-  supporting_skills: [playwright-interactive?, observability?, systematic-debugging?]
-  test_strategy:
-    unit: <number of tests>
-    integration: <number of tests>
-    e2e: <number of tests>
-  tests_written: [<test-file-path>]
-  coverage:
-    before: <percentage or description>
-    after: <percentage or description>
-  gaps_remaining: [<string>] | []
-  follow_up_items: [<string>] | []
-```
-
-> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.

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

@@ -1,76 +0,0 @@
----
-command: "/vercel"
-description: "Drive Vercel implementation and operations via vercel-expert with deployment, runtime, security, and observability guardrails."
-triggers:
-  [
-    "vercel",
-    "deployment",
-    "preview",
-    "edge",
-    "functions",
-    "domains",
-    "vercel cli",
-  ]
----
-
-# Vercel Workflow
-
-## When to use
-
-Use this for Vercel-specific deployment, configuration, runtime optimization, or platform operations.
-
-## Routing
-
-- Primary specialist: `the vercel-expert posture`
-- Infrastructure support: `the ci-cd-pipeline posture`
-- Verification support: `the test-engineer posture`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach the Vercel project config, deployment target, and any specific Vercel feature requirements.
-
-## Skill Routing
-
-- Primary skills: `nextjs`, `ci-cd-pipeline`
-- Supporting skills (optional): `performance-testing`, `react`, `frontend-design`, `javascript-best-practices`, `typescript-best-practices`, `javascript-best-practices`
-- Start with `nextjs` for Next.js on Vercel and `ci-cd-pipeline` for runtime behavior. Add `performance-testing` for performance optimization.
-
-## Workflow steps
-
-1. Assess deployment requirements and runtime selection (Edge vs Serverless vs Static).
-2. Configure project settings and environment variables.
-3. Set up deployment pipeline with preview deployments.
-4. Verify deployment health and performance.
-5. Configure monitoring and alerting.
-
-## Verification
-
-- Deployment successful with no build errors.
-- Runtime selection appropriate for each route.
-- Environment variables correctly configured per environment.
-- Preview deployments working for PRs.
-- Performance metrics within acceptable ranges.
-
-## Output Contract
-
-```yaml
-VERCEL_WORKFLOW_RESULT:
-  primary_agent: vercel-expert
-  supporting_agents: [ci-cd-pipeline?, test-engineer?]
-  primary_skills: [nextjs, ci-cd-pipeline]
-  supporting_skills: [performance-testing?, react?]
-  deployment:
-    project: <string>
-    runtime: <edge | serverless | static>
-    environment: <development | preview | production>
-    status: success | failure
-  configuration:
-    env_vars: [<string>]
-    domains: [<string>]
-    caching: <string>
-  monitoring: <string>
-  follow_up_items: [<string>] | []
-```
-
-> **Gemini note:** Commands route into workflow files under `.gemini/workflows/`. Specialists are inline postures coordinated through GEMINI.md guidance, not separate agent artifacts.