slopflow

Design, review, or improve agentic systems with LLM loops, tools, memory/state, handoffs, subagents, guardrails, tracing, evaluations, or agent prompts. Use for agent architecture, agent implementation plans, prompt/skill design for agents, tool-contract design, multi-agent vs single-agent decisions, production-readiness reviews, and avoiding no-op agent instructions.

Programmatically validate datasets, parsed records, tables, CSV/JSON/YAML/XML/log outputs, benchmark outputs, metric reports, matrix results, counts, percentages, joins, migrations, exports, imports, and any claim that depends on data being read correctly. Use when the user asks to validate data, verify numbers, check parsing, compare expected vs actual data, audit metrics/results, or confirm that nothing was misread.

The coding workflow for any change that edits code or configuration scope calibration, implementation plan, plan audit, validation, and post-implementation audit. Use when implementing, fixing, adding, updating, or refactoring. Not for deciding whether code is safe to delete use legacy-cleanup or for review of someone else's change use code-review-discipline.

Threat-model a code, configuration, infrastructure, auth, data, cryptography, networking, or dependency change by decomposing it into application sub-components and applying each one's threat lens and controls. Use when building or modifying a feature with security in scope, or when the global Security Gate is accepted. Not for incident investigation (use rca-investigation) or for writing security tests alone (use adversarial-test-design).

Runtime evidence collection for workflow and CI incidents workflow run ids, CI job ids, GCP Cloud Logging queries, GCS artifact lookup, workflow DB artifacts, cache hit/miss proof, and worker behavior. Use when the input is a run identifier or a question about why a workflow failed, retried, slowed down, loaded cache, or built fresh. This skill gathers and proves runtime facts, hand its evidence packet to rca-investigation for the cumulative code-level root cause.

The reasoning spine for non-trivial, ambiguous, open-ended, or high-stakes work frame the problem, generate structurally different options, verify load-bearing claims, diagnose with competing hypotheses, evaluate against weighted criteria, decide under uncertainty, and synthesize — executed via mode files read one at a time with a todo ledger. Also holds the metric/oracle audit and meta-reasoning checks behind Core Rules 9-10. Use for design decisions, tradeoffs, "which approach" questions, planning, and before reporting any count, cost, accuracy, or pass/fail number. Engage on your own when the work warrants it; skip for trivial or mechanical tasks.

System-level analysis and design mapping entrypoints, active wiring, data/control flow, runtime variants, boundaries, and failure modes before proposing a design. Use for architecture questions, system design, RFCs, design reviews, production-path mapping, or "how is this system wired". Not for line-level correctness review of a diff (use code-review-discipline).

Correctness-first review of diffs and PRs behavioral regressions, hidden callers, production-path mismatch, error-handling gaps, weak tests, and a verdict. Use when reviewing a change, checking a diff for bugs, or deciding approve vs request-changes. Not for designing the system (use architecture-review) or writing new tests (use adversarial-test-design).

Invariant-driven adversarial unit tests that attack assumptions instead of exercising happy paths. Use when writing, reviewing, or improving tests for security-sensitive, correctness-critical, parser, validator, authorization, workflow, migration, concurrency, or AI/LLM-pipeline logic, or whenever happy-path coverage is insufficient. Not for deciding what to threat-model in a design (use secure-design).

Grounding discipline for any non-trivial claim about code behavior, production paths, or repository state — "is this used", "is this safe", "already implemented", investigation, analysis, and security conclusions. Use before asserting how code behaves in messy or unfamiliar repositories. Not for system-level design (use architecture-review) or deletion decisions (use legacy-cleanup).

Reachability-based classification of dead, duplicated, stale, or migration-leftover code before deletion, with quarantine/delete decisions and validation. Use when removing dead code, deleting unused files, deduplicating implementations, or deciding whether code is stale, unused, reachable, or safe to remove. Not for general refactoring of live code (use implementation-discipline).

Cumulative, proof-driven root-cause analysis for incidents, failed runs, regressions, OOMs, API-limit errors, restarts, and stale-state failures. Integrates runtime evidence with competing hypotheses, code/config/git tracing, proof levels, and systemic fixes. Use when the user asks for an RCA, "why did this fail", or incident analysis. When the input is a workflow/run id, cloud logs, artifacts, or cache behavior, run workflow-rca first to collect the runtime evidence packet, then continue here.

Current external research with hard citations: official docs, competitor practice, recent papers, benchmarks, advisories, and release notes. Use when a decision or implementation would materially benefit from current external evidence, when facts may be stale, or when the user asks to research, look up, compare tools, or find current best practices. Every substantive external claim must carry a source URL. Not for claims about the local codebase (use evidence-first).