@cubis/foundry 0.3.83 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/sanitize-pii/references/pii-detection.md

@@ -1,219 +0,0 @@
-# PII Detection Patterns Reference
-
-## Overview
-
-PII (Personally Identifiable Information) detection requires a combination of pattern matching, context analysis, and domain knowledge. This reference provides detection patterns, classification taxonomy, and scanning strategies for identifying PII in code, logs, databases, and data flows.
-
-## PII Taxonomy
-
-### Direct Identifiers
-
-Can identify a person on their own.
-
-| Category | Examples | Regex Pattern |
-|----------|---------|---------------|
-| Email address | john@example.com | `\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z\|a-z]{2,}\b` |
-| Social Security Number | 123-45-6789 | `\b\d{3}-\d{2}-\d{4}\b` |
-| Phone number | +1 (555) 123-4567 | `(\+\d{1,3}\s?)?\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}` |
-| Credit card number | 4111 1111 1111 1111 | `\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b` |
-| Passport number | Varies by country | Country-specific patterns |
-| Driver's license | Varies by state/country | State-specific patterns |
-| National ID | Varies by country | Country-specific patterns |
-| IP address | 192.168.1.100 | `\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b` |
-| IBAN | DE89 3704 0044 0532 0130 00 | `\b[A-Z]{2}\d{2}\s?\d{4}\s?\d{4}\s?\d{4}\s?\d{4}\s?\d{0,2}\b` |
-| Bank account + routing | 021000021 / 1234567890 | `\b\d{9}\b` (routing), `\b\d{8,17}\b` (account) |
-
-### Quasi-Identifiers
-
-Can identify a person when combined.
-
-| Category | Risk Level | Combined With |
-|----------|-----------|---------------|
-| Full name | Medium | Address, DOB, employer |
-| Date of birth | Medium | ZIP code, gender |
-| ZIP/postal code | Low alone | DOB, gender (87% re-identification rate per Sweeney) |
-| Gender | Low alone | DOB, ZIP code |
-| Ethnicity/race | Low alone | ZIP code, age |
-| Job title + employer | Medium | Name, location |
-| Medical condition | High (special category) | Any identifier |
-
-### Sensitive Attributes (Special Category under GDPR)
-
-| Category | GDPR Article | Extra Protection Required |
-|----------|-------------|--------------------------|
-| Health data | Art. 9 | Explicit consent or specific legal basis |
-| Biometric data | Art. 9 | Purpose-limited, strong encryption |
-| Genetic data | Art. 9 | Highest protection tier |
-| Racial/ethnic origin | Art. 9 | Explicit consent required |
-| Political opinions | Art. 9 | Explicit consent required |
-| Religious beliefs | Art. 9 | Explicit consent required |
-| Sexual orientation | Art. 9 | Explicit consent required |
-| Trade union membership | Art. 9 | Explicit consent required |
-
-## Detection Strategies
-
-### 1. Regex Pattern Matching
-
-Fast, high recall, but higher false positive rate.
-
-```python
-import re
-
-PII_PATTERNS = {
-    'email': re.compile(r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b'),
-    'ssn': re.compile(r'\b\d{3}-\d{2}-\d{4}\b'),
-    'credit_card': re.compile(r'\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b'),
-    'phone_us': re.compile(r'(\+1\s?)?\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}'),
-    'ip_address': re.compile(r'\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b'),
-    'date_of_birth': re.compile(r'\b(0[1-9]|1[0-2])[-/](0[1-9]|[12]\d|3[01])[-/](19|20)\d{2}\b'),
-}
-
-def scan_text(text):
-    findings = []
-    for pii_type, pattern in PII_PATTERNS.items():
-        for match in pattern.finditer(text):
-            findings.append({
-                'type': pii_type,
-                'value': match.group(),
-                'position': match.span(),
-            })
-    return findings
-```
-
-### 2. NLP-Based Entity Recognition
-
-Better for unstructured text (support tickets, notes, free-form fields).
-
-```python
-# Using Microsoft Presidio
-from presidio_analyzer import AnalyzerEngine
-
-analyzer = AnalyzerEngine()
-results = analyzer.analyze(
-    text="John Smith's SSN is 123-45-6789 and he lives at 42 Oak St",
-    language='en',
-    entities=[
-        "PERSON", "PHONE_NUMBER", "EMAIL_ADDRESS",
-        "US_SSN", "CREDIT_CARD", "LOCATION", "DATE_TIME",
-    ]
-)
-
-for result in results:
-    print(f"  Type: {result.entity_type}, Score: {result.score}")
-    print(f"  Text: {text[result.start:result.end]}")
-```
-
-### 3. Database Schema Analysis
-
-Identify PII by column names and types.
-
-```python
-PII_COLUMN_PATTERNS = {
-    'email': ['email', 'email_address', 'e_mail', 'user_email'],
-    'name': ['first_name', 'last_name', 'full_name', 'name', 'display_name'],
-    'phone': ['phone', 'phone_number', 'mobile', 'telephone', 'cell'],
-    'address': ['address', 'street', 'city', 'state', 'zip', 'postal_code', 'country'],
-    'ssn': ['ssn', 'social_security', 'national_id', 'tax_id', 'tin'],
-    'dob': ['date_of_birth', 'dob', 'birth_date', 'birthday'],
-    'financial': ['credit_card', 'card_number', 'account_number', 'routing_number', 'iban'],
-    'ip': ['ip_address', 'ip', 'client_ip', 'remote_addr'],
-}
-
-def classify_columns(schema):
-    findings = []
-    for table in schema.tables:
-        for column in table.columns:
-            col_lower = column.name.lower()
-            for pii_type, patterns in PII_COLUMN_PATTERNS.items():
-                if any(p in col_lower for p in patterns):
-                    findings.append({
-                        'table': table.name,
-                        'column': column.name,
-                        'pii_type': pii_type,
-                        'data_type': column.type,
-                    })
-    return findings
-```
-
-### 4. Log Pattern Scanning
-
-Detect PII in structured and unstructured log output.
-
-```python
-def scan_log_line(line):
-    findings = []
-
-    # Check structured fields
-    if '=' in line:
-        for pair in line.split():
-            if '=' in pair:
-                key, _, value = pair.partition('=')
-                key_lower = key.lower()
-                if any(k in key_lower for k in ['email', 'ssn', 'password', 'card', 'phone', 'name']):
-                    findings.append({
-                        'key': key,
-                        'type': 'structured_pii_field',
-                        'severity': 'high'
-                    })
-
-    # Check for PII patterns in unstructured content
-    for pii_type, pattern in PII_PATTERNS.items():
-        if pattern.search(line):
-            findings.append({
-                'type': pii_type,
-                'severity': 'high' if pii_type in ['ssn', 'credit_card'] else 'medium'
-            })
-
-    return findings
-```
-
-## Code Scanning Patterns
-
-### Logging Statements
-
-```python
-# PATTERNS TO FLAG IN CODE REVIEW
-
-# Direct PII in log statements
-logger.info(f"User registered: {user.email}")        # FLAG: email in log
-logger.debug(f"Payment: card={card_number}")          # FLAG: card in log
-logger.error(f"Auth failed: password={password}")     # FLAG: password in log
-
-# Object serialization (may contain PII)
-logger.info(f"User data: {json.dumps(user.__dict__)}") # FLAG: full object dump
-logger.debug(f"Request body: {request.body}")          # FLAG: request body may have PII
-```
-
-### Semgrep Rules for PII in Logs
-
-```yaml
-rules:
-  - id: pii-in-log-email
-    patterns:
-      - pattern: |
-          $LOGGER.$METHOD(..., $MSG, ...)
-      - metavariable-regex:
-          metavariable: $MSG
-          regex: ".*(email|e_mail).*"
-      - metavariable-regex:
-          metavariable: $METHOD
-          regex: "(info|debug|warn|error|log)"
-    message: "Potential PII (email) in log statement"
-    severity: WARNING
-
-  - id: pii-in-log-user-object
-    pattern: |
-      $LOGGER.$METHOD(..., json.dumps($USER.__dict__), ...)
-    message: "Full object serialization in log may contain PII"
-    severity: WARNING
-```
-
-## Scanning Tools
-
-| Tool | Type | Strengths | Limitations |
-|------|------|-----------|-------------|
-| Microsoft Presidio | NLP + regex | Multi-language, extensible, open source | Requires Python runtime |
-| AWS Macie | Managed SaaS | S3 scanning, ML-powered, low ops | AWS only, S3 only |
-| Google DLP | Managed SaaS | 150+ detectors, infoTypes, de-identification | GCP API, cost per scan |
-| piisern | CLI tool | Fast, simple, pattern-based | Limited to common patterns |
-| detect-secrets | Pre-commit | Secret + PII patterns, baseline tracking | Secrets-focused, limited PII |

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/sanitize-pii/references/redaction-strategies.md

@@ -1,252 +0,0 @@
-# Redaction Strategies Reference
-
-## Overview
-
-Redaction removes or replaces PII values so the data cannot identify individuals. The right strategy depends on whether redaction must be reversible, whether data utility must be preserved, and what compliance requirements apply.
-
-## Redaction Types
-
-| Type | Description | Reversible | Data Utility | Use Case |
-|------|------------|-----------|-------------|----------|
-| Destructive | Replace with fixed token | No | None | Logs, error messages |
-| Deterministic | Same input always produces same output | No (but consistent) | Referential | Analytics, testing |
-| Format-preserving | Output matches input format | Optional | High | Staging databases |
-| Tokenization | Replace with random token, store mapping | Yes (with vault) | None (without vault) | Payment processing |
-| Partial masking | Reveal some characters | No | Partial | Display (card ending 4242) |
-
-## Implementation Patterns
-
-### Destructive Redaction (Logs)
-
-```javascript
-// Log sanitizer middleware
-const REDACTION_RULES = [
-  { name: 'email', pattern: /\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b/g, replacement: '[REDACTED:email]' },
-  { name: 'ssn', pattern: /\b\d{3}-\d{2}-\d{4}\b/g, replacement: '[REDACTED:ssn]' },
-  { name: 'credit_card', pattern: /\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b/g, replacement: '[REDACTED:card]' },
-  { name: 'phone', pattern: /(\+\d{1,3}\s?)?\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}/g, replacement: '[REDACTED:phone]' },
-  { name: 'ip', pattern: /\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b/g, replacement: '[REDACTED:ip]' },
-];
-
-function sanitizeLogMessage(message) {
-  let sanitized = message;
-  for (const rule of REDACTION_RULES) {
-    sanitized = sanitized.replace(rule.pattern, rule.replacement);
-  }
-  return sanitized;
-}
-
-// Integrate with logging library
-const winston = require('winston');
-const sanitizeFormat = winston.format((info) => {
-  info.message = sanitizeLogMessage(info.message);
-  return info;
-});
-
-const logger = winston.createLogger({
-  format: winston.format.combine(
-    sanitizeFormat(),
-    winston.format.json()
-  ),
-  transports: [new winston.transports.Console()],
-});
-```
-
-### Deterministic Redaction (Analytics)
-
-Same input always produces the same pseudonym, enabling joins and aggregation.
-
-```python
-import hashlib
-import hmac
-
-REDACTION_KEY = os.environ['REDACTION_HMAC_KEY']
-
-def deterministic_redact(value, pii_type):
-    """Same input always produces same output for consistent references."""
-    tag = hmac.new(
-        REDACTION_KEY.encode(),
-        f"{pii_type}:{value}".encode(),
-        hashlib.sha256
-    ).hexdigest()[:16]
-    return f"[{pii_type}:{tag}]"
-
-# Usage
-email = "sarah@example.com"
-redacted = deterministic_redact(email, "email")
-# Always returns: [email:a7b3c9d1e5f2g8h4]
-# Can join records by this pseudonym without knowing the real email
-```
-
-### Format-Preserving Redaction (Staging)
-
-Output looks like real data and passes format validation.
-
-```python
-from faker import Faker
-import hashlib
-
-fake = Faker()
-
-def format_preserving_redact(value, pii_type, seed_salt):
-    """Replace PII with realistic fake data, deterministically."""
-    seed = int(hashlib.sha256(f"{seed_salt}:{value}".encode()).hexdigest()[:8], 16)
-    fake.seed_instance(seed)
-
-    if pii_type == 'email':
-        return f"{fake.user_name()}@masked.example.com"
-    elif pii_type == 'name':
-        return fake.name()
-    elif pii_type == 'phone':
-        return fake.phone_number()
-    elif pii_type == 'address':
-        return fake.address()
-    elif pii_type == 'ssn':
-        return f"{fake.random_int(100,999)}-{fake.random_int(10,99)}-{fake.random_int(1000,9999)}"
-    elif pii_type == 'credit_card':
-        return fake.credit_card_number()
-    elif pii_type == 'date_of_birth':
-        return fake.date_of_birth(minimum_age=18, maximum_age=80).isoformat()
-    else:
-        return f"[REDACTED:{pii_type}]"
-```
-
-### Tokenization (Payment Processing)
-
-Replace sensitive data with a random token; store the mapping in a secure vault.
-
-```python
-class TokenVault:
-    def __init__(self, vault_client):
-        self.vault = vault_client
-
-    def tokenize(self, value, data_type):
-        """Replace value with a random token, store mapping in vault."""
-        token = f"tok_{secrets.token_hex(16)}"
-        self.vault.write(
-            f"tokens/data/{token}",
-            original=value,
-            data_type=data_type,
-            created_at=datetime.utcnow().isoformat()
-        )
-        return token
-
-    def detokenize(self, token):
-        """Retrieve original value (requires vault access + authorization)."""
-        secret = self.vault.read(f"tokens/data/{token}")
-        return secret['data']['original']
-```
-
-### Partial Masking (Display)
-
-```javascript
-function partialMask(value, type) {
-  switch (type) {
-    case 'email':
-      const [local, domain] = value.split('@');
-      return `${local[0]}***@${domain}`;
-      // sarah@example.com → s***@example.com
-
-    case 'phone':
-      return value.replace(/\d(?=\d{4})/g, '*');
-      // +1 (555) 123-4567 → +* (***) ***-4567
-
-    case 'credit_card':
-      return `**** **** **** ${value.slice(-4)}`;
-      // 4111111111111111 → **** **** **** 1111
-
-    case 'ssn':
-      return `***-**-${value.slice(-4)}`;
-      // 123-45-6789 → ***-**-6789
-
-    default:
-      return '[MASKED]';
-  }
-}
-```
-
-## Structured Logging with Built-in Redaction
-
-### PII-Aware Logger
-
-```javascript
-class PIIAwareLogger {
-  constructor(sensitiveFields) {
-    this.sensitiveFields = new Set(sensitiveFields);
-  }
-
-  sanitizeObject(obj) {
-    const sanitized = {};
-    for (const [key, value] of Object.entries(obj)) {
-      if (this.sensitiveFields.has(key.toLowerCase())) {
-        sanitized[key] = '[REDACTED]';
-      } else if (typeof value === 'object' && value !== null) {
-        sanitized[key] = this.sanitizeObject(value);
-      } else {
-        sanitized[key] = value;
-      }
-    }
-    return sanitized;
-  }
-
-  log(level, message, context = {}) {
-    const sanitizedContext = this.sanitizeObject(context);
-    console.log(JSON.stringify({
-      level,
-      message,
-      ...sanitizedContext,
-      timestamp: new Date().toISOString(),
-    }));
-  }
-}
-
-const logger = new PIIAwareLogger([
-  'email', 'password', 'ssn', 'credit_card', 'phone',
-  'date_of_birth', 'address', 'name', 'first_name', 'last_name',
-  'card_number', 'cvv', 'national_id', 'passport',
-]);
-
-// Usage — PII fields are automatically redacted
-logger.log('info', 'User created', {
-  user_id: 123,
-  email: 'sarah@example.com',  // → [REDACTED]
-  plan: 'premium',
-});
-```
-
-## Redaction Validation
-
-### Testing Redaction Effectiveness
-
-```python
-def test_redaction_completeness():
-    """Assert that no real PII appears in redacted output."""
-    real_emails = load_production_emails()  # Hashed for comparison
-    redacted_data = load_redacted_dataset()
-
-    for record in redacted_data:
-        for field_value in record.values():
-            if isinstance(field_value, str):
-                # Check no real email pattern exists
-                assert not re.search(r'@(gmail|yahoo|outlook|company)', field_value), \
-                    f"Possible real email in redacted data: {field_value}"
-
-                # Check no SSN pattern exists
-                assert not re.search(r'\b\d{3}-\d{2}-\d{4}\b', field_value), \
-                    f"Possible SSN in redacted data: {field_value}"
-
-                # Check against known production values
-                hashed = hashlib.sha256(field_value.encode()).hexdigest()
-                assert hashed not in real_emails, \
-                    f"Production PII found in redacted data"
-```
-
-## Performance Considerations
-
-| Strategy | Throughput | Memory | Latency |
-|----------|-----------|--------|---------|
-| Regex replacement | Very high | Low | < 1ms per record |
-| NLP-based detection | Low | High | 50-200ms per record |
-| Format-preserving encryption | High | Low | < 5ms per record |
-| Tokenization (with vault) | Medium | Low | 10-50ms per record (network) |
-| Deterministic HMAC | Very high | Low | < 1ms per record |

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

@@ -1,25 +0,0 @@
-# Eval Assertions — Secret Management
-
-## Eval 1: Secret Rotation Strategy
-
-**ID:** `secret-rotation-strategy`
-
-| # | Assertion Type | Expected Value | Rationale |
-|---|---------------|----------------|-----------|
-| 1 | content_matches_regex | `Vault\|vault\|AWS Secrets Manager\|GCP Secret Manager\|secret.*manager` | Must recommend a proper secrets management platform to replace base64-encoded Kubernetes Secrets. |
-| 2 | content_matches_regex | `rotation\|rotate\|schedule\|frequenc\|interval\|30.*day\|90.*day` | Must define specific rotation schedules for different secret types based on risk profile. |
-| 3 | content_matches_regex | `zero.downtime\|graceful\|dual.credential\|rolling\|overlap` | Must address zero-downtime rotation strategy since shared credentials across services require coordination. |
-| 4 | content_matches_regex | `dynamic.*secret\|short.lived\|ephemeral\|per.request\|lease` | Must recommend dynamic secrets for database credentials to eliminate long-lived shared passwords. |
-| 5 | content_matches_regex | `TLS\|certificate\|cert.manager\|auto.renew\|PKI\|Let.*Encrypt` | Must urgently address TLS certificate automation given the 2-month expiry timeline. |
-
-## Eval 2: Vault Integration Pattern
-
-**ID:** `secret-vault-integration`
-
-| # | Assertion Type | Expected Value | Rationale |
-|---|---------------|----------------|-----------|
-| 1 | content_matches_regex | `Kubernetes auth\|kubernetes.*method\|auth.*method\|service.account` | Must configure Kubernetes authentication for Vault to leverage existing pod identity. |
-| 2 | content_matches_regex | `vault.agent\|sidecar\|inject\|annotation\|vault.hashicorp` | Must describe the Vault Agent sidecar injection pattern for transparent secret delivery to pods. |
-| 3 | content_matches_regex | `polic\|role\|namespace\|path\|capabilities` | Must define namespace-scoped Vault policies to enforce least-privilege access per service. |
-| 4 | content_matches_regex | `database.*engine\|dynamic.*credential\|database.*role\|secret.*engine` | Must configure database secret engines for PostgreSQL and MongoDB dynamic credentials. |
-| 5 | content_matches_regex | `PKI\|pki.*engine\|certificate\|mTLS\|mutual.*TLS` | Must address PKI engine setup for mTLS certificate generation as specified in requirements. |

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/secret-management/evals/evals.json

@@ -1,68 +0,0 @@
-[
-  {
-    "id": "secret-rotation-strategy",
-    "title": "Design a secret rotation strategy for a microservices architecture",
-    "description": "Given a microservices setup with various secret types, the skill should produce a rotation strategy with schedules, methods, and zero-downtime considerations.",
-    "prompt": "Design a secret rotation strategy for our microservices platform:\n\n- 12 microservices running in Kubernetes\n- PostgreSQL database with shared credentials across 4 services\n- Redis with a single AUTH password\n- 3 third-party API keys (Stripe, SendGrid, Twilio)\n- TLS certificates managed manually, expiring in 2 months\n- JWT signing key shared across auth service and 3 consumer services\n- All secrets currently stored as Kubernetes Secrets (base64 encoded)\n- No vault infrastructure in place",
-    "assertions": [
-      {
-        "type": "content_matches_regex",
-        "value": "Vault|vault|AWS Secrets Manager|GCP Secret Manager|secret.*manager",
-        "description": "Must recommend implementing a vault or managed secret service"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "rotation|rotate|schedule|frequenc|interval|30.*day|90.*day",
-        "description": "Must define rotation schedules for different secret types"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "zero.downtime|graceful|dual.credential|rolling|overlap",
-        "description": "Must address zero-downtime rotation strategy (dual credentials or rolling)"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "dynamic.*secret|short.lived|ephemeral|per.request|lease",
-        "description": "Must recommend dynamic/short-lived secrets for database credentials"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "TLS|certificate|cert.manager|auto.renew|PKI|Let.*Encrypt",
-        "description": "Must address TLS certificate automation before the 2-month expiry"
-      }
-    ]
-  },
-  {
-    "id": "secret-vault-integration",
-    "title": "Design a HashiCorp Vault integration for Kubernetes workloads",
-    "description": "Given a Kubernetes deployment, the skill should provide a vault integration pattern including agent injection, policy design, and secret engine configuration.",
-    "prompt": "We want to integrate HashiCorp Vault with our Kubernetes cluster for secret management. We have:\n\n- 3 namespaces: production, staging, development\n- Each namespace has 4-6 services that need database credentials\n- Services are written in Go, Python, and Node.js\n- We need to support both sidecar injection and direct API access\n- PostgreSQL and MongoDB databases need dynamic credentials\n- Some services need PKI certificates for mTLS\n\nDesign the Vault integration architecture.",
-    "assertions": [
-      {
-        "type": "content_matches_regex",
-        "value": "Kubernetes auth|kubernetes.*method|auth.*method|service.account",
-        "description": "Must configure Kubernetes authentication method for Vault"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "vault.agent|sidecar|inject|annotation|vault.hashicorp",
-        "description": "Must describe Vault Agent sidecar injection pattern"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "polic|role|namespace|path|capabilities",
-        "description": "Must define Vault policies scoped per namespace"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "database.*engine|dynamic.*credential|database.*role|secret.*engine",
-        "description": "Must configure database secret engines for dynamic credentials"
-      },
-      {
-        "type": "content_matches_regex",
-        "value": "PKI|pki.*engine|certificate|mTLS|mutual.*TLS",
-        "description": "Must address PKI secret engine for mTLS certificate generation"
-      }
-    ]
-  }
-]

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

@@ -1,35 +0,0 @@
-# Skill Creator — Eval Assertions
-
-## Eval 1: Create a new GraphQL Gateway skill
-
-### Assertion 1: Valid YAML frontmatter
-The skill-creator must generate a SKILL.md with properly formatted YAML frontmatter between `---` delimiters. Required fields: name (kebab-case), description (string), license (MIT or Apache-2.0), metadata (object with author and version), compatibility (string listing platforms).
-
-### Assertion 2: Trigger-based description
-The description field must start with "Use when" and list 3-6 specific scenarios where the skill should be loaded. This is critical because the description drives the skill routing engine — vague descriptions cause mis-routing.
-
-### Assertion 3: WHAT + WHY instructions
-Each numbered instruction must state what to do AND why, using "because" to connect the action to its rationale. This format enables the LLM to adapt instructions to context rather than following them mechanically.
-
-### Assertion 4: References table
-The SKILL.md must include a References table with columns for File and "Load when" conditions. Each reference should point to a file in the `references/` directory. This enables progressive disclosure — loading detailed context only when needed.
-
-### Assertion 5: Valid evals
-The skill-creator must produce an evals.json file with valid JSON containing at least 2 eval objects. Each eval must have a `prompt` field (the test scenario) and an `assertions` array with at least 5 items (behavioral checks on the skill's output).
-
-## Eval 2: Evaluate python-best-practices skill
-
-### Assertion 1: Reads existing evals
-Before running evaluations, the skill-creator must read the target skill's evals.json to understand what prompts and assertions to test. This ensures the evaluation uses the skill's own test suite rather than inventing ad-hoc checks.
-
-### Assertion 2: Individual assertion checking
-Each assertion must be checked independently and reported separately. Lumping assertions together as "mostly passed" loses the granularity needed to identify specific instruction weaknesses.
-
-### Assertion 3: Evidence-based reporting
-Every pass/fail verdict must include specific evidence — a quote or summary from the skill's output that supports the verdict. Without evidence, the eval results are opinions rather than measurements.
-
-### Assertion 4: Flaky assertion detection
-The skill-creator should identify assertions that might pass inconsistently across runs — typically assertions that depend on exact phrasing rather than behavioral substance. These should be flagged for rewriting.
-
-### Assertion 5: Actionable improvements
-For failed assertions, the skill-creator must provide specific suggestions for improving the skill's instructions to increase the pass rate. Generic advice like "improve the instructions" is not actionable.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/skill-creator/evals/evals.json

@@ -1,24 +0,0 @@
-{
-  "evals": [
-    {
-      "prompt": "Create a new skill called 'graphql-gateway' for building GraphQL federation gateways with Apollo Router, subgraph composition, and schema stitching.",
-      "assertions": [
-        "generates a SKILL.md with valid YAML frontmatter including name, description, license, metadata, and compatibility fields",
-        "description starts with 'Use when' and includes 3-6 specific trigger conditions for GraphQL gateway scenarios",
-        "includes 12-18 numbered instructions in WHAT + WHY format with 'because' reasoning",
-        "creates a References table with 3-6 reference files and 'Load when' conditions",
-        "produces an evals.json with at least 2 eval prompts and 5 assertions each"
-      ]
-    },
-    {
-      "prompt": "Evaluate the python-best-practices skill by running its evals and reporting which assertions pass or fail with evidence.",
-      "assertions": [
-        "reads the existing skill's evals.json before running evaluations",
-        "runs each eval prompt and checks every assertion individually",
-        "reports pass/fail per assertion with specific evidence from the output",
-        "identifies any flaky or borderline assertions that might fail inconsistently",
-        "provides actionable improvement suggestions for failed assertions"
-      ]
-    }
-  ]
-}

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

@@ -1,21 +0,0 @@
-# Spring Boot Skill Assertions
-
-## Eval 1: Secure REST API with Spring Security
-
-| # | Assertion | Type | Expected Value | Rationale |
-|---|-----------|------|----------------|-----------|
-| 1 | Defines SecurityFilterChain | contains | `SecurityFilterChain` | Spring Security 6 requires a SecurityFilterChain bean with the lambda DSL; the removed WebSecurityConfigurerAdapter pattern will not compile. |
-| 2 | Uses Java records | contains | `record ` | DTO types must use Java records for immutability, automatic equals/hashCode/toString, and clear signaling that the type carries data without behavior. |
-| 3 | Uses @PreAuthorize | contains | `@PreAuthorize` | Method-level authorization must use @PreAuthorize with SpEL expressions for domain-level access rules that URL-pattern matching cannot express. |
-| 4 | Uses MockMvc | contains | `MockMvc` | Controller tests must use MockMvc to exercise the full filter chain including security, content negotiation, and exception handling. |
-| 5 | Uses @WebMvcTest | contains | `@WebMvcTest` | Slice tests must use @WebMvcTest to load only the web layer, avoiding the startup cost and complexity of the full application context. |
-
-## Eval 2: Reactive WebFlux Endpoint
-
-| # | Assertion | Type | Expected Value | Rationale |
-|---|-----------|------|----------------|-----------|
-| 1 | Returns Flux | contains | `Flux<` | Streaming reactive endpoints must return Flux to emit multiple values over time, enabling Server-Sent Events and backpressure-aware data flow. |
-| 2 | Uses WebClient | contains | `WebClient` | Non-blocking HTTP calls to external services must use WebClient, which integrates with the reactive pipeline without blocking carrier threads. |
-| 3 | Defines SecurityWebFilterChain | contains | `SecurityWebFilterChain` | Reactive applications must use SecurityWebFilterChain instead of the servlet-based SecurityFilterChain for compatibility with the Netty runtime. |
-| 4 | Uses WebTestClient | contains | `WebTestClient` | Reactive endpoint tests must use WebTestClient, which supports streaming assertions and reactive security testing that MockMvc cannot handle. |
-| 5 | Produces TEXT_EVENT_STREAM | contains | `TEXT_EVENT_STREAM` | SSE endpoints must declare the TEXT_EVENT_STREAM media type so clients receive a proper event stream with keep-alive semantics. |