agentscamp 0.2.0 → 0.3.0

package/content/manifest.json

@@ -1,10 +1,10 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-06-18T01:25:44.460Z",
+  "generatedAt": "2026-06-18T01:57:52.358Z",
   "counts": {
-    "agents": 49,
-    "skills": 49,
-    "commands": 40
+    "agents": 58,
+    "skills": 52,
+    "commands": 43
   },
   "items": [
     {
@@ -113,6 +113,36 @@
       "installAs": "agents/browser-agent-engineer.md",
       "url": "https://agentscamp.com/agents/data-ai/browser-agent-engineer"
     },
+    {
+      "id": "agents/ci-cd-engineer",
+      "type": "agent",
+      "slug": "ci-cd-engineer",
+      "category": "infrastructure-devops",
+      "title": "CI/CD Engineer",
+      "description": "Use this agent to design, speed up, and harden CI/CD pipelines on any provider (GitHub Actions, GitLab CI, CircleCI, Buildkite). Examples — setting up a build→test→deploy pipeline from scratch, cutting a 25-minute CI run down with caching and matrix parallelism, adding a canary or blue-green deploy with automatic rollback, or reviewing a workflow for leaked secrets, over-broad tokens, and unpinned third-party actions.",
+      "topics": [
+        "devops-infra"
+      ],
+      "model": "sonnet",
+      "file": "agents/ci-cd-engineer.md",
+      "installAs": "agents/ci-cd-engineer.md",
+      "url": "https://agentscamp.com/agents/infrastructure-devops/ci-cd-engineer"
+    },
+    {
+      "id": "agents/cli-tooling-engineer",
+      "type": "agent",
+      "slug": "cli-tooling-engineer",
+      "category": "developer-tools",
+      "title": "CLI Tooling Engineer",
+      "description": "Use this agent to design or build a command-line tool — subcommand and flag layout, --help and error UX, exit codes, --json/machine output, config precedence, stdin/stdout/stderr and pipe behavior, TTY/color/NO_COLOR detection, and CLI testing. Examples — \"design the command and flag surface for our new deploy CLI\", \"this tool prints errors to stdout and returns 0 on failure — fix its ergonomics\", \"make our command pipe-friendly and add a --json mode for CI\".",
+      "topics": [
+        "coding-languages"
+      ],
+      "model": "sonnet",
+      "file": "agents/cli-tooling-engineer.md",
+      "installAs": "agents/cli-tooling-engineer.md",
+      "url": "https://agentscamp.com/agents/developer-tools/cli-tooling-engineer"
+    },
     {
       "id": "agents/cloud-architect",
       "type": "agent",
@@ -144,6 +174,37 @@
       "installAs": "agents/code-reviewer.md",
       "url": "https://agentscamp.com/agents/quality-security/code-reviewer"
     },
+    {
+      "id": "agents/context-engineer",
+      "type": "agent",
+      "slug": "context-engineer",
+      "category": "meta-orchestration",
+      "title": "Context Engineer",
+      "description": "Use this agent to engineer what an LLM agent carries in its context window — deciding what to include vs exclude vs retrieve on demand, designing project/agent memory (CLAUDE.md), compacting growing history, and allocating the token budget across system prompt, memory, retrieved docs, tool results, and conversation. Examples — \"my agent forgets the schema we agreed on three turns ago\", \"the agent gets dumber and more inconsistent as the chat grows\", \"we're burning 60k tokens of tool output every turn\", \"what should this support agent always know vs look up?\".",
+      "topics": [
+        "ai-agents-systems",
+        "workflow-prompting"
+      ],
+      "model": "opus",
+      "file": "agents/context-engineer.md",
+      "installAs": "agents/context-engineer.md",
+      "url": "https://agentscamp.com/agents/meta-orchestration/context-engineer"
+    },
+    {
+      "id": "agents/csharp-pro",
+      "type": "agent",
+      "slug": "csharp-pro",
+      "category": "language-specialists",
+      "title": "C# Pro",
+      "description": "Use this agent for modern C#/.NET 8+ — records, pattern matching, nullable reference types, correct async/await, LINQ, Span<T>, and source generators — plus ASP.NET Core and EF Core. Examples — building a minimal-API service, fixing an EF Core N+1 or tracking leak, hunting a deadlock from sync-over-async, or turning on nullable reference types across a project.",
+      "topics": [
+        "coding-languages"
+      ],
+      "model": "sonnet",
+      "file": "agents/csharp-pro.md",
+      "installAs": "agents/csharp-pro.md",
+      "url": "https://agentscamp.com/agents/language-specialists/csharp-pro"
+    },
     {
       "id": "agents/data-engineer",
       "type": "agent",
@@ -174,6 +235,21 @@
       "installAs": "agents/data-scientist.md",
       "url": "https://agentscamp.com/agents/data-ai/data-scientist"
     },
+    {
+      "id": "agents/database-architect",
+      "type": "agent",
+      "slug": "database-architect",
+      "category": "core-development",
+      "title": "Database Architect",
+      "description": "Use this agent to design data models and storage strategy from access patterns — schema design, normalization vs deliberate denormalization, relational vs document vs key-value vs wide-column vs graph selection, indexing, partitioning/sharding, transaction boundaries, and consistency models. Examples — modeling a new feature's schema, choosing a database for a write-heavy event workload, reviewing a schema for missing indexes or scaling cliffs, planning how to shard a table that no longer fits one node.",
+      "topics": [
+        "architecture"
+      ],
+      "model": "opus",
+      "file": "agents/database-architect.md",
+      "installAs": "agents/database-architect.md",
+      "url": "https://agentscamp.com/agents/core-development/database-architect"
+    },
     {
       "id": "agents/debugger",
       "type": "agent",
@@ -234,6 +310,22 @@
       "installAs": "agents/documentation-engineer.md",
       "url": "https://agentscamp.com/agents/developer-tools/documentation-engineer"
     },
+    {
+      "id": "agents/eval-driven-developer",
+      "type": "agent",
+      "slug": "eval-driven-developer",
+      "category": "meta-orchestration",
+      "title": "Eval Driven Developer",
+      "description": "Use this agent to drive AI feature development with evals the way TDD drives code with tests — define success criteria and a representative eval set BEFORE iterating on prompts/models, then optimize against measured scores instead of vibes. Examples — \"make the summarizer better\" (turn it into measurable criteria first), \"our prompt change keeps regressing quality, set up a loop that catches it\", \"add an eval gate to CI so a model swap can't silently degrade output\", \"we tweak prompts and pray — give us a baseline and a change-by-change scoreboard\".",
+      "topics": [
+        "llm-evals",
+        "ai-agents-systems"
+      ],
+      "model": "opus",
+      "file": "agents/eval-driven-developer.md",
+      "installAs": "agents/eval-driven-developer.md",
+      "url": "https://agentscamp.com/agents/meta-orchestration/eval-driven-developer"
+    },
     {
       "id": "agents/finetuning-engineer",
       "type": "agent",
@@ -309,6 +401,36 @@
       "installAs": "agents/graphql-architect.md",
       "url": "https://agentscamp.com/agents/core-development/graphql-architect"
     },
+    {
+      "id": "agents/incident-responder",
+      "type": "agent",
+      "slug": "incident-responder",
+      "category": "infrastructure-devops",
+      "title": "Incident Responder",
+      "description": "Use this agent during a live production incident to restore service fast and learn from it — triage and severity, mitigation-first action (roll back, fail over, shed load), change correlation, status updates, and the blameless postmortem. Examples — an alert just fired and the API is 5xx-ing, a deploy broke checkout and you need to decide rollback vs. forward-fix, latency is climbing and the pager is going off, or you're writing the postmortem the morning after.",
+      "topics": [
+        "devops-infra"
+      ],
+      "model": "opus",
+      "file": "agents/incident-responder.md",
+      "installAs": "agents/incident-responder.md",
+      "url": "https://agentscamp.com/agents/infrastructure-devops/incident-responder"
+    },
+    {
+      "id": "agents/java-pro",
+      "type": "agent",
+      "slug": "java-pro",
+      "category": "language-specialists",
+      "title": "Java Pro",
+      "description": "Use this agent for idiomatic, modern Java (17/21+) — records, sealed types, pattern matching, virtual threads and structured concurrency, the Streams API, and JVM/GC performance. Examples — modernizing a legacy POJO-and-thread-pool service to records and virtual threads, diagnosing a GC pause or allocation hotspot, reviewing concurrency correctness, or fixing a Spring Boot service that blocks the wrong threads.",
+      "topics": [
+        "coding-languages"
+      ],
+      "model": "sonnet",
+      "file": "agents/java-pro.md",
+      "installAs": "agents/java-pro.md",
+      "url": "https://agentscamp.com/agents/language-specialists/java-pro"
+    },
     {
       "id": "agents/kubernetes-specialist",
       "type": "agent",
@@ -521,6 +643,21 @@
       "installAs": "agents/python-pro.md",
       "url": "https://agentscamp.com/agents/language-specialists/python-pro"
     },
+    {
+      "id": "agents/qa-automation-engineer",
+      "type": "agent",
+      "slug": "qa-automation-engineer",
+      "category": "quality-security",
+      "title": "QA Automation Engineer",
+      "description": "Use this agent for end-to-end and UI test automation — building flake-resistant Playwright/Cypress suites, stabilizing flaky browser tests, structuring page objects and fixtures, and reviewing E2E suites. Examples — adding E2E coverage for a checkout or signup flow, killing a test that fails 1-in-5 in CI, choosing a framework and folder structure, replacing sleeps with web-first waits, or auditing a suite that's slow and brittle.",
+      "topics": [
+        "review-qa"
+      ],
+      "model": "sonnet",
+      "file": "agents/qa-automation-engineer.md",
+      "installAs": "agents/qa-automation-engineer.md",
+      "url": "https://agentscamp.com/agents/quality-security/qa-automation-engineer"
+    },
     {
       "id": "agents/rag-pipeline-engineer",
       "type": "agent",
@@ -1037,6 +1174,20 @@
       "installAs": "commands/flaky-test-hunt.md",
       "url": "https://agentscamp.com/commands/testing/flaky-test-hunt"
     },
+    {
+      "id": "commands/generate-e2e-test",
+      "type": "command",
+      "slug": "generate-e2e-test",
+      "category": "testing",
+      "title": "Generate E2E Test",
+      "description": "Scaffold a resilient end-to-end test for a user flow grounded in the real UI.",
+      "topics": [
+        "review-qa"
+      ],
+      "file": "commands/generate-e2e-test.md",
+      "installAs": "commands/generate-e2e-test.md",
+      "url": "https://agentscamp.com/commands/testing/generate-e2e-test"
+    },
     {
       "id": "commands/git-bisect",
       "type": "command",
@@ -1181,6 +1332,20 @@
       "installAs": "commands/run-evals.md",
       "url": "https://agentscamp.com/commands/testing/run-evals"
     },
+    {
+      "id": "commands/scaffold-dockerfile",
+      "type": "command",
+      "slug": "scaffold-dockerfile",
+      "category": "scaffold",
+      "title": "Scaffold Dockerfile",
+      "description": "Scaffold a production-grade multi-stage Dockerfile and .dockerignore for the current project.",
+      "topics": [
+        "devops-infra"
+      ],
+      "file": "commands/scaffold-dockerfile.md",
+      "installAs": "commands/scaffold-dockerfile.md",
+      "url": "https://agentscamp.com/commands/scaffold/scaffold-dockerfile"
+    },
     {
       "id": "commands/scaffold-pgvector-schema",
       "type": "command",
@@ -1241,6 +1406,20 @@
       "installAs": "commands/security-scan.md",
       "url": "https://agentscamp.com/commands/review/security-scan"
     },
+    {
+      "id": "commands/seed-data",
+      "type": "command",
+      "slug": "seed-data",
+      "category": "db",
+      "title": "Seed Data",
+      "description": "Generate realistic, referentially-consistent seed data and a re-runnable seed script from your actual schema — types and constraints respected, plausible values, FK-dependency insert order, idempotent, never aimed at production.",
+      "topics": [
+        "data-ml"
+      ],
+      "file": "commands/seed-data.md",
+      "installAs": "commands/seed-data.md",
+      "url": "https://agentscamp.com/commands/db/seed-data"
+    },
     {
       "id": "commands/set-perf-budget",
       "type": "command",
@@ -1357,6 +1536,20 @@
       "installAs": "skills/agent-memory-designer/SKILL.md",
       "url": "https://agentscamp.com/skills/workflow/agent-memory-designer"
     },
+    {
+      "id": "skills/architecture-diagram-generator",
+      "type": "skill",
+      "slug": "architecture-diagram-generator",
+      "category": "docs",
+      "title": "Architecture Diagram Generator",
+      "description": "Generate accurate architecture diagrams as Mermaid — straight from the codebase, not from imagination — by first choosing which view answers the question (container/component, sequence, ER, or state) and then reading the real entry points, module boundaries, service calls, and schema. Use when onboarding to an unfamiliar repo, documenting a system, or visualizing one complex flow.",
+      "topics": [
+        "architecture"
+      ],
+      "file": "skills/architecture-diagram-generator.md",
+      "installAs": "skills/architecture-diagram-generator/SKILL.md",
+      "url": "https://agentscamp.com/skills/docs/architecture-diagram-generator"
+    },
     {
       "id": "skills/auth-flow-reviewer",
       "type": "skill",
@@ -1555,6 +1748,20 @@
       "installAs": "skills/finetune-dataset-builder/SKILL.md",
       "url": "https://agentscamp.com/skills/data/finetune-dataset-builder"
     },
+    {
+      "id": "skills/github-actions-optimizer",
+      "type": "skill",
+      "slug": "github-actions-optimizer",
+      "category": "workflow",
+      "title": "GitHub Actions Optimizer",
+      "description": "Make a GitHub Actions workflow faster, cheaper, and harder to attack — by profiling where wall-clock and billed minutes actually go, then adding content-keyed caching, matrix/job parallelism, run-cancellation, and path filters, and hardening the supply chain (SHA-pinned actions, least-privilege GITHUB_TOKEN, safe fork-PR handling). Use when CI is slow or queues, when a repo burns Actions minutes, or before trusting a workflow that runs on untrusted pull requests.",
+      "topics": [
+        "devops-infra"
+      ],
+      "file": "skills/github-actions-optimizer.md",
+      "installAs": "skills/github-actions-optimizer/SKILL.md",
+      "url": "https://agentscamp.com/skills/workflow/github-actions-optimizer"
+    },
     {
       "id": "skills/graphrag-scaffolder",
       "type": "skill",
@@ -1653,6 +1860,20 @@
       "installAs": "skills/llm-output-schema-generator/SKILL.md",
       "url": "https://agentscamp.com/skills/api/llm-output-schema-generator"
     },
+    {
+      "id": "skills/load-test-designer",
+      "type": "skill",
+      "slug": "load-test-designer",
+      "category": "performance",
+      "title": "Load Test Designer",
+      "description": "Design a defensible load test — a realistic workload model, a deliberate test type, and SLO-tied pass/fail thresholds — instead of a meaningless tight-loop script that hammers one endpoint. Use when validating capacity or SLOs before a launch or scaling event, when sizing infrastructure, or when an existing load test reports averages that nobody trusts.",
+      "topics": [
+        "devops-infra"
+      ],
+      "file": "skills/load-test-designer.md",
+      "installAs": "skills/load-test-designer/SKILL.md",
+      "url": "https://agentscamp.com/skills/performance/load-test-designer"
+    },
     {
       "id": "skills/mcp-server-scaffolder",
       "type": "skill",

package/content/skills/architecture-diagram-generator.md

@@ -0,0 +1,78 @@
+---
+name: "architecture-diagram-generator"
+description: "Generate accurate architecture diagrams as Mermaid — straight from the codebase, not from imagination — by first choosing which view answers the question (container/component, sequence, ER, or state) and then reading the real entry points, module boundaries, service calls, and schema. Use when onboarding to an unfamiliar repo, documenting a system, or visualizing one complex flow."
+allowed-tools: "Read, Grep, Glob, Write"
+version: 1.0.0
+---
+
+Most architecture diagrams lie. They were drawn once on a whiteboard, drifted as the code changed, and now mislead the next person who trusts them. This skill draws diagrams *from the repository* — by reading entry points, module boundaries, service calls, and the schema — so the picture reflects what exists today. It picks the single view that answers the question instead of one sprawling everything-diagram, and emits Mermaid, which renders natively in GitHub, GitLab, Obsidian, and most docs tooling with no image pipeline.
+
+## When to use this skill
+
+- You're onboarding to an unfamiliar repo and need a map of the services and how they call each other before you start changing anything.
+- You're documenting a system for a README, ADR, or design doc and want a diagram that won't go stale the moment someone reads the code.
+- One specific flow is hard to reason about — a checkout, an auth handshake, a webhook fan-out — and you want it laid out as a sequence over time.
+- You need the data model visible (tables, foreign keys, cardinality) or the lifecycle of a stateful entity (an order, a job, a subscription).
+
+## Instructions
+
+1. **Choose the view before drawing anything.** Pick the *one* diagram type that answers the actual question — they are not interchangeable:
+   - **Container / component (`graph` or `flowchart`)** — "what are the services/modules and who calls whom?" Use for onboarding and system overviews.
+   - **Sequence (`sequenceDiagram`)** — "how does *this one request* move through the system over time?" Use for a single flow with ordering, async, and error paths.
+   - **ER (`erDiagram`)** — "what is the data model and how are entities related?" Use when the schema is the question.
+   - **State (`stateDiagram-v2`)** — "what states can *this entity* be in and what transitions are legal?" Use for orders, jobs, payments, finite-state logic.
+   If the question spans concerns, emit two small diagrams, not one fused diagram.
+2. **Find the real boundaries — read, don't assume.** Locate evidence before drawing a single node:
+   - Entry points: `Glob` for `main.*`, `app.*`, `server.*`, `index.*`, route files, `Procfile`, `docker-compose.yml`, `*.tf`, k8s manifests, `package.json`/`pyproject.toml` workspaces.
+   - Service-to-service edges: `Grep` for HTTP clients (`fetch`, `axios`, `requests`, `httpx`), queue/topic names, gRPC stubs, and env vars like `*_URL`/`*_HOST` that name a dependency.
+   - Data stores: connection strings, ORM models, migration files, `*.sql`, `schema.prisma`.
+   A node or edge goes in the diagram only if you found it in the code or config — never because the architecture "should" have it.
+3. **Build the chosen diagram from that evidence.**
+   - *Container/component:* one node per deployable/service/module; directed edges labeled with the real protocol or call (`-->|REST|`, `-->|publishes order.created|`). Group with `subgraph` by boundary (per process, per network zone). Mark external systems (Stripe, S3, a third-party API) distinctly so the trust boundary is obvious.
+   - *Sequence:* one participant per real actor/service; arrows in call order (`->>` sync request, `-->>` response, `-)` async/fire-and-forget); use `alt`/`opt` for the error and conditional branches you found, not idealized happy-path only.
+   - *ER:* `erDiagram` with real table/entity names, key attributes (mark `PK`/`FK`), and correct crow's-foot cardinality (`||--o{`) read from the foreign keys, not guessed.
+   - *State:* `stateDiagram-v2` with `[*]` start/end, named transitions, and only the states the code actually models.
+4. **Cut everything that doesn't serve the diagram's purpose.** A container view does not need every helper class; a sequence diagram does not need every logging call. Aim for a diagram a reader can absorb in one screen. If a container view exceeds ~12 nodes, split it: one high-level map plus a zoom-in on the busy subgraph.
+5. **Validate the Mermaid.** Check that the first line declares the diagram type, every node referenced in an edge is defined, labels with special characters are quoted (`["Auth Service (OIDC)"]`), and the block is fenced as ` ```mermaid `. Broken Mermaid renders as a red error box in GitHub — worse than no diagram.
+6. **Write and caption.** Emit the diagram(s) into the requested doc (or return inline), and follow each with one line stating what it *does* and *does not* show (e.g. "Shows synchronous request flow for checkout; does not show the async receipt-email worker or retry behavior").
+
+> [!WARNING]
+> A stale or wrong diagram is worse than none — readers trust a picture more than prose and will design against a lie. Draw only edges and nodes you found in the code, and date or version-anchor the diagram so the next reader knows when it was true.
+
+> [!NOTE]
+> Resist the everything-diagram. A single chart that crams services, data model, and request flow into one canvas communicates nothing — no reader can hold it. Each diagram answers exactly one question; if you have two questions, draw two diagrams.
+
+## Output
+
+For each request, the skill returns:
+
+1. **The chosen view + rationale** — e.g. "Sequence diagram, because the question is about ordering across services in one flow, not the static topology."
+2. **Paste-ready Mermaid** in a fenced ` ```mermaid ` block, built from real entry points and calls.
+3. **A scope caption** — one line on what the diagram does and does not show.
+
+Example — a container view of a small web app, traced from `docker-compose.yml` (web, api, worker, redis, postgres) and the API's HTTP client to Stripe:
+
+```mermaid
+flowchart LR
+  user(["Browser"])
+  subgraph app["app network"]
+    web["Web (Next.js)"]
+    api["API (Node)"]
+    worker["Worker"]
+    redis[("Redis<br/>queue + cache")]
+    db[("Postgres")]
+  end
+  stripe["Stripe API"]:::ext
+
+  user -->|HTTPS| web
+  web -->|REST /api| api
+  api -->|SQL| db
+  api -->|"enqueue charge"| redis
+  worker -->|"dequeue"| redis
+  worker -->|"create charge"| stripe
+  worker -->|SQL| db
+
+  classDef ext fill:#fde68a,stroke:#b45309;
+```
+
+*Shows the deployed services and their call/data edges as wired in `docker-compose.yml` and the API client. Does not show request timing/order (use a sequence diagram) or the table schema (use an ER diagram).*

package/content/skills/github-actions-optimizer.md

@@ -0,0 +1,45 @@
+---
+name: "github-actions-optimizer"
+description: "Make a GitHub Actions workflow faster, cheaper, and harder to attack — by profiling where wall-clock and billed minutes actually go, then adding content-keyed caching, matrix/job parallelism, run-cancellation, and path filters, and hardening the supply chain (SHA-pinned actions, least-privilege GITHUB_TOKEN, safe fork-PR handling). Use when CI is slow or queues, when a repo burns Actions minutes, or before trusting a workflow that runs on untrusted pull requests."
+allowed-tools: "Read, Grep, Glob, Edit, Bash"
+version: 1.0.0
+---
+
+A workflow that takes 22 minutes and costs you a fortune in minutes is rarely slow for one reason — it's usually re-downloading dependencies every run, running serially what could run in parallel, and building branches no one is waiting on. And the same file is often a supply-chain liability: a third-party action pinned to `@v3` can be repointed under you, and a `write-all` token plus `pull_request_target` is one malicious fork PR away from leaking secrets. This skill measures before it touches anything, then ships fixes ordered by payoff — biggest time or security win first — as concrete YAML diffs.
+
+## When to use this skill
+
+- CI wall-clock is the bottleneck on every PR, runs queue behind each other, or the monthly Actions bill is climbing.
+- A job re-installs the whole dependency tree or rebuilds from scratch on every run, with no cache or a cache that never hits.
+- The workflow runs on `pull_request` / `pull_request_target` from forks and you haven't audited what secrets and permissions are exposed.
+- You inherited a workflow that pins actions to floating tags (`@v4`, `@main`) and grants the default broad `GITHUB_TOKEN`.
+
+## When NOT to use this skill
+
+- The slowness is in your test suite itself (flaky retries, an N+1 in integration tests) rather than the CI plumbing — fix the tests; faster runners won't save a 9-minute test that should take 90 seconds.
+- You need a workflow authored from scratch for a new stack — that's scaffolding work; this skill optimizes and hardens an *existing* `.github/workflows/*.yml`.
+
+## Instructions
+
+1. **Inventory the workflows before changing one.** Glob `.github/workflows/*.{yml,yaml}` and read each. For every workflow note its triggers (`on:`), its jobs and their `needs:` graph, the runner labels (`ubuntu-latest` vs a larger/self-hosted runner — larger runners bill at a multiple), and the matrix dimensions. This is the map; you optimize against it, not against guesses.
+2. **Profile where time actually goes — don't optimize from intuition.** Pull recent run timings with the CLI: `gh run list --workflow <file> -L 20 --json databaseId,conclusion,createdAt,updatedAt` for wall-clock per run, then `gh run view <id> --json jobs` to get per-job durations. The serial critical path is `needs:`-chained job durations summed; a 4-minute lint that gates a 12-minute test set adds 4 minutes to *everyone*. Rank jobs and steps by total billed minutes (duration × runs/day × runner multiplier). Fix the top one first.
+3. **Add caching with a content-based key — or don't bother.** Cache the package manager's store, not `node_modules`/`.venv` (restoring a half-built tree is worse than a clean install). Key on a hash of the lockfile so the cache invalidates exactly when deps change: `key: ${{ runner.os }}-deps-${{ hashFiles('**/package-lock.json') }}` with a `restore-keys: ${{ runner.os }}-deps-` prefix fallback for partial hits. For language setup actions (`actions/setup-node`, `setup-python`, `setup-go`), prefer their built-in `cache:` input — it keys on the lockfile for you and handles the path. Confirm a hit after: the run log prints `Cache restored from key` (or `Cache not found`). A cache that never hits is pure overhead — it uploads on every run and restores nothing.
+4. **Parallelize the critical path.** Convert serial variants (Node 18/20/22, OS targets, test shards) into a `strategy.matrix` so they run concurrently instead of in sequence. Split a single monster test job into shards with `matrix` + a test-splitting flag (`--shard ${{ matrix.shard }}/${{ matrix.total }}`). Drop unnecessary `needs:` edges — only gate a job on what it truly consumes; lint and unit tests rarely need to wait on each other. Set `fail-fast: false` only when you want all matrix legs to report; leave it `true` (default) to abort the matrix the moment one leg fails and stop burning minutes.
+5. **Cancel superseded runs with `concurrency`.** Add a top-level `concurrency` group keyed on the ref so a new push cancels the in-flight run for that branch instead of running both: `concurrency: { group: ${{ github.workflow }}-${{ github.ref }}, cancel-in-progress: true }`. This alone can halve minutes on an active branch. Do NOT set `cancel-in-progress: true` on deploy/release workflows — cancelling a half-finished deploy mid-flight can leave the environment in a broken state.
+6. **Skip work that can't be affected.** Add `paths:` / `paths-ignore:` filters so a docs-only change doesn't trigger the full build matrix, and `branches:` filters so feature pushes don't run release jobs. For required status checks, use a path filter plus a tiny "always-green" companion job (or `paths-filter` action with a downstream `if:`) so the required check still reports success on skipped paths — a hard `paths:` skip leaves a required check pending forever and blocks merges.
+7. **Pin third-party actions to a full commit SHA.** Replace every `uses: owner/action@v4` (and especially `@main`) for *third-party* actions with the full 40-char commit SHA, keeping the version in a trailing comment: `uses: owner/action@a1b2c3...def # v4.1.2`. A floating tag is mutable — the owner (or an attacker who compromises them) can repoint it at code that exfiltrates your secrets, and your pinned-to-tag workflow will silently run it. First-party `actions/*` are lower risk but pinning them too is the consistent posture. Use `gh api repos/<owner>/<repo>/git/ref/tags/<tag>` to resolve a tag to its SHA.
+8. **Set least-privilege `permissions` on `GITHUB_TOKEN`.** Add a top-level `permissions: { contents: read }` to default everything to read, then grant exactly what each job needs at the job level (`packages: write` to publish, `pull-requests: write` to comment, `id-token: write` for OIDC). The repo default is often `read-write` on everything; a token that can push to `contents` is a token a compromised dependency can use to push to your branches.
+9. **Quarantine secrets from untrusted fork PRs.** Understand the split: `pull_request` from a fork runs with a read-only token and *no* repo secrets — safe but limited. `pull_request_target` runs in the context of the base repo *with* secrets and a writable token, while checking out the fork's code — this is the dangerous one. Never `checkout` and then build/run a fork's code under `pull_request_target`; that hands an attacker your secrets via a malicious build script or workflow. If you need a label-gated privileged step, split it into a separate `workflow_run`/manually-approved job that operates only on trusted artifacts, never on raw fork code.
+
+> [!WARNING]
+> An unkeyed or over-broad cache rots silently. If the key isn't tied to the lockfile, the cache never invalidates — CI keeps restoring stale dependencies, masking lockfile changes and producing "works in CI, broken locally" drift. If the key is too unique (includes `github.sha`), it never hits and you pay the upload cost every run for nothing. Verify "Cache restored from key" appears in real run logs before calling caching done.
+
+> [!CAUTION]
+> A third-party action pinned to a moving tag (`@v4`, `@main`) is remote code you don't control, running with your token and secrets. Tag mutation is the documented supply-chain attack (see the `tj-actions/changed-files` incident). Pin to a full commit SHA, and review the diff before bumping the SHA — never auto-update action SHAs without reading what changed.
+
+> [!CAUTION]
+> Secrets must never reach untrusted fork code. `pull_request_target` + checking out the PR head + running its scripts = secret exfiltration. Default to `pull_request` for fork CI, keep secrets out of those runs, and gate any privileged automation behind manual approval or a separate trusted workflow.
+
+## Output
+
+A prioritized remediation plan ordered by payoff — each item tagged TIME or SECURITY, with the measured cost it addresses (e.g. "SECURITY: 3 actions on floating tags"; "TIME: deps re-installed every run, ~90s × 40 runs/day") — followed by the concrete YAML diffs to apply, smallest-blast-radius wins first. Each diff is a minimal, reviewable change to a specific workflow file (added `concurrency` block, a cache step with its key, a matrix rewrite, SHA pins with version comments, a `permissions` block). The skill proposes edits via Edit and uses Bash only for read-only `gh`/`git` profiling and tag-to-SHA resolution; it does not push, re-run, or alter pipeline behavior beyond the diffs you approve.

package/content/skills/load-test-designer.md

@@ -0,0 +1,87 @@
+---
+name: "load-test-designer"
+description: "Design a defensible load test — a realistic workload model, a deliberate test type, and SLO-tied pass/fail thresholds — instead of a meaningless tight-loop script that hammers one endpoint. Use when validating capacity or SLOs before a launch or scaling event, when sizing infrastructure, or when an existing load test reports averages that nobody trusts."
+allowed-tools: "Read, Grep, Glob, Write"
+version: 1.0.0
+---
+
+Most "load tests" hammer a single endpoint in a tight loop with no think-time, run from one laptop, and report an average response time that makes everyone feel good and predicts nothing. This skill designs a load test you can actually defend in a launch review. It builds a workload model from the real traffic mix, picks the test type that answers your actual question (Will we survive peak? Where do we break? Do we leak under sustained load? Can we absorb a surge?), writes thresholds tied to your SLOs *before* the run so the test has a pass/fail answer, and produces a runnable script plus a guide to reading the results by percentile and saturation point.
+
+## When to use this skill
+
+- You have a launch, marketing event, sale, or migration coming and need numbers to prove the system survives expected peak.
+- You need to size infrastructure (instance count, DB connection pool, autoscaling thresholds) and want evidence, not a guess.
+- You want to find the breaking point — the concurrency or RPS at which latency or error rate falls off a cliff — before users do.
+- An existing load test reports a single average latency and nobody believes it represents real traffic.
+- You suspect a slow leak (memory, connections, file handles) that only appears after the system runs hot for an hour.
+
+## Instructions
+
+1. **Build a workload model from real traffic, not a single URL.** A load test that loops on `GET /health` measures your load balancer, not your system. Derive the endpoint mix from production access logs, APM, or analytics: which routes, in what proportion, with which payloads. Capture the *journey* (e.g. browse 60%, search 25%, add-to-cart 10%, checkout 5%) because checkout hits the DB and payment provider while browse hits a cache — they are not interchangeable load. Write the mix down as weighted scenarios with a representative, **distinct** data set (rotating user IDs, search terms, cart contents) so you exercise cache misses and row contention instead of the one hot row that gets cached after the first request.
+
+2. **Add think-time between actions.** Real users pause to read, type, and decide. A closed-loop test with zero think-time generates a firehose no human population produces and tells you about your queueing behavior at an impossible arrival rate. Insert randomized think-time (e.g. 1–5s) between steps in a journey, and prefer an **open model** (specify arrival rate — new users per second) over a **closed model** (fixed VU count) when you are modeling a real-world population, because closed models artificially throttle load as the system slows.
+
+3. **Pick the test type deliberately — it determines the shape, not just the size.** Choose one question per test:
+   - **Load test** — sustain *expected peak* (e.g. Black Friday 1.5×) for 15–30 min. Answers "do we meet SLOs at peak?"
+   - **Stress test** — ramp past peak until something breaks. Answers "where is the cliff, and how does it fail — graceful 503s or a cascading meltdown?"
+   - **Soak test** — hold a moderate, realistic load for hours. Answers "do we leak memory/connections/handles, and does latency drift upward over time?"
+   - **Spike test** — jump from baseline to a large surge in seconds, then drop. Answers "can autoscaling and queues absorb a sudden surge, and do we recover cleanly?"
+
+4. **Choose the tool to match the model.** Use **k6** (JS scenarios, first-class thresholds, scriptable open/closed models) as the default; **Locust** (Python, good for complex stateful user flows); **Gatling** (Scala/JVM, strong reporting, high single-node throughput). Match the tool to the team's language and to whether you need a closed VU model or an open arrival-rate model — k6 `scenarios` with `ramping-arrival-rate` is the cleanest open model.
+
+5. **Set pass/fail thresholds tied to actual SLOs — before you run.** A test with no threshold is a demo, not a test. Translate each SLO into a machine-checkable pass condition and encode it so the tool exits non-zero on breach (k6 `thresholds`, Gatling `assertions`). Example bar: `http_req_duration: p(95)<300 AND p(99)<800`, `http_req_failed: rate<0.001` (0.1% errors), and per-scenario thresholds for the expensive journey (checkout p95 < 1s). Define these from the SLO doc, not from whatever the first run happened to produce.
+
+6. **Run against a prod-like, isolated environment from enough generators.** The environment must match production in the dimensions that saturate: instance size/count, DB tier and connection limits, cache size, and rate limits. Isolate it so you are not loading a shared staging DB that other teams use. Generate load from multiple machines (or a distributed runner / k6 Cloud / a fleet of generator nodes) and **monitor the generators' own CPU, network, and open sockets** — if a generator saturates, you measured the generator, not the target. Capture server-side metrics in parallel (CPU, memory, DB connections, queue depth, GC) so you can locate the bottleneck, not just observe that latency rose.
+
+7. **Interpret by percentiles and the saturation point, not the average.** Read p95/p99 (and the max), error rate, and throughput together. The headline result is the **knee**: the load level where latency percentiles start climbing super-linearly and/or error rate crosses the threshold — that is your real capacity, and anything below it with headroom is the number you size to. Correlate the knee with a server-side resource hitting its limit (CPU pegged, connection pool exhausted, GC thrashing) to name the actual bottleneck.
+
+> [!WARNING]
+> The average latency hides the tail, and the tail is what pages you. A 50ms mean can sit on top of a 2s p99 — meaning 1 in 100 requests is 40× slower, which at scale is thousands of furious users. Never let an average be the pass/fail metric; gate on p95/p99 and error rate.
+
+> [!WARNING]
+> Load-testing a tiny staging environment tells you nothing transferable. A 1-instance, free-tier-DB staging box breaks at numbers that say nothing about your 12-instance production fleet, and the bottleneck (e.g. a 5-connection pool) may not even exist in prod. Test against prod-like capacity, or test prod itself in a maintenance window — not a toy.
+
+> [!CAUTION]
+> A single under-powered load generator caps your result: you will report the *client's* ceiling as the *server's*. If generator CPU or network is pegged, or you exhaust ephemeral ports, the numbers are invalid. Distribute generators and watch their own metrics; treat a saturated generator as a failed run, not a finding.
+
+## Output
+
+A complete, defensible load-test design, written as files plus an interpretation guide:
+
+1. **Workload model** — a table of weighted scenarios with endpoint mix, payloads, think-time ranges, and the data set strategy.
+
+```text
+Scenario        Weight  Steps (think-time)                         Data
+browse          60%     GET /  -> GET /p/{id}  (2-5s)              rotate 5k product IDs
+search          25%     GET /search?q={term}  (1-3s)               2k distinct terms
+add-to-cart     10%     POST /cart  (1-4s)                         rotate user + product
+checkout         5%     POST /cart -> POST /checkout  (3-8s)       unique cart per VU
+```
+
+2. **Test type + tool + load profile** — which of load/stress/soak/spike, the tool, the model (open arrival-rate vs closed VU), ramp shape, and duration, with the one question the test answers.
+
+3. **The threshold-bearing script** (e.g. k6) — runnable, with SLO-tied thresholds that fail the run on breach:
+
+```javascript
+export const options = {
+  scenarios: {
+    peak: {
+      executor: "ramping-arrival-rate",
+      startRate: 50, timeUnit: "1s",
+      preAllocatedVUs: 500, maxVUs: 2000,
+      stages: [
+        { target: 300, duration: "3m" },   // ramp to expected peak
+        { target: 300, duration: "20m" },  // hold at peak
+        { target: 0,   duration: "2m" },   // ramp down
+      ],
+    },
+  },
+  thresholds: {
+    http_req_failed:   ["rate<0.001"],                  // < 0.1% errors
+    http_req_duration: ["p(95)<300", "p(99)<800"],      // SLO latency
+    "http_req_duration{scenario:checkout}": ["p(95)<1000"],
+  },
+};
+```
+
+4. **How to read the results** — the percentile/error/throughput table to produce, where the saturation knee is, which server-side metric to correlate it with, and the explicit pass/fail call against the thresholds, plus the recommended capacity number with headroom.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agentscamp",
-  "version": "0.2.0",
+  "version": "0.3.0",
   "description": "Install AgentsCamp agents, skills, and slash commands into Claude Code from your terminal.",
   "license": "MIT",
   "type": "module",