contemplative-agent
contemplative-agent enthÀlt 10 gesammelte Skills von shimo4228, mit Repository-Berufsabdeckung und Skill-Detailseiten auf SkillsMP.
Skills in diesem Repository
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 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).
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.
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.
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.
contemplative-agent ăăăăŻă°ă©ăŠăłăă§è”·ćăăăćŒæ°ă§ă»ăă·ă§ăłæéăšăăăŻăšăłă (ollama / cloud / mlx) ăæćźïŒäŸ: /agent-run 4æé, /agent-run 30ć cloud openai, /agent-run 30ć mlxïŒ
Apple Silicon (M1âM5) ă§ăăŒă«ă« LLM ăźæšè«ă©ăłăżă€ă ăéžă¶ă»è¶łăă»æé©ćăăăšăăźć€æè»žămlx_lm.server 㯠Ollama æŻ ~1.8x éă ăçæć°çšïŒćăèŸŒăż endpoint ăȘăă»response_format/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 ă«çż»èšłăăćż èŠăăăăšăă
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.
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.