brilliantrough/agent-skills

exp-probe

Run one-off research spot experiments with minimal ceremony.

Quelltext ansehen
Originales Skill-Dokument

Aus dem Quell-Repository gerendert; Überschriften, Beispiele, Code, Tabellen, Links und Bilder bleiben erhalten.

Exp Probe: ask once if needed → run → record → one line

A probe exists to answer one question cheaply. Everything about it is minimal except honesty.

  • Define the single question first ("does config X fit in memory", "is this NaN reproducible", "what is the missing anchor value"). If you cannot name the question, this is not a probe.
  • Shrink, don't distort: reduce sample counts and steps, never the semantics being measured (sequence length, batch semantics, dtype). State exactly what was shrunk when reporting.
  • Reproduce the real entry point: probes run through the same launcher/flags as the real run (e.g., a preflight mode), not a rewritten ad-hoc path — a probe that bypasses the real path proves nothing about it. Probe code lives in the project's scratch/experiment area, isolated per probe, and follows the same rule as all research code: no defensive programming — minimum code, real errors exit as-is; environment failures (device contention, disk full) are diagnosed as environment, not patched around.
  • Preflight even when cheap: the same pass as a real run, one look — environment active, and a live device read with the platform's own tool (nvidia-smi, npu-smi, mthreads-smi, …) that picks a free device and passes it explicitly through the platform's visible-device variable (never the default). A probe that lands on someone else's device wastes their run and yours.
  • Probes are meant to be cheap, so waiting inline is normal. If a probe's run is long (full-size model sanity check, slow dataset), use the same delegated pattern as exp-batch: background launch + later wake-up instead of holding the turn.
  • One question to the user at most, and only if the question itself is ambiguous. No plan docs, no grilling rounds, no sub-agents.
  • Record where the campaign can find it: scratch area per project rules, with config, observation, and exit status. If the probe's answer prunes campaign cells, the claim and its evidence belong in the campaign's pruning ledger — say which cells it affects.
  • Report in one line: question, observed answer, cost, and what it unblocks or rules out. If the answer is "unknown/inconclusive", say that and propose the next smallest probe — do not upgrade it silently into a batch.
aus demselben Repository

Weitere Skills

Alle Skills
brilliantrough
Community

code-review

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".

Installationen
2
GitHub Stars
5
Aktualisiert
25. Sept.
brilliantrough
Community

domain-modeling

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.

Installationen
2
GitHub Stars
5
Aktualisiert
25. Sept.
brilliantrough
Community

exp-discuss

Talk a research idea through with the researcher before anything is designed or run. Use when a researcher brings a fuzzy idea, hypothesis, or direction ("我在想……", "你觉得这个方向……") and wants to think together rather than execute. Explore it through evidence-informed rounds of frontier questions, surface overlooked details, and sharpen what the researcher actually wants to observe; stop when both sides know which execution skill comes next — exp-campaign for a staged multi-branch plan, exp-batch for o

Installationen
2
GitHub Stars
5
Aktualisiert
25. Sept.
brilliantrough
Community

migrate-mem

Establish useful memory for a project that already has development history, or improve an incomplete memory setup. Survey the project and its existing evidence, then initialize or enrich human-readable StrictDoc docs/ with current norms and historical context. Use Magic Context and other available memory alongside it where useful. No previous workflow, legacy folder convention, or pre-existing StrictDoc skeleton is assumed.

Installationen
2
GitHub Stars
5
Aktualisiert
25. Sept.