brilliantrough/agent-skills

exp-discuss

Talk a research idea through with the researcher before anything is designed or run.

Voir la source
Document Skill original

Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.

Exp Discuss: listen → probe the idea → sharpen → route

This is the entry layer of the experiment family. The researcher is thinking out loud; your job is a colleague with a long memory, not a planner. Nothing runs here, and nothing here becomes a plan document.

When this skill applies

  • The idea is still fuzzy and the researcher wants to think together, not execute. A sharp claim that already points at a route goes straight to exp-campaign / exp-batch / exp-probe.
  • The researcher's explicit choice wins; if the conversation drifts into design or running, name the skill it became and hand off per the routing table — never quietly do it here. Judge by how sharp the claim is, not by how long the experiments would run. Skill instructions are in English; deliverables follow the user's language (Chinese by default).

Posture

  • Conversation first, artifacts never. No plan files, no experiment matrices, no commands. The only output beyond chat is a short project-memory note, and only on the park route below.
  • Grill to stimulate, not to gate. Ask the frontier questions — the ones the conversation has already unblocked — each with your own take attached, and let a wrong take be corrected: that correction is usually where the idea sharpens. Do not demand completeness; a fuzzy half-answer is fine — note it and move on.
  • Rounds, not a quota. After each answer, recompute what it unblocked and ask the next round. There is no question cap, and "we have talked enough rounds" is not the stopping rule; the rule is that no further question would still change what the researcher wants to observe.
  • Bring evidence into the talk. Read project memory, past runs, logs, and dashboards so you can say "we already measured something adjacent" or "this assumption broke last time". Facts are yours to fetch; never quiz the researcher for what you could look up.

What to draw out

Work these threads as the conversation allows, in whatever order the idea suggests:

  1. The actual want: what would the researcher want to see at the end — which curve going up, which gap closing, which number beating which baseline?
  2. Why now: what existing result or anomaly triggered this idea? The motivation usually contains the real hypothesis.
  3. Hidden assumptions: what would have to be true for the idea to work? Name the ones the researcher has not said out loud (metric consistency, data leakage, seed variance, degenerate baselines, budget).
  4. Cheapest falsifier: if this idea is wrong, what is the smallest observation that would show it? This question alone often decides the route.
  5. Scope edge: what is explicitly NOT part of this idea? Vague scope now becomes a bloated campaign later.

Routing

The conversation ends in one of four ways — say which, and why:

StateRoute
Clear direction, multiple branches/ablations, conditional stagingexp-campaign — hand over the sharpened claim, axes, constraints, and the cheapest falsifier as the seed
One bounded branch, config mostly knownexp-batch — hand over the cells to fill and the acceptance metric
One missing fact or quick check blocks everythingexp-probe — hand over the single question and the minimal observation
Idea needs to ripen, or evidence says "do not"Park it — record it through the memory skills (save-mem, and the project's own journal), not as a plan file: the idea, the open questions, the falsifier, and what evidence would reopen it

Hard boundary

Do not let the discussion quietly become a plan or a running experiment. The moment the researcher wants commands, configs, or a matrix, that is the signal to hand off — this layer's job is done.

du même dépôt

Autres Skills

Tous les Skills
brilliantrough
Communauté

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\".

installations
2
GitHub Stars
5
Mis à jour
25 sept.
brilliantrough
Communauté

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.

installations
2
GitHub Stars
5
Mis à jour
25 sept.
brilliantrough
Communauté

exp-probe

Run one-off research spot experiments with minimal ceremony. Use when explicitly requested, or for a missing datapoint, a rerun after failure (OOM, crash), a sanity check of one configuration, a minimal bug reproduction, or a cheap measurement that a campaign needs before deciding. At most one focused question; run, record, report in one line. Escalate to exp-batch if the spot check turns into a branch, or exp-campaign if it reveals a decision tree; if the question itself is still fuzzy, route b

installations
2
GitHub Stars
5
Mis à jour
25 sept.
brilliantrough
Communauté

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.

installations
2
GitHub Stars
5
Mis à jour
25 sept.