Claude Skills by macintog

Prepare a substantive, source-backed causal account of an existing behavior, incident, or historical design decision when reconstructing and documenting the evidence is the selected deliverable. Do not trigger for routine rationale, explanation of your own recommendation, ordinary technical questions, current-task updates, or active failure diagnosis.

Map affected consumers and verification obligations before implementing or reviewing a change across interfaces, persistence or schemas, permissions, deployment or release boundaries, or independently failing downstream paths. Use for blast-radius and what-could-break questions. Do not use for ordinary local edits, generic code review, or a post-hoc risk narrative with no decision or verification consequence.

Find evidence-backed simplification, module deepening, terminology, and semantic-symmetry opportunities in a codebase. Use for architecture or refactoring audits, unnecessary architectural complexity, tightly coupled or shallow modules, weak test seams, scattered domain concepts, overloaded names, or sibling workflows whose ownership and transitions drift unexpectedly. Do not use for a narrow fix or an implementation whose architecture is already selected.

Measure and judge hardware-bound optimization tradeoffs involving latency, throughput, CPU/GPU/device or unified memory, headroom, capacity, OOM, fallback, offload, admission limits, or workload size. Use for benchmark design or execution, performance-claim review, hardware qualification, and optimization acceptance decisions. Do not use for routine cleanup or performance-neutral refactors with no material resource claim.

Design, inspect, adopt, repair, resume, or hand off multi-session project continuity. Use for continuity setup or audit, stale or conflicting startup docs, recursive checkpoints or queues, handoffs, context drift, or adjacent-repository topology. Separate durable intent, repo rules, volatile state, and history. Do not use for ordinary one-off work or infer adoption or current task authority from filenames.

Draft, revise, or review a substantive writing deliverable when editorial quality is itself part of the requested outcome. Use for authored documentation, reports, public copy, or explicit editing and style critique. Do not trigger for ordinary conversation, engineering reasoning, explanations of current work, or requests for longer or more expressive answers alone.

Audit or govern Codex skills, external skill intake, prompt packets, or skill-like guidance for routing, placement, prompt economy, validation, distribution, provenance, or collision safety. Use alongside the platform's skill-creation guidance when creating or revising a skill. Do not use for product-specific skill execution or subjective prose polish without a governance or safety consequence.

Use as an evidence-design overlay to create, revise, or critique charts, dashboards, analytical figures, visual tables, maps, KPI displays, evidence-rich diagrams, and decision-grade reports. Governs truthful comparison, uncertainty, documentation, restraint, accessibility, and rendered QA while medium-specific skills own implementation mechanics. Do not use for generic frontend or marketing design, decorative graphics, analysis without visual output, or diagrams without an evidentiary claim.

Publish a validated PR revision while continuing review, or complete a validated registered Git task when a selected private task reaches terminal delivery or the operator explicitly says yeet. Default pull-request completion delivers a tested ready PR and retires owned local state; integrate only for the user-selected outcome. Do not use for ordinary commits, tests, deployments, read-only or no-diff work, or selecting integration refs outside the user-selected outcome.