@event4u/agent-config 1.28.0 → 1.29.0

package/.agent-src/skills/prompt-engineering-patterns/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: prompt-engineering-patterns
+description: "Use when designing production-LLM prompts — few-shot, chain-of-thought, system prompts, templates, self-verification — distinct from prompt-optimizer and refine-prompt."
+source: package
+status: active
+---
+
+# prompt-engineering-patterns
+
+Production patterns for LLM prompts: few-shot, chain-of-thought, system-prompt design, templating, self-verification. **Distinct surface** from sibling skills:
+
+- [`prompt-optimizer`](../prompt-optimizer/SKILL.md) — polishes a single end-user prompt for ChatGPT / Claude / Gemini.
+- [`refine-prompt`](../refine-prompt/SKILL.md) — refines a free-form work prompt into engine-ready acceptance criteria.
+- **This skill** — designs prompts that ship inside an application that calls an LLM at runtime.
+
+## When to use
+
+- Designing the system prompt for a new LLM-powered feature.
+- Building a few-shot template with dynamic example selection.
+- Adding chain-of-thought reasoning to a low-accuracy prompt.
+- Reviewing a prompt diff in production code.
+- Diagnosing inconsistent LLM outputs that look like prompt drift.
+
+Do NOT use when:
+
+- Polishing a one-off prompt for a chat session — route to `prompt-optimizer`.
+- Turning a Jira ticket into engine input — route to `refine-prompt`.
+- Tuning a model's weights — this skill is prompt-only, not fine-tuning.
+
+## Decision framework
+
+### Step 1 — Pick the prompt level (progressive disclosure)
+
+```
+Start at Level 1; only escalate when measurement says you must.
+
+Level 1  Direct instruction                    "Summarize this article."
+Level 2  + constraints (length, format, focus) "...in 3 bullets, key findings only."
+Level 3  + reasoning scaffold                  "Read first, identify findings, then summarize."
+Level 4  + few-shot examples                   "Like these examples: ..."
+Level 5  + self-verification step              "...then check answer against criteria; revise if fails."
+```
+
+Escalating without evidence is over-engineering. Each level adds tokens, latency, and a maintenance surface.
+
+### Step 2 — Structure the prompt
+
+Fixed instruction hierarchy — every production prompt fills these slots in order:
+
+```
+[System context]   role, expertise, constraints, safety
+[Task instruction] what to do, in one sentence
+[Examples]         few-shot demonstrations (optional)
+[Input data]       the user-supplied content
+[Output format]    schema, length, citation rules
+```
+
+Stable slots (system, task, format) belong in cached prompt prefixes; volatile slots (examples, input) belong in the per-call portion.
+
+### Step 3 — Pick the few-shot strategy
+
+```
+Examples are uniform and small (< 20)         → embed all of them; deterministic.
+Examples are large or diverse                 → semantic-similarity retrieval per call.
+Edge cases dominate                           → diversity-sampled examples (cluster + pick one per cluster).
+Token budget tight                            → fewer, higher-quality examples beats many mediocre.
+Examples drift with the data                  → regenerate from a labeled corpus on a schedule, not hand-edited.
+```
+
+Bad examples are worse than no examples — the model imitates structure.
+
+### Step 4 — Add chain-of-thought ONLY when measured
+
+CoT improves accuracy on multi-step reasoning, hurts on classification and lookup. Decision rule:
+
+```
+Task is multi-step / arithmetic / multi-hop   → add CoT (zero-shot "let's think step by step", or few-shot CoT).
+Task is single-step extraction / classify     → CoT adds tokens without lift; skip.
+You haven't measured                          → measure first, decide second.
+Self-consistency needed (high-stakes answers) → sample N reasoning paths, majority vote.
+```
+
+### Step 5 — Build error recovery into the prompt
+
+Production prompts handle their own failure cases:
+
+- Specify the explicit "I don't know" output (don't let the model invent).
+- Require a confidence indicator when downstream code needs to gate.
+- Define the format for "missing information" so callers can branch.
+- For self-verification: specify the criteria, then the revision rule.
+
+### Step 6 — Treat prompts as code
+
+- Version every prompt (file + git, not a wiki page).
+- Test on a frozen evaluation set before shipping changes.
+- Track P50 / P95 latency, token usage, accuracy, success rate per version.
+- A/B test prompt variants behind a flag; never edit a live prompt without a rollback path.
+
+## Procedure: Apply to a new LLM feature
+
+1. **Inspect** the existing prompt (if any) and the eval set; verify a success metric exists (accuracy / consistency / latency / token cost) — refuse to design without it.
+2. Draft Level-1 prompt (Step 1) and measure on the eval set.
+3. Escalate one level at a time (Step 1) until metric is met or budget runs out.
+4. Lock the structure (Step 2), choose few-shot strategy (Step 3), decide CoT (Step 4).
+5. Add error-recovery clauses (Step 5).
+6. Commit prompt + eval results + chosen version (Step 6); cite this skill.
+
+## Output format
+
+1. Prompt-spec table: slot · content · stable-vs-volatile · cached-vs-per-call.
+2. Eval results table: prompt-version · metric · delta-vs-previous.
+3. Failure-mode list: trigger · prompt clause that handles it.
+
+## Gotcha
+
+- Few-shot examples leak the model's style — examples that include hedging produce hedging.
+- "Let's think step by step" works zero-shot on capable models, fails on smaller models without exemplar reasoning traces.
+- Self-consistency (N samples + vote) multiplies cost by N — only on high-stakes paths.
+- Cached prompt prefixes only cache when byte-identical — a single reformat busts the cache.
+- Prompts that drift across model versions silently regress accuracy when the provider rolls a model update; pin model version OR re-run eval per release.
+
+## Do NOT
+
+- Do NOT escalate to Level 4 / 5 before measuring at lower levels.
+- Do NOT mix few-shot examples from different tasks; the model averages them.
+- Do NOT add CoT to single-step classification — it hurts.
+- Do NOT hand-edit production prompts without versioning + eval.
+- Do NOT echo secrets or PII into the prompt — they end up in provider logs.
+
+## Auto-trigger keywords
+
+- prompt engineering
+- few-shot learning
+- chain-of-thought
+- system prompt design
+- prompt template
+- LLM prompt versioning
+- prompt evaluation
+
+## Provenance
+
+- Adopted from: `Microck/ordinary-claude-skills@8f5c83174f7aa683b4ddc7433150471983b93131:skills_all/prompt-engineering-patterns/SKILL.md` (MIT, © 2025 Microck) — restructured into a decision-framework shape; vendor `prompt_optimizer` Python snippets dropped (project-specific to Microck).
+- Cross-linked: [`prompt-optimizer`](../prompt-optimizer/SKILL.md), [`refine-prompt`](../refine-prompt/SKILL.md), [`mcp-builder`](../mcp-builder/SKILL.md), [`async-python-patterns`](../async-python-patterns/SKILL.md).
+- Provenance registry: `agents/contexts/skills-provenance.yml` (entry: `prompt-engineering-patterns`).
+- Iron-Law floor: `verify-before-complete`, `skill-quality`, `non-destructive-by-default`.

package/.agent-src/skills/repomix/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: repomix
+description: "Use when packaging a codebase to a single AI-friendly file for LLM analysis — local or remote, XML/Markdown/JSON, token counting, gitignore filtering, peer-side `repomix` CLI."
+source: package
+---
+
+> **Pinned upstream:** `repomix` CLI (npm: `repomix`, brew: `repomix`). Re-verify per minor bump. Repomix is an **optional dependency** — this skill never installs it silently.
+
+# repomix
+
+Wraps the upstream [`yamadashy/repomix`](https://github.com/yamadashy/repomix) CLI for codebase-snapshot workflows: pack a local or remote repo into a single XML / Markdown / JSON file with token counts and secret detection, then feed it to an LLM for review, audit, or migration scoping.
+
+## When to use
+
+- Producing an LLM-ingestible snapshot of a repo (or a sub-tree) for review or audit.
+- Comparing two branches by packaging each and diffing the snapshots.
+- Pulling a remote third-party library into context without cloning.
+- Pre-flighting a token budget before sending a codebase to an LLM.
+
+Do NOT use when:
+
+- You only need a few specific files — read them directly with `view`.
+- The snapshot will only feed a non-text format (PDF, image, audio) — route to [`markitdown`](../markitdown/SKILL.md).
+- The repo is sensitive and `--no-security-check` would be needed — STOP, route to a human.
+
+## Procedure: Snapshot a repo for LLM review
+
+### Step 0: Verify repomix is installed (peer-side)
+
+```bash
+repomix --version
+```
+
+If the binary is missing, surface one of the install recipes and STOP — do not install silently:
+
+```bash
+# npm (preferred for project-local installs)
+npm install -g repomix
+
+# Homebrew (macOS / Linux)
+brew install repomix
+```
+
+### Step 1: Decide local vs remote
+
+```bash
+# Local: pack the current directory.
+repomix
+
+# Remote shorthand: owner/repo
+npx repomix --remote owner/repo
+
+# Remote URL with a pinned commit
+npx repomix --remote https://github.com/owner/repo/commit/<sha>
+```
+
+### Step 2: Filter the snapshot to the smallest useful slice
+
+```bash
+# Include patterns
+repomix --include "src/**/*.php,*.md"
+
+# Add ignore patterns on top of .gitignore
+repomix -i "tests/**,*.test.js"
+
+# Strip comments to save tokens
+repomix --remove-comments
+```
+
+### Step 3: Pick the output format and destination
+
+```bash
+repomix --style markdown -o snapshot.md   # human-readable
+repomix --style xml -o snapshot.xml       # default; clearest separators for LLMs
+repomix --style json -o snapshot.json     # programmatic post-processing
+repomix --copy                            # also copy to clipboard
+```
+
+### Step 4: Verify token budget and secrets
+
+Repomix prints per-file and total token counts and runs Secretlint on the output. Check the totals against the target LLM context window:
+
+| Model              | Approx context |
+|--------------------|----------------|
+| Claude Sonnet 4.5  | ~200K tokens   |
+| GPT-4 family       | ~128K tokens   |
+| GPT-3.5            | ~16K tokens    |
+
+If Secretlint flags anything, STOP — sanitize the input or add the offending paths to `.repomixignore` before re-packing. Never use `--no-security-check` on an unfamiliar codebase.
+
+### Step 5: Hand the snapshot to the consumer skill
+
+Most workflows that call this skill pass the snapshot to:
+
+- A code-review pass — pair with [`judge-bug-hunter`](../judge-bug-hunter/SKILL.md) or [`judge-security-auditor`](../judge-security-auditor/SKILL.md).
+- Reference-repo analysis — route to [`analyze-reference-repo`](../../commands/analyze-reference-repo.md).
+- Migration scoping — route to [`blast-radius-analyzer`](../blast-radius-analyzer/SKILL.md).
+
+Cite the snapshot path so the consumer skill can read it.
+
+## Output format
+
+1. The repomix invocation (one shell line, with all filters and the output path).
+2. The output file path + format + total token count.
+3. Any Secretlint findings, verbatim. Empty section if none.
+
+## Gotcha
+
+- `--copy` puts the entire snapshot on the clipboard — surprising on large repos. Prefer `-o <path>` for anything > a few KB.
+- `--no-gitignore` plus a wildcard include can pull in `.env`, `vendor/`, `node_modules/` — never combine without a tight `--include` first.
+- Remote `npx repomix --remote owner/repo` defaults to the latest commit on the default branch — pin a commit SHA when reproducing a previous snapshot.
+- Token counts are LLM-tokenizer estimates, not exact — leave a 10–15% headroom under the model's documented context window.
+
+## Do NOT
+
+- Do NOT run `repomix --no-security-check` on an unfamiliar codebase.
+- Do NOT install repomix silently — surface the recipe and let the consumer install it.
+- Do NOT commit `repomix-output.*` artifacts — add the pattern to `.gitignore`.
+- Do NOT package `.env`, key material, or `.git/` — adjust `.repomixignore` first.
+- Do NOT vendor repomix into the repo — it is a peer-side CLI.
+
+## Auto-trigger keywords
+
+- repomix
+- pack codebase
+- repository snapshot
+- llm context bundle
+- codebase to single file
+
+## Provenance
+
+- Upstream tool: https://github.com/yamadashy/repomix (MIT).
+- Adopted from: `Microck/ordinary-claude-skills@8f5c83174f7aa683b4ddc7433150471983b93131:skills_all/repomix/SKILL.md` (MIT, © 2025 Microck) — wrapper-style adoption, no upstream code vendored.
+- Provenance registry: `agents/contexts/skills-provenance.yml` (entry: `repomix`).
+- Iron-Law floor: `non-destructive-by-default`, `missing-tool-handling`, `tool-safety`.

package/.agent-src/skills/secrets-management/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: secrets-management
+description: "Use when picking a secrets store, designing rotation, or wiring scanning gates — multi-cloud (Vault, AWS, Azure, GCP), CI, and Kubernetes — decision framework, provider deep-dives externalized."
+source: package
+status: active
+refresh_trigger: "A cited provider deprecates an auth method, OR External Secrets Operator ships a major version with breaking CRD changes, OR ≥30% of cited scanner tools change their gate semantics."
+sunset_criterion: "When provider docs (Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) all converge on a single rotation + scanning standard AND consumer projects no longer cite this skill in PR reviews for two consecutive review cycles."
+---
+
+# secrets-management
+
+Decision framework for storing, rotating, and scanning secrets across cloud, CI, and Kubernetes. **Provider deep-dives live upstream** (links in § Provenance) — this skill is the predicate, not the per-vendor cookbook. Sunset-policy compliant.
+
+## When to use
+
+- Designing where a new secret lives (env var, Vault, AWS Secrets Manager, Azure KV, GCP SM, GitHub/GitLab CI, k8s).
+- Reviewing a diff that introduces a credential, API key, signing key, or DB password.
+- Setting up secret rotation for an existing application.
+- Wiring secret-scanning gates into pre-commit, CI, or org-policy.
+
+Do NOT use when:
+
+- The secret is project-AWS-only and `aws-infrastructure` already covers the placement — route there.
+- The work is a security audit of running code — route to [`security-audit`](../security-audit/SKILL.md) or [`threat-modeling`](../threat-modeling/SKILL.md).
+- The decision is which cipher to use for at-rest encryption — read the provider's KMS docs directly.
+
+## Decision framework
+
+### Step 1 — Pick the store
+
+```
+Ephemeral, dev-only, never leaves the laptop  → .env (gitignored). Stop.
+Single-cloud, single-app                       → that cloud's native store
+                                                  (AWS Secrets Manager / Azure Key Vault /
+                                                  GCP Secret Manager).
+Multi-cloud OR on-prem hybrid                  → HashiCorp Vault (or cloud-agnostic equivalent).
+CI-only (deploy keys, signing tokens)          → GitHub/GitLab repo+environment secrets;
+                                                  scope to environment (production/staging).
+Kubernetes workload secrets                    → External Secrets Operator pulling from
+                                                  the canonical store above; never hand-rolled
+                                                  k8s `Secret` objects committed to git.
+Cross-tenant / cross-org shared secret         → don't. Re-architect; shared secrets are an
+                                                  outage and a breach class on their own.
+```
+
+### Step 2 — Pick the access pattern
+
+```
+Application reads at boot                      → fetch once, hold in memory; re-fetch on rotation event.
+Application reads per-request                  → cache with TTL ≤ rotation period / 2.
+Short-lived workload (Lambda, Job)             → fetch per-invocation; rely on platform IAM.
+Long-lived workload                            → leased / dynamic credentials (Vault DB engine,
+                                                  AWS IAM role) — never static creds.
+Human access                                   → no shared logins; per-user identity + audit.
+```
+
+### Step 3 — Define the rotation contract
+
+Every secret MUST have:
+
+- **Owner** — team/person responsible for rotation; tracked in code or runbook.
+- **Period** — calendar trigger (e.g. 90 days for static creds, hours/minutes for dynamic).
+- **Mechanism** — automated (Lambda + Secrets Manager rotation, Vault dynamic secret, IAM role) or documented manual procedure.
+- **Verification** — post-rotation health check; alert if old credential still observed in use after rotation grace window.
+
+Static secrets without a rotation mechanism are a deferred incident — refuse to merge.
+
+### Step 4 — Wire the scanning gates
+
+Three layers, all required:
+
+```
+Pre-commit  → gitleaks / TruffleHog / detect-secrets pre-commit hook.
+CI          → server-side scan on every PR; block merge on high-confidence finding.
+Org policy  → push-protection at the SCM (GitHub Advanced Security secret scanning,
+              GitLab Secret Detection); rotate any leaked secret immediately.
+```
+
+A leaked secret is rotated, not deleted. Git history retention defeats deletion.
+
+### Step 5 — Egress controls
+
+```
+Logs                → mask before write; CI runners must mark secrets as masked.
+Stack traces        → never include secret values; sanitize at the boundary.
+Error responses     → never echo the secret back, even on failure.
+Telemetry / APM     → strip from request/response captures; allowlist headers.
+```
+
+## Procedure: Apply to a new secret
+
+1. **Inspect** the existing secret inventory and IaC for store conventions; run Step 1 and lock the store decision in code/IaC.
+2. Define the access pattern (Step 2); choose static-vs-dynamic explicitly.
+3. Write the rotation contract (Step 3) into the runbook **before** the secret ships.
+4. Verify the three scanning gates (Step 4) cover the repo.
+5. Audit egress paths (Step 5) for the new secret class.
+6. Hand the design to a reviewer; cite this skill.
+
+## Output format
+
+1. Secret-inventory entry: name · store · access-pattern · owner · rotation-period · mechanism.
+2. Scanner-gate matrix: layer · tool · scope · failure mode.
+3. Egress-control checklist with sign-off per category.
+
+## Gotcha
+
+- "We rotate in Secrets Manager" — but the application caches the value forever. Cache TTL must be ≤ rotation grace.
+- External Secrets Operator pulls into a k8s `Secret`; that Secret is base64, **not encrypted**. Threat-model node access accordingly.
+- GitHub environment secrets are NOT available on `pull_request` events from forks — designs that rely on them silently break for external contributors.
+- Vault dynamic creds expire faster than long-running connection pools assume; close + re-acquire on lease near-expiry, don't wait for the failure.
+- Pre-commit scanners fire only when developers install the hook — CI scanners are the load-bearing gate.
+
+## Do NOT
+
+- Do NOT commit a secret, even to a private repo. Rotate any leaked secret; deletion does not work.
+- Do NOT pass secrets via CLI args (`ps` exposes them) — use env or stdin.
+- Do NOT echo secrets in logs, stack traces, error responses, or APM captures.
+- Do NOT hand-roll Kubernetes `Secret` objects committed to git — use External Secrets Operator.
+- Do NOT inline the per-provider cookbooks into this skill — externalize per Sunset Policy.
+
+## Auto-trigger keywords
+
+- secrets management
+- secret rotation
+- vault / aws secrets manager / azure key vault / gcp secret manager
+- external secrets operator
+- secret scanning / gitleaks / trufflehog
+- credential leak
+
+## Provenance
+
+- Adopted from: `Microck/ordinary-claude-skills@8f5c83174f7aa683b4ddc7433150471983b93131:skills_all/secrets-management/SKILL.md` (MIT, © 2025 Microck) — **Sunset Policy applied**: 346-line provider cookbook reduced to a ~140-line decision framework; per-provider deep-dives externalized to upstream docs below.
+- Externalized provider docs:
+  - HashiCorp Vault: https://developer.hashicorp.com/vault/docs · https://developer.hashicorp.com/vault/docs/secrets/databases
+  - AWS Secrets Manager: https://docs.aws.amazon.com/secretsmanager/ · rotation: https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html
+  - Azure Key Vault: https://learn.microsoft.com/en-us/azure/key-vault/general/
+  - GCP Secret Manager: https://cloud.google.com/secret-manager/docs
+  - External Secrets Operator: https://external-secrets.io/
+  - GitHub secret scanning: https://docs.github.com/en/code-security/secret-scanning · gitleaks: https://github.com/gitleaks/gitleaks · TruffleHog: https://github.com/trufflesecurity/trufflehog
+- Cross-linked: [`aws-infrastructure`](../aws-infrastructure/SKILL.md), [`security-audit`](../security-audit/SKILL.md), [`threat-modeling`](../threat-modeling/SKILL.md), [`security`](../security/SKILL.md).
+- Provenance registry: `agents/contexts/skills-provenance.yml` (entry: `secrets-management`).
+- Iron-Law floor: `verify-before-complete`, `skill-quality`, `non-destructive-by-default`.

package/.agent-src/skills/testing-anti-patterns/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: testing-anti-patterns
+description: "Use BEFORE writing or changing tests, adding mocks, or putting test-only methods on production classes — five Iron Laws and gates against mocking-the-mock, production pollution, silent partial mocks."
+source: package
+---
+
+# testing-anti-patterns
+
+Tests must verify real behavior, not mock behavior. Mocks isolate; they are not the thing under test. This skill is the **prevention** layer; [`judge-test-coverage`](../judge-test-coverage/SKILL.md) catches what slips through afterwards.
+
+## When to use
+
+- About to write a new test that mocks a collaborator.
+- Tempted to add a method to a production class purely for test cleanup.
+- Mock setup is becoming longer than the test logic itself.
+- A test passes but you cannot explain *what real behavior* it verified.
+- Code review of a diff that adds mocks — run the gates below before approving.
+
+Do NOT use when:
+
+- You need to *write* tests (no anti-pattern present yet) — route to [`pest-testing`](../pest-testing/SKILL.md) or [`test-driven-development`](../test-driven-development/SKILL.md).
+- The test failure is a real bug — route to [`systematic-debugging`](../systematic-debugging/SKILL.md).
+- You need overall coverage assessment of a finished diff — route to [`judge-test-coverage`](../judge-test-coverage/SKILL.md).
+
+## The Iron Laws
+
+```
+1. NEVER test mock behavior — assert on real component behavior.
+2. NEVER add test-only methods to production classes — put them in test utilities.
+3. NEVER mock without understanding the dependency chain — observe first, mock minimally.
+4. NEVER ship partial mocks — mirror the real response shape completely.
+5. NEVER treat tests as an afterthought — write the failing test first.
+```
+
+## Procedure: Run the gate before each anti-pattern
+
+### Anti-Pattern 1 — Asserting on mock elements
+
+Symptom: `expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument()` or `$this->assertSee('mock-sidebar')`. Test passes when the mock is present, fails when it is not — proves nothing about the component.
+
+Gate:
+
+```
+BEFORE asserting on any mocked element / id / class:
+  Ask: "Am I asserting that the mock exists, or that the component behaves correctly?"
+
+  IF asserting that the mock exists:
+    STOP — delete the assertion or unmock the dependency.
+    Replace with a behavior assertion (role, output, side effect).
+```
+
+### Anti-Pattern 2 — Test-only methods in production classes
+
+Symptom: `Session::destroy()` only ever called from `tearDown`. Production class polluted with code dangerous in production.
+
+Gate:
+
+```
+BEFORE adding any method to a production class:
+  Ask: "Is this only used by tests?"
+  IF yes:
+    STOP — move it to a test utility / trait / helper.
+  Ask: "Does this class own this resource's lifecycle?"
+  IF no:
+    STOP — wrong class for this method.
+```
+
+Replacement: a `tests/Support/cleanupSession.php` helper or a trait used only by test classes.
+
+### Anti-Pattern 3 — Mocking without understanding
+
+Symptom: A mocked method had a side effect the test depended on (e.g. wrote config). Mock kills the side effect; the test passes for the wrong reason or fails mysteriously.
+
+Gate:
+
+```
+BEFORE mocking any method:
+  STOP — do not mock yet.
+  1. List the side effects the real method produces.
+  2. List which of those side effects the test actually depends on.
+  3. If the test depends on any of them, mock at a *lower* level (the slow / external bit), preserving the necessary behavior.
+  IF unsure:
+    Run the test with the real implementation FIRST. Observe what fails.
+    THEN mock minimally, just below the failing seam.
+
+  Red flags:
+    - "I'll mock this just to be safe."
+    - "This might be slow, better mock it."
+    - You cannot draw the dependency chain.
+```
+
+### Anti-Pattern 4 — Partial / incomplete mocks
+
+Symptom: Mock returns only the fields the immediate test reads. Downstream code accesses an absent field and the test passes; integration breaks.
+
+Iron Rule: mock the **complete** response shape that the real API returns, not just the fields your assertion uses. If you cannot enumerate the shape, you should not mock.
+
+```
+BEFORE creating a mock response object:
+  1. Examine the real response (docs, recorded fixture, type definition).
+  2. Include EVERY documented field — even ones the test does not read.
+  3. If the shape is unknown, capture a real response into `tests/fixtures/` instead of inventing one.
+```
+
+### Anti-Pattern 5 — Tests as an afterthought
+
+Symptom: "Implementation complete, ready for testing." Implementation went in without tests. TDD was skipped, anti-patterns 1–4 are now likely.
+
+Gate: a feature is not complete until a failing-then-passing test cycle ran for it. Route to [`test-driven-development`](../test-driven-development/SKILL.md).
+
+## Output format
+
+1. The mocking decision recorded as a one-line comment in the test file (`// mock at <seam>: <reason>`).
+2. The replacement test (or refactor) once an anti-pattern is identified.
+3. If a test-only method moved out of production, the diff must show both the deletion and the test-utility addition.
+
+## Gotcha
+
+- Vague-test asserts (`assertTrue($result)`) hide mock-behavior assertions — flag any test where the assertion does not name an observable behavior.
+- A "complete" mock that mirrors a v1 API silently rots when v2 ships — link mock fixtures to a real recorded response and re-record on schema changes.
+- Layer 3 environment guards from [`defense-in-depth`](../defense-in-depth/SKILL.md) often expose anti-pattern 2: if a production guard fires only in tests, the test setup is wrong, not the guard.
+- Long mock setups (> 50% of the test) are a signal that integration tests would be simpler — consider it before piling on more mocks.
+
+## Do NOT
+
+- Do NOT add `*-mock` test ids to production templates.
+- Do NOT extend a production class to expose internals "just for testing".
+- Do NOT mock a method whose side effects the test depends on without reading the implementation.
+- Do NOT invent mock data shapes from memory — record from the real source.
+- Do NOT mark a story complete until at least one test was watched failing first.
+
+## Auto-trigger keywords
+
+- testing anti-patterns
+- mock behavior
+- test-only method
+- partial mock
+- mock without understanding
+
+## Provenance
+
+- Adopted from: `Microck/ordinary-claude-skills@8f5c83174f7aa683b4ddc7433150471983b93131:skills_all/testing-anti-patterns/SKILL.md` (MIT, © 2025 Microck).
+- Cross-linked: [`pest-testing`](../pest-testing/SKILL.md), [`test-driven-development`](../test-driven-development/SKILL.md), [`judge-test-coverage`](../judge-test-coverage/SKILL.md).
+- Provenance registry: `agents/contexts/skills-provenance.yml` (entry: `testing-anti-patterns`).
+- Iron-Law floor: `verify-before-complete`, `skill-quality`.

package/.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
   },
   "metadata": {
     "description": "Shared agent configuration \u2014 skills for AI coding tools (Claude Code, Augment, Cursor, Cline, Windsurf, Gemini CLI).",
-    "version": "1.28.0"
+    "version": "1.29.0"
   },
   "plugins": [
     {
@@ -33,6 +33,7 @@
         "./.claude/skills/api-endpoint",
         "./.claude/skills/api-testing",
         "./.claude/skills/artisan-commands",
+        "./.claude/skills/async-python-patterns",
         "./.claude/skills/authz-review",
         "./.claude/skills/aws-infrastructure",
         "./.claude/skills/blade-ui",
@@ -81,6 +82,7 @@
         "./.claude/skills/database",
         "./.claude/skills/dcf-modeling",
         "./.claude/skills/deep-reading-analyst",
+        "./.claude/skills/defense-in-depth",
         "./.claude/skills/dependency-upgrade",
         "./.claude/skills/description-assist",
         "./.claude/skills/design-review",
@@ -91,6 +93,7 @@
         "./.claude/skills/e2e-heal",
         "./.claude/skills/e2e-plan",
         "./.claude/skills/eloquent",
+        "./.claude/skills/error-handling-patterns",
         "./.claude/skills/estimate-ticket",
         "./.claude/skills/existing-ui-audit",
         "./.claude/skills/fe-design",
@@ -146,6 +149,7 @@
         "./.claude/skills/logging-monitoring",
         "./.claude/skills/markitdown",
         "./.claude/skills/mcp",
+        "./.claude/skills/mcp-builder",
         "./.claude/skills/md-language-check",
         "./.claude/skills/memory",
         "./.claude/skills/memory-add",
@@ -197,6 +201,7 @@
         "./.claude/skills/project-analyzer",
         "./.claude/skills/project-docs",
         "./.claude/skills/project-health",
+        "./.claude/skills/prompt-engineering-patterns",
         "./.claude/skills/prompt-optimizer",
         "./.claude/skills/quality-fix",
         "./.claude/skills/quality-tools",
@@ -208,6 +213,7 @@
         "./.claude/skills/receiving-code-review",
         "./.claude/skills/refine-prompt",
         "./.claude/skills/refine-ticket",
+        "./.claude/skills/repomix",
         "./.claude/skills/requesting-code-review",
         "./.claude/skills/research",
         "./.claude/skills/review-changes",
@@ -225,6 +231,7 @@
         "./.claude/skills/rule-compliance-audit",
         "./.claude/skills/rule-writing",
         "./.claude/skills/script-writing",
+        "./.claude/skills/secrets-management",
         "./.claude/skills/security",
         "./.claude/skills/security-audit",
         "./.claude/skills/sentry-integration",
@@ -244,6 +251,7 @@
         "./.claude/skills/terragrunt",
         "./.claude/skills/test-driven-development",
         "./.claude/skills/test-performance",
+        "./.claude/skills/testing-anti-patterns",
         "./.claude/skills/tests",
         "./.claude/skills/tests-create",
         "./.claude/skills/tests-execute",