xcoder-dna 0.0.0-stage → 1.3.0

package/dist/skills/git-vcs/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: git-vcs
+role: devops
+description: Git workflow discipline — clean, atomic commits, safe branching/merging/rebasing, and the correct recovery command for common "I broke my git state" situations, using this project's github_tool (clone/fetch/pull/status/commit/push).
+triggers:
+  - "git repo"
+  - "git log"
+  - "git status"
+  - "using git"
+  - "commit"
+  - "branch"
+  - "merge conflict"
+  - "rebase"
+  - "pull request"
+  - "git history"
+  - "revert"
+  - "cherry-pick"
+version: "1.0.0"
+requires_tools:
+  - github_tool
+  - run_command_tool
+composes_with:
+  - workspace-context
+  - software-engineer
+---
+
+## Process
+
+1. Before committing, check `status` and the actual diff (not just the file list) — stage exactly
+   the intended changes. `files` defaults to `['.']` in this project's `github_tool`, which stages
+   everything in the working tree; be deliberate about that when unrelated changes exist locally.
+2. Write commit messages that state *why*, not just *what* — the diff already shows what changed;
+   the message's job is the reasoning a diff can't express (why this approach, what it fixes, what
+   it doesn't cover).
+3. Keep commits atomic: one logical change per commit. A commit that mixes an unrelated formatting
+   pass with a real fix makes `git blame`/`git bisect` far less useful later.
+4. Pull/rebase onto the latest target branch before starting new work when working against a
+   shared branch, to minimize conflict surface discovered at the end instead of the start.
+5. Before pushing, re-read the actual diff being pushed (not just recall what you intended to
+   change) — catches accidental debug code, unintended file inclusions, or leftover conflict markers.
+
+## Instructions — non-negotiable
+
+- Never force-push (`push --force`) to a shared/main branch — if history needs rewriting on a
+  shared branch, coordinate explicitly or use `--force-with-lease` on a branch confirmed to be
+  exclusively yours.
+- Never commit secrets, credentials, or `.env` files — if one is committed by mistake, rotating the
+  credential is required; removing it from a later commit does not remove it from history that's
+  already been pushed/shared.
+- Never resolve a merge conflict by blindly accepting "ours" or "theirs" wholesale without reading
+  both sides — conflicts often mean both changes are needed, merged correctly, not one discarded.
+- Never rewrite (rebase/amend) commits that have already been pushed and pulled by others, without
+  explicit coordination.
+
+## Strategies
+
+- Prefer `rebase` for keeping a feature branch current with its base (linear, readable history) and
+  `merge` for combining a completed feature branch back into a shared branch (preserves the actual
+  point-in-time context of when work merged) — know which one the project's convention expects.
+- Prefer small, frequent commits over one large commit at the end of a task — easier to review,
+  easier to revert just the problematic part if something's wrong.
+- When a change touches generated files (lockfiles, build output) alongside source, commit them
+  together only if the project tracks generated files at all — check `.gitignore` first.
+
+## Recovery commands for common situations
+
+- Committed to the wrong branch, not yet pushed: `git reset --soft HEAD~1` on the wrong branch,
+  switch to the correct branch, commit there.
+- Need to undo a pushed commit without rewriting shared history: `git revert <sha>` (creates a new
+  commit undoing it) rather than resetting/force-pushing.
+- Merge conflict mid-rebase and want to abandon: `git rebase --abort` restores the pre-rebase state
+  cleanly — always safe to bail out this way rather than trying to force through a confusing
+  conflict state.
+- Need one specific commit from another branch without merging everything: `git cherry-pick <sha>`.
+- Accidentally staged something that shouldn't be committed: `git restore --staged <file>` (unstages
+  without discarding the actual edit).
+
+## Experience
+
+- Most "git broke" panics have a clean, low-risk recovery command (see above) — resist the urge to
+  delete and re-clone the repo, which loses any uncommitted local work.
+- A conflict that reappears identically after a previous "resolution" usually means the resolution
+  wasn't actually committed/staged correctly, not that the conflict is unresolvable — verify with
+  `status` after resolving.

package/dist/skills/kafka/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: kafka
+role: devops
+description: Design and troubleshoot Kafka topics, partitioning, and consumer groups — correct delivery-semantics choice, partition-key design for ordering guarantees, and the standard diagnostic sequence for consumer lag.
+triggers:
+  - "kafka"
+  - "topic partition"
+  - "consumer group"
+  - "message queue"
+  - "event streaming"
+  - "producer consumer"
+version: "1.0.0"
+requires_tools:
+  - run_command_tool
+  - ssh_tool
+  - read_tool
+composes_with:
+  - workspace-context
+  - docker
+  - kubernetes
+  - aws
+---
+
+## Process
+
+1. Decide the delivery-semantics requirement explicitly before configuring anything: at-most-once
+   (fire and forget, fine for non-critical telemetry), at-least-once (default for most Kafka setups
+   — requires idempotent consumers since duplicates are possible), or exactly-once (transactional
+   producer + consumer, real throughput cost — only use where a duplicate is genuinely unacceptable,
+   e.g. financial transactions).
+2. Choose the partition key based on the ordering guarantee actually needed: messages with the same
+   key land on the same partition and are ordered relative to each other, but there is no ordering
+   guarantee across partitions. Partitioning by a high-cardinality key (e.g. user ID) gives good
+   parallelism; partitioning by something low-cardinality or constant defeats the purpose of having
+   multiple partitions.
+3. Set partition count based on target consumer parallelism, not arbitrarily — max useful
+   parallelism for one consumer group equals the partition count; more consumers than partitions
+   sit idle. Partition count can be increased later but never decreased on an existing topic, so
+   under-provisioning is more recoverable than over-provisioning is reversible.
+4. Set a retention policy (`retention.ms`/`retention.bytes`) deliberately based on how long
+   consumers legitimately need to replay from, not left at the cluster default by accident.
+5. For schema evolution, use a schema registry with a compatibility mode (backward/forward/full)
+   matched to the actual deploy order of producers vs. consumers — deploying an incompatible schema
+   change before all consumers are updated is a common outage cause.
+
+## Instructions — non-negotiable
+
+- Never assume global ordering across a topic — only same-key messages on the same partition are
+  ordered. Design consumers to be correct under cross-partition reordering.
+- Always make consumers idempotent (dedupe on a message ID/offset, or make the operation naturally
+  idempotent) when using at-least-once delivery — duplicates *will* happen (rebalances, retries).
+- Never rely on manual offset management without understanding the commit strategy in use
+  (auto-commit vs. manual commit, and whether it's committed before or after processing) — this
+  determines exactly what's re-processed on a consumer crash.
+- Monitor and alert on consumer lag, not just consumer liveness — a consumer that's running but
+  falling behind is a slow-motion outage that liveness checks won't catch.
+
+## Strategies
+
+- Prefer fewer, well-designed topics over many narrow ones unless there's a genuine reason to
+  separate (different retention needs, different access-control boundary, different consumer
+  scaling needs).
+- For high-throughput producers, batch and compress (`linger.ms`, `batch.size`, `compression.type`)
+  rather than sending every message individually — meaningful throughput difference at scale.
+- Prefer Kafka Streams/ksqlDB for stream-processing logic that needs to live close to the data
+  over pulling everything into a separate service, when the processing is naturally
+  stream-shaped (windowed aggregation, joins between topics).
+
+## Diagnostic sequence for consumer lag / "messages aren't being processed"
+
+1. Check consumer group lag directly (`kafka-consumer-groups.sh --describe --group <g>` or the
+   equivalent cluster UI/API) — confirms whether it's actually lagging vs. a false alarm.
+2. If lag is growing steadily: is the consumer under-provisioned relative to partition count and
+   incoming rate, or is per-message processing slow (check consumer-side processing time, not just
+   Kafka-side metrics)?
+3. If lag is flat/not moving at all: check for a stuck/crashed consumer, a rebalance loop (frequent
+   rebalances usually mean `session.timeout.ms`/`max.poll.interval.ms` too tight for actual
+   processing time), or a permissions/connectivity issue preventing fetch.
+4. Check for a "poison pill" message (one malformed message repeatedly failing and blocking the
+   partition if the consumer isn't skipping/dead-lettering failed messages).
+
+## Experience
+
+- Rebalance storms (consumers repeatedly leaving/rejoining the group) are usually caused by
+  processing taking longer than `max.poll.interval.ms`, not a Kafka infrastructure problem —
+  check consumer-side timing before touching cluster config.
+- A "topic doesn't exist" error on first produce often means `auto.create.topics.enable` is off
+  (common and correct for production clusters) — the topic needs to be created explicitly, not
+  debugged as a connectivity issue.

package/dist/skills/kubernetes/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: kubernetes
+role: devops
+description: Write and troubleshoot Kubernetes manifests and cluster workloads — correct workload type choice, resource requests/limits, probes, and the standard kubectl-based diagnostic sequence for a failing pod/deployment.
+triggers:
+  - "kubernetes"
+  - "k8s"
+  - "kubectl"
+  - "the pod "
+  - "a pod "
+  - "pod is "
+  - "pod status"
+  - "deployment yaml"
+  - "helm chart"
+  - "ingress"
+  - "kubernetes cluster"
+version: "1.0.0"
+requires_tools:
+  - run_command_tool
+  - ssh_tool
+  - read_tool
+  - write_edit_tool
+composes_with:
+  - workspace-context
+  - docker
+  - openshift
+  - rosa
+  - aws
+  - azure
+---
+
+## Process
+
+1. Choose the right workload type deliberately: `Deployment` for stateless/replaceable pods,
+   `StatefulSet` when pods need stable identity/storage/ordering, `DaemonSet` for one-per-node
+   agents, `Job`/`CronJob` for run-to-completion work. Using `Deployment` for something that needs
+   stable network identity or ordered startup is a common, hard-to-debug-later mistake.
+2. Always set both `resources.requests` and `resources.limits` (CPU and memory) — no requests means
+   the scheduler can't place pods sensibly; no limits means one runaway pod can starve its node.
+3. Define `readinessProbe` (traffic routing) and `livenessProbe` (restart-if-stuck) separately and
+   correctly — a liveness probe that's too aggressive causes restart loops on slow-starting apps; a
+   missing readiness probe sends traffic to a pod before it's actually ready.
+4. Use `ConfigMap`/`Secret` for configuration, never bake environment-specific values into the
+   image — the same image should be deployable unchanged across environments.
+5. For anything beyond a handful of static manifests, prefer Helm or Kustomize over hand-copied
+   YAML per environment, to keep environment diffs explicit and reviewable instead of implicit.
+
+## Instructions — non-negotiable
+
+- Never apply a manifest without first running `kubectl diff` (or `--dry-run=client -o yaml`) to
+  see what will actually change, when the cluster is a shared/production one.
+- Never set `livenessProbe` with a timeout/period tight enough to fail during normal startup —
+  check actual startup time first, or use `startupProbe` to give slow-starting apps room before
+  liveness checks begin.
+- Namespace every resource explicitly rather than relying on `kubectl`'s current context default —
+  applying to the wrong namespace/cluster is a common, costly mistake.
+- Never store secrets as plain `ConfigMap` values or in-image — use `Secret` objects (and note that
+  base64 in a `Secret` is encoding, not encryption; use a proper secrets manager/sealed-secrets
+  approach for anything genuinely sensitive).
+
+## Strategies
+
+- Prefer many small, single-purpose containers/pods over one large pod doing several unrelated
+  jobs — matches Kubernetes' scaling and failure-isolation model.
+- Set `PodDisruptionBudget` for anything that must maintain a minimum available replica count
+  during voluntary disruptions (node drains, cluster upgrades).
+- Prefer `kubectl rollout status`/`kubectl rollout undo` for deploys over deleting and recreating
+  resources — preserves rollout history and enables clean rollback.
+
+## The standard diagnostic sequence for "pod isn't working"
+
+1. `kubectl get pods -n <ns>` — what phase is it in (Pending/CrashLoopBackOff/ImagePullBackOff/
+   Running-but-not-Ready)? The phase narrows the cause category immediately.
+2. `kubectl describe pod <pod> -n <ns>` — check `Events` at the bottom first; scheduling failures,
+   image pull errors, and probe failures all show up here with a specific reason.
+3. `kubectl logs <pod> -n <ns>` (add `--previous` if it's currently restarting) — application-level
+   errors.
+4. `kubectl get events -n <ns> --sort-by='.lastTimestamp'` — cluster-level events (evictions,
+   node pressure) that `describe pod` alone might not surface.
+5. For networking issues specifically: confirm the `Service` selector actually matches the pod's
+   labels (`kubectl get endpoints <svc>` should list the pod IPs — if empty, the selector is wrong).
+
+## Experience
+
+- `ImagePullBackOff` is almost always either a typo'd image tag, a private registry the cluster
+  isn't authenticated against, or a platform/architecture mismatch (e.g. arm64 image on an amd64
+  node) — check these three before anything more exotic.
+- `CrashLoopBackOff` combined with a very short `Age`-to-restart interval usually means the
+  container is exiting immediately on start (missing env var, bad config, wrong entrypoint) rather
+  than crashing after real work — `kubectl logs --previous` is the fastest path to the actual error.
+- Pending pods are almost always a scheduling constraint (insufficient resources, node
+  selector/affinity nothing matches, or a taint with no matching toleration) — `describe pod`'s
+  Events section names the specific unmet constraint.

package/dist/skills/kubernetes-expert/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: kubernetes-expert
+role: Kubernetes Specialist
+description: >
+  Designs and troubleshoots Kubernetes manifests, cluster resources, and workload
+  configuration. Load whenever the task involves k8s manifests, deployments, services,
+  ingress, helm charts, cluster troubleshooting, or resource scaling.
+triggers: [kubernetes, k8s, pod, deployment.yaml, helm, ingress, "cluster", "kubectl", statefulset, hpa]
+version: 1.0
+requires_tools: [read_tool, glob_tool, grep_tool, write_edit_tool, run_command_tool, ssh_tool]
+composes_with: [docker-expert, devops, secops, performance-tester]
+---
+
+## Role
+Owns correctness and efficiency of workloads on Kubernetes: manifests, resource sizing,
+networking (Service/Ingress), scaling policy, and cluster-level troubleshooting.
+
+## Process
+1. **Understand workload shape** — stateless vs stateful, traffic pattern, resource needs.
+2. **Author manifests** — Deployment/StatefulSet, Service, Ingress, ConfigMap/Secret refs,
+   resource requests/limits set deliberately (not omitted, not copy-pasted defaults).
+3. **Wire health checks** — readiness/liveness probes matched to actual startup/health
+   behavior.
+4. **Validate** — `kubectl apply --dry-run` / lint manifests, then apply and check rollout
+   status and pod events.
+5. **Troubleshoot** — for issues, read pod events/logs and describe output before guessing at
+   a fix.
+
+## Strategies
+- Always set resource requests/limits; unset limits are the most common cause of noisy-
+  neighbor incidents.
+- Use readiness probes to gate traffic, liveness probes to recover hung processes — don't
+  conflate the two.
+- Prefer Horizontal Pod Autoscaler over manual replica counts for variable load.
+- Keep secrets out of manifests directly — reference Kubernetes Secrets/external secret
+  stores.
+
+## Planning Approach
+- Namespace and label workloads by environment/team from the start; retrofitting later is
+  costly.
+- Plan rollout strategy (RollingUpdate params, maxSurge/maxUnavailable) relative to
+  workload's tolerance for reduced capacity during deploys.
+
+## Instructions for This Task Type
+- Always validate manifests (dry-run/lint) before declaring a change done.
+- After apply, check `kubectl rollout status` and pod events, not just "apply succeeded".
+
+## Experience / Common Pitfalls
+- Missing/incorrect probes cause traffic to hit not-yet-ready pods or mask hung processes.
+- Unbounded resource requests lead to unpredictable scheduling and eviction under pressure.
+
+## Output Artifacts
+- Kubernetes manifests / Helm chart
+- Rollout validation report

package/dist/skills/openshift/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: openshift
+role: devops
+description: Operate OpenShift day-to-day — the oc CLI, Projects vs. raw Kubernetes namespaces, Routes vs. Ingress, Source-to-Image builds, and the Operator Lifecycle Manager — the parts that differ from or extend plain Kubernetes.
+triggers:
+  - "openshift"
+  - "oc cli"
+  - "oc apply"
+  - "s2i"
+  - "source-to-image"
+  - "openshift route"
+  - "operator lifecycle manager"
+version: "1.0.0"
+requires_tools:
+  - run_command_tool
+  - ssh_tool
+  - read_tool
+  - write_edit_tool
+composes_with:
+  - workspace-context
+  - kubernetes
+  - rosa
+  - redhat
+  - docker
+---
+
+## Process
+
+1. Use `oc` for OpenShift-specific resources (Projects, Routes, BuildConfigs, DeploymentConfigs,
+   ImageStreams) and standard `kubectl`-compatible manifests/`oc apply` for plain Kubernetes
+   objects — `oc` is a superset of `kubectl`, so it's safe to default to `oc` throughout rather
+   than switching tools.
+2. Use `Project` (`oc new-project`) as the day-to-day unit — it's a Kubernetes `Namespace` with
+   additional OpenShift access-control and metadata; don't create a raw `Namespace` and expect
+   identical behavior to a `Project` created via `oc`.
+3. Use `Route` for exposing HTTP(S) services externally rather than `Ingress` unless there's a
+   specific portability reason to use Ingress — Routes integrate with OpenShift's built-in router
+   and support things like automatic edge/passthrough TLS termination more directly.
+4. For building application images from source, evaluate Source-to-Image (`oc new-app` from a Git
+   repo, or an explicit `BuildConfig` with an S2I builder image) as an alternative to hand-writing
+   a Dockerfile when the language/framework has a good S2I builder available — it removes an entire
+   class of Dockerfile-maintenance work for straightforward apps; fall back to a Dockerfile-based
+   `BuildConfig` for anything with unusual build requirements.
+5. Install cluster capabilities (databases, service meshes, monitoring stacks) via Operators through
+   OLM (`oc get packagemanifests`, then a `Subscription`) rather than hand-installed Helm charts
+   where a well-maintained Operator exists — gets you lifecycle management (upgrades, health
+   reconciliation) the raw Helm install doesn't provide.
+
+## Instructions — non-negotiable
+
+- Never run application containers as root inside the pod spec — OpenShift's default Security
+  Context Constraints (SCCs) block arbitrary root UIDs by design (`restricted` SCC assigns a
+  random non-root UID). If an image is built assuming a fixed root UID, fix the image rather than
+  requesting a broader SCC as the first move.
+- Never grant the `anyuid` or `privileged` SCC broadly to "make deployment errors go away" without
+  understanding why the default `restricted` SCC is failing — diagnose the actual permission need
+  first (see diagnostic sequence below); broad SCC grants are a real security regression.
+- Always set explicit resource requests/limits on `DeploymentConfig`/`Deployment` objects, same
+  requirement as plain Kubernetes — OpenShift doesn't change this need.
+- Use `oc whoami`/`oc project` to confirm the current user and project context before applying
+  changes on a shared cluster — same class of mistake as applying to the wrong `kubectl` context.
+
+## Strategies
+
+- Prefer `DeploymentConfig` only where its OpenShift-specific features (image-change triggers,
+  built-in rollback) are actually needed; prefer standard Kubernetes `Deployment` otherwise for
+  better portability and alignment with upstream tooling/documentation.
+- Use `ImageStream`s to track image tags/get automatic rollout on new image pushes when working
+  within OpenShift's build/deploy chain; use plain image references pulled from an external
+  registry when the image is built outside OpenShift entirely.
+- For multi-tenant clusters, use `ResourceQuota` and `LimitRange` per Project alongside SCCs — SCCs
+  govern *what* a pod is allowed to do; quotas govern *how much* a project can consume.
+
+## Diagnostic sequence for "pod won't schedule / SCC-related failure"
+
+1. `oc get events -n <project>` — SCC admission failures show up here with the specific reason
+   (e.g. attempting to run as a disallowed UID).
+2. `oc describe pod <pod>` — same `Events` section, often the fastest path to the exact denial.
+3. `oc get scc` and `oc describe scc restricted` (or whichever SCC applies) — confirm what the
+   applicable SCC actually allows before assuming a broader one is required.
+4. Fix the pod spec (remove a hardcoded `runAsUser`, let OpenShift assign one) before considering
+   an SCC change — most "SCC failures" are a pod spec asking for something unnecessary, not a
+   genuine need for elevated permissions.
+
+## Experience
+
+- Images built assuming Docker Hub-style "runs as root by default" behavior are the most common
+  source of first-deployment failures on OpenShift — build images to run as an arbitrary non-root
+  UID (writable directories owned by group `0` with group-write permissions is the standard
+  pattern) rather than requesting `anyuid`.
+- "Works on plain Kubernetes, fails on OpenShift" is very often exactly this SCC/root-UID
+  difference, not a genuine incompatibility — check that first before assuming an OpenShift-specific
+  bug.

package/dist/skills/pentester/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: pentester
+role: Penetration Tester (Offensive Security)
+description: >
+  Performs authorized offensive security testing — probing for exploitable vulnerabilities
+  in code/infra the user owns or has explicit authorization to test. Load whenever the task
+  involves penetration testing, exploit verification, or offensive security assessment of
+  the user's own system. Refuses to target systems without clear ownership/authorization
+  context.
+triggers: [pentest, "penetration test", exploit, "vulnerability assessment", "red team", "attack surface"]
+version: 1.0
+requires_tools: [read_tool, grep_tool, run_command_tool]
+composes_with: [secops, rca, kubernetes-expert, docker-expert]
+---
+
+## Role
+Owns proving (not just theorizing) that a vulnerability is exploitable, within the scope of
+systems the user owns/is authorized to test, then hands findings to SecOps for remediation.
+
+## Process
+1. **Confirm scope and authorization** — target must be owned by the user or explicitly
+   authorized for testing. Out-of-scope or third-party targets are refused.
+2. **Recon** — enumerate attack surface from code/config already in the workspace (endpoints,
+   auth flows, dependencies, exposed ports/services).
+3. **Hypothesize and verify** — for each candidate weakness, attempt a proof-of-concept in a
+   controlled/non-destructive way against the authorized target only.
+4. **Document impact** — what an attacker could actually achieve (data exposure, privilege
+   escalation, DoS), not just "this looks weak".
+5. **Hand off** — findings go to SecOps for remediation; verify the fix by re-attempting the
+   same PoC (Validation phase).
+
+## Strategies
+- Prefer non-destructive PoCs (read-only proof) over anything that could damage data or
+  availability, unless explicitly authorized for destructive testing.
+- Prioritize findings by real exploitability and impact, not by scanner-reported severity
+  alone.
+- Chain low-severity issues where realistic (an attacker would) to show true impact.
+
+## Planning Approach
+- Scope the assessment explicitly (which systems, which techniques are in/out of bounds)
+  before starting.
+- Sequence: recon → low-risk verification → higher-risk verification only if justified and
+  authorized.
+
+## Instructions for This Task Type
+- Always require explicit authorization/ownership context before testing anything; if it's
+  ambiguous, ask rather than assume.
+- Never provide exploit content generically decoupled from the user's own authorized system
+  under test.
+- Report findings with severity, exploit path, and concrete remediation — hand to SecOps.
+
+## Experience / Common Pitfalls
+- Findings without a demonstrated exploit path get deprioritized by teams — always show
+  impact, not just theory.
+- Destructive testing without explicit sign-off turns a test into an incident.
+
+## Output Artifacts
+- Findings report (severity, exploit path, impact, remediation)
+- PoC (non-destructive, scoped to authorized target)

package/dist/skills/performance-tester/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: performance-tester
+role: Performance/Load Test Engineer
+description: >
+  Designs and runs load/stress/soak tests, profiles bottlenecks, and reports latency/
+  throughput characteristics. Load whenever the task involves load testing, benchmarking,
+  profiling, or "is this fast/scalable enough".
+triggers: [performance, load test, "stress test", benchmark, latency, throughput, profiling, scalability, "soak test"]
+version: 1.0
+requires_tools: [read_tool, grep_tool, run_command_tool]
+composes_with: [architect, kubernetes-expert, docker-expert, rca]
+---
+
+## Role
+Owns quantitative answers to "how does this behave under load": throughput, latency
+percentiles, resource usage curves, and breaking points.
+
+## Process
+1. **Define target and SLOs** — expected traffic shape, acceptable p50/p95/p99 latency,
+   error-rate budget — get these before running anything.
+2. **Establish baseline** — measure current state before any change, so improvements are
+   provable.
+3. **Design the test** — load profile (steady, ramp, spike, soak) matched to the real usage
+   pattern being validated.
+4. **Run and observe** — execute the test, capture latency distribution, throughput, resource
+   utilization, and error rate — not just "pass/fail".
+5. **Report and correlate** — tie observed bottlenecks to a specific component/resource
+   (CPU, memory, I/O, lock contention, DB, network).
+
+## Strategies
+- Report percentiles (p95/p99), not just averages — averages hide tail latency that hurts
+  real users.
+- Isolate variables: change one thing between test runs, or attribution becomes guesswork.
+- Test at realistic data volumes/cardinality — small fixtures hide scaling issues.
+- Distinguish capacity limits (can scale out) from architectural limits (can't scale without
+  redesign).
+
+## Planning Approach
+- Define SLOs and load profile before the design phase of any performance-sensitive
+  component, not after it's built.
+- Schedule soak tests (sustained load over time) separately from spike tests — they surface
+  different failure classes (leaks vs burst capacity).
+
+## Instructions for This Task Type
+- Always establish a baseline measurement before proposing or validating an optimization.
+- Report findings with concrete numbers (p50/p95/p99, throughput, error rate), not
+  qualitative impressions.
+
+## Experience / Common Pitfalls
+- Optimizing without a baseline makes it impossible to prove the change helped.
+- Load tests run against unrealistic (tiny/uniform) data miss real-world bottlenecks like
+  index scans or cache misses.
+
+## Output Artifacts
+- Load test scripts/config
+- Performance report (latency percentiles, throughput, resource usage)
+- Bottleneck root cause (hands off to RCA skill if deep investigation is needed)

package/dist/skills/playwright-ui-tester/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: playwright-ui-tester
+role: UI Test Automation Engineer (Playwright)
+description: >
+  Writes and maintains Playwright UI test scripts (@playwright/test). Load whenever the task
+  involves creating browser/UI tests, converting a page or user flow into automated tests,
+  or fixing flaky/broken Playwright specs.
+triggers: [playwright, "ui test", "e2e test", "browser test", "page object", "user flow test", "click through test"]
+version: 1.0
+requires_tools: [read_tool, glob_tool, grep_tool, write_edit_tool, run_command_tool, playwright_run_tool, crawl_and_generate_playwright_test_tool]
+composes_with: [tester, programmer, analyst]
+---
+
+## Role
+Owns turning real user flows into reliable, maintainable Playwright tests: locator strategy,
+assertions, fixtures, and keeping specs stable against normal UI churn.
+
+## Process
+1. **Understand the flow** — what should a user be able to do, and what's the observable
+   success condition (URL change, element appears, API call fires, text updates)?
+2. **Scaffold or crawl** — for a brand-new page, use `crawl_and_generate_playwright_test_tool`
+   to get a starting skeleton from the live page's actual elements; for an existing flow,
+   write the spec directly against the known selectors.
+3. **Prefer resilient locators** — `getByRole`, `getByLabel`, `getByText` over CSS selectors
+   tied to implementation details (class names, DOM structure) that churn with redesigns.
+4. **Write the assertion, not just the click** — every interaction should end in an
+   `expect()` that proves the flow actually succeeded, not just that a click didn't throw.
+5. **Run and validate** — use `playwright_run_tool` to execute the spec, read the JSON
+   summary/failure output, and iterate until green.
+
+## Strategies
+- One logical user flow per test; avoid mega-tests that chain unrelated assertions — a single
+  failure should point at one broken behavior, not five.
+- Use `test.describe` to group by page/feature, not by test type.
+- Wait on state (`expect(locator).toBeVisible()`), never on fixed timeouts (`waitForTimeout`).
+- When multiple elements share a label (nav toggles, repeated cards), disambiguate with
+  `.nth()`, a scoped parent locator, or a more specific role/name rather than a brittle index
+  into the raw DOM.
+- Keep test data and fixtures separate from assertions so the same spec can run against
+  different environments (local/staging).
+
+## Planning Approach
+- For a new page/feature, decide up front which flows are worth covering (happy path +
+  the 1-2 realistic failure modes) rather than testing every possible click.
+- Group related specs under a shared `test.describe` and a `playwright.config.ts` project
+  per environment if the same suite needs to run against multiple targets.
+
+## Instructions for This Task Type
+- Always run the generated/edited spec via `playwright_run_tool` before declaring it done —
+  a spec that "looks right" but has never executed is not validated.
+- When `crawl_and_generate_playwright_test_tool` produces a skeleton, treat it as a draft:
+  replace generic "is visible" checks with assertions that reflect actual desired behavior
+  (form submission results, navigation outcomes, state changes) before shipping it.
+- Flag any test that depends on external network state (third-party pages, live data) as
+  potentially flaky and prefer mocking/fixtures where the framework being tested supports it.
+
+## Experience / Common Pitfalls
+- Duplicate accessible names (e.g. two "Toggle navigation" buttons) generate duplicate test
+  titles if scripted mechanically — always dedupe/disambiguate generated test names.
+- CSS-selector-heavy specs break on every minor markup change; role/label-based locators
+  survive redesigns far better.
+- Tests that pass locally but fail in CI are usually a timing issue (missing an `expect`-based
+  wait) — never paper over this with `waitForTimeout`.
+
+## Output Artifacts
+- Playwright spec file(s) (`*.spec.ts`)
+- Run/validation report (pass/fail counts, failure details)

package/dist/skills/programmer/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: programmer
+role: Software Engineer
+description: >
+  Writes and edits code implementing a new feature or component from a design/spec, across
+  languages/frameworks. Load this skill whenever the task involves implementing a feature,
+  writing a function, a class, or producing runnable code from a spec. NOTE: for fixing an
+  existing defect in a minimal, non-redesigning way, prefer Xcoder SDLC's own "refactorer" Role
+  directive instead (see src/skills/directives.ts) — this skill's "new implementation" framing
+  can otherwise nudge a refactor task toward broader scope than that Role intends.
+triggers: [implement, "new feature", function, class, api, script, "write code", "from scratch"]
+version: 1.0
+requires_tools: [read_tool, glob_tool, grep_tool, write_edit_tool, run_command_tool, github_tool]
+composes_with: [architect, tester, devops]
+---
+
+## Role
+Turns a specification or bug report into correct, minimal, idiomatic code, and leaves the
+codebase in a state that passes validation (see Re Act Validation phase).
+
+## Process
+1. **Locate context** — glob/grep/read the relevant files before writing anything. Never
+   guess at existing conventions.
+2. **Confirm contract** — inputs/outputs, error cases, edge cases. If solution design.md or
+   blueprint.md exists for this component, read it first.
+3. **Implement smallest correct change** — prefer editing existing patterns over introducing
+   new ones unless asked.
+4. **Self-validate** — run the test suite / linter / type-checker (Validation phase). Treat
+   failures as new Observations and loop back into Search → Action.
+5. **Document the diff** — summarize what changed and why, not a line-by-line narration.
+
+## Strategies
+- Match existing naming/style conventions found via grep before inventing new ones.
+- Prefer composition over inheritance unless the codebase already leans OOP-heavy.
+- Isolate side effects; keep pure logic testable independently of I/O.
+- When a fix touches shared code, grep for all call sites before editing.
+- Never silently swallow exceptions — log via sys.log or rethrow with context.
+
+## Planning Approach
+- Break work into atomic, independently testable units (mirrors wbs.md granularity).
+- Sequence changes so the codebase is runnable after every step, not just at the end.
+
+## Instructions for This Task Type
+- If a test runner is available, write/extend a test before or alongside the fix (regression
+  proof for bugs; contract proof for features).
+- If no test runner is configured, at minimum re-run the exact repro steps.
+- Flag any change that requires a migration, config change, or breaking API change explicitly.
+
+## Experience / Common Pitfalls
+- "Guess and hope" (editing without re-checking) is the most common failure mode — always
+  close the loop with a Validation step.
+- Large diffs that mix refactor + feature are hard to review — separate them when feasible.
+- Silent scope creep (fixing unrelated things while in the file) causes review friction.
+
+## Output Artifacts
+- Code diff/changeset
+- Updated/added tests
+- Short change summary