@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/t3-stack/references/trpc-patterns.md

@@ -1,196 +0,0 @@
-# tRPC Patterns
-
-Load this when designing tRPC routers, procedures, middleware, error handling, or server-side callers in a T3 Stack application.
-
-## Router structure
-
-```typescript
-// src/server/api/root.ts
-import { createTRPCRouter } from "~/server/api/trpc";
-import { userRouter } from "./routers/user";
-import { postRouter } from "./routers/post";
-
-export const appRouter = createTRPCRouter({
-  user: userRouter,
-  post: postRouter,
-});
-
-export type AppRouter = typeof appRouter;
-```
-
-- One router per domain entity or bounded context.
-- The root router re-exports all sub-routers and exposes `AppRouter` as the single type import for the client.
-- Never define procedures directly on the root router.
-
-## Procedure types
-
-```typescript
-import { createTRPCRouter, publicProcedure, protectedProcedure } from "~/server/api/trpc";
-import { z } from "zod";
-
-export const postRouter = createTRPCRouter({
-  // Public: no auth required
-  getPublished: publicProcedure
-    .input(z.object({ cursor: z.string().optional(), limit: z.number().min(1).max(50).default(20) }))
-    .query(async ({ ctx, input }) => {
-      return ctx.db.post.findMany({
-        where: { published: true },
-        take: input.limit + 1,
-        cursor: input.cursor ? { id: input.cursor } : undefined,
-        orderBy: { createdAt: "desc" },
-      });
-    }),
-
-  // Protected: requires authenticated session
-  create: protectedProcedure
-    .input(z.object({ title: z.string().min(1).max(200), body: z.string().min(1) }))
-    .mutation(async ({ ctx, input }) => {
-      return ctx.db.post.create({
-        data: { ...input, authorId: ctx.session.user.id },
-      });
-    }),
-});
-```
-
-- Use `publicProcedure` for reads that do not require auth.
-- Use `protectedProcedure` for any operation that reads or writes user-specific data.
-- Always attach Zod schemas to `.input()` even for simple inputs.
-
-## Custom middleware
-
-```typescript
-// src/server/api/trpc.ts
-import { TRPCError, initTRPC } from "@trpc/server";
-
-const t = initTRPC.context<typeof createTRPCContext>().create({
-  transformer: superjson,
-  errorFormatter({ shape, error }) {
-    return { ...shape, data: { ...shape.data, zodError: error.cause instanceof ZodError ? error.cause.flatten() : null } };
-  },
-});
-
-// Auth middleware — enforces session presence
-const enforceUserIsAuthed = t.middleware(({ ctx, next }) => {
-  if (!ctx.session?.user) {
-    throw new TRPCError({ code: "UNAUTHORIZED" });
-  }
-  return next({ ctx: { session: { ...ctx.session, user: ctx.session.user } } });
-});
-
-// Role-based middleware — stacks on top of auth
-const enforceUserIsAdmin = t.middleware(({ ctx, next }) => {
-  if (ctx.session?.user?.role !== "ADMIN") {
-    throw new TRPCError({ code: "FORBIDDEN", message: "Admin access required." });
-  }
-  return next({ ctx });
-});
-
-export const publicProcedure = t.procedure;
-export const protectedProcedure = t.procedure.use(enforceUserIsAuthed);
-export const adminProcedure = t.procedure.use(enforceUserIsAuthed).use(enforceUserIsAdmin);
-```
-
-- Middleware chains execute in order. Auth must come before role checks.
-- Each middleware narrows the context type so downstream procedures have typed access.
-- Never duplicate auth checks inside procedure handlers when middleware already handles them.
-
-## Error handling
-
-```typescript
-import { TRPCError } from "@trpc/server";
-
-// Use structured error codes
-throw new TRPCError({ code: "NOT_FOUND", message: "Post not found." });
-throw new TRPCError({ code: "FORBIDDEN", message: "You do not own this resource." });
-throw new TRPCError({ code: "BAD_REQUEST", message: "Invalid input." });
-throw new TRPCError({ code: "INTERNAL_SERVER_ERROR", message: "Unexpected failure." });
-
-// Wrap external service errors
-try {
-  await stripeClient.charges.create(chargeData);
-} catch (err) {
-  throw new TRPCError({
-    code: "INTERNAL_SERVER_ERROR",
-    message: "Payment processing failed.",
-    cause: err,
-  });
-}
-```
-
-- Always use `TRPCError` instead of generic `throw new Error()`.
-- Map HTTP-like codes: `NOT_FOUND`, `UNAUTHORIZED`, `FORBIDDEN`, `BAD_REQUEST`, `INTERNAL_SERVER_ERROR`.
-- Attach the original error as `cause` for server-side debugging without leaking details to clients.
-
-## Server-side callers (React Server Components)
-
-```typescript
-// src/trpc/server.ts
-import { createCallerFactory } from "~/server/api/trpc";
-import { appRouter } from "~/server/api/root";
-import { createTRPCContext } from "~/server/api/trpc";
-import { headers } from "next/headers";
-import { cache } from "react";
-
-const createContext = cache(async () => {
-  const heads = new Headers(await headers());
-  heads.set("x-trpc-source", "rsc");
-  return createTRPCContext({ headers: heads });
-});
-
-const callerFactory = createCallerFactory(appRouter);
-export const api = callerFactory(createContext);
-```
-
-```typescript
-// app/dashboard/page.tsx (React Server Component)
-import { api } from "~/trpc/server";
-
-export default async function DashboardPage() {
-  const posts = await api.post.getPublished({ limit: 10 });
-  return <PostList posts={posts} />;
-}
-```
-
-- Server callers bypass the HTTP layer entirely — no network round-trip.
-- Use `cache()` from React to deduplicate context creation within a single render.
-- Never import the server caller in client components (`"use client"`).
-
-## Client-side usage with React Query
-
-```typescript
-// src/trpc/react.tsx
-"use client";
-import { createTRPCReact } from "@trpc/react-query";
-import type { AppRouter } from "~/server/api/root";
-
-export const api = createTRPCReact<AppRouter>();
-```
-
-```typescript
-// Client component
-"use client";
-import { api } from "~/trpc/react";
-
-export function CreatePostForm() {
-  const utils = api.useUtils();
-  const createPost = api.post.create.useMutation({
-    onSuccess: () => utils.post.getPublished.invalidate(),
-  });
-
-  return (
-    <form onSubmit={(e) => {
-      e.preventDefault();
-      const data = new FormData(e.currentTarget);
-      createPost.mutate({ title: data.get("title") as string, body: data.get("body") as string });
-    }}>
-      <input name="title" required />
-      <textarea name="body" required />
-      <button type="submit" disabled={createPost.isPending}>Create</button>
-    </form>
-  );
-}
-```
-
-- Import `api` from `~/trpc/react` (not `~/trpc/server`) in client components.
-- Invalidate related queries after mutations to keep the UI consistent.
-- Use `isPending` (not the deprecated `isLoading`) for mutation state.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/tech-doc/evals/assertions.md

@@ -1,49 +0,0 @@
-# Technical Documentation Eval Assertions
-
-## Eval 1: API Documentation Generation
-
-This eval tests the ability to produce comprehensive API documentation with endpoint descriptions, authentication details, request/response examples, and error catalogs.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `Bearer` — Authentication format specification  | API consumers need the exact authorization header format. Vague "use a token" instructions cause integration failures. |
-| 2 | contains | `curl` — Working request examples               | Copy-pasteable curl commands are the fastest way for consumers to test endpoints. Abstract parameter tables without examples leave guessing. |
-| 3 | contains | `400` — Validation error documentation          | HTTP 400 is the most common error consumers encounter. Undocumented validation rules force trial-and-error debugging. |
-| 4 | contains | `401` — Authentication error documentation      | HTTP 401 responses need clear documentation because authentication failures are the first blocker for new API consumers. |
-| 5 | contains | `application/json` — Content type specification | Explicit content types prevent mismatched headers, which produce cryptic parsing errors that are hard to diagnose remotely. |
-
-### What a passing response looks like
-
-- An overview section explaining the API purpose, base URL, and versioning strategy.
-- Authentication section specifying JWT Bearer token format with header example.
-- Each endpoint documented with: HTTP method, path, description, request body schema, response schema, and status codes.
-- Working curl examples for each endpoint showing headers, request body, and expected response.
-- Error catalog listing 400, 401, 403, 404, and 422 responses with descriptions and example payloads.
-- Rate limiting section with limits, headers (X-RateLimit-Limit, X-RateLimit-Remaining), and retry guidance.
-
----
-
-## Eval 2: Runbook Writing
-
-This eval tests the ability to produce an operational runbook with prerequisites, step-by-step procedures, verification, rollback, and escalation paths.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `## Prerequisites` — Pre-procedure requirements | Missing prerequisites discovered mid-procedure cause failures and wasted time. They must be checked before step one. |
-| 2 | contains | `## Rollback` — Revert procedure                | Production procedures without rollback plans turn partial failures into full outages. Every destructive step needs an undo path. |
-| 3 | contains | `snapshot` — Backup before destructive changes  | Database upgrades must start with a snapshot or backup. This is the non-negotiable safety net for any data-touching operation. |
-| 4 | contains | `## Verification` — Success confirmation steps  | Procedures without verification leave ambiguous outcomes. Specific checks (query test, health endpoint, metric dashboard) confirm success. |
-| 5 | contains | `Escalat` — Escalation path documentation       | On-call engineers need to know when and who to escalate to. Runbooks without escalation contacts leave operators stranded during failures. |
-
-### What a passing response looks like
-
-- A title and metadata section with last-updated date, owner team, and estimated duration.
-- Prerequisites listing: AWS console access, RDS modify permissions, read replica status, current version confirmation, maintenance window confirmation.
-- Numbered step-by-step procedure: create snapshot, create read replica on target version, verify replica, promote replica, update connection strings, verify application health.
-- Verification section: run test queries, check application error rates, verify connection pool metrics, confirm replication lag is zero.
-- Rollback section: revert connection strings to original instance, verify application reconnects, document the failure for post-mortem.
-- Escalation section: DBA team contact, AWS support case creation criteria, management notification threshold.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/tech-doc/evals/evals.json

@@ -1,66 +0,0 @@
-[
-  {
-    "name": "api-documentation-generation",
-    "description": "Validate that the skill produces comprehensive API documentation with endpoint descriptions, authentication details, request/response examples, and error catalogs.",
-    "input": "Write API documentation for a user management service with these endpoints: POST /api/users (create user), GET /api/users/:id (get user by ID), PATCH /api/users/:id (update user), DELETE /api/users/:id (delete user), POST /api/users/login (authenticate). The API uses JWT bearer tokens for authentication. Include request/response examples, error codes, and rate limiting information.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "Bearer",
-        "description": "Authentication documentation must specify Bearer token format because API consumers need to know the exact authorization header format to make authenticated requests."
-      },
-      {
-        "type": "contains",
-        "value": "curl",
-        "description": "At least one working curl example must be provided for each endpoint because copy-pasteable examples are the fastest path to API consumer success."
-      },
-      {
-        "type": "contains",
-        "value": "400",
-        "description": "Error documentation must include HTTP 400 (Bad Request) responses with descriptions because validation errors are the most common API consumer mistake."
-      },
-      {
-        "type": "contains",
-        "value": "401",
-        "description": "Error documentation must include HTTP 401 (Unauthorized) responses because authentication failures need clear documentation for debugging."
-      },
-      {
-        "type": "contains",
-        "value": "application/json",
-        "description": "Request and response content types must be specified explicitly because content type mismatches are a frequent source of integration errors."
-      }
-    ]
-  },
-  {
-    "name": "runbook-writing",
-    "description": "Validate that the skill produces an operational runbook with numbered steps, prerequisites, expected outcomes, escalation paths, and rollback procedures.",
-    "input": "Write an operational runbook for performing a zero-downtime PostgreSQL major version upgrade (e.g., 14 to 16) on a production system running on AWS RDS. The system serves a web application with approximately 1000 requests per second. Include prerequisites, step-by-step procedure, verification steps, rollback plan, and escalation contacts.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "## Prerequisites",
-        "description": "The runbook must include a Prerequisites section listing required access, tools, and conditions to verify before starting because missing prerequisites discovered mid-procedure cause failures."
-      },
-      {
-        "type": "contains",
-        "value": "## Rollback",
-        "description": "The runbook must include a Rollback section with explicit steps to revert changes because production procedures without rollback plans turn failures into outages."
-      },
-      {
-        "type": "contains",
-        "value": "snapshot",
-        "description": "The procedure must include creating a database snapshot or backup before the upgrade because data safety is the non-negotiable first step of any destructive operation."
-      },
-      {
-        "type": "contains",
-        "value": "## Verification",
-        "description": "The runbook must include a Verification section with specific checks to confirm the upgrade succeeded because procedures without verification steps leave ambiguous outcomes."
-      },
-      {
-        "type": "contains",
-        "value": "Escalat",
-        "description": "The runbook must include escalation information (contacts, conditions for escalation) because on-call engineers need to know when and who to contact if the procedure fails."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/typescript-best-practices/evals/assertions.md

@@ -1,33 +0,0 @@
-# TypeScript Best Practices — Eval Assertions
-
-## Eval 1: Strict Migration (typescript-strict-migration)
-
-This eval tests whether the skill correctly migrates a loose TypeScript project to strict mode with proper null safety.
-
-### Assertions
-
-1. **Strict mode enabled with explanation** — The response must enable `strict: true` in tsconfig.json and explain what flags it activates (at minimum: `strictNullChecks`, `noImplicitAny`, `strictFunctionTypes`). Understanding what strict mode enables is essential for migration.
-
-2. **noUncheckedIndexedAccess enabled** — The response must add `noUncheckedIndexedAccess: true` and demonstrate handling the resulting `T | undefined` return types. This flag is the most impactful strict addition beyond the `strict` umbrella.
-
-3. **Explicit parameter types and null handling** — The `id` parameter in `getUser` must receive an explicit type annotation (e.g., `number`), and the return type `User | undefined` must be handled properly by the caller rather than assumed to be non-null.
-
-4. **Runtime validation for external data** — The `processUsers` function's `any` parameter must be replaced with either a properly typed interface or runtime validation using Zod, Valibot, or a similar schema validator. Trusting `as` assertions on external data is a common source of runtime crashes.
-
-5. **satisfies for config objects** — The `config` object should use the `satisfies` operator (e.g., `satisfies AppConfig`) to validate the shape while preserving the `as const` literal types, or an equivalent approach that does not widen the types through assertion.
-
-## Eval 2: Discriminated Union Design (typescript-discriminated-union)
-
-This eval tests whether the skill produces a type-safe state machine with proper exhaustiveness checking.
-
-### Assertions
-
-1. **Literal discriminant field** — Each payment state must have a literal string field (e.g., `status: 'pending'`, `status: 'authorized'`) that TypeScript can use as a discriminant for union narrowing.
-
-2. **State-specific data** — Each variant must carry its own fields. Authorized should have an authorization code, Captured should have a capture ID, etc. States should not share a flat bag of optional fields.
-
-3. **Exhaustiveness checking with never** — The response must include a `switch` statement (or equivalent) whose default case assigns to `never`, so the compiler errors if a new state is added but not handled. This is the core safety guarantee of discriminated unions.
-
-4. **Type-safe transitions** — The transition function must use type narrowing to ensure only valid transitions compile. For example, `Refunded` can only come from `Captured`, not from `Pending`.
-
-5. **Compile-time invalid transition rejection** — The response must demonstrate (through types, not runtime checks) that attempting an invalid transition is a compiler error. This proves the state machine is enforced at the type level.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/typescript-best-practices/evals/evals.json

@@ -1,54 +0,0 @@
-[
-  {
-    "id": "typescript-strict-migration",
-    "prompt": "I need to migrate a legacy TypeScript project to strict mode. The tsconfig currently has `strict: false` and uses `any` extensively. Here is a sample module:\n\n```typescript\n// user-service.ts\ninterface User {\n  id: number;\n  name: string;\n  email: string;\n  role: 'admin' | 'user' | 'moderator';\n  metadata?: Record<string, any>;\n}\n\nfunction getUser(users: User[], id) {\n  return users.find(u => u.id === id);\n}\n\nfunction getUserProperty(user: User, key: string) {\n  return user[key];\n}\n\nfunction processUsers(data: any) {\n  const users = data.users;\n  return users.map(u => ({ ...u, displayName: u.name.toUpperCase() }));\n}\n\nconst config = {\n  apiUrl: 'https://api.example.com',\n  timeout: 5000,\n  retries: 3,\n} as const;\n```\n\nMigrate this to strict TypeScript 5.9+ with proper typing, null safety, and noUncheckedIndexedAccess. Explain the tsconfig changes needed.",
-    "assertions": [
-      {
-        "type": "content",
-        "value": "enables strict: true in tsconfig and explains the flags it activates (strictNullChecks, noImplicitAny, strictFunctionTypes)"
-      },
-      {
-        "type": "content",
-        "value": "adds noUncheckedIndexedAccess: true and handles the resulting T | undefined return types from indexed access"
-      },
-      {
-        "type": "content",
-        "value": "adds explicit type annotation for the `id` parameter in getUser and handles the possible undefined return"
-      },
-      {
-        "type": "content",
-        "value": "replaces the untyped `any` in processUsers with a proper type or runtime validation using Zod or similar"
-      },
-      {
-        "type": "content",
-        "value": "uses satisfies operator or proper type annotation for the config object to validate shape while preserving literal types"
-      }
-    ]
-  },
-  {
-    "id": "typescript-discriminated-union",
-    "prompt": "Design a type-safe state machine for a payment processing flow with these states: Pending, Authorized, Captured, Refunded, Failed. Each state has different allowed transitions and carries different data. Implement discriminated unions with exhaustiveness checking. Include a transition function that only allows valid state changes.",
-    "assertions": [
-      {
-        "type": "content",
-        "value": "defines a discriminated union with a literal type discriminant field (e.g., status or kind) for each payment state"
-      },
-      {
-        "type": "content",
-        "value": "each state variant carries state-specific data fields (e.g., Authorized has authorizationCode, Captured has captureId)"
-      },
-      {
-        "type": "content",
-        "value": "implements exhaustiveness checking using never in the default case of a switch statement or equivalent pattern"
-      },
-      {
-        "type": "content",
-        "value": "the transition function uses type narrowing to restrict which transitions are valid from each state"
-      },
-      {
-        "type": "content",
-        "value": "demonstrates that invalid transitions produce compile-time errors rather than runtime checks"
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/unit-testing/evals/assertions.md

@@ -1,42 +0,0 @@
-# Unit Testing -- Eval Assertions
-
-## Eval 001: Mock Strategy for External Payment Service
-
-| # | Assertion Type | Value | Rationale |
-|---|---------------|-------|-----------|
-| 1 | contains | `stub` | The response must recommend stubs or test doubles for the external payment gateway to ensure test isolation from the real HTTP service. |
-| 2 | contains | `timeout` | The response must include a test case that covers network timeout handling, since timeout is a critical error path for external service calls. |
-| 3 | contains | `assert` | The response must include explicit assertions for each scenario (success, decline, timeout, idempotency conflict) to verify correct behavior. |
-| 4 | contains | `arrange` | The response must demonstrate the Arrange-Act-Assert (AAA) pattern or equivalent structured test layout, ensuring consistent test organization. |
-| 5 | contains | `idempoten` | The response must address the idempotency key conflict scenario, which is a real-world edge case specific to payment integrations. |
-
-### What a Passing Response Looks Like
-
-A passing response designs a complete mock strategy that:
-- Creates a stub or fake for `PaymentGateway.charge()` rather than calling the real service.
-- Defines four distinct test cases: successful charge, declined card, network timeout, and idempotency conflict.
-- Uses the Arrange-Act-Assert structure in each test.
-- Includes specific assertions (e.g., `expect(result.status).toBe('declined')`) rather than vague checks.
-- Explains why each mock behavior is configured (e.g., timeout stub simulates network failure).
-
----
-
-## Eval 002: TDD Red-Green-Refactor Cycle for Validator
-
-| # | Assertion Type | Value | Rationale |
-|---|---------------|-------|-----------|
-| 1 | contains | `red` | The response must explicitly identify the Red phase where a failing test is written before any implementation code exists. |
-| 2 | contains | `green` | The response must explicitly identify the Green phase where the minimum code is written to make the test pass. |
-| 3 | contains | `refactor` | The response must explicitly identify the Refactor phase where code is improved while tests remain green. |
-| 4 | contains | `fail` | The response must show or describe the test failing before implementation, proving the test is valid and exercises the intended behavior. |
-| 5 | contains | `edge` | The response must address edge cases (consecutive dots, unusual formats) as part of the TDD cycle. |
-
-### What a Passing Response Looks Like
-
-A passing response walks through a complete TDD cycle that:
-- Starts with a failing test for the simplest case (e.g., valid email returns true).
-- Shows the test failing (Red) before any implementation.
-- Writes minimal implementation to pass (Green).
-- Iterates the cycle for each requirement: no `@`, spaces, consecutive dots.
-- Refactors the validation logic while all tests stay green.
-- Clearly labels each phase (Red, Green, Refactor) in the walkthrough.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/unit-testing/evals/evals.json

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "unit-testing-eval-001",
-    "name": "Mock strategy for external payment service",
-    "description": "Evaluate the skill's ability to design a mocking strategy for an external payment gateway in a checkout flow, ensuring isolation from the real service while testing all response scenarios.",
-    "prompt": "I have an OrderService that calls a PaymentGateway.charge(amount, currency, token) method. The gateway is an external HTTP service. Design a unit test strategy with mocking for: successful charge, declined card, network timeout, and idempotency key conflict. Show me the test structure and mock setup.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "stub",
-        "description": "Should recommend stubs or test doubles for the payment gateway rather than calling the real service"
-      },
-      {
-        "type": "contains",
-        "value": "timeout",
-        "description": "Should include a test case for network timeout handling as an error path"
-      },
-      {
-        "type": "contains",
-        "value": "assert",
-        "description": "Should include specific assertions for each test scenario outcome"
-      },
-      {
-        "type": "contains",
-        "value": "arrange",
-        "description": "Should structure tests using the Arrange-Act-Assert pattern or equivalent"
-      },
-      {
-        "type": "contains",
-        "value": "idempoten",
-        "description": "Should address the idempotency conflict scenario as an edge case"
-      }
-    ]
-  },
-  {
-    "id": "unit-testing-eval-002",
-    "name": "TDD red-green-refactor cycle for a validator",
-    "description": "Evaluate the skill's ability to walk through a complete TDD red-green-refactor cycle for implementing an email validator, demonstrating each phase with concrete code.",
-    "prompt": "Walk me through a TDD red-green-refactor cycle to implement an EmailValidator.validate(email) function. It should accept standard emails, reject emails without @, reject emails with spaces, and handle edge cases like consecutive dots. Show each phase clearly.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "red",
-        "description": "Should explicitly identify the Red phase where a failing test is written first"
-      },
-      {
-        "type": "contains",
-        "value": "green",
-        "description": "Should explicitly identify the Green phase where minimal code is written to pass"
-      },
-      {
-        "type": "contains",
-        "value": "refactor",
-        "description": "Should explicitly identify the Refactor phase where code is cleaned up under green tests"
-      },
-      {
-        "type": "contains",
-        "value": "fail",
-        "description": "Should show the test failing before implementation as proof of test validity"
-      },
-      {
-        "type": "contains",
-        "value": "edge",
-        "description": "Should address edge cases like consecutive dots or unusual valid formats"
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/vibesec/SKILL.md

@@ -1,96 +0,0 @@
----
-name: vibesec
-description: "Perform a lightweight security vibe check on codebases, configurations, and dependencies. Quick assessment of common security pitfalls, dependency health, and configuration hygiene without a full audit."
----
-# VibeSec — Lightweight Security Vibe Check
-
-## Purpose
-
-Deliver a fast, opinionated security assessment that catches the most common and impactful issues in minutes rather than days. VibeSec is not a replacement for a full security audit; it is a triage pass that identifies the biggest risks so teams can prioritize deeper review where it matters most.
-
-## When to Use
-
-- Quick security sanity check before a release or PR merge
-- Onboarding onto an unfamiliar codebase and need a security first impression
-- Auditing dependency health and known vulnerabilities
-- Reviewing configuration files for security misconfigurations
-- Assessing whether a project needs a full security audit
-- Checking for hardcoded secrets, weak defaults, and missing security headers
-
-## Instructions
-
-1. **Scan for hardcoded secrets and credentials** — Search for API keys, passwords, tokens, and private keys in source code, config files, and environment templates because leaked secrets are the fastest path to a breach.
-
-2. **Check dependency health** — Run `npm audit`, `pip-audit`, `cargo audit`, or the ecosystem equivalent and review the output because vulnerable dependencies are the most common real-world attack vector.
-
-3. **Review dependency age and maintenance** — Flag dependencies that have not been updated in 12+ months or have known maintainer abandonment because unmaintained packages accumulate vulnerabilities silently.
-
-4. **Inspect environment and configuration files** — Check `.env`, `docker-compose.yml`, `nginx.conf`, cloud IAM policies, and similar files for overly permissive settings, debug modes left on, and default credentials because misconfigurations are exploitable without any code vulnerability.
-
-5. **Verify HTTPS and TLS configuration** — Confirm that all external communications use TLS, certificates are valid, and insecure protocol fallbacks are disabled because cleartext transport exposes all other security measures.
-
-6. **Check authentication defaults** — Verify that default passwords are changed, admin endpoints are protected, MFA is available, and session timeouts are reasonable because weak authentication defaults are low-effort, high-impact targets.
-
-7. **Look for common injection points** — Spot-check user input handling for SQL concatenation, unsanitized HTML rendering, command string building, and path concatenation because injection vulnerabilities have the highest exploitability.
-
-8. **Review CORS and CSP headers** — Check for `Access-Control-Allow-Origin: *`, missing Content-Security-Policy, and absent X-Frame-Options because permissive headers enable cross-origin attacks.
-
-9. **Assess logging and error exposure** — Verify that stack traces are not exposed to users, sensitive data is not logged, and security events are captured because information leaks aid attackers and missing logs delay incident response.
-
-10. **Check for exposed debug endpoints** — Search for `/debug`, `/actuator`, `/phpinfo`, `/__debug__`, GraphQL introspection, and similar endpoints because debug interfaces provide reconnaissance information and sometimes direct code execution.
-
-11. **Evaluate Docker and container security** — Check for containers running as root, unscanned base images, exposed ports, and secrets mounted as environment variables because container misconfigurations amplify application vulnerabilities.
-
-12. **Produce a vibe check summary with risk rating** — Assign an overall vibe (Green/Yellow/Orange/Red) and list the top 5 issues to fix first because a clear, prioritized summary drives immediate action.
-
-13. **Recommend whether a full audit is needed** — Based on findings, state whether the codebase needs a comprehensive security review, a targeted deep-dive on specific areas, or is reasonably healthy because this guides resource allocation decisions.
-
-## Output Format
-
-```
-## VibeSec Report
-
-### Overall Vibe: [GREEN / YELLOW / ORANGE / RED]
-
-### Quick Stats
-- Hardcoded secrets found: [count]
-- Vulnerable dependencies: [critical/high/medium/low]
-- Config issues: [count]
-- Missing security headers: [list]
-
-### Top 5 Issues (Fix These First)
-1. [Issue — why it matters — how to fix]
-2. ...
-
-### Secrets Scan
-[Results or clean bill]
-
-### Dependency Health
-[Vulnerability counts, outdated packages, unmaintained deps]
-
-### Configuration Review
-[Findings per config file]
-
-### Header & Transport Check
-[Missing headers, TLS issues]
-
-### Recommendation
-[Full audit needed? Targeted review? Ship it?]
-```
-
-## References
-
-| Topic | Reference | Load When |
-|-------|-----------|-----------|
-| Quick Security Checks | `references/quick-checks.md` | Running the initial scan pass |
-| Dependency Audit Guide | `references/dependency-audit.md` | Assessing dependency health |
-| Configuration Review | `references/config-review.md` | Inspecting config files |
-| Common Security Pitfalls | `references/common-pitfalls.md` | Identifying frequent mistakes |
-
-## Antigravity Platform Notes
-
-- Use Agent Manager for parallel agent coordination and task delegation.
-- Skill and agent files are stored under `.agent/skills/` and `.agent/agents/` respectively.
-- TOML command files in `.agent/commands/` provide slash-command entry points for workflows.
-- Replace direct `@agent-name` delegation with Agent Manager dispatch calls.
-- Reference files are loaded relative to the skill directory under `.agent/skills/<skill-id>/`.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/vibesec/evals/assertions.md

@@ -1,25 +0,0 @@
-# Eval Assertions — VibeSec
-
-## Eval 1: Quick Security Vibe Check
-
-**ID:** `vibesec-quick-assessment`
-
-| # | Assertion Type | Expected Value | Rationale |
-|---|---------------|----------------|-----------|
-| 1 | content_matches_regex | `RED\|ORANGE\|red\|orange` | Given committed secrets, wildcard CORS, root containers, and stack trace leaks, the vibe must be RED or ORANGE. |
-| 2 | content_matches_regex | `\\.env\|secret\|credential\|DATABASE_URL` | The committed .env file with database credentials is the most critical finding and must be flagged immediately. |
-| 3 | content_matches_regex | `CORS\|Access-Control\|origin.*\\*` | Wildcard CORS is a commonly exploited misconfiguration that enables cross-origin attacks. Must be identified. |
-| 4 | content_matches_regex | `stack trace\|error\|debug\|production` | Stack trace exposure in production leaks internal architecture details to attackers. Must be flagged. |
-| 5 | content_matches_regex | `root\|container\|Docker\|privilege` | Containers running as root amplify any container escape vulnerability. Must be identified. |
-
-## Eval 2: Dependency Health Audit
-
-**ID:** `vibesec-dependency-audit`
-
-| # | Assertion Type | Expected Value | Rationale |
-|---|---------------|----------------|-----------|
-| 1 | content_matches_regex | `Django.*3\\.2\|outdated\|end.of.life\|EOL\|upgrade\|update` | Django 3.2 is past end-of-life and must be flagged for upgrade, especially for a financial application. |
-| 2 | content_matches_regex | `Pillow\|CVE\|vulnerability\|vulnerab` | Pillow 8.0.0 has multiple known CVEs and must be identified as vulnerable. |
-| 3 | content_matches_regex | `PyYAML\|YAML\|deserializ\|unsafe` | PyYAML 5.3 has known unsafe deserialization vulnerabilities (CVE-2020-14343) that must be flagged. |
-| 4 | content_matches_regex | `pip.audit\|safety\|dependabot\|renovate\|scan` | Must recommend an automated dependency scanning tool for ongoing monitoring. |
-| 5 | content_matches_regex | `financial\|critical\|high.*risk\|sensitive\|priority` | The financial transaction context must elevate the risk assessment and urgency of remediation. |