prime-radiant-inc

Reverse engineering - multi-source product intelligence analysis with provenance tracking. Master methodology for all analysis agents.

Layer 1 intelligence source discovery - auto-detect available sources, search for public information, negotiate with user, produce inventory manifest

Layer 3 deep documentation methodology. Per-module behavioral specifications, external and behavioral integration contracts, behavior documentation, end-to-end user journey analysis. Transforms Layer 2 synthesis into implementable behavioral specifications.…

Layer 1 methodology for extracting behavioral intelligence from compiled binaries, bytecode archives, managed assemblies, and bundled applications. Covers artifact identification, string extraction strategy, decompilation workflows, provenance requirements,…

Layer 1 skill for community intelligence gathering. Search channels, extraction methodology, consensus analysis, version-aware behavioral changes, structural contamination guard. Loaded by the analyzer agent for community intelligence gathering.

Infrastructure skill for containerized target execution. Runtime detection, container lifecycle, security restrictions, interaction patterns.

Layer 1 skill for parsing machine-readable API contracts. OpenAPI/Swagger, GraphQL, Protobuf/gRPC, and JSON Schema detection, extraction, and behavioral claim generation. Loaded by the analyzer agent during Layer 1.

Public documentation extraction methodology. Search sequence (3 tiers), behavioral claim extraction rules, output structure, termination criteria, and gap analysis. Loaded by the analyzer agent for documentation research.

Use when reading or working produces a durable insight worth keeping past the current session, when extracting ideas from a finished per-source note, or when a claim deserves a permanent home in the slip-box (atomic notes, zettels, Zettelkasten).

Use when catching yourself making a load-bearing claim you haven't named as a belief; unable to articulate why you're invoking a skill; noticing a defendable pattern across your own work; feeling unnamed resistance to a claim while reading; finishing a…

Use when starting a substantive piece of writing — essay, summary, post, design doc, blog draft — where the topic has been encountered in past reading or work.

Use at decision points where the proposed action is non-trivial (high blast radius, hard reversibility, work that branches on early choices, or goal ambiguity) AND the situation is ambiguous — multiple interpretations or response shapes plausibly fit, or a…

Use mid-task when something procedurally interesting just happened — a skill's procedure didn't fit the situation, a novel approach worked, a failure-then-recovery taught something, a source or your human partner's critique bears on an existing skill, or a…

Use when reading a book, paper, RFC, long essay, or any sustained written work your human partner wants you to understand and apply later — when the goal is comprehension and durable use, not lookup or skim.

Use when you've just read a source (book, course, paper) that teaches a named procedure, technique, or move-sequence, and the procedural detail is fresh in working memory — or when a reflecting-on-experience pass has just concluded the experience log points…

Use at deliberate reflection moments — finishing significant work, unconsumed experience entries having accumulated in notes/experience/ since the last pass, a notable success or failure involving a skill, teaching forcing you to articulate what you do, or…

Use when executing a batch of TDD-sized tasks inside a running-an-iteration call — dispatches an implementer subagent per task following red-green-refactor discipline and returns per-task completion status.

Use when executing the next pending iteration from an iterative-development roadmap — picks the iteration, decomposes into code and evidence tasks, runs sentinel corpus baseline, dispatches implementing-tasks, runs impacted + sentinel scenarios, and updates…

Use when implementing a project with a large, comprehensive, or ambiguous spec — extracts requirements with proof obligations, defines a walking skeleton with its first journey scenario, then loops through audited sprints that continuously build a behavior…

Use when turning extracted requirements into a roadmap — selects the walking skeleton iteration with its first journey scenario, orders remaining work into follow-on iterations, and applies story splitting when ACs have different dependency profiles.

Use when starting an iterative-development run on human spec collateral — reads the spec, produces per-epic requirement files with proof obligations and behavior scenario cards with stable IDs.

Use when an iteration has just finished and you need to verify behavior evidence quality in three tiers — deep evidence for current stories, impacted behavior for touched scenarios, and sentinel corpus for high-value regression detection.

Reconcile and maintain useful personal and project memory with the native memory tools.

Use when diagnosing a evener session, job, watch, or the session tree — investigating watch runaways (self-influence depth + runaway-fuse drops), dropped/coalesced deliveries, "how many times did X actually get called", stuck turns, or…

Use when designing, running, or diagnosing Evener tool-fluency experiments for a real built-in, plugin, or newly added tool. Covers probe manifests, model comparisons, semantic oracles, and interpreting fluency failures without ad-hoc transcript parsing.

Use when a surface parses untrusted or model-generated input — a wire protocol, tool-call JSON, upstream SSE, an HTTP body — or after a parser/dispatch bug, to fuzz that surface and turn any deterministic failure into a permanent, flake-guarded regression…

Use when designing, running, or diagnosing Serf tool-fluency experiments for a real built-in, plugin, or newly added tool. Covers probe manifests, model comparisons, semantic oracles, and interpreting fluency failures without ad-hoc transcript parsing.

Use when diagnosing a serf session, job, watch, or the session tree — investigating watch runaways (self-influence depth + runaway-fuse drops), dropped/coalesced deliveries, "how many times did X actually get called", stuck turns, or parent↔delegate↔observer…

Use when a surface parses untrusted or model-generated input — a wire protocol, tool-call JSON, upstream SSE, an HTTP body — or after a parser/dispatch bug, to fuzz that surface and turn any deterministic failure into a permanent, flake-guarded regression…

Use when a toil run has failed or produced unexpected results and you need to investigate what happened

Use when monitoring an in-progress toil run, checking if a run is stuck, or observing live workflow execution

Use when writing, editing, validating, or debugging toil workflow YAML — node/edge structure, ForEach, decision tags, expression syntax (${workflow_input.X} vs ${input.X}, supported node fields, required ! refs), or analyzing why a run misbehaved

Use when the user asks for a greeting - produces a friendly greeting

Use when starting any conversation - explains the kitchen-sink fixture plugin's capabilities

Use for high-stakes review where you want multiple model providers reviewing the same artifact and critiquing each other. Shells out to installed coding-agent CLIs (claude, codex, gemini, pi, opencode by default; amp and droid available opt-in) to run…

Use when reviewing a diff, commit, branch, or implementation against a spec — dispatches two same-model reviewer subagents in parallel under a competitive scoring frame, then aggregates findings. Triggers on "review this", "PAR review", "adversarial review",…

Use when working a shared ledger issue board — picking and claiming tasks, closing with evidence, breaking cycles, and reconciling contested state after sync.

Use when work spans sessions or agents and needs durable, verifiable state — starting multi-session or multi-agent work, dispatching subagent fleets, resuming after context death, handing off, tracking an investigation, running an issue board, picking…

Manage Linear issues. Use when asked about tasks, tickets, bugs, or Linear.

Use when writing or reviewing a Gauntlet story card. Establishes the calibration framing — outcomes, persona binding, observable acceptance criteria — and explicitly rules out wrong-shaped frames (Agile user stories, QA step-scripts, BDD Given/When/Then) so…

Use when asked for a demo, screencast, tutorial, walkthrough, or proof video of software actually running, when a reviewer needs to see a feature work rather than take your word for it, or when handing over any video artifact of app behavior