@cubis/foundry 0.3.83 → 0.3.84

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

@@ -1,72 +0,0 @@
----
-name: refactor
-description: "Improve maintainability while preserving behavior through incremental safe refactoring."
-license: MIT
-metadata:
-  author: cubis-foundry
-  route-kind: "workflow"
-  route-id: "refactor"
-  platform: "Codex"
-  command: "/refactor"
-compatibility: Codex
----
-# refactor Workflow
-# Refactor Workflow
-
-## When to use
-
-Use this when improving code structure, reducing tech debt, or modularizing without changing behavior.
-
-## Routing
-
-- Primary specialist: `@code-archaeologist`
-- Domain support: `@backend-specialist`, `@frontend-specialist`
-- Verification support: `@test-engineer`, `@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 `docs/foundation/TECH.md` first so behavior-preserving structure changes do not drift from the accepted architecture contract. Check `docs/foundation/ARCHITECTURE.md` for `## Dependency Rules` and `## Crosscutting Concerns` before restructuring.
-
-## Skill Routing
-
-- Primary skills: `static-analysis`, `legacy-modernizer`
-- Supporting skills (optional): `testing-patterns`, `system-design`, `typescript-pro`, `javascript-pro`, `python-pro`, `golang-pro`
-- Start with `static-analysis` for automated code quality assessment. Add `legacy-modernizer` for modernization patterns. Add `testing-patterns` 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: [static-analysis, legacy-modernizer]
-  supporting_skills: [testing-patterns?, 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>] | []
-```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/release/SKILL.md

@@ -1,75 +0,0 @@
----
-name: release
-description: "Prepare and execute release with rollout guardrails, verification, and rollback plan."
-license: MIT
-metadata:
-  author: cubis-foundry
-  route-kind: "workflow"
-  route-id: "release"
-  platform: "Codex"
-  command: "/release"
-compatibility: Codex
----
-# release Workflow
-# Release Workflow
-
-## When to use
-
-Use this when preparing a release, deploying to production, or managing a rollout.
-
-## Routing
-
-- Primary coordinator: `@devops-engineer`
-- Release verification: `@test-engineer`, `@validator`
-- Documentation: `@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 `docs/foundation/TECH.md` before release if the shipped changes touched architecture, scaling assumptions, or design-system rules. Check `docs/foundation/TECH.md` for `## Build And Validation` and `## CI CD Pipeline` steps to verify the release pipeline.
-
-## Skill Routing
-
-- Primary skills: `ci-cd-pipelines`, `git-workflow`
-- Supporting skills (optional): `changelog-generator`, `devops-engineer`, `sre-engineer`, `docker-kubernetes`, `observability`, `serverless-patterns`, `typescript-pro`, `javascript-pro`
-- Start with `ci-cd-pipelines` for deployment automation and `git-workflow` for release branching. Add `changelog-generator` 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: devops-engineer
-  supporting_agents: [test-engineer?, validator?, documentation-writer?]
-  primary_skills: [ci-cd-pipelines, git-workflow]
-  supporting_skills: [changelog-generator?, devops-engineer?, sre-engineer?]
-  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>] | []
-```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/security/SKILL.md

@@ -1,74 +0,0 @@
----
-name: security
-description: "Run security-focused analysis and remediation planning with exploitability-first triage."
-license: MIT
-metadata:
-  author: cubis-foundry
-  route-kind: "workflow"
-  route-id: "security"
-  platform: "Codex"
-  command: "/security"
-compatibility: Codex
----
-# security Workflow
-# 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>] | []
-```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/spec/SKILL.md

@@ -1,76 +0,0 @@
----
-name: spec
-description: "Create or refresh a Git-tracked spec pack for non-trivial work, including acceptance criteria, traceability, architecture impact, and next-route handoff."
-license: MIT
-metadata:
-  author: cubis-foundry
-  route-kind: "workflow"
-  route-id: "spec"
-  platform: "Codex"
-  command: "/spec"
-compatibility: Codex
----
-# spec Workflow
-# 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>] | []
-```

package/workflows/workflows/agent-environment-setup/platforms/codex/generated-skills/vercel/SKILL.md

@@ -1,72 +0,0 @@
----
-name: vercel
-description: "Drive Vercel implementation and operations via vercel-expert with deployment, runtime, security, and observability guardrails."
-license: MIT
-metadata:
-  author: cubis-foundry
-  route-kind: "workflow"
-  route-id: "vercel"
-  platform: "Codex"
-  command: "/vercel"
-compatibility: Codex
----
-# vercel Workflow
-# 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>] | []
-```

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/api-design/evals/assertions.md

@@ -1,53 +0,0 @@
-# API Design Eval Assertions
-
-## Eval 1: REST API Contract Design
-
-This eval tests the ability to design a RESTful API with proper resource modeling, HTTP semantics, pagination, error handling, and OpenAPI documentation for a task management system.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `GET` — Proper HTTP method usage | REST APIs must use HTTP methods with their standardized semantics. GET for safe retrieval enables caching and is idempotent. Using POST for reads breaks HTTP semantics and cache layers. |
-| 2 | contains | `cursor` — Cursor-based pagination | Offset pagination breaks when data changes between requests (duplicates, skipped items). Cursor-based pagination provides stable pages regardless of concurrent writes. |
-| 3 | contains | `application/problem+json` — RFC 9457 error format | Ad-hoc error formats require custom parsing per API. Problem Details provides a standardized structure that clients can handle generically while still including API-specific detail fields. |
-| 4 | contains | `openapi` — OpenAPI specification | A spec-first approach ensures documentation is always synchronized with implementation. OpenAPI enables code generation, testing, and SDK creation from a single source of truth. |
-| 5 | contains | `filter` — Collection filtering support | Clients must be able to retrieve subsets of collections without downloading everything. Query parameter filters reduce payload size, database load, and client-side processing. |
-
-### What a passing response looks like
-
-- Resource hierarchy: `/v1/workspaces/{id}/projects/{id}/tasks/{id}/comments/{id}`.
-- GET (list with filters), GET (by ID), POST (create), PATCH (partial update), DELETE for each resource.
-- Cursor-based pagination: `?cursor=eyJpZCI6MTIzfQ&limit=25` with `next_cursor` in response.
-- Filtering: `?status=in_progress&priority=high&assignee=user_123&due_before=2025-12-31`.
-- Error responses with `application/problem+json` content type, including `type` URI, `title`, `status`, `detail`, and `errors` array for validation failures.
-- OpenAPI 3.1 spec with `info`, `paths`, `components/schemas`, and `examples`.
-- Standard response envelope or direct resource representation with consistent field naming (camelCase).
-- Rate limit headers: `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`.
-
----
-
-## Eval 2: GraphQL Schema Design
-
-This eval tests the ability to design a GraphQL schema with Relay-style pagination, input types, union-based error handling, and DataLoader for N+1 prevention in a social content platform.
-
-### Assertions
-
-| # | Type | What it checks | Why it matters |
-|---|------|----------------|----------------|
-| 1 | contains | `Connection` — Relay-style pagination types | Relay connections provide a standardized cursor-based pagination contract that works with any GraphQL client. Custom pagination reinvents a solved problem and breaks client library expectations. |
-| 2 | contains | `input` — Dedicated mutation input types | Input types encapsulate mutation arguments into a single typed object, enabling validation, documentation, and future field additions without breaking existing mutations. |
-| 3 | contains | `DataLoader` — N+1 query prevention | Without DataLoader, resolving a list of posts with their authors generates N+1 database queries. DataLoader batches and deduplicates loader calls within a single request. |
-| 4 | contains | `union` — Union types for error modeling | Returning errors in the data layer (union of success and error types) gives clients type-safe error handling. Throwing exceptions forces clients to parse untyped error extensions. |
-| 5 | contains | `visibility` — Authorization in resolvers | Post visibility (public, followers, private) must be enforced in resolvers, not just in the client. Missing server-side authorization means private content is accessible via direct GraphQL queries. |
-
-### What a passing response looks like
-
-- Types: `User`, `Post`, `Comment`, `Reaction`, `MediaAttachment`, `Tag`.
-- Connection types: `PostConnection { edges: [PostEdge], pageInfo: PageInfo }` with `PostEdge { cursor, node }`.
-- Input types: `CreatePostInput { content, mediaIds, tagIds, visibility }`, `UpdatePostInput { content?, visibility? }`.
-- Union result types: `CreatePostResult = Post | ValidationError | AuthorizationError`.
-- Visibility enum: `enum PostVisibility { PUBLIC, FOLLOWERS, PRIVATE }`.
-- Feed query with DataLoader for batch-loading authors, reaction counts, and comment counts.
-- Resolver architecture: per-type DataLoaders instantiated per-request to avoid cross-request caching.
-- Subscription type for real-time updates: `onNewComment(postId: ID!): Comment`.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/api-design/evals/evals.json

@@ -1,68 +0,0 @@
-{
-  "evals": [
-    {
-      "name": "rest-api-contract-design",
-      "description": "Validate that the skill produces a REST API contract with proper resource modeling, HTTP method semantics, pagination, error responses, and OpenAPI documentation for a task management system.",
-      "input": "Design a REST API for a task management system with workspaces, projects, tasks, and comments. Tasks can be assigned to users, have due dates, priorities (low, medium, high, urgent), and statuses (todo, in_progress, review, done). Include endpoints for CRUD operations, task filtering and search, pagination, bulk operations, and proper error responses. Provide an OpenAPI 3.1 specification for the core endpoints.",
-      "assertions": [
-        {
-          "type": "contains",
-          "value": "GET",
-          "description": "The API must use proper HTTP methods with GET for retrieval operations, demonstrating understanding of safe and idempotent HTTP semantics."
-        },
-        {
-          "type": "contains",
-          "value": "cursor",
-          "description": "The API must implement cursor-based pagination for collection endpoints to maintain page stability when data changes between requests."
-        },
-        {
-          "type": "contains",
-          "value": "application/problem+json",
-          "description": "Error responses must follow RFC 9457 Problem Details format with structured fields (type, title, status, detail) rather than ad-hoc error structures."
-        },
-        {
-          "type": "contains",
-          "value": "openapi",
-          "description": "The specification must be a valid OpenAPI 3.x document with paths, components, and schema references demonstrating a spec-first API design approach."
-        },
-        {
-          "type": "contains",
-          "value": "filter",
-          "description": "The API must support filtering on collection endpoints (by status, priority, assignee, due date) using query parameters to enable efficient client-side data retrieval."
-        }
-      ]
-    },
-    {
-      "name": "graphql-schema-design",
-      "description": "Validate that the skill produces a GraphQL schema with proper type definitions, connection-based pagination, input types, error handling, and resolver architecture for a social content platform.",
-      "input": "Design a GraphQL schema for a social content platform with users, posts, comments, and reactions. Users can follow other users. Posts have media attachments, tags, and visibility settings (public, followers, private). Include the schema with type definitions, queries, mutations, connection-based pagination (Relay-style), input validation types, and union types for error handling. Show the resolver architecture for the feed query with DataLoader for N+1 prevention.",
-      "assertions": [
-        {
-          "type": "contains",
-          "value": "Connection",
-          "description": "The schema must implement Relay-style connection types with edges and pageInfo for cursor-based pagination of collections (PostConnection, CommentConnection)."
-        },
-        {
-          "type": "contains",
-          "value": "input",
-          "description": "Mutations must use dedicated input types (CreatePostInput, UpdatePostInput) to encapsulate mutation arguments rather than passing individual scalar arguments."
-        },
-        {
-          "type": "contains",
-          "value": "DataLoader",
-          "description": "The resolver architecture must use DataLoader or an equivalent batching mechanism to prevent N+1 query problems when resolving nested relationships."
-        },
-        {
-          "type": "contains",
-          "value": "union",
-          "description": "The schema must use union types or result types (e.g., CreatePostResult = Post | ValidationError) to model operation outcomes that include both success and typed error cases."
-        },
-        {
-          "type": "contains",
-          "value": "visibility",
-          "description": "The schema must model the visibility enum (PUBLIC, FOLLOWERS, PRIVATE) and the resolver must enforce authorization based on the viewer's relationship to the post author."
-        }
-      ]
-    }
-  ]
-}

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/architecture-doc/evals/assertions.md

@@ -1,49 +0,0 @@
-# Architecture Documentation Eval Assertions
-
-## Eval 1: C4 Diagram Generation
-
-This eval tests the ability to produce correct C4 model diagrams at System Context and Container levels with proper notation, relationships, and technology labels.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `Person` — External actor identification        | C4 requires human actors to be modeled as Person elements. Mixing users into system boxes obscures who interacts with the system. |
-| 2 | contains | `System_Boundary` — Boundary delineation        | Container diagrams must show what is inside vs outside the system. Without boundaries, readers cannot tell owned from external. |
-| 3 | contains | `Container` — Deployable unit modeling          | Each independently deployable unit must be a Container with a technology label. Lumping multiple services into one box hides deployment complexity. |
-| 4 | contains | `Rel` — Explicit relationship definitions       | Connections between elements need labeled relationships describing protocol and purpose. Lines without labels are meaningless. |
-| 5 | contains | `System_Ext` — External system identification   | Third-party integrations (Stripe, SendGrid) must be System_Ext to make integration boundaries and vendor dependencies visible. |
-
-### What a passing response looks like
-
-- A System Context diagram showing three Person types (end-user, admin, API consumer) and the analytics platform as a central System element.
-- External systems (Stripe, SendGrid) shown as System_Ext with labeled relationships.
-- A Container diagram within a System_Boundary showing: React SPA, Node.js/Express API, PostgreSQL database, Redis cache, Bull job processor.
-- Each Container labeled with its technology stack (e.g., "Container(api, 'API Server', 'Node.js / Express')").
-- Relationships between containers showing protocols (HTTPS, TCP, Redis protocol) and data flow direction.
-- A diagram key or legend explaining the notation.
-
----
-
-## Eval 2: ADR Writing
-
-This eval tests the ability to produce a well-structured Architecture Decision Record with context, alternatives analysis, and consequence documentation.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `## Status` — Decision lifecycle tracking       | ADRs without status markers cannot be distinguished as active, superseded, or deprecated. Teams act on stale decisions. |
-| 2 | contains | `## Context` — Decision drivers documented      | The context section captures the forces and constraints that drove the decision. Without it, future readers cannot evaluate if the decision still applies. |
-| 3 | contains | `## Decision` — Clear statement of choice       | The decision must be stated explicitly. ADRs that discuss trade-offs without concluding leave readers uncertain about what was actually chosen. |
-| 4 | contains | `## Consequences` — Impact documentation        | Both positive and negative consequences must be recorded so teams can monitor for predicted risks and verify expected benefits. |
-| 5 | contains | `MongoDB` — Alternative analysis                | The ADR must discuss rejected alternatives with specific reasoning. One-sided ADRs that only describe the winner lack the trade-off analysis that gives ADRs their value. |
-
-### What a passing response looks like
-
-- A numbered ADR title (e.g., "ADR-001: Use PostgreSQL as Primary Database").
-- Status set to "Accepted" (or "Proposed" if presented as a draft).
-- Context section explaining: multi-tenant SaaS, strong relational data, flexible form submissions, team's PostgreSQL experience.
-- Discussion of both PostgreSQL (with JSONB for flexible schemas) and MongoDB (native document model) with specific trade-offs.
-- Decision section clearly stating the chosen option with brief rationale.
-- Consequences section listing: benefits (team familiarity, ACID transactions, JSONB flexibility), risks (JSONB query complexity, potential schema rigidity), and mitigations.

package/workflows/workflows/agent-environment-setup/platforms/codex/skills/architecture-doc/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "c4-diagram-generation",
-    "description": "Validate that the skill produces correct C4 model diagrams at Context and Container levels with proper notation, relationships, and technology labels.",
-    "input": "Create C4 model diagrams (System Context and Container level) for a SaaS analytics platform. The system has: a React single-page application, a REST API built with Node.js/Express, a PostgreSQL database, a Redis cache, a background job processor (Bull/Redis), and integrations with Stripe for billing and SendGrid for email. Users include end-users (dashboard viewers), admin users, and an external data ingestion API consumer. Provide the diagrams in Mermaid syntax.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "Person",
-        "description": "The System Context diagram must identify external actors as Person elements to distinguish human users from system integrations."
-      },
-      {
-        "type": "contains",
-        "value": "System_Boundary",
-        "description": "The Container diagram must use System_Boundary to clearly delineate which containers are inside the system vs external dependencies."
-      },
-      {
-        "type": "contains",
-        "value": "Container",
-        "description": "Each deployable unit (SPA, API, database, cache, job processor) must be modeled as a Container element with technology labels."
-      },
-      {
-        "type": "contains",
-        "value": "Rel",
-        "description": "Relationships between elements must be explicitly defined with Rel statements that describe the purpose and protocol of each connection."
-      },
-      {
-        "type": "contains",
-        "value": "System_Ext",
-        "description": "External systems (Stripe, SendGrid) must be modeled as System_Ext to distinguish them from internal containers and make integration boundaries visible."
-      }
-    ]
-  },
-  {
-    "name": "adr-writing",
-    "description": "Validate that the skill produces a well-structured Architecture Decision Record with proper sections, alternatives analysis, and consequence documentation.",
-    "input": "Write an Architecture Decision Record for the following decision: The team is choosing between PostgreSQL and MongoDB as the primary database for a multi-tenant SaaS application. The application has strong relational data (users, organizations, billing) but also needs to store flexible form submissions with varying schemas. The team has more PostgreSQL experience. Write the ADR in the standard format.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "## Status",
-        "description": "The ADR must include a Status section (Proposed, Accepted, Deprecated, or Superseded) to indicate the decision lifecycle stage."
-      },
-      {
-        "type": "contains",
-        "value": "## Context",
-        "description": "The ADR must include a Context section explaining the forces, constraints, and business requirements that drive the decision."
-      },
-      {
-        "type": "contains",
-        "value": "## Decision",
-        "description": "The ADR must include a Decision section that clearly states what was decided, not just what was considered."
-      },
-      {
-        "type": "contains",
-        "value": "## Consequences",
-        "description": "The ADR must include a Consequences section documenting both positive and negative outcomes of the decision."
-      },
-      {
-        "type": "contains",
-        "value": "MongoDB",
-        "description": "The ADR must discuss MongoDB as a considered alternative with specific trade-offs evaluated, not just mention the chosen option."
-      }
-    ]
-  }
-]