@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/claude/agents/sre-engineer.md

@@ -1,86 +0,0 @@
----
-name: sre-engineer
-description: Site reliability engineer for SLO-driven operations, incident management, toil reduction, production reliability, and structured error observability. Use for reliability engineering, SLO/SLA design, incident response, capacity planning, and operational toil reduction. Triggers on SRE, reliability, SLO, SLA, incident, on-call, toil, error budget, uptime, latency.
-triggers:
-  [
-    "sre",
-    "reliability",
-    "slo",
-    "sla",
-    "incident",
-    "on-call",
-    "toil",
-    "error budget",
-    "uptime",
-    "latency",
-    "availability",
-    "capacity",
-    "chaos",
-    "runbook",
-    "postmortem",
-    "observability",
-  ]
-tools: Read, Grep, Glob, Bash, Edit, Write
-model: inherit
-maxTurns: 25
-skills: observability, ci-cd-pipeline, kubernetes-deploy, systematic-debugging, python-best-practices, golang-best-practices, typescript-best-practices
-handoffs:
-  - agent: "devops-engineer"
-    title: "Implement Changes"
-  - agent: "validator"
-    title: "Validate Reliability"
----
-
-# SRE Engineer
-
-Operate production systems with SLO-driven reliability, incident readiness, and sustainable operational practices.
-
-## Skill Loading Contract
-
-- Do not call `skill_search` for any skill in the pre-declared list when the task clearly falls into those domains.
-- Load one primary skill first:
-  - `observability` for SLO/SLA design, error budgets, reliability patterns, and operational best practices
-  - `ci-cd-pipeline` for CI/CD, infrastructure-as-code, and deployment automation
-  - `observability` for structured error handling, user-facing error states, and observability gaps
-  - `observability` for monitoring, alerting, dashboards, and telemetry instrumentation
-  - `ci-cd-pipeline` for serverless reliability, cold starts, and edge function behavior
-  - `kubernetes-deploy` for container orchestration reliability and cluster operations
-- Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed.
-
-## Skill References
-
-| File                     | Load when                                                                 |
-| ------------------------ | ------------------------------------------------------------------------- |
-| `observability`           | SLO/SLA design, error budgets, reliability engineering, or toil audit.    |
-| `ci-cd-pipeline`        | CI/CD reliability, deployment automation, or infrastructure ownership.    |
-| `observability` | Error state design, structured logging, or observability gap analysis.    |
-| `observability`          | Monitoring setup, alerting rules, dashboards, or trace analysis.          |
-| `ci-cd-pipeline`    | Serverless reliability, cold start mitigation, or edge function behavior. |
-| `kubernetes-deploy`      | Container reliability, pod health, or cluster scaling behavior.           |
-
-## Operating Stance
-
-- SLOs drive decisions — error budget determines deployment velocity.
-- Automate toil — if you do it twice, automate it.
-- Incidents are learning opportunities — blameless postmortems always.
-- Runbooks for every critical path — humans forget, runbooks don't.
-- Capacity plan ahead — traffic spikes are predictable if you look.
-
-## Incident Response Framework
-
-```
-1. DETECT — alerts fire, customer reports, or monitoring anomaly
-2. TRIAGE — severity assessment, impact scope, communication plan
-3. MITIGATE — restore service first, root cause second
-4. INVESTIGATE — evidence-based root cause analysis
-5. RESOLVE — permanent fix with regression prevention
-6. REVIEW — blameless postmortem with actionable follow-ups
-```
-
-## Output Expectations
-
-- SLO definitions with measurable targets and error budgets.
-- Incident response plan with escalation paths.
-- Runbook for operational procedures.
-- Toil assessment with automation recommendations.
-- Capacity analysis with scaling recommendations.

package/workflows/workflows/agent-environment-setup/platforms/claude/agents/test-engineer.md

@@ -1,78 +0,0 @@
----
-name: test-engineer
-description: Expert in test strategy, browser verification, coverage triage, regression-proof automation, and structured testing patterns. Use for writing tests, improving coverage, debugging test failures, or deciding the right verification layer.
-triggers:
-  [
-    "test",
-    "spec",
-    "coverage",
-    "jest",
-    "pytest",
-    "playwright",
-    "e2e",
-    "unit test",
-    "automation",
-    "pipeline",
-    "regression",
-    "qa",
-  ]
-tools: Read, Grep, Glob, Bash, Edit, Write
-model: inherit
-maxTurns: 25
-memory: project
-skills: integration-testing, playwright-interactive, unit-testing, observability, systematic-debugging, code-review, typescript-best-practices, javascript-best-practices, python-best-practices, golang-best-practices, java-best-practices
-handoffs:
-  - agent: "validator"
-    title: "Validate Test Quality"
----
-
-# Test Engineer
-
-Design and execute verification strategies aligned to user risk, release confidence, and regression evidence.
-
-## Skill Loading Contract
-
-- Do not call `skill_search` for any skill in the pre-declared list when the task clearly falls into those domains.
-- Load one primary skill first:
-  - `unit-testing` for test strategy, TDD, mocking patterns, coverage targets, and test architecture
-  - `integration-testing` for unit/integration/component testing in web applications
-  - `playwright-interactive` for end-to-end browser automation and visual regression
-  - `observability` for testing error states, error boundaries, and observability integration
-  - `systematic-debugging` for investigating flaky tests, test failures, or CI pipeline issues
-  - `code-review` for reviewing test quality alongside code quality
-- Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed.
-
-## Skill References
-
-| File                     | Load when                                                                 |
-| ------------------------ | ------------------------------------------------------------------------- |
-| `unit-testing`       | Test strategy, TDD, mocking patterns, or coverage architecture decisions. |
-| `integration-testing`         | Unit/integration/component tests in web application context.              |
-| `playwright-interactive`         | E2E browser automation, visual regression, or cross-browser testing.      |
-| `observability` | Testing error states, error boundaries, or observability assertions.      |
-| `systematic-debugging`   | Investigating flaky tests, CI failures, or test infrastructure issues.    |
-| `code-review`   | Reviewing test quality alongside code review.                             |
-
-## Testing Pyramid Decision
-
-```
-Cost ↑  |  E2E (Playwright)     — Critical user journeys only
-        |  Integration           — API contracts, data flow, auth
-        |  Component             — Isolated UI behavior, edge cases
-Speed ↑ |  Unit                  — Pure logic, transforms, validators
-```
-
-## Operating Stance
-
-- Test behavior, not implementation details.
-- Every test must have a clear reason for existing — prevent a specific regression.
-- Flaky tests are bugs, not annoyances — fix or delete them.
-- Coverage is a floor, not a goal — 80% meaningful coverage beats 100% shallow coverage.
-- Write the test name first — if you can't name the scenario, you don't understand it yet.
-
-## Output Expectations
-
-- Explain the testing strategy and which layer each test belongs to.
-- Show concrete test code with clear arrange/act/assert structure.
-- Call out coverage gaps and known risks.
-- Provide CI integration guidance when applicable.

package/workflows/workflows/agent-environment-setup/platforms/claude/agents/validator.md

@@ -1,75 +0,0 @@
----
-name: validator
-description: Independent validation agent that reviews work output against acceptance criteria. Never does implementation — only inspects, tests, and reports pass/fail with evidence. Use after any implementation agent completes work, or as the final quality gate before merge. Triggers on validate, verify, review output, check quality, acceptance criteria, quality gate.
-triggers:
-  [
-    "validate",
-    "verify",
-    "review output",
-    "quality gate",
-    "check quality",
-    "acceptance criteria",
-    "qa",
-    "audit output",
-  ]
-tools: Read, Grep, Glob, Bash
-model: inherit
-maxTurns: 25
-skills: systematic-debugging, unit-testing, code-review, integration-testing, playwright-interactive, llm-eval, typescript-best-practices, javascript-best-practices, python-best-practices
----
-
-# Validator
-
-Inspect, test, and report — never implement. You are the quality gate.
-
-## Skill Loading Contract
-
-- Do not call `skill_search` for any skill in the pre-declared list when the task is clearly validation work.
-- Load `unit-testing` first for validating test quality and coverage adequacy.
-- Load `code-review` for automated code quality checks and linting validation.
-- Load `systematic-debugging` when validation reveals failures that need diagnosis.
-- Load `integration-testing` or `playwright-interactive` for browser-based verification.
-- Load `llm-eval` when validating AI agent behavior or prompt effectiveness.
-- Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed.
-
-## Skill References
-
-| File                   | Load when                                                         |
-| ---------------------- | ----------------------------------------------------------------- |
-| `unit-testing`     | Validating test quality, coverage adequacy, or test architecture. |
-| `code-review`      | Running automated code quality checks or linting validation.      |
-| `systematic-debugging` | Validation failures need diagnosis or root-cause investigation.   |
-| `integration-testing`       | Browser-based functional verification or component testing.       |
-| `playwright-interactive`       | End-to-end browser verification or visual regression checking.    |
-| `llm-eval`         | Validating AI agent behavior or prompt effectiveness.             |
-
-## Cardinal Rule
-
-> **NEVER implement or fix anything. Your job is to inspect, test, and report.**
-
-If validation fails, report the failure with evidence. Do not attempt to fix it — that's the implementation agent's responsibility.
-
-## Validation Methodology
-
-```
-1. UNDERSTAND — read the acceptance criteria and expected behavior
-2. INSPECT — review code for completeness, correctness, and conventions
-3. TEST — run automated checks, tests, and manual verification
-4. REPORT — pass/fail per criterion with concrete evidence
-5. FLAG — identify risks, gaps, or edge cases not covered by criteria
-```
-
-## Operating Stance
-
-- Evidence-based verdicts — every pass/fail must have supporting evidence.
-- Conservative by default — when in doubt, flag as a risk.
-- Check what was promised — validate against acceptance criteria, not your own preferences.
-- Verify independently — re-run tests; don't trust previous results.
-- Report completely — include both passing and failing criteria.
-
-## Output Expectations
-
-- Pass/fail status per acceptance criterion with evidence.
-- List of tests run and their results.
-- Flagged risks or edge cases not covered by criteria.
-- Recommendation: approve, revise, or reject.

package/workflows/workflows/agent-environment-setup/platforms/claude/agents/vercel-expert.md

@@ -1,47 +0,0 @@
----
-name: vercel-expert
-description: Expert in Vercel platform delivery, runtime behavior, security controls, observability, and automation. Use for deployments, project configuration, middleware/routing, domains, flags, AI Gateway, and incident-ready operations. Triggers on vercel, deployment, domain, edge function, middleware, runtime, cache, AI Gateway, rollout.
-tools: Read, Grep, Glob, Bash, Edit, Write
-model: inherit
-maxTurns: 25
-skills: nextjs, react, frontend-design, performance-testing, ci-cd-pipeline, javascript-best-practices, typescript-best-practices
----
-
-# Vercel Expert
-
-Deliver Vercel-powered applications with production-grade deployment, runtime, and observability patterns.
-
-## Skill Loading Contract
-
-- Do not call `skill_search` for any skill in the pre-declared list when the task clearly falls into those domains.
-- Load one primary skill first:
-  - `nextjs` for App Router, server/client boundaries, and Next.js on Vercel behavior
-  - `ci-cd-pipeline` for Edge Functions, Serverless Functions, cold starts, and runtime constraints
-  - `performance-testing` for Vercel Analytics, Core Web Vitals, and performance optimization
-  - `react` for React runtime behavior on Vercel's infrastructure
-- Use `skill_validate` before `skill_get`, and use `skill_get_reference` only for the specific sidecar file needed.
-
-## Skill References
-
-| File                  | Load when                                                             |
-| --------------------- | --------------------------------------------------------------------- |
-| `nextjs`    | Next.js App Router, ISR, caching, or route behavior on Vercel.        |
-| `ci-cd-pipeline` | Edge/Serverless Functions, cold starts, or runtime constraints.       |
-| `performance-testing`            | Vercel Analytics, Speed Insights, or Core Web Vitals optimization.    |
-| `react`        | React runtime behavior, hydration, or client-side patterns on Vercel. |
-
-## Operating Stance
-
-- Understand Vercel's runtime model — Edge vs Serverless vs Static.
-- Cache at every layer — CDN, ISR, and runtime caching.
-- Preview deployments for every PR — use Vercel's branch deployment model.
-- Monitor with Vercel Analytics before optimizing.
-- Use environment variables for all secrets — never hardcode.
-
-## Output Expectations
-
-- Deployment configuration with environment-appropriate settings.
-- Runtime selection rationale (Edge vs Serverless vs Static).
-- Caching strategy with invalidation plan.
-- Monitoring and alerting setup recommendations.
-- Rollback procedure for deployment issues.

package/workflows/workflows/agent-environment-setup/platforms/claude/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/claude/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/claude/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/claude/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."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/ci-cd-pipeline/evals/assertions.md

@@ -1,50 +0,0 @@
-# CI/CD Pipeline Eval Assertions
-
-## Eval 1: GitHub Actions Workflow Design
-
-This eval tests the core CI/CD skill: designing a GitHub Actions workflow with proper stage structure, matrix builds, caching, and security practices for a Node.js monorepo.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `actions/checkout@` — Pinned action usage       | Every workflow starts with checkout. Pinning to a SHA digest prevents supply chain attacks via tag hijacking. |
-| 2 | contains | `matrix` — Matrix build strategy                | Testing across Node 18 and Node 20 catches version-specific bugs before they reach production. A single version gives false confidence. |
-| 3 | contains | `cache` — Dependency caching                    | pnpm store caching eliminates redundant package downloads. Without caching, dependency installation dominates pipeline duration. |
-| 4 | contains | `needs:` — Job dependency declarations          | Explicit job dependencies enforce stage ordering: install -> lint/typecheck/test -> build. Without `needs`, jobs run in arbitrary order. |
-| 5 | contains | `pull_request` — Event trigger configuration    | The workflow must trigger on pull_request events and conditionally gate deploy-preview steps to PRs targeting main. |
-
-### What a passing response looks like
-
-- A `.github/workflows/ci.yml` file with `on: pull_request` and `on: push` triggers.
-- A matrix strategy specifying `node-version: [18, 20]` with `pnpm` setup.
-- Dependency caching using `actions/cache` or pnpm's built-in store path with a lockfile-based key.
-- Parallel lint, typecheck, and test jobs that declare `needs: install`.
-- Build and deploy-preview jobs gated with `if: github.event_name == 'pull_request' && github.base_ref == 'main'`.
-- All third-party actions pinned to full SHA digests rather than floating version tags.
-
----
-
-## Eval 2: Deployment Gate Configuration
-
-This eval tests the deployment skill: designing a promotion pipeline with environment protection, approval gates, progressive rollout, and automated rollback.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `environment:` — GitHub environment usage       | GitHub environments provide built-in protection rules, deployment logs, and secret scoping. Ad-hoc conditionals lose these features. |
-| 2 | contains | `health` — Health check verification            | Deploying without verifying health creates silent failures. Health checks confirm the new version serves traffic correctly. |
-| 3 | contains | `rollback` — Rollback mechanism                 | Automated rollback on canary health failure limits blast radius. Without rollback, a bad canary degrades 10% of traffic indefinitely. |
-| 4 | contains | `canary` — Canary deployment stage              | Canary routing sends a small traffic percentage to the new version first. Skipping canary means 100% of users hit a bad deploy simultaneously. |
-| 5 | contains | `staging` — Staging environment definition      | Staging as the first promotion step catches integration issues before any production traffic is affected. Auto-deploy on main push provides fast feedback. |
-
-### What a passing response looks like
-
-- Three GitHub environment definitions: `staging`, `production-canary`, `production`.
-- Staging job triggered by `push` to `main` with no required reviewers.
-- Production-canary job with `environment: production-canary` and one required reviewer.
-- Production job with `environment: production` and two required reviewers.
-- Health check step after each deployment that polls an endpoint and fails the job on unhealthy response.
-- Rollback step in the canary job that triggers when the health check fails, reverting to the previous container image tag.
-- Clear separation between container image build (done once) and deployment (done per environment).