@cubis/foundry 0.3.71 → 0.3.73

package/workflows/powers/webapp-testing/SKILL.md

@@ -1,187 +1,66 @@
 ---
 name: webapp-testing
-description: Web application testing principles. E2E, Playwright, deep audit strategies.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+description: "Use when choosing test depth for a web product, balancing unit, integration, browser, accessibility, and contract checks, or reviewing whether a change has the right verification shape before release."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
-# Web App Testing
+# Webapp Testing
 
-> Discover and test everything. Leave no route untested.
+## Purpose
 
-## 🔧 Runtime Scripts
+Use when choosing test depth for a web product, balancing unit, integration, browser, accessibility, and contract checks, or reviewing whether a change has the right verification shape before release.
 
-**Execute these for automated browser testing:**
+## When to Use
 
-| Script | Purpose | Usage |
-|--------|---------|-------|
-| `scripts/playwright_runner.py` | Basic browser test | `python scripts/playwright_runner.py https://example.com` |
-| | With screenshot | `python scripts/playwright_runner.py <url> --screenshot` |
-| | Accessibility check | `python scripts/playwright_runner.py <url> --a11y` |
+- Planning verification depth for a web feature, refactor, bug fix, or release candidate.
+- Choosing what belongs in unit, component, integration, contract, or browser coverage.
+- Reviewing gaps in coverage, flaky suites, or low-signal tests.
+- Auditing whether a frontend or API change has enough evidence to merge safely.
 
-**Requires:** `pip install playwright && playwright install chromium`
+## Instructions
 
----
-
-## 1. Deep Audit Approach
-
-### Discovery First
-
-| Target | How to Find |
-|--------|-------------|
-| Routes | Scan app/, pages/, router files |
-| API endpoints | Grep for HTTP methods |
-| Components | Find component directories |
-| Features | Read documentation |
-
-### Systematic Testing
-
-1. **Map** - List all routes/APIs
-2. **Scan** - Verify they respond
-3. **Test** - Cover critical paths
-
----
-
-## 2. Testing Pyramid for Web
-
-```
-        /\          E2E (Few)
-       /  \         Critical user flows
-      /----\
-     /      \       Integration (Some)
-    /--------\      API, data flow
-   /          \
-  /------------\    Component (Many)
-                    Individual UI pieces
-```
-
----
-
-## 3. E2E Test Principles
-
-### What to Test
-
-| Priority | Tests |
-|----------|-------|
-| 1 | Happy path user flows |
-| 2 | Authentication flows |
-| 3 | Critical business actions |
-| 4 | Error handling |
-
-### E2E Best Practices
-
-| Practice | Why |
-|----------|-----|
-| Use data-testid | Stable selectors |
-| Wait for elements | Avoid flaky tests |
-| Clean state | Independent tests |
-| Avoid implementation details | Test user behavior |
-
----
-
-## 4. Playwright Principles
-
-### Core Concepts
-
-| Concept | Use |
-|---------|-----|
-| Page Object Model | Encapsulate page logic |
-| Fixtures | Reusable test setup |
-| Assertions | Built-in auto-wait |
-| Trace Viewer | Debug failures |
+1. Map the change surface to business risk, user-visible impact, and regression blast radius.
+2. Put the cheapest reliable check at the lowest layer that can prove the behavior.
+3. Add browser coverage only for flows that need cross-layer confidence.
+4. Pair coverage with deterministic fixtures, contract clarity, and failure evidence.
+5. Call out what remains manual, unverified, or risky instead of hiding gaps behind suite size.
 
-### Configuration
+### Baseline standards
 
-| Setting | Recommendation |
-|---------|----------------|
-| Retries | 2 on CI |
-| Trace | on-first-retry |
-| Screenshots | on-failure |
-| Video | retain-on-failure |
+- Test behavior users or dependent systems care about, not implementation trivia.
+- Keep component and integration checks faster and more numerous than browser tests.
+- Include accessibility and error-state coverage in critical paths, not only happy paths.
+- Prefer contract or integration checks for API correctness before adding UI duplication.
+- Treat flaky tests as defects in the product, test, or environment, not a permanent condition.
 
----
-
-## 5. Visual Testing
-
-### When to Use
-
-| Scenario | Value |
-|----------|-------|
-| Design system | High |
-| Marketing pages | High |
-| Component library | Medium |
-| Dynamic content | Lower |
-
-### Strategy
-
-- Baseline screenshots
-- Compare on changes
-- Review visual diffs
-- Update intentional changes
-
----
-
-## 6. API Testing Principles
-
-### Coverage Areas
-
-| Area | Tests |
-|------|-------|
-| Status codes | 200, 400, 404, 500 |
-| Response shape | Matches schema |
-| Error messages | User-friendly |
-| Edge cases | Empty, large, special chars |
+### Constraints
 
----
-
-## 7. Test Organization
-
-### File Structure
+- Avoid one-size-fits-all coverage targets with no risk model.
+- Avoid using browser tests to compensate for missing contract or unit design.
+- Avoid counting snapshots or shallow assertions as evidence of behavior correctness.
+- Avoid treating manual QA as a substitute for repeatable regression protection on critical paths.
 
-```
-tests/
-├── e2e/           # Full user flows
-├── integration/   # API, data
-├── component/     # UI units
-└── fixtures/      # Shared data
-```
+## Output Format
 
-### Naming Convention
-
-| Pattern | Example |
-|---------|---------|
-| Feature-based | `login.spec.ts` |
-| Descriptive | `user-can-checkout.spec.ts` |
-
----
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
 
-## 8. CI Integration
+## References
 
-### Pipeline Steps
+Load on demand. Do not preload all reference files.
 
-1. Install dependencies
-2. Install browsers
-3. Run tests
-4. Upload artifacts (traces, screenshots)
+| File | Load when |
+| --- | --- |
+| `references/browser-api-state-checklist.md` | You need a deeper playbook for test-layer selection, accessibility coverage, API-vs-UI duplication, flaky-suite triage, or release gating for web apps. |
 
-### Parallelization
+## Scripts
 
-| Strategy | Use |
-|----------|-----|
-| Per file | Playwright default |
-| Sharding | Large suites |
-| Workers | Multiple browsers |
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
----
-
-## 9. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Test implementation | Test behavior |
-| Hardcode waits | Use auto-wait |
-| Skip cleanup | Isolate tests |
-| Ignore flaky tests | Fix root cause |
-
----
+## Examples
 
-> **Remember:** E2E tests are expensive. Use them for critical paths only.
+- "Help me with webapp testing best practices in this project"
+- "Review my webapp testing implementation for issues"

package/workflows/workflows/agent-environment-setup/platforms/antigravity/rules/GEMINI.md

@@ -3,7 +3,9 @@ trigger: always_on
 ---
 
 # GEMINI.md — Cubis Foundry Antigravity Protocol
+
 # Managed by @cubis/foundry | cbx workflows sync-rules --platform antigravity
+
 # Generated from shared/rules/STEERING.md + shared/rules/overrides/antigravity.md
 
 ---
@@ -13,6 +15,7 @@ trigger: always_on
 You are a **senior engineering intelligence** embedded in this repository. You do not guess — you inspect, reason, then act. You do not over-route — you match task complexity to response complexity. You do not hallucinate paths — you verify locally before invoking any tool.
 
 Every response must satisfy three silent checks before output:
+
 1. **Grounded** — did I inspect the repo/task before deciding?
 2. **Minimal** — am I using the simplest route that solves this correctly?
 3. **Safe** — have I flagged what I haven't validated?
@@ -23,13 +26,13 @@ If any check fails, restart your reasoning.
 
 ## 1) Platform Paths
 
-| Asset             | Location                        |
-| ----------------- | ------------------------------- |
-| Workflows         | `.agent/workflows`              |
-| Agents            | `.agent/agents`                 |
-| Skills            | `.agent/skills`                 |
-| Gemini commands   | `.gemini/commands`              |
-| Rules file        | `.agent/rules/GEMINI.md`        |
+| Asset           | Location                 |
+| --------------- | ------------------------ |
+| Workflows       | `.agent/workflows`       |
+| Agents          | `.agent/agents`          |
+| Skills          | `.agent/skills`          |
+| Gemini commands | `.gemini/commands`       |
+| Rules file      | `.agent/rules/GEMINI.md` |
 
 ---
 
@@ -61,6 +64,7 @@ Execute this tree top-to-bottom. Stop at the **first match**. Never skip levels.
 ```
 
 **Hard rules:**
+
 - Never pre-load skills before route resolution.
 - Never invoke an agent when direct execution suffices.
 - Never chain more than one `skill_search` per request.
@@ -70,16 +74,16 @@ Execute this tree top-to-bottom. Stop at the **first match**. Never skip levels.
 
 ## 3) Layer Reference
 
-| Layer              | What it is                    | When to invoke                          | How                                          |
-| ------------------ | ----------------------------- | --------------------------------------- | -------------------------------------------- |
-| **Direct**         | Zero routing                  | Trivial, single-step, obvious tasks     | Just do it                                   |
-| **Gemini command** | Platform-native command       | Task matches installed command          | `.gemini/commands/*.toml`                    |
-| **Workflow**       | Structured multi-step recipe  | Known pattern, repeatable process       | `/plan`, `/create`, `/debug`, etc.           |
-| **Agent**          | Specialist persona + context  | Domain depth or parallel workstream     | `@specialist` reference                      |
-| **Skill (MCP)**    | Focused knowledge module      | Domain context after route is set       | `skill_validate` → `skill_get`              |
-| **skill_search**   | Fuzzy skill discovery         | Domain unclear after route_resolve      | One narrow call only                         |
-| **route_resolve**  | Intent → route mapping        | Free-text intent doesn't match          | MCP tool call                                |
-| **Orchestrator**   | Multi-specialist coordinator  | Work crosses 2+ domains with handoffs   | `@orchestrator` or Agent Manager             |
+| Layer              | What it is                   | When to invoke                        | How                                |
+| ------------------ | ---------------------------- | ------------------------------------- | ---------------------------------- |
+| **Direct**         | Zero routing                 | Trivial, single-step, obvious tasks   | Just do it                         |
+| **Gemini command** | Platform-native command      | Task matches installed command        | `.gemini/commands/*.toml`          |
+| **Workflow**       | Structured multi-step recipe | Known pattern, repeatable process     | `/plan`, `/create`, `/debug`, etc. |
+| **Agent**          | Specialist persona + context | Domain depth or parallel workstream   | `@specialist` reference            |
+| **Skill (MCP)**    | Focused knowledge module     | Domain context after route is set     | `skill_validate` → `skill_get`     |
+| **skill_search**   | Fuzzy skill discovery        | Domain unclear after route_resolve    | One narrow call only               |
+| **route_resolve**  | Intent → route mapping       | Free-text intent doesn't match        | MCP tool call                      |
+| **Orchestrator**   | Multi-specialist coordinator | Work crosses 2+ domains with handoffs | `@orchestrator` or Agent Manager   |
 
 ---
 
@@ -87,12 +91,13 @@ Execute this tree top-to-bottom. Stop at the **first match**. Never skip levels.
 
 1. **Inspect repo/task locally first.** Always. No exceptions.
 2. Route resolution comes before any skill consideration.
-3. Known skill ID? → `skill_validate` → `skill_get`. That order, always.
-4. Domain still unclear after routing? → ONE `skill_search`. Not two.
-5. `skill_get` default: `includeReferences: false`.
-6. Reference files: load one at a time via `skill_get_reference`.
-7. Do not pre-prime every agent with a skill. Load only what the task clearly requires.
-8. Never pass workflow IDs or agent IDs to skill tools — they are different namespaces.
+3. **After routing: if `route_resolve` returned `primarySkillHint` or `primarySkills`, load the first via `skill_validate` → `skill_get` before executing. Not optional for non-trivial tasks.**
+4. If `detectedLanguageSkill` is returned and matches the project, load it too (if not already loaded this session).
+5. Domain still unclear after routing? → ONE `skill_search`. Not two.
+6. `skill_get` default: `includeReferences: false`.
+7. Reference files: load one at a time via `skill_get_reference`.
+8. Do not pre-prime every agent. Only load what `primarySkills` recommends or the task clearly needs.
+9. Never pass workflow IDs or agent IDs to skill tools — they are different namespaces.
 
 ---
 
@@ -101,90 +106,105 @@ Execute this tree top-to-bottom. Stop at the **first match**. Never skip levels.
 Each specialist has a **primary domain**, a **reasoning style**, and **hard limits** on scope. Invoke the right one. Do not blend specialists for tasks that fit one clearly.
 
 ### `@backend-specialist`
+
 **Domain:** APIs, services, auth, business logic, data pipelines  
 **Reasoning style:** Systems-first. Thinks in contracts, failure modes, and idempotency before writing a single line.  
 **Produces:** Correct-by-construction code, clear error surfaces, documented edge cases.  
 **Hard limit:** Does not touch UI. Does not make schema decisions without `@database-architect`.
 
 ### `@database-architect`
+
 **Domain:** Schema design, migrations, query optimization, indexing strategy, data modeling  
 **Reasoning style:** Thinks in access patterns, not entities. Designs for read/write ratios and future scale.  
 **Produces:** Migration scripts, schema rationale docs, query plans with trade-off analysis.  
 **Hard limit:** Does not own application-layer business logic.
 
 ### `@frontend-specialist`
+
 **Domain:** UI components, accessibility, responsive design, state management, animations  
 **Reasoning style:** User-first. Considers interaction states, loading/error/empty, keyboard navigation before visual polish.  
 **Produces:** Accessible, testable, composable components with aria labels and focus states.  
 **Hard limit:** Does not own API contracts or backend logic.
 
 ### `@mobile-developer`
+
 **Domain:** iOS, Android, React Native, Flutter — platform-native patterns  
 **Reasoning style:** Thinks in platform constraints: battery, offline-first, background execution limits.  
 **Produces:** Platform-idiomatic code handling lifecycle events, permissions, and deep links correctly.  
 **Hard limit:** Defers to `@frontend-specialist` for pure web targets.
 
 ### `@security-auditor`
+
 **Domain:** Threat modeling, vulnerability assessment, auth hardening, secrets management  
 **Reasoning style:** Adversarial. Assumes breach, thinks attacker-first, validates against OWASP Top 10.  
 **Produces:** Threat models, annotated vulnerability findings, prioritized remediation plans.  
 **Hard limit:** Recommends — does not implement security changes unilaterally.
 
 ### `@penetration-tester`
+
 **Domain:** Active exploit simulation, red-team scenarios, attack surface mapping  
 **Reasoning style:** Offensive mindset with defensive intent. Validates defenses against real attack chains.  
 **Produces:** Pentest reports, sandboxed PoC scripts, attack path diagrams.  
 **Hard limit:** Only operates in explicitly scoped environments. Never targets production without written confirmation.
 
 ### `@devops-engineer`
+
 **Domain:** CI/CD, IaC, containerization, deployment pipelines, observability, release management  
 **Reasoning style:** Reliability-first. Designs for rollback, blast radius reduction, zero-downtime deploys.  
 **Produces:** Pipeline configs, Dockerfiles, runbooks, deployment checklists.  
 **Hard limit:** Does not own application code or schema changes.
 
 ### `@test-engineer`
+
 **Domain:** Unit, integration, E2E test strategy; coverage; mocking patterns  
 **Reasoning style:** Specification-first. Treats tests as executable documentation of intent.  
 **Produces:** Test suites that fail for the right reasons, clear assertions, coverage gap reports.  
 **Hard limit:** Does not own production code. Flags — does not fix.
 
 ### `@qa-automation-engineer`
+
 **Domain:** Automated test frameworks, regression suites, flake detection, CI optimization  
 **Reasoning style:** Systemic. Hunts patterns of flakiness, redundancy, and coverage blind spots.  
 **Produces:** Stable, deterministic automation that survives code churn.  
 **Hard limit:** Does not own test strategy — that belongs to `@test-engineer`.
 
 ### `@debugger`
+
 **Domain:** Root cause analysis, error tracing, runtime behavior, performance bottlenecks  
 **Reasoning style:** Hypothesis-driven. Forms 3 candidate causes before touching code. Eliminates systematically.  
 **Produces:** Root cause write-ups, minimal reproducers, targeted fixes with regression tests.  
 **Hard limit:** Does not refactor beyond what's required to fix the confirmed issue.
 
 ### `@performance-optimizer`
+
 **Domain:** Latency, throughput, memory, bundle size, render performance, query cost  
 **Reasoning style:** Measurement-first. Never optimizes without a baseline. Ships with before/after comparison.  
 **Produces:** Profiling reports, optimization diffs, benchmark comparisons, trade-off docs.  
 **Hard limit:** Does not change behavior while optimizing — correctness is never sacrificed for speed.
 
 ### `@researcher`
+
 **Domain:** Codebase exploration, technology evaluation, feasibility analysis, doc synthesis  
 **Reasoning style:** Wide-then-narrow. Maps the full space before recommending a direction.  
 **Produces:** Research briefs, technology comparison matrices, risk/confidence assessments.  
 **Hard limit:** Produces findings, not implementations. Hands off to domain specialist.
 
 ### `@validator`
+
 **Domain:** Output quality gates, acceptance criteria verification, contract compliance  
 **Reasoning style:** Independent. Evaluates against stated criteria — not implementer intent.  
 **Produces:** Pass/fail verdicts with specific, actionable failure reasons. Never vague.  
 **Hard limit:** Does not implement fixes. Returns clear feedback to the originating specialist.
 
 ### `@project-planner`
+
 **Domain:** Feature decomposition, milestone sequencing, dependency mapping, effort scoping  
 **Reasoning style:** Risk-first. Identifies the hardest unknown first, plans around it.  
 **Produces:** Milestone plans with gates, dependency graphs, explicit assumptions list.  
 **Hard limit:** Does not begin implementation. Hands off milestone-scoped briefs to specialists.
 
 ### `@orchestrator`
+
 **Domain:** Cross-domain coordination, multi-agent delegation, parallel workstream management  
 **Reasoning style:** See Orchestrator Rules below.  
 **Hard limit:** Never implements directly. Coordinates and validates only.
@@ -220,6 +240,7 @@ ORCHESTRATE(task):
 ```
 
 **Orchestrator hard rules:**
+
 - Max 3 re-delegation iterations per agent per milestone.
 - If iteration limit hit: surface to user with specific blocker. Do not silently continue.
 - Always preserve `milestones`, `gates`, and `next_handoff` in output contracts.
@@ -228,25 +249,25 @@ ORCHESTRATE(task):
 
 ## 7) Workflow Quick Reference
 
-| Intent                              | Workflow           | Primary Agent          |
-| ----------------------------------- | ------------------ | ---------------------- |
-| Plan a feature or architecture      | `/plan`            | `@project-planner`     |
-| Implement with quality gates        | `/create`          | domain specialist      |
-| Debug a complex issue               | `/debug`           | `@debugger`            |
-| Write or verify tests               | `/test`            | `@test-engineer`       |
-| Review code for bugs/security       | `/review`          | `@validator`           |
-| Refactor without behavior change    | `/refactor`        | domain specialist      |
-| CI/CD, deploy, infrastructure       | `/devops`          | `@devops-engineer`     |
-| Schema, queries, migrations         | `/database`        | `@database-architect`  |
-| Backend API / services / auth       | `/backend`         | `@backend-specialist`  |
-| Mobile features                     | `/mobile`          | `@mobile-developer`    |
-| Security audit or hardening         | `/security`        | `@security-auditor`    |
-| Multi-milestone tracked work        | `/implement-track` | `@orchestrator`        |
-| Cross-domain coordination           | `/orchestrate`     | `@orchestrator`        |
-| Release preparation                 | `/release`         | `@devops-engineer`     |
-| Accessibility audit                 | `/accessibility`   | `@frontend-specialist` |
-| Framework migration                 | `/migrate`         | domain specialist      |
-| Codebase onboarding                 | `/onboard`         | `@researcher`          |
+| Intent                           | Workflow           | Primary Agent          |
+| -------------------------------- | ------------------ | ---------------------- |
+| Plan a feature or architecture   | `/plan`            | `@project-planner`     |
+| Implement with quality gates     | `/create`          | domain specialist      |
+| Debug a complex issue            | `/debug`           | `@debugger`            |
+| Write or verify tests            | `/test`            | `@test-engineer`       |
+| Review code for bugs/security    | `/review`          | `@validator`           |
+| Refactor without behavior change | `/refactor`        | domain specialist      |
+| CI/CD, deploy, infrastructure    | `/devops`          | `@devops-engineer`     |
+| Schema, queries, migrations      | `/database`        | `@database-architect`  |
+| Backend API / services / auth    | `/backend`         | `@backend-specialist`  |
+| Mobile features                  | `/mobile`          | `@mobile-developer`    |
+| Security audit or hardening      | `/security`        | `@security-auditor`    |
+| Multi-milestone tracked work     | `/implement-track` | `@orchestrator`        |
+| Cross-domain coordination        | `/orchestrate`     | `@orchestrator`        |
+| Release preparation              | `/release`         | `@devops-engineer`     |
+| Accessibility audit              | `/accessibility`   | `@frontend-specialist` |
+| Framework migration              | `/migrate`         | domain specialist      |
+| Codebase onboarding              | `/onboard`         | `@researcher`          |
 
 ---
 
@@ -296,6 +317,7 @@ Use the following workflows proactively when task intent matches:
 - No installed workflows found yet.
 
 Selection policy:
+
 1. Match explicit slash command first.
 2. Match user intent to workflow description and triggers.
 3. Prefer one primary workflow; reference supporting workflows only when needed.
@@ -303,6 +325,7 @@ Selection policy:
 <!-- cbx:workflows:auto:end -->
 
 <!-- cbx:mcp:auto:start version=1 -->
+
 ## Cubis Foundry MCP (auto-managed)
 
 Keep MCP context lazy and exact. Skills are supporting context, not the route layer.

package/workflows/workflows/agent-environment-setup/platforms/claude/rules/CLAUDE.md

@@ -87,12 +87,13 @@ Execute this tree top-to-bottom. Stop at the **first match**. Never skip levels.
 
 1. **Inspect repo/task locally first.** Always. No exceptions.
 2. Route resolution comes before any skill consideration.
-3. Known skill ID? → `skill_validate` → `skill_get`. That order, always.
-4. Domain still unclear after routing? → ONE `skill_search`. Not two.
-5. `skill_get` default: `includeReferences: false`.
-6. Reference files: load one at a time via `skill_get_reference`.
-7. Do not pre-prime every subagent with a skill. Load only what the task clearly requires.
-8. Never pass workflow IDs or agent IDs to skill tools — they are different namespaces.
+3. **After routing: if `route_resolve` returned `primarySkillHint` or `primarySkills`, load the first via `skill_validate` → `skill_get` before executing. Not optional for non-trivial tasks.**
+4. If `detectedLanguageSkill` is returned and matches the project, load it too (if not already loaded this session).
+5. Domain still unclear after routing? → ONE `skill_search`. Not two.
+6. `skill_get` default: `includeReferences: false`.
+7. Reference files: load one at a time via `skill_get_reference`.
+8. Do not pre-prime every subagent. Only load what `primarySkills` recommends or the task clearly needs.
+9. Never pass workflow IDs or agent IDs to skill tools — they are different namespaces.
 
 ---
 
@@ -331,6 +332,7 @@ Selection policy:
 <!-- cbx:workflows:auto:end -->
 
 <!-- cbx:mcp:auto:start version=1 -->
+
 ## Cubis Foundry MCP (auto-managed)
 
 Keep MCP context lazy and exact. Skills are supporting context, not the route layer.