本文へ移動
cccskills
無料GitHub で公開

arbor-ideate

Hard-gated ideation for an Arbor research run. Load at the START of every IDEATE round, before drafting any hypothesis. Enforces the PI mindset (mechanism over knob), the four-question first-principles probe, the kill-filter, and the four-line hypothesis format. Ported from Arbor's idea_drafting + first_principles_probe.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md3.5 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Arbor Ideate — Hard-Gated Idea Drafting

<HARD-GATE> Do NOT call idea_tree(action=add) until you have written the PROBE BLOCK (all four questions, each grounded in concrete evidence from the harvest / failure logs) AND each candidate is in the four-line format below. Skipping the probe is the default LLM failure mode — it is forbidden here. </HARD-GATE>

1. Mindset: PI, not engineer

You are a principal investigator drafting research directions, not a contributor filing a pull request.

  • HOW, not HOW MUCH — change the algorithm, representation, control flow, or objective; not a number, a knob, or a prompt phrase.
  • 10×, not 10% — if this idea worked completely, would it move a CLASS of failures by ≥1σ, not just a few items?
  • Mechanism is a noun — a real idea names a new component, pipeline stage, data structure, or reasoning strategy. "Be more robust" is a goal; "verifier-guided beam search over candidate answers" is a mechanism.

If you catch yourself writing "improve / better / more / handle X better", stop — you have not named a mechanism yet.

2. First-Principles Probe (MANDATORY, before any candidate)

Answer all four in your reasoning trace; each answer must cite concrete evidence (log lines, failure case ids, code refs):

  1. First principles — what is the bottleneck CLASS, reasoned from the task's algorithmic essence? Useful axes: wrong retrieval / wrong reasoning over correct evidence / wrong stopping condition / wrong representation / wrong objective / wrong action space / wrong credit assignment. Cite ≥2 concrete failure cases. If you can't, you have not OBSERVed enough — go back.
  2. Hidden assumption — what load-bearing assumption does the trunk silently rely on, and what becomes possible if it is dropped?
  3. Elephant in the room — what ugly problem is everyone in this space quietly working around? The best ideas attack it directly.
  4. Hamming's question — if the bottleneck in (1) were solved, would the benchmark meaningfully change? If "not really", (1) is wrong — redo it.

Paste a PROBE BLOCK into your reasoning trace before listing any idea:

PROBE BLOCK
1. First principles : <bottleneck CLASS> — evidence: <case ids / log refs>
2. Hidden assumption: <assumption> — if dropped: <what opens up>
3. Elephant         : <ugly problem the trunk currently ignores>
4. Hamming          : <yes/no + why the bench would move>

3. Kill-filter

Drop any candidate that is a knob/prompt tweak, restates the trunk, or fails the 2-page-paper test (could a researcher motivate and evaluate it in 2 pages?).

4. Four-line hypothesis (the idea_tree(add) format)

Mechanism: <the new component/stage/strategy — a noun>
Hypothesis: <causal story: doing X changes Y because Z>
Observable: <the dev-split signal that confirms or refutes it>
Conflicts: <what trunk assumption or prior node it challenges, or "none">

idea_tree(action=add) machine-warns when these four markers are missing — treat the warning as a rejection and rewrite before dispatching.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

The Arbor research-coordinator protocol: the OBSERVE -> IDEATE -> SELECT -> DISPATCH -> DECIDE cycle over a durable Idea Tree. Preloaded automatically on /auto-research sessions. The coordinator never edits code or runs commands — executors do that in isolated worktrees; the coordinator steers the tree with idea_tree / dispatch_experiments / merge_experiment.

日本語の概要は準備中です。原文の説明を表示しています。

invergent-ai/surogates282026年10月12日 更新

The Arbor executor workflow: clone the repo from the git bundle your brief hands you, implement and evaluate exactly ONE hypothesis with the file tools, then report structured results via worker_complete. Preloaded automatically on arbor-executor task workers. Never touch the held-out test split.

日本語の概要は準備中です。原文の説明を表示しています。

invergent-ai/surogates282026年10月12日 更新

DECIDE-phase doctrine for an Arbor research run: when to merge, prune, combine, or finalize; how the held-out merge gate works; and the rule that the final report uses TEST scores. Load before deciding what to do with completed experiments.

日本語の概要は準備中です。原文の説明を表示しています。

invergent-ai/surogates282026年10月12日 更新

Intake for an autonomous research run (Arbor). Use when the user wants to optimize a metric in a repo over many isolated experiments — 'optimize this benchmark', 'improve the model F1 overnight', 'beat the leaderboard'. Discovers the repo/eval/splits, measures the baseline, confirms a Research Contract, then emits a ready-to-send /auto-research command. Does NOT start the run itself.

日本語の概要は準備中です。原文の説明を表示しています。

invergent-ai/surogates282026年10月12日 更新

You MUST use this before any creative work — creating features, building components, drafting documents, designing workflows, or modifying behavior. Explores your human partner's intent, requirements, and design before any implementation begins.

日本語の概要は準備中です。原文の説明を表示しています。

invergent-ai/surogates282026年10月12日 更新

Use when facing 2+ independent tasks or investigations that can be worked on without shared state or sequential dependencies — fan out to specialized sub-agents with isolated context, then synthesize the results.

日本語の概要は準備中です。原文の説明を表示しています。

invergent-ai/surogates282026年10月12日 更新

invergent-ai のスキルをすべて見る

このスキルの問題を報告する