본문으로 건너뛰기
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.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

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월 20일 업데이트

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월 20일 업데이트

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월 20일 업데이트

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월 20일 업데이트

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월 20일 업데이트

Reflective pass over your memory — merge duplicates, fix stale facts, prune what no longer matters. Use when the user asks to clean up or review what you remember, or when memory has grown cluttered or contradictory.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

invergent-ai/surogates282026년 10월 20일 업데이트

invergent-ai의 스킬 모두 보기

이 스킬의 문제 신고