@cubis/foundry 0.3.81 → 0.3.83

package/workflows/workflows/agent-environment-setup/platforms/antigravity/workflows/onboard.md

@@ -1,72 +0,0 @@
----
-command: "/onboard"
-description: "Survey an unfamiliar codebase, map its architecture, identify patterns and conventions, and produce a structured orientation report for new contributors."
-triggers:
-  [
-    "onboard",
-    "explore codebase",
-    "understand project",
-    "new to this repo",
-    "codebase survey",
-  ]
----
-
-# Onboard Workflow
-
-## When to use
-
-Use this when joining a new project, exploring an unfamiliar codebase, or preparing orientation material.
-
-## Routing
-
-- Primary specialist: `.agent/agents/researcher`
-- Architecture mapping: `.agent/agents/code-archaeologist`
-- Domain specialists as needed: `.agent/agents/backend-specialist`, `.agent/agents/frontend-specialist`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Provide the repo URL, focus areas, and any specific questions to answer during onboarding.
-- Read `ENGINEERING_RULES.md` first and `TECH.md` next when present so onboarding distinguishes the intended contract from current implementation reality.
-
-## Skill Routing
-
-- Primary skills: `deep-research`, `system-design`
-- Supporting skills (optional): `system-design`, `database-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`
-- Start with `deep-research` for systematic exploration and `system-design` for architecture mapping. Add `system-design` for undocumented systems. Prefer repo evidence first; use external sources only when setup or dependency behavior cannot be confirmed locally.
-
-## Workflow steps
-
-1. Survey the project structure — directories, entry points, and configuration.
-2. Map the architecture — components, data flow, and integration points.
-3. Identify patterns — naming conventions, design patterns, and coding standards.
-4. Document dependencies — external services, databases, and APIs.
-5. Produce orientation report with development setup instructions.
-
-## Verification
-
-- All major components identified and documented.
-- Development setup instructions verified (can be followed by a newcomer).
-- Architecture diagram or description covers main data flows.
-- Key patterns and conventions explicitly documented.
-
-## Output Contract
-
-```yaml
-ONBOARD_WORKFLOW_RESULT:
-  primary_agent: researcher
-  supporting_agents: [code-archaeologist?, backend-specialist?, frontend-specialist?]
-  primary_skills: [deep-research, system-design]
-  supporting_skills: [system-design?, database-design?]
-  project_overview:
-    purpose: <string>
-    tech_stack: [<string>]
-    architecture: <string>
-  key_components: [<string>]
-  patterns_and_conventions: [<string>]
-  development_setup: [<step>]
-  dependencies: [<string>]
-  knowledge_gaps: [<string>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/workflows/refactor.md

@@ -1,67 +0,0 @@
----
-command: "/refactor"
-description: "Improve maintainability while preserving behavior through incremental safe refactoring."
-triggers: ["refactor", "cleanup", "maintainability", "debt", "modularize"]
----
-
-# Refactor Workflow
-
-## When to use
-
-Use this when improving code structure, reducing tech debt, or modularizing without changing behavior.
-
-## Routing
-
-- Primary specialist: `.agent/agents/code-archaeologist`
-- Domain support: `.agent/agents/backend-specialist`, `.agent/agents/frontend-specialist`
-- Verification support: `.agent/agents/test-engineer`, `.agent/agents/validator`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach the target code, pain points, and any constraints on what can change.
-- Read `ENGINEERING_RULES.md` and `TECH.md` first so behavior-preserving structure changes do not drift from the accepted architecture contract.
-
-## Skill Routing
-
-- Primary skills: `code-review`, `system-design`
-- Supporting skills (optional): `unit-testing`, `system-design`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`
-- Start with `code-review` for automated code quality assessment. Add `system-design` for modernization patterns. Add `unit-testing` when refactoring needs test coverage to proceed safely.
-
-## Workflow steps
-
-1. Map the current structure and identify refactoring targets.
-2. Ensure adequate test coverage before modifying (add tests if needed).
-3. Apply one refactoring at a time with behavior preservation.
-4. Verify behavior unchanged after each step.
-5. Document the improved structure and any conventions established.
-6. Set `doc_impact` when the refactor changes project structure, module boundaries, or design-system conventions.
-
-## Verification
-
-- All existing tests pass after each refactoring step.
-- No behavioral changes introduced (unless explicitly intended).
-- Code quality metrics improved (complexity, coupling, cohesion).
-- New tests added for any gaps discovered during refactoring.
-
-## Output Contract
-
-```yaml
-REFACTOR_WORKFLOW_RESULT:
-  primary_agent: code-archaeologist
-  supporting_agents: [backend-specialist?, frontend-specialist?, test-engineer?, validator?]
-  primary_skills: [code-review, system-design]
-  supporting_skills: [unit-testing?, system-design?]
-  refactoring_summary:
-    targets: [<string>]
-    changes_applied: [<string>]
-    behavior_preserved: true | false
-  quality_improvement:
-    complexity_before: <string>
-    complexity_after: <string>
-  doc_impact: none | tech | rules | both
-  tests_added: [<test-file-path>] | []
-  follow_up_items: [<string>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/workflows/release.md

@@ -1,70 +0,0 @@
----
-command: "/release"
-description: "Prepare and execute release with rollout guardrails, verification, and rollback plan."
-triggers: ["release", "deploy", "rollout", "ship", "go-live"]
----
-
-# Release Workflow
-
-## When to use
-
-Use this when preparing a release, deploying to production, or managing a rollout.
-
-## Routing
-
-- Primary coordinator: `.agent/agents/ci-cd-pipeline`
-- Release verification: `.agent/agents/test-engineer`, `.agent/agents/validator`
-- Documentation: `.agent/agents/documentation-writer`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach the release scope, version number, changelog draft, and deployment target.
-- Read `ENGINEERING_RULES.md` and `TECH.md` before release if the shipped changes touched architecture, scaling assumptions, or design-system rules.
-
-## Skill Routing
-
-- Primary skills: `ci-cd-pipeline`, `git-workflow`
-- Supporting skills (optional): `tech-doc`, `ci-cd-pipeline`, `observability`, `kubernetes-deploy`, `observability`, `ci-cd-pipeline`, `typescript-best-practices`, `javascript-best-practices`
-- Start with `ci-cd-pipeline` for deployment automation and `git-workflow` for release branching. Add `tech-doc` for release notes.
-
-## Workflow steps
-
-1. Finalize scope — confirm all changes are merged and tested.
-2. Generate changelog and release notes.
-3. Prepare deployment artifacts and configuration.
-4. Execute staged rollout with health checks at each stage.
-5. Verify production health post-deployment.
-6. Document rollback procedure and post-release status.
-7. Set `doc_impact` if the release includes architecture-affecting work that should refresh the managed docs.
-
-## Verification
-
-- All tests pass on release branch/tag.
-- Changelog accurately reflects changes.
-- Deployment artifacts built and verified.
-- Production health confirmed after rollout.
-- Rollback procedure tested or documented.
-
-## Output Contract
-
-```yaml
-RELEASE_WORKFLOW_RESULT:
-  primary_agent: ci-cd-pipeline
-  supporting_agents: [test-engineer?, validator?, documentation-writer?]
-  primary_skills: [ci-cd-pipeline, git-workflow]
-  supporting_skills: [tech-doc?, ci-cd-pipeline?, observability?]
-  release:
-    version: <string>
-    changelog: <string>
-    artifacts: [<string>]
-  deployment:
-    strategy: <staged | canary | blue-green | direct>
-    stages_completed: [<string>]
-    health_checks: [<string>]
-  rollback_plan: <string>
-  doc_impact: none | tech | rules | both
-  follow_up_items: [<string>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/workflows/review.md

@@ -1,66 +0,0 @@
----
-command: "/review"
-description: "Run a strict review for bugs, regressions, accessibility issues, security risk, and code quality with prioritized findings."
-triggers: ["review", "audit", "pr", "quality", "security review"]
----
-
-# Review Workflow
-
-## When to use
-
-Use this for code review, PR review, or quality audit of existing code changes.
-
-## Routing
-
-- Primary specialist: `.agent/agents/frontend-specialist` (for frontend code) or `.agent/agents/backend-specialist` (for backend code)
-- Security review: `.agent/agents/security-auditor`
-- Quality validation: `.agent/agents/validator`
-- Verification support: `.agent/agents/test-engineer`
-
-## Context notes
-
-- This workflow file, active platform rules, and selected agents or skills guide execution.
-- Attach the PR diff, changed files, or specific code paths to review.
-
-## Skill Routing
-
-- Primary skills: `code-review`, `code-review`, `unit-testing`
-- Supporting skills (optional): `owasp-security-review`, `owasp-security-review`, `performance-testing`, `react`, `nextjs`, `typescript-best-practices`, `javascript-best-practices`, `python-best-practices`, `golang-best-practices`
-- Start with `code-review` for UI code or `code-review` for backend code. Add `unit-testing` when evaluating test quality. Add `owasp-security-review` for security-sensitive changes.
-
-## Workflow steps
-
-1. Understand the intent and scope of the changes.
-2. Review for correctness — logic bugs, edge cases, and regressions.
-3. Review for security — input validation, auth, secrets exposure.
-4. Review for accessibility — WCAG compliance, keyboard navigation, screen readers.
-5. Review for performance — unnecessary re-renders, N+1 queries, bundle impact.
-6. Prioritize findings by severity and provide actionable feedback.
-
-## Verification
-
-- Each finding has severity, location, and suggested fix.
-- Findings prioritized: critical > high > medium > low.
-- Positive observations noted alongside issues.
-- Reviewed against codebase conventions.
-
-## Output Contract
-
-```yaml
-REVIEW_WORKFLOW_RESULT:
-  primary_agent: <frontend-specialist | backend-specialist>
-  supporting_agents: [security-auditor?, validator?, test-engineer?]
-  primary_skills: [code-review?, code-review?, unit-testing?]
-  supporting_skills: [owasp-security-review?, owasp-security-review?, performance-testing?]
-  findings:
-    - severity: critical | high | medium | low
-      category: correctness | security | accessibility | performance | style
-      location: <file:line>
-      description: <string>
-      suggestion: <string>
-  overall_assessment: approve | request_changes | reject
-  positive_observations: [<string>] | []
-  follow_up_items: [<string>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/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: `.agent/agents/security-auditor`
-- Offensive assessment: `.agent/agents/penetration-tester`
-- Domain support: `.agent/agents/backend-specialist`, `.agent/agents/frontend-specialist`
-- Verification support: `.agent/agents/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: `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>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/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: `.agent/agents/test-engineer`
-- Automation support: `.agent/agents/qa-automation-engineer`
-- Domain support: `.agent/agents/backend-specialist`, `.agent/agents/frontend-specialist`
-- Verification support: `.agent/agents/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: `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>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/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: `.agent/agents/vercel-expert`
-- Infrastructure support: `.agent/agents/ci-cd-pipeline`
-- Verification support: `.agent/agents/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`, `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>] | []
-```
-
-> **Antigravity note:** Use Agent Manager for parallel agent coordination. Workflow files are stored under `.agent/workflows/`.

package/workflows/workflows/agent-environment-setup/platforms/claude/workflows/architecture.md

@@ -1,88 +0,0 @@
----
-command: "/architecture"
-description: "Refresh the core project foundation docs in docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md, and ADR scaffolds with explicit structure, product context, testing, and flow guidance."
-triggers:
-  [
-    "architecture",
-    "design system",
-    "adr",
-    "clean architecture",
-    "system map",
-    "app structure",
-    "technical governance",
-    "flow diagram",
-  ]
----
-
-# Architecture Workflow
-
-## When to use
-
-Use this when the task is to declare, refresh, or validate the project backbone docs, especially after structure changes, scale changes, design-system changes, migrations, product-direction shifts, or major feature additions.
-
-## Routing
-
-- Primary coordinator: `@project-planner`
-- Documentation support: `@documentation-writer`
-- Research support: `@researcher`
-- Domain validation: `@backend-specialist`, `@frontend-specialist`, `@database-architect`
-
-## Skill Routing
-
-- Primary skills: `architecture-doc`, `system-design`, `tech-doc`, `frontend-design`
-- Supporting skills (optional): `api-design`, `database-design`, `sadd`, `deep-research`
-- Load the four primary skills directly for this workflow. Add `api-design` or `database-design` when service or data boundaries are central, `sadd` when tying the architecture update to an active spec pack, and `deep-research` only when outside evidence is required.
-
-## Workflow steps
-
-1. Inspect the repo first and derive the current product surfaces, architecture style, module boundaries, technical constraints, and testing strategy from the codebase itself.
-2. Read concrete repo anchors before drafting: root README/manifests, main entrypoints, the primary app roots, existing `docs/specs/`, and representative source folders for each major surface.
-3. Read `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md` in that order if they exist.
-4. Update the managed foundation sections in `docs/foundation/PRODUCT.md`, `docs/foundation/ARCHITECTURE.md`, and `docs/foundation/TECH.md`.
-5. Make `docs/foundation/ARCHITECTURE.md` explicitly state the architecture type in use and include a folder-structure guide for the important apps/packages/directories.
-6. Add or refresh Mermaid diagrams and flow narratives inside `docs/foundation/ARCHITECTURE.md` or `docs/foundation/TECH.md` when they clarify system behavior.
-7. Seed or refresh `docs/foundation/adr/README.md` and `docs/foundation/adr/0000-template.md`, and keep ADR linkage explicit when decisions should be durable.
-8. Record whether the update was driven by a broader spec and whether future implementation must follow newly declared structure or product constraints.
-
-## Context notes
-
-- This workflow is route-fixed and skill-fixed: do not start with `route_resolve` or `skill_search`.
-- `docs/foundation/PRODUCT.md` captures intent, `docs/foundation/ARCHITECTURE.md` captures accepted structure, and `docs/foundation/TECH.md` is the developer-facing technical map. Keep them aligned but not redundant.
-- Favor a lean arc42/C4 style: clear scope, boundaries, building blocks, runtime flows, deployment/testing notes, and only diagrams that add real value.
-- `docs/foundation/ARCHITECTURE.md` should guide future contributors, not just describe the system. Be explicit about architecture style and folder ownership.
-- Prefer stable section headings over ad hoc prose so future refreshes stay clean and easy to diff.
-- Preserve manual content outside the managed foundation sections.
-- Mark non-applicable sections explicitly instead of silently omitting them.
-
-## Verification
-
-- Managed foundation sections exist in the target docs under `docs/foundation/`.
-- Product intent, architecture style, dependency rules, and technical guidance are explicit.
-- `docs/foundation/ARCHITECTURE.md` or `docs/foundation/TECH.md` includes flow text and at least one Mermaid diagram when the repo has meaningful flow complexity.
-- The update records `doc_impact` and whether future feature work must refresh the docs again.
-
-## Output Contract
-
-```yaml
-ARCHITECTURE_WORKFLOW_RESULT:
-  primary_agent: project-planner
-  supporting_agents: [documentation-writer?, researcher?, backend-specialist?, frontend-specialist?, database-architect?]
-  primary_skills: [architecture-doc, system-design, tech-doc, frontend-design]
-  supporting_skills: [api-design?, database-design?, sadd?, deep-research?]
-  managed_targets:
-    product_doc: docs/foundation/PRODUCT.md
-    architecture_doc: docs/foundation/ARCHITECTURE.md
-    tech_doc: docs/foundation/TECH.md
-    adr_dir: docs/foundation/adr
-  files_updated: [docs/foundation/PRODUCT.md, docs/foundation/ARCHITECTURE.md, docs/foundation/TECH.md]
-  architecture_contract:
-    style: <string>
-    dependency_rules: [<string>]
-    design_system_source: <string>
-  technical_snapshot:
-    topology: [<string>]
-    flows: [<string>]
-    diagrams: [<string>] | []
-  doc_impact: rules | tech | both
-  next_actions: [<string>] | []
-```

package/workflows/workflows/agent-environment-setup/platforms/codex/agents/backend-specialist.md

@@ -1,81 +0,0 @@
----
-name: backend-specialist
-description: Backend specialist for API contracts, service logic, schema-aware backend changes, auth-sensitive implementation, payment integrations, and serverless architecture. Triggers on backend, api, endpoint, route, middleware, database, migration, auth, jwt, oauth, oidc, passkey, rbac, session, tenant, secrets, payments, stripe, serverless.
-tools: Read, Grep, Glob, Bash, Edit, Write
-model: inherit
-maxTurns: 25
-skills: api-design, system-design, owasp-security-review, database-design, drizzle-orm, microservices-design, javascript-best-practices, nestjs, fastapi, stripe-integration, ci-cd-pipeline, frontend-design, typescript-best-practices, python-best-practices, golang-best-practices, java-best-practices, csharp-best-practices, kotlin-best-practices, rust-best-practices, php-best-practices
-handoffs:
-  - agent: "test-engineer"
-    title: "Test Backend"
-  - agent: "database-architect"
-    title: "Review Schema"
----
-
-# Backend Specialist
-
-Build backend systems that stay correct under production pressure.
-
-## Skill Loading Contract
-
-- Do not call `skill_search` for any skill in the pre-declared list when the task clearly falls into that domain.
-- Load one primary skill first based on the dominant concern:
-  - `api-design` for API contract shape, versioning, or endpoint design
-  - `api-design` for REST/RPC conventions and HTTP semantics
-  - `owasp-security-review` for authentication, authorization, session, RBAC, or SSO flows
-  - `database-design` for schema design, query optimization, or migration planning
-  - `nestjs` for NestJS-specific module, provider, or decorator patterns
-  - `fastapi` for FastAPI route, dependency injection, or Pydantic model patterns
-  - `api-design` for GraphQL schema, resolver, or subscription design
-  - `microservices-design` for service boundaries, event-driven patterns, or distributed systems
-  - `stripe-integration` for payment processing, subscription management, or webhook handling
-  - `ci-cd-pipeline` for Lambda, Edge Functions, cold starts, or serverless architecture
-  - `frontend-design` for internationalization of backend responses, locale-aware data
-- Add one supporting skill only when the task genuinely crosses concerns.
-- Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed by the current step.
-
-## Skill References
-
-Load on demand. Do not preload all references.
-
-| File                      | Load when                                                                    |
-| ------------------------- | ---------------------------------------------------------------------------- |
-| `api-design`            | Designing new API contracts, versioning, or endpoint shape.                  |
-| `api-design`            | REST/RPC conventions, HTTP status codes, or pagination patterns.             |
-| `owasp-security-review`          | Auth flows, token management, session design, or access control.             |
-| `database-design`         | Schema design, query optimization, or migration strategy.                    |
-| `nestjs`           | NestJS modules, providers, guards, interceptors, or decorators.              |
-| `fastapi`          | FastAPI routes, middleware, Pydantic models, or async patterns.              |
-| `api-design`       | GraphQL schema design, resolvers, or subscription patterns.                  |
-| `microservices-design` | Service boundaries, event-driven architecture, or distributed transactions.  |
-| `stripe-integration`   | Payment processing, subscriptions, webhooks, or Stripe SDK usage.            |
-| `ci-cd-pipeline`     | Lambda architecture, cold starts, Edge Functions, or serverless constraints. |
-| `frontend-design`       | Locale-aware responses, pluralization, or internationalization patterns.     |
-
-## Operating Stance
-
-- Prefer explicit contracts over implicit coupling.
-- Treat auth as a first-class concern, not an afterthought.
-- Design for observability: structured logging, correlation IDs, and clear error responses.
-- Keep database access behind a data-access layer; never scatter raw queries across handlers.
-- Validate at boundaries, trust within boundaries.
-- Prefer idempotent operations for anything that touches external state.
-
-## Decision Frameworks
-
-| When choosing... | Prefer                        | Because                                    |
-| ---------------- | ----------------------------- | ------------------------------------------ |
-| API style        | REST for CRUD, GraphQL for UI | Match consumption pattern to client needs  |
-| Auth approach    | JWT + refresh for SPAs        | Stateless scaling with secure rotation     |
-| Database access  | ORM with raw escape hatch     | Safety by default, performance when needed |
-| Error responses  | Structured error envelope     | Machine-parseable, debuggable, consistent  |
-| Background work  | Queue-based with dead-letter  | Fault tolerance and retry isolation        |
-
-## Output Expectations
-
-- Explain the main architecture decision in concrete terms.
-- Call out any security, performance, or data-integrity risk left behind.
-- Run focused checks when code changes land.
-- Note any API contract or schema changes that affect consumers.
-
-> **Codex note:** Prefer native Codex delegation when the host exposes it. If delegation is unavailable, switch specialist postures inline and preserve the same scope and verification contract.