cclaw-cli 0.5.17 → 0.7.0

package/dist/content/utility-skills.js

@@ -1,5 +1,5 @@
 /**
- * Utility skills that complement the 9 flow stages.
+ * Utility skills that complement the 8 flow stages.
  * These are contextual lenses, not flow stages.
  * Each skill: ~120-180 lines, under the 500-line progressive disclosure guideline.
  */
@@ -504,12 +504,45 @@ Do not start implementation execution without an approved plan artifact and expl
 - Machine-only checks are delegated to subagents when supported.
 - User approvals are requested only at required gate boundaries.
 
+## Fresh Context Protocol (between waves)
+
+After a wave completes — especially after long agent turns — context drift is
+the #1 cause of degraded execution quality. Before starting the **next wave**,
+prefer a **fresh agent context** over continuing in a saturated session:
+
+1. **Snapshot wave outcome** — append a short summary to the plan artifact
+   (\`### Wave <N> outcome\` with: tasks done, evidence files, blockers, next-wave inputs).
+2. **Capture handoff facts** — the minimum information the next agent needs:
+   - Stage and run id (from \`.cclaw/state/flow-state.json\`)
+   - List of completed task IDs from the plan
+   - Open blockers / failing gates by name
+   - File paths the next wave will touch (no full diffs)
+3. **Decide: continue or rotate**
+   - **Rotate** (start a new agent session) when: prior wave consumed > ~50% of the context budget, the prior wave required deep investigation that the next wave does not need, or you are about to cross a stage boundary.
+   - **Continue** when: next wave is a tiny follow-up (≤ 1 task) and the prior context is directly relevant.
+4. **Resume** in the new session via \`/cc-next\` — the session-start hook will restore flow state, checkpoint, and digest automatically.
+
+This is the same intuition as Compound Engineering's "fresh context per iteration": every wave starts with a clean, intentionally-loaded context, not a degraded carry-over.
+
+### Handoff template (paste into next session)
+
+\`\`\`markdown
+## Wave <N> handoff
+- Stage: <stage>
+- Run: <runId>
+- Completed task IDs: <list>
+- Blockers: <list or none>
+- Files next wave will touch: <list>
+- Verification command(s) used: <list>
+\`\`\`
+
 ## Anti-Patterns
 
 - Executing all tasks in one pass without intermediate verification.
 - Marking tasks done without command evidence.
 - Reordering critical dependencies for speed.
 - Continuing after a gate failure hoping later tasks fix it.
+- Carrying a saturated context across wave boundaries because "it has all the history" — saturated context is a liability, not an asset.
 `;
 }
 export function contextEngineeringSkill() {
@@ -649,6 +682,681 @@ Do not approve user-facing UI changes that break basic keyboard navigation or re
 - Color-only status indicators with no text/aria support.
 `;
 }
+export function landscapeCheckSkill() {
+    return `---
+name: landscape-check
+description: "Landscape survey before a design/scope decision. Use when deciding whether to build, reuse, or adopt — inside and outside the repo."
+---
+
+# Landscape Check
+
+## Quick Start
+
+> 1. Before committing to a build decision, survey the landscape: in-repo, in-ecosystem, and in-class.
+> 2. Produce a one-page table of candidates (build / reuse in-repo / adopt external) with evidence.
+> 3. Explicitly kill alternatives with a one-line reason. Do not leave implicit assumptions.
+
+## HARD-GATE
+
+Do not approve a scope or design that introduces a new system, library,
+or abstraction without comparing at least **one in-repo candidate** and
+**one external/ecosystem candidate** (or explicitly stating why no such
+candidates exist).
+
+## When to Use
+
+- Scope stage, before picking a mode (expand/selective/hold/reduce)
+- Design stage, before committing to a new architecture boundary
+- Brainstorm stage, when the user frames the problem as "let's build X"
+- Review stage, when a proposed change duplicates an existing capability
+
+## Protocol
+
+1. **Define the capability in one sentence.** "We need a way to <verb> <object> under <constraint>."
+2. **In-repo search.** Grep for similar verbs/modules/components. Read the closest 1-3 candidates. Record their fit and why they are or are not a good adapter target.
+3. **Ecosystem search.** Check ecosystem defaults (stdlib, framework primitives, common OSS packages in use). Do not invent new dependencies when an existing one covers 80%+ of the need.
+4. **In-class search.** Look at how other well-known projects in the same class solve this. Cite at least one concrete example (even if you end up rejecting it).
+5. **Produce the decision table.** Columns: Candidate, Kind (build / reuse / adopt), Fit (1-5), Effort (S/M/L/XL), Risk, Reason accepted or rejected.
+6. **Commit.** Pick exactly one winner. All losers must have a one-line kill reason.
+
+## Output Template
+
+\`\`\`markdown
+### Landscape Check — <capability>
+
+| Candidate | Kind | Fit | Effort | Risk | Verdict |
+|---|---|---|---|---|---|
+| src/foo/Bar | reuse | 4/5 | S | Low | SELECTED — already covers 80% of the need |
+| external/lib-x | adopt | 3/5 | M | Med | REJECTED — heavy dep, 20% unused surface |
+| build new | build | 2/5 | L | High | REJECTED — premature abstraction |
+
+**Decision:** Reuse \`src/foo/Bar\` with a thin adapter. Kill reasons recorded above.
+\`\`\`
+
+## Anti-Patterns
+
+- "We looked and nothing fits" without citing what was looked at.
+- Treating "nobody on the team knows library X" as a kill reason without evaluating the learning cost.
+- Choosing "build" because reuse would require a small refactor of the existing component.
+- Skipping the in-class search because "our case is special" — it usually is not.
+
+## Red Flags
+
+- Decision table has only the winner listed.
+- Ecosystem search is empty when a well-known primitive obviously applies.
+- "Fit" scores without evidence (no file:line, no cited OSS repo, no framework docs reference).
+- The in-repo candidate was never read before being dismissed.
+`;
+}
+export function knowledgeCurationSkill() {
+    return `---
+name: knowledge-curation
+description: "Read-only curation pass over .cclaw/knowledge.md and .cclaw/knowledge.jsonl. Surfaces stale, duplicate, or low-confidence entries and proposes a soft-archive plan; never deletes without explicit user approval."
+---
+
+# Knowledge Curation
+
+## Quick Start
+
+> 1. This is a **read-only audit** of \`.cclaw/knowledge.md\` and, when present, \`.cclaw/knowledge.jsonl\`. Never delete or rewrite entries here.
+> 2. Surface candidates for soft-archive when the active file > 50 entries OR contains stale/duplicate/superseded entries.
+> 3. Propose a single archive plan and require explicit user approval before any move.
+
+## HARD-GATE
+
+- Do not modify \`.cclaw/knowledge.md\` or \`.cclaw/knowledge.jsonl\` from this skill except via an explicit user-approved archive plan that **moves** markdown entries to \`.cclaw/knowledge.archive.md\` and appends soft-archive lines (same title, \`archived: true\`) to the JSONL. Never physically removes entries.
+- Do not silently rewrite or summarize entries — preserve original wording.
+- Prefer the JSONL store for queries when present (faster, structured); use the markdown mirror as the human-readable source of truth for final user approval.
+
+## When to run
+
+- Triggered automatically by **\`/cc-learn curate\`**.
+- Recommended after \`cclaw archive\` of a feature run, when knowledge has grown.
+- Recommended when active entry count exceeds **50**.
+
+## Audit dimensions
+
+For each entry in \`.cclaw/knowledge.md\` produce a row with:
+
+| Field | Source |
+|---|---|
+| Title | \`### <ts> [type] <title>\` heading |
+| Type | \`rule\` / \`pattern\` / \`lesson\` / \`compound\` |
+| Stage | \`Stage:\` field (or \`unknown\`) |
+| Age | days since timestamp |
+| Confidence | \`Confidence:\` field if present, else \`unstated\` |
+| Domain | \`Domain:\` field if present |
+| Supersedes | \`Supersedes:\` field if present |
+| Status hint | one of: keep / supersede-candidate / archive-candidate / duplicate |
+
+### Status rules
+
+- **supersede-candidate**: another entry has \`Supersedes: <this-title>\`.
+- **duplicate**: title or insight ≈ another entry's (caller's judgment, not regex).
+- **archive-candidate**:
+  - Type \`lesson\` AND age > 180 days AND no \`Supersedes\` chain points to it; OR
+  - Stage = \`brainstorm\` AND age > 90 days; OR
+  - Confidence = \`low\` AND age > 60 days; OR
+  - Total active entries > 50 and entry has lowest reuse signal.
+- **keep**: everything else.
+
+## Output format
+
+Produce two artifacts as **chat output only** (do not write files):
+
+### 1. Audit table
+
+\`\`\`markdown
+| # | Title | Type | Stage | Age | Confidence | Status hint |
+|---|---|---|---|---|---|---|
+| 1 | … | … | … | … | … | … |
+\`\`\`
+
+### 2. Soft-archive proposal
+
+\`\`\`markdown
+## Proposed archive (requires user approval)
+
+Threshold reasoning: <why entries below were selected>
+
+Entries to archive:
+1. <title> — reason
+2. <title> — reason
+
+Action plan if approved:
+1. Append a header to \`.cclaw/knowledge.archive.md\` with today's UTC date.
+2. Move (cut/paste) selected entries verbatim from \`.cclaw/knowledge.md\` into the archive file.
+3. Append a single supersession line to \`.cclaw/knowledge.md\`:
+   \\\`### <ts> [pattern] knowledge-curation-<date> — archived <N> entries, see knowledge.archive.md\\\`
+
+After approval: ask the user to run the move themselves, or — if they explicitly grant write access — perform the move atomically and report the new active count.
+\`\`\`
+
+## Anti-patterns
+
+- Deleting entries instead of archiving — knowledge must be append-only.
+- Rewriting an entry to "clean it up" — preserve original wording verbatim.
+- Auto-archiving without user approval, even when above threshold.
+- Removing \`compound\` entries — these are the highest-leverage records.
+- Treating high age as a proxy for low value — a 2-year-old security rule may be the most important entry in the file.
+`;
+}
+export function securityAuditSkill() {
+    return `---
+name: security-audit
+description: "Proactive security audit — hunts for vulnerabilities across the codebase using pattern-based detection. Distinct from security review (checklist for a specific diff)."
+---
+
+# Security Audit
+
+## Quick Start
+
+> 1. Scan the codebase for high-signal vulnerability patterns (not just the diff).
+> 2. Produce a finding register grouped by category with severity and file:line.
+> 3. For each Critical: provide a concrete exploit path (not just a category label).
+
+## HARD-GATE
+
+Do not close a security audit pass while any Critical pattern match is
+unresolved. Each Critical finding must be either fixed, suppressed with
+a documented reason, or tracked as a named accepted risk with an owner.
+
+## When to Use
+
+- Initial project onboarding (baseline audit)
+- Before a major release that expands attack surface
+- When new dependencies are introduced
+- After a security incident (to check for same-class issues)
+- On a scheduled cadence (quarterly for stable projects, monthly for high-risk)
+
+This is complementary to the \`security\` skill, which is a point-in-time
+review checklist scoped to a single diff.
+
+## Audit Pattern Catalog
+
+Run each category as a focused pass. For every pattern, capture
+file:line evidence — never assume the project is clean just because
+there was "no obvious problem".
+
+### 1. Secret Exposure
+
+Patterns to grep for (language-agnostic):
+
+- \`AKIA[0-9A-Z]{16}\` — AWS access key id
+- \`-----BEGIN (RSA |EC |DSA )?PRIVATE KEY-----\`
+- \`xox[bp]-[0-9a-zA-Z-]+\` — Slack tokens
+- \`ghp_[A-Za-z0-9]{36}\` — GitHub PAT
+- \`console\\.log.*(token|secret|password|api_key)\`
+- Hard-coded JWTs (3 base64 segments separated by \`.\`)
+
+Also inspect: .env.example for real values, logs for PII, git history for
+leaked secrets via \`git log -p | grep -i secret\`.
+
+### 2. Injection
+
+- Raw SQL string concatenation with request data
+- \`eval(\`, \`new Function(\`, \`exec(\`, \`execSync(\` with untrusted input
+- \`dangerouslySetInnerHTML\`, \`innerHTML =\` with user-provided content
+- Shell command construction from user input
+- Template literal SQL (\`\\\`SELECT ... \${userInput}\\\`\`)
+
+### 3. Auth and Session
+
+- Missing auth middleware on routes that mutate state
+- JWT verification that trusts the \`alg\` header (algorithm confusion)
+- \`setCookie\` without \`HttpOnly\`, \`Secure\`, or \`SameSite\`
+- Session fixation (no regenerate-on-login)
+- Rate limit absent on login, signup, password reset
+
+### 4. Trust Boundary and LLM Output
+
+- LLM output passed directly to \`exec\` / SQL / filesystem calls
+- Tool-call arguments from the model used without schema validation
+- Untrusted markdown rendered without sanitization
+- Confused deputy: service acts on behalf of user without passing auth context
+
+### 5. Crypto Misuse
+
+- MD5 / SHA1 for password hashing
+- \`Math.random()\` used for security tokens
+- Reused IV in AES-GCM (catastrophic)
+- ECB mode cipher usage
+- Missing constant-time comparison for secrets
+
+### 6. Dependency and Supply Chain
+
+- \`npm audit\` / \`pip audit\` Critical or High advisories unresolved
+- Dependencies pulled from non-locked tags instead of pinned versions
+- Post-install scripts from new/unknown packages
+- Un-reviewed direct-to-main dependency bumps
+
+### 7. File System and Path Traversal
+
+- \`path.join\` with user input without \`path.normalize\` + prefix check
+- Unzip/untar without entry path validation (zip-slip)
+- Writing to user-supplied paths without allowlist
+- Following symlinks inside trusted directories
+
+### 8. Logging and Observability
+
+- Stack traces returned in API responses (production)
+- Logs containing tokens, passwords, full request bodies
+- Error messages that reveal DB schema or internal paths
+
+## Output Format
+
+Produce a single audit report with this structure:
+
+\`\`\`markdown
+# Security Audit — <scope>, <date>
+
+## Summary
+- Files scanned: <N>
+- Categories checked: <list>
+- Critical: <N>, Important: <N>, Suggestion: <N>
+
+## Findings
+
+### <Category> — <Pattern name>
+- **Severity:** Critical | Important | Suggestion
+- **File:line:** path/to/file.ts:42
+- **Evidence:** short excerpt (≤ 3 lines)
+- **Exploit path:** specific, concrete (not a category label)
+- **Fix:** specific remediation with command/patch-level detail
+- **Owner:** <name or role>
+- **Target date:** <YYYY-MM-DD for Critical/Important>
+
+## Accepted Risks
+- <finding id>: <reason documented>, owner <name>, revisit <date>
+
+## Suppressed (False Positives)
+- <finding id>: <why this pattern is not exploitable here>
+\`\`\`
+
+## Anti-Patterns
+
+- "No Critical findings" without stating what patterns were actually run.
+- Accepting a Critical risk without named owner + revisit date.
+- Treating a lint rule as equivalent to a runtime security check.
+- Running audits only on the diff — the diff does not contain legacy risks.
+- Deleting audit reports after fixing findings (keep them as regression evidence).
+
+## Red Flags
+
+- Audit claims coverage but cites zero file:line evidence.
+- Every Critical pattern has zero matches (this is implausible for any non-trivial codebase — verify the grep commands were actually executed).
+- Findings are Important-only (no Critical or Suggestion buckets) — usually means severity was compressed to avoid escalation.
+`;
+}
+export function adversarialReviewSkill() {
+    return `---
+name: adversarial-review
+description: "Adversarial review lens. Use during review to deliberately attack the implementation — as a hostile user, a future maintainer, or a competitor."
+---
+
+# Adversarial Review
+
+## Quick Start
+
+> 1. Stop assuming good-faith usage. Play three roles in sequence: hostile user, stressed operator, future maintainer.
+> 2. For each role, produce at least 2 concrete attack/friction scenarios with file:line evidence.
+> 3. Escalate any finding that a Critical severity review would miss.
+
+## HARD-GATE
+
+Do not complete review stage without an adversarial-review pass when
+**any** of the following apply: user-facing input surface changed,
+trust boundary moved, concurrency was introduced, or a new failure
+mode path was added.
+
+## When to Use
+
+- Review stage, after Layer 2 quality checks complete
+- Before shipping anything user-facing or revenue-sensitive
+- When fuzz/property-testing exists but was not exercised against this change
+- When the implementer has a strong "this is fine" prior
+
+## Roles and Questions
+
+### Role 1 — Hostile User
+
+You are trying to break, trick, or exploit the system. Ask:
+
+- What happens on empty / null / maximum / negative / unicode / newline inputs?
+- What if I call the endpoint 1000 times per second? What about 1 every 10 minutes for a week?
+- What if I send a payload that is almost valid (off-by-one schema, wrong content-type, duplicate keys)?
+- What if two honest actions collide (double-click, race, retry after timeout)?
+- Can I observe a secret through error messages, timing, or response size?
+
+### Role 2 — Stressed Operator
+
+You are on call at 3 AM. Ask:
+
+- What does this look like in logs when it fails? Is the failure actionable?
+- If I restart the service mid-request, does state recover cleanly?
+- Is the rollback procedure real, tested, and under 15 minutes?
+- Can I tell from metrics alone whether this is healthy?
+
+### Role 3 — Future Maintainer
+
+You are reading this code in 6 months with no memory of the context. Ask:
+
+- Can I safely change this without breaking callers I cannot see?
+- Are there hidden invariants not captured in tests?
+- Will renaming this field silently break serialized consumers?
+- Is the "obviously correct" path actually correct, or is it just plausible?
+
+## Output Format
+
+For each finding:
+
+\`\`\`
+- **Role:** Hostile User | Stressed Operator | Future Maintainer
+- **Scenario:** concrete scenario (not a category)
+- **File:line:** path/to/file.ts:42
+- **Impact:** what breaks, for whom, under what frequency
+- **Recommendation:** specific fix or mitigation
+\`\`\`
+
+Escalate to the main review-army under the matching severity (Critical / Important / Suggestion).
+
+## Anti-Patterns
+
+- Treating adversarial review as a category list without producing concrete scenarios.
+- Assuming "our users would never do that" — they will, or the next integration will.
+- Running adversarial review after the ship decision is already made.
+- Only playing the hostile-user role and skipping operator + maintainer.
+`;
+}
+export function retrospectiveSkill() {
+    return `---
+name: retrospective
+description: "Post-ship retrospective lens. Use after a ship to extract durable lessons (rules, patterns, accelerators) before context fades. Distinct from the inline ship Compound Step — this is a deeper, optional sweep across the whole run."
+---
+
+# Retrospective
+
+## Quick Start
+
+> 1. Run **after** the ship stage closes (PR merged or release tagged), while the run is still loaded in memory.
+> 2. Walk the four lenses below; harvest concrete entries for \`.cclaw/knowledge.md\`.
+> 3. Stop when you have at least one durable entry **or** an explicit "no new lesson this run".
+
+## HARD-GATE
+
+Do **not** run retrospective before ship gates pass. The goal is to learn from
+a *closed* loop, not to evaluate work-in-progress.
+Do **not** invent generic platitudes ("write more tests"). Every entry must cite
+a concrete moment in *this* run (file, decision, blocker, surprise).
+
+## When to use
+
+- Right after \`/cc-next\` reports the ship stage complete.
+- Before starting the next \`/cc <idea>\` — fresh context, lessons captured.
+- After an incident or surprise during ship (rollback, hotfix, regression).
+
+## When NOT to use
+
+- Mid-flow (use the per-stage Operational Self-Improvement block instead).
+- For trivial changes (typo fix, config bump) — the Compound Step in the
+  ship template is enough.
+
+## Four Lenses
+
+For each lens, write either a knowledge entry **or** the explicit string
+"no new lesson". Skipping a lens silently is forbidden.
+
+### 1. What surprised us?
+
+- A bug that hid in a place no one suspected → \`[lesson]\`.
+- A test that passed but missed a real failure mode → \`[lesson]\`.
+- A library/API behavior that contradicted our mental model → \`[rule]\`.
+
+### 2. What slowed us down?
+
+- Repeated context loss between waves → \`[compound]\` accelerator.
+- Re-derivation of a fact already in upstream artifacts → \`[pattern]\` "re-read X first".
+- Tooling friction (slow test loop, flaky CI) → \`[compound]\` follow-up.
+
+### 3. What worked unreasonably well?
+
+- A refactor that unlocked the next 3 tasks → \`[pattern]\`.
+- A skill/agent invocation that nailed it on first try → \`[pattern]\` (record the prompt shape).
+- Adopting an existing solution instead of building → \`[rule]\` reinforcement.
+
+### 4. What would we do differently next time?
+
+- Architectural decision that aged poorly within the same run → \`[lesson]\`.
+- Scope mode chosen incorrectly → \`[rule]\` heuristic update.
+- Order-of-operations mistake (e.g. spec drift before tdd) → \`[pattern]\` ordering.
+
+## Output protocol
+
+For every harvested insight, append one entry to \`.cclaw/knowledge.md\` using
+the standard format (see \`learnings\` skill). Prefer:
+
+- \`[compound]\` for process/speed accelerators.
+- \`[lesson]\` for "we learned this the hard way".
+- \`[pattern]\` for repeatable shapes that worked.
+- \`[rule]\` only for hard constraints that must always hold.
+
+Then write a one-paragraph **Run Summary** at the top of the next
+\`/cc <idea>\` brainstorm context citing the lessons in scope.
+
+## Anti-patterns
+
+- Retrospective as performance review — frame is *system improvement*, not blame.
+- Harvesting only positive ("what worked") and skipping uncomfortable lessons.
+- Writing entries so generic they could apply to any project.
+- Letting the retrospective drift into a re-design of the shipped feature.
+`;
+}
+export function languageTypescriptSkill() {
+    return `---
+name: language-typescript
+description: "TypeScript rule pack. Opt-in language lens. Use when reviewing or writing TypeScript/JavaScript diffs during tdd or review — enforces type-safety, runtime-boundary validation, and idiomatic patterns."
+---
+
+# TypeScript Rule Pack
+
+## Quick Start
+
+> 1. Activate during tdd or review whenever the diff touches \`.ts\`, \`.tsx\`, \`.mts\`, \`.cts\`, or \`.js\` files.
+> 2. Walk the rule tiers in order. Tier-1 violations block merge. Tier-2 need a named follow-up.
+> 3. Cite each finding as \`file:line — <rule id> — <one-line remediation>\`.
+
+## HARD-GATE
+
+Do not approve a TypeScript change that ships \`any\`, \`@ts-ignore\`, or
+\`@ts-expect-error\` *without* (a) a comment explaining why, (b) a linked issue,
+and (c) an assertion that the blast radius is bounded to the current file.
+No exceptions in production code paths.
+
+## Tier 1 — blocking rules
+
+1. **No silent \`any\`.** Unknown inputs must be typed as \`unknown\` first, then narrowed.
+2. **Runtime validate trust boundaries.** HTTP bodies, env vars, file contents, and
+   IPC payloads must be parsed through a schema validator (zod, valibot, io-ts) before
+   being treated as typed data.
+3. **No \`as\` without a narrowing reason.** \`value as Foo\` is only acceptable when
+   preceded by a runtime check that proves the shape (e.g. \`if ("id" in value)\`).
+4. **Exhaustive switches on discriminated unions.** Every \`switch\` on a tagged
+   union must end with a \`default\` branch that assigns to \`never\` to surface
+   missing cases at compile time.
+5. **Promise hygiene.** No unawaited promises in \`async\` functions; no
+   \`void promise\` unless documented. Use \`@typescript-eslint/no-floating-promises\`.
+6. **Null-safety at the boundary.** Optional chaining (\`?.\`) and nullish
+   coalescing (\`??\`) must only be used when the null path is handled, not as a
+   silent default.
+
+## Tier 2 — follow-up rules
+
+7. Prefer \`readonly\` for arrays/object fields that are not mutated.
+8. Prefer \`type\` aliases for unions, \`interface\` for extendable object shapes.
+9. Name generic parameters descriptively once they carry semantic meaning (\`TEvent\`, \`TPayload\`).
+10. Avoid re-exporting entire namespaces; named re-exports keep bundle analysis tractable.
+11. Co-locate test fixtures with their types to keep drift visible.
+
+## Anti-patterns
+
+- "It compiles, ship it" — compilation is necessary, not sufficient. Runtime boundary validation is the gate.
+- Casting library return types to tighten them without reading the library's actual contract.
+- Wrapping every function in \`try/catch\` and swallowing the error — errors must either be rethrown typed or mapped to a Result/Either shape.
+- Using enums where a string-literal union would do (enums carry runtime cost and erase at tree-shaking time only when \`const\`).
+
+## Review output shape
+
+\`\`\`
+- **Rule:** T1-2 (runtime validate trust boundaries)
+- **File:line:** src/api/users.ts:42
+- **Finding:** POST body cast directly to \`UserCreateInput\`; no schema parse.
+- **Remediation:** Parse through \`userCreateSchema\` (zod) before passing to the service layer.
+\`\`\`
+`;
+}
+export function languagePythonSkill() {
+    return `---
+name: language-python
+description: "Python rule pack. Opt-in language lens. Use when reviewing or writing Python diffs during tdd or review — enforces typing, exception hygiene, and idiomatic patterns."
+---
+
+# Python Rule Pack
+
+## Quick Start
+
+> 1. Activate during tdd or review whenever the diff touches \`.py\` / \`.pyi\` files.
+> 2. Walk the rule tiers in order. Tier-1 violations block merge. Tier-2 need a named follow-up.
+> 3. Cite each finding as \`file:line — <rule id> — <one-line remediation>\`.
+
+## HARD-GATE
+
+Do not approve a Python change that catches bare \`except:\` or \`except Exception:\`
+in production code *without* (a) re-raising, (b) logging with \`logger.exception\`, or
+(c) a comment explaining the intentional swallow. Silent broad catches are the
+single biggest source of "works on my machine" bugs in Python services.
+
+## Tier 1 — blocking rules
+
+1. **Type hints on public APIs.** Every exported function, method, and dataclass
+   must have full type hints. Use \`from __future__ import annotations\` or PEP 604 union syntax.
+2. **No mutable default arguments.** \`def f(x=[])\` is a bug. Use \`None\` + inline default.
+3. **Exception specificity.** Catch the narrowest exception class you actually handle.
+4. **Context managers for resources.** Files, sockets, DB sessions, locks — always \`with\`.
+5. **No bare \`assert\` in production code.** \`assert\` is stripped under \`python -O\`.
+   For invariants, raise \`ValueError\`/\`RuntimeError\` explicitly.
+6. **Deterministic imports.** No conditional imports at module top level except for
+   platform branches; no import-time side effects.
+
+## Tier 2 — follow-up rules
+
+7. Prefer \`@dataclass(slots=True, frozen=True)\` for value objects.
+8. Prefer \`pathlib.Path\` over \`os.path\` for new code.
+9. Use f-strings for interpolation; reserve \`%\` and \`.format\` for logger messages (lazy eval).
+10. Use \`logging.getLogger(__name__)\` per module; never the root logger.
+11. Pin dependency ranges in \`pyproject.toml\`; lock with \`uv lock\` / \`pip-compile\`.
+
+## Async-specific
+
+- Do not mix \`requests\`/sync I/O inside \`async def\`. Use \`httpx.AsyncClient\` / \`aiofiles\`.
+- \`asyncio.gather\` with \`return_exceptions=False\` cancels siblings on first failure — be explicit.
+- Every task created with \`asyncio.create_task\` must have its reference kept and awaited.
+
+## Anti-patterns
+
+- Using \`**kwargs\` to avoid writing a real signature.
+- Monkey-patching modules from tests without a \`contextlib.contextmanager\` cleanup.
+- Treating \`__init__.py\` as a place to run logic (imports only).
+- Re-inventing \`itertools\`/\`functools\` instead of using stdlib.
+
+## Review output shape
+
+\`\`\`
+- **Rule:** P1-3 (exception specificity)
+- **File:line:** users/service.py:88
+- **Finding:** \`except Exception\` around DB call silently drops integrity errors.
+- **Remediation:** Catch \`IntegrityError\` explicitly; re-raise everything else.
+\`\`\`
+`;
+}
+export function languageGoSkill() {
+    return `---
+name: language-go
+description: "Go rule pack. Opt-in language lens. Use when reviewing or writing Go diffs during tdd or review — enforces error handling discipline, concurrency safety, and idiomatic patterns."
+---
+
+# Go Rule Pack
+
+## Quick Start
+
+> 1. Activate during tdd or review whenever the diff touches \`.go\` files.
+> 2. Walk the rule tiers in order. Tier-1 violations block merge. Tier-2 need a named follow-up.
+> 3. Cite each finding as \`file:line — <rule id> — <one-line remediation>\`.
+
+## HARD-GATE
+
+Do not approve a Go change that discards an \`error\` return value with \`_ = ...\`
+in production code *without* a comment explaining why the error is provably
+irrelevant. Discarded errors are Go's #1 source of silent data loss.
+
+## Tier 1 — blocking rules
+
+1. **Every \`error\` is checked or explicitly wrapped with \`fmt.Errorf("%w", err)\`.**
+2. **No goroutine leaks.** Every \`go func()\` must have a stop condition visible in
+   the diff: a \`context.Context\` cancellation, a \`done\` channel, or a bounded
+   input channel that will close.
+3. **Context propagation.** Any function that does I/O, RPC, or long work must take
+   \`ctx context.Context\` as the first parameter.
+4. **No mutex by value.** Fields of type \`sync.Mutex\` / \`sync.RWMutex\` must be
+   pointers *or* the containing struct must be used only via pointer receivers.
+5. **Defer placement.** \`defer file.Close()\` must immediately follow a successful
+   open, before any code path that can return early.
+6. **\`for range\` capture hygiene** (pre-Go 1.22): copy loop variables before
+   capturing in goroutines or deferred functions. From Go 1.22+ the language fixes
+   this, but confirm the repo's \`go\` directive in \`go.mod\`.
+
+## Tier 2 — follow-up rules
+
+7. Prefer small interfaces defined at the consumer site, not upstream.
+8. Prefer \`errors.Is\` / \`errors.As\` over string matching.
+9. Avoid \`init()\` except for registering with a framework.
+10. Use \`t.Helper()\` inside test helpers so failure lines point at the caller.
+11. Use \`//go:build\` tags for OS-specific code, not runtime \`runtime.GOOS\` checks.
+
+## Concurrency-specific
+
+- Buffered channels are a performance hint, not a correctness fix. Unbuffered first.
+- \`sync.WaitGroup\` \`Add\` must happen **before** \`go\`, not inside the goroutine.
+- \`atomic\` operations must be paired on the same variable — do not mix \`atomic.Load\`
+  with plain reads of the same field.
+- Shared maps require a mutex or \`sync.Map\`; Go's race detector in CI is non-negotiable.
+
+## Anti-patterns
+
+- Returning \`interface{}\` / \`any\` to "keep options open" — narrow it now.
+- Building "smart" error types that lose the wrapped chain.
+- Using \`panic\` for control flow in library code (allowed only for unrecoverable invariants).
+- Ignoring \`go vet\` warnings because "the code works".
+
+## Review output shape
+
+\`\`\`
+- **Rule:** G1-2 (no goroutine leaks)
+- **File:line:** internal/worker/pool.go:57
+- **Finding:** \`go w.loop()\` has no stop condition; context is not threaded through.
+- **Remediation:** Accept \`ctx\` in \`Start\` and select on \`ctx.Done()\` inside \`loop\`.
+\`\`\`
+`;
+}
+export const LANGUAGE_RULE_PACK_FOLDERS = {
+    typescript: "language-typescript",
+    python: "language-python",
+    go: "language-go"
+};
+export const LANGUAGE_RULE_PACK_GENERATORS = {
+    "language-typescript": languageTypescriptSkill,
+    "language-python": languagePythonSkill,
+    "language-go": languageGoSkill
+};
 export const UTILITY_SKILL_FOLDERS = [
     "security",
     "debugging",
@@ -658,7 +1366,12 @@ export const UTILITY_SKILL_FOLDERS = [
     "executing-plans",
     "context-engineering",
     "source-driven-development",
-    "frontend-accessibility"
+    "frontend-accessibility",
+    "landscape-check",
+    "adversarial-review",
+    "security-audit",
+    "knowledge-curation",
+    "retrospective"
 ];
 export const UTILITY_SKILL_MAP = {
     security: securityReviewSkill,
@@ -669,5 +1382,10 @@ export const UTILITY_SKILL_MAP = {
     "executing-plans": executingPlansSkill,
     "context-engineering": contextEngineeringSkill,
     "source-driven-development": sourceDrivenDevelopmentSkill,
-    "frontend-accessibility": frontendAccessibilitySkill
+    "frontend-accessibility": frontendAccessibilitySkill,
+    "landscape-check": landscapeCheckSkill,
+    "adversarial-review": adversarialReviewSkill,
+    "security-audit": securityAuditSkill,
+    "knowledge-curation": knowledgeCurationSkill,
+    retrospective: retrospectiveSkill
 };