Software Development Skills

Design know-how for ADR-0077 chaos-TDD — deterministic fault injection at existing seams (LLMBackend Protocol / requests HTTP layer) where the fault-injection test states the desired guarded behavior FIRST and the minimal guard lands in the same PR. Use when hardening a pipeline against LLM/external-I/O fault families (truncation, timeouts, 429s, wrong-shaped-but-parseable JSON, flapping backends), when building a fault catalog from operational bug history, when adding hypothesis-based fuzz over LLM output shapes, or when reviewing whether a new pipeline's failure paths abstain with reason codes. NOT for per-event audit log schema design (that is replayable-audit-logs / ADR-0075), NOT for read-only aggregate readings (read-only-instruments / ADR-0071), NOT for single-bug regression pinning after the fact (that is ai-regression-testing — this skill is its front-loaded, catalog-driven counterpart), and NOT for infra-level chaos (chaostoolkit/toxiproxy are the wrong altitude for a single local process).

Design patterns for layering deterministic code and LLM calls in a single pipeline or agent. Use when designing a pipeline that mixes semantic and structural work — distillation, extraction with validation, approval gates, orchestrated multi-step workflows. Catalogs four load-bearing layering patterns (LLM→Code guard, Code filter→LLM, LLM judge + Code enforce, Code orchestrator + LLM worker) with when-to-use, failure modes, and minimal code sketches. Macro-level companion to the micro "which tool for this one task" question.

Structural security design principles for building LLM agents, autonomous systems, and self-improving harnesses. Use when designing a new agent, reviewing agent architecture, adding a new capability, or auditing an existing agent for prompt injection resistance. Covers three load-bearing principles — Security by Absence, Untrusted Content Boundary, One External Adapter — plus concrete defense patterns for HTTP, credentials, and LLM hosts.

Design know-how for splitting a small local LLM's work across calls — by KIND of work (extract, then format/validate) and by ORDER (a call that judges an artifact must run after that artifact exists). Use when one generate() call is asked to do two things at once (decide-then-produce, extract-then-format), when a prompt's abstain path is a degenerate case of its output format and never fires, when choosing whether constrained decoding (format=/enum) helps or starves a task, when a reasoning model's chain-of-thought is being suppressed by an answer-only constraint, or when deciding where a quality gate belongs. NOT for choosing code vs LLM for a task in the first place (that is when-code-when-llm), NOT for the 4-layer code/LLM pipeline split (code-and-llm-collaboration), and NOT for fault injection at those seams (chaos-tdd-fault-injection / ADR-0077).

Design know-how for read-only instruments (計器) — aggregate readings over stored state (distributions, compositions, cluster structure) that inform the operator before an intervention, in the style of ADR-0071's pattern-composition instruments. Use when quantifying an open observation before intervening (instrument-first sequencing), when a design floor/threshold would otherwise be guessed, when calibrating an embedding-based reading (three-point scale), or when deciding whether to build OR remove an instrument (signal-first both ways). NOT for per-event audit logs that replay a decision offline (that is replayable-audit-logs / ADR-0075) and NOT for metrics that feed gates, ranking, or retrieval — instruments are observability, never intervention.

Design know-how for ADR-0075 observability-by-default — every feature that performs external I/O, calls an LLM, or makes non-deterministic/heuristic decisions ships a replayable append-only JSONL audit log in the same PR. Use when adding or reviewing such a feature (the Verify-gate question "which log answers why, and can we replay it offline?"), when designing a new audit record schema, when a recurring failure needs corpus-driven repair (replay harness, positive/negative ground truth, regression fixtures from real traffic), or when deciding how to store untrusted text in a log. NOT for read-only aggregate readings over stored state — distributions, compositions, calibration scales (that is read-only-instruments / ADR-0071) — NOT for choosing code vs LLM for a task (when-code-when-llm), and NOT for the security boundary model itself (llm-agent-security-principles / ADR-0007).

Design know-how for shadow-mode validation — running a candidate decision mechanism (typically an LLM judgment) in observe-only parallel with the live path, recording what it WOULD have decided per event, and letting the accumulated record decide enforcement, in the style of ADR-0076's skill-selection shadow instrument. Use when an unvalidated stochastic mechanism is about to replace or filter a live behavior (a one-way door for output quality), when a selector/classifier/gate has no published reliability evidence for the model class in play, or when designing the isolation, kill-switch, and exit criteria for a shadow deployment. NOT for aggregate readings over stored state (that is read-only-instruments / ADR-0071), NOT for the audit-log record schema itself (that is replayable-audit-logs / ADR-0075 — a shadow log IS one of those logs), and NOT a substitute for unit tests — shadow mode validates decision quality in production traffic, not code correctness.

Weekly レポート (A-E) を入力に、コードベース + ADR + identity/constitution/skills/rules を読んで F1 (構造提案) / F2 (identity-level questions) / F3 (observations) を別ファイル (weekly-{end-date}-findings.md) として生成する。weekly-analysis.sh が生成する自己内省レポートに対するコード診断 companion。Use when a new weekly report has been generated, or when refreshing F section of past reports after new ADRs land or pipeline code changes.

Decision framework for choosing between deterministic code (regex, keyword match, AST parse, schema validation) and LLM-based processing (classification, semantic similarity, judge) for a single task. Use when you catch yourself writing a regex for a task that keeps producing false positives or negatives, or when you are about to call an LLM for something a three-line code check would handle. Covers the structural-vs-semantic axis, the false-positive test, worked examples of both directions, and the enumerate/decide split for tasks where detection is structural but resolution needs judgment.

contemplative-agent をバックグラウンドで起動する。引数でセッション時間とバックエンド (ollama / cloud / mlx) を指定(例: /agent-run 4時間, /agent-run 30分 cloud openai, /agent-run 30分…

Apple Silicon (M1–M5) でローカル LLM の推論ランタイムを選ぶ・足す・最適化するときの判断軸。mlxlm.server は Ollama 比 ~1.8x 速だが生成専用(埋め込み endpoint なし・responseformat/JSON schema 拘束なし)なので埋め込みは Ollama に残す2サーバ構成になる点、ユニファイドメモリは VRAM 容量でなくメモリ帯域律速で MoE は RAM を節約しない点、コンテナは Metal 非対応な点を扱う。Use when 「Mac でもっと速く / 大きいモデルを動かしたい」「mlx-lm / MLX を入れたい」「Ollama から乗り換え / 併用したい」「16GB で実用的なモデルは」を検討するとき、生成を MLX に寄せて埋め込みの扱いで詰まったとき、ローカル LLM のベンチ A/B でメモリ圧の交絡を疑うとき。NVIDIA 前提(VRAM の壁・量子化・MoE オフロード)の知識を Apple Silicon…

土曜の単一承認セッション(ADR-0085)。無人 weekly チェーンが生成した承認パケット(weekly-{end-date}-packet.md)を読み、code patch の apply → Verify → 単一 commit、prompt diff の本文承認、insight staging の adopt-staged、gate メトリクスの記録までを 1 セッションで行う。Use when the user says 「週次の承認をする」「packet をレビューする」/weekly-gate, or on Saturday after the unattended chain has produced a decision packet.