OutlineDriven
OutlineDriven / odin-claude-plugin
40Outline-Driven Development for Claude Code - 46 agents, 25+ skills, diagram-first methodology, AST-based editing, atomic commits.
OutlineDriven / bazel
Use when writing Bazel BUILD files with cc_library or cc_binary rules, Bzlmod dependencies, toolchain registration, remote execution, sandbox debugging, or bazel query and cquery graphs.
OutlineDriven / meson
Use when setting up a Meson project, meson setup/compile/test, wrap dependencies, cross-file cross-compiling, meson.build, or migrating from CMake/Autotools to Meson.
OutlineDriven / ebpf
Use when writing eBPF programs with libbpf, bpftrace, or Rust with aya-ebpf and aya-log, attaching kprobes, tracepoints, or XDP hooks, declaring maps, sharing data with a Tokio loader, triaging verifier or Aya load errors, or porting with CO-RE. Not for full kernel bypass: use dpdk.
OutlineDriven / cmake
Use when writing CMakeLists.txt, out-of-source builds, target_link_libraries, target properties, find_package/FetchContent, toolchain files, CPack, CMake presets, or cmake configure errors.
OutlineDriven / fuzzing
Use when planning an end-to-end fuzzing program for a project: engine and target selection, corpus management, and CI or nightly wiring. Not for harness design: use fuzz-harness-writing. Not for engine operation or triage: use libfuzzer. Not for sanitizer flag reference: use sanitizers.
OutlineDriven / make
Use when writing or debugging Makefiles, understanding pattern rules and automatic dependency generation, managing CFLAGS/LDFLAGS, or diagnosing incremental build, phony targets, or recursive make.
OutlineDriven / cuda
Use when writing CUDA kernels, managing the thread, block, and grid hierarchy, tiling shared memory, using streams, setting nvcc flags, or using Thrust. Not for kernel debugging: use cuda-debugging.
OutlineDriven / taste
Use when asking "overkill?", "elegant?", "audit", or "taste-test this", or setting a taste register. Not for tasks that require source or remote-system changes.
OutlineDriven / ninja
Use when diagnosing Ninja build failures, tuning parallelism, interpreting verbose output, or working with build.ninja files as a CMake-generated low-level build executor.
OutlineDriven / commit
Use when asked to commit changes, create a typed branch, format history for a changelog, or rewrite messages of HEAD or an unpushed range. Not for pushing or a PR: use commit-push-pr.
OutlineDriven / deslop
Use when the user says deslop, debloat, tidy, simplify, clean a diff, cleanup codebase, or deslop branch diff, or remove dead code or config. Not for remote, credential, publish, deploy, or irreversible changes.
OutlineDriven / principles
Use when a request names a working principle (subtract before you add, idempotent operations, never block on the human) or asks which principle applies. Not for running a repair: use strike-the-root.
OutlineDriven / msvc-cl
Use when building C or C++ on Windows with cl.exe or clang-cl: GCC-to-MSVC flag translation, /MT versus /MD, PDB output, or an LNK error. Not for MinGW cross builds from Linux: use cross-gcc.
OutlineDriven / review
Use when asked to review a pull request, examine code changes, find bugs, or audit a branch, in standard or depth mode. Not for an iterative review-and-fix loop: use audit-project.
OutlineDriven / saga
Use when a user runs saga or asks to autonomously build a sizable feature. Not for executing a given plan: use subagent-driven.
OutlineDriven / to-spec
Use when settled conversation decisions need synthesis into an agent-ready implementation spec, stopping before publication. Not for turning plans into tickets: use to-tickets.
OutlineDriven / unslop
Use when prose is drafted or edited, reviewed for AI tells, or the user asks to remove AI patterns, humanize, or add voice. Offers dedash and detool modes. Not for code debris: use deslop.
OutlineDriven / vulnerability-triage-brocards
Use when a vulnerability report, CVE, bug-bounty submission, or automated finding needs triage before deep verification. Don''t use for tasks that require source or remote-system changes.
OutlineDriven / work
Use when implementing from a plan, spec, clear build request, or settled ticket, orchestrated or standalone. Don''t use for open-ended debugging (figure-it-out), exploration, or read-only research.
OutlineDriven / resolve
Use when addressing review feedback in analyze or reception mode, or handling GitHub PR feedback in autonomous, interactive, or summary mode for a named PR target. Classifies, applies, replies, or summarizes comments.
OutlineDriven / gcc
Use when a C or C++ build uses GCC and needs build-mode flags, warning triage, debug info, LTO, PGO, or a compilation error explained. Not for Clang-only diagnostics: use clang.
OutlineDriven / mpi
Use when writing or debugging MPI programs: sends and receives, collectives, non-blocking requests, communicators, MPI-IO, hybrids with OpenMP, or mpirun launches. Not for threads alone: use openmp.
OutlineDriven / pov
Use when asked to judge whether to adopt, switch, reject, or revisit technology, library, pattern, or architecture, or a second opinion. Not for scoping: use brainstorm. Not for forks: use decide.
OutlineDriven / tdd
Use when developing a fix or feature test-first, plan a TDD build, or work red-to-green in slices. Not for hardening: use tests-adversarial. Not for deleting weak tests: use tests-purge-unneeded.
OutlineDriven / why
Use when asked why something works this way, for design rationale, a postmortem, a data-backed threshold, or a source-tiered evidence report. Not for current runtime behavior: use how.