ingest
Skill15 starsChanged 4 months agoMITView on GitHub
Entry point for new or resumed work. Researches and scopes new tasks; validates and resumes handoff/checkpoint manifests. Triggers: start, begin, do, implement, build, fix, create, resume, continue.
88 other projects use a version of this.
Adopted by
Most recently taken up by
- zaynram/scholartheir own version, first seen Nov 8, 2026
- silouone/skillstheir own version, first seen Nov 8, 2026
- hydra-db/hydradb-claude-codetheir own version, first seen Nov 8, 2026
- fjwood69/moritheir own version, first seen Nov 8, 2026
- zedarvates/frugal-skillstheir own version, first seen Nov 8, 2026
- Mharbulous/probanda-devtheir own version, first seen Nov 8, 2026
Used with
Projects with it also use daily-arxiv, exp-eval and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
LambenthanSkilldaily-arxiv
每日从 arXiv 拉取新论文,过滤相关性,auto-ingest 高优先级论文,检测 SOTA 更新
Also in 5 projects that use this
LambenthanSkillexp-eval
实验判决门:Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges
Also in 5 projects that use this
phanghonghaoSkillposter
HTML/CSS A4 海报生成。从沙龙/活动 Markdown 文件生成科技风 A4 海报 PDF/PNG。Use when user mentions: poster, 海报, 海报生成, make poster, generate poster, 活动海报, 沙龙海报.
Also in 5 projects that use this
skyllwtSkillexp-pilot-eval
Pilot result evaluation — read pilot results, apply success criteria, update idea page (pilot_result, failure_reason if failed), generate PILOT_VERDICT_REPORT. Called by /ideate Phase 5 after /exp-pilot-run.
Also in 4 projects that use this
skyllwtSkillexp-pilot-run
Pilot experiment execution — read Pilot Spec YAML, write pilot code, run experiment(Confirm with the user before operation and require the applicant to conduct manual inspection), return results. Called by /ideate Phase 5. Does NOT modify wiki pages or judge pass/fail.
Also in 4 projects that use this
- +6 more from Lambenthan
- +1 more from skyllwt
Other versions88 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 88
- garrytan/gbrain★ 32ksame name
- skyllwt/OmegaWiki★ 1.7ksame name
- DAIR-AutoResearch/AutoSci★ 1.7ksame name
- PKU-DAIR/AutoSci★ 1.7ksame name
- skyllwt/AutoSci★ 1.7ksame name
- suboss87/FDEOps★ 940same name
- coreyhaines31/makerskills★ 893same name
- jason-effi-lab/karpathy-llm-wiki-vault★ 718same name
- ZimoLiao/scholaraio★ 585same name
- egregore-labs/egregore★ 293same name
78 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository30 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- app-devSkill
- architectureSkill
- buildSkill
- checkpointSkill
- context-mgmtSkill
- debugSkill
- dreamSkill
- evalSkill
- experimentSkill
- forgeSkill
- frontendSkill
- governance-syncSkill
- handoffSkill
- helpSkill
- human-passSkill
- initSkill
- knowledge-graphSkill
- landing-pageSkill
- marketing-siteSkill
- metricsSkill
- orchestrationSkill
- qualitySkill
- retrospectiveSkill
- reviewSkill
- shipSkill
- simplifySkill
- tearitapartSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
38 rules. 0 are common, 27 are distinctive, and 11 are very specific to this project.
0
Common
Most of the 72 edited versions we read keep these.
27
Distinctive
This author's own choices. Worth a look.
11
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 54
After classify: load task-specific skills above.
- Distinctive: line 55
After scope: if tier 2+, load /kernel:orchestration.
- Distinctive: line 56
If any domain detected (API, auth, frontend, backend): load domain skills.
- Distinctive: line 64
Search before asking: Glob, Grep, common paths.
- Distinctive: line 67
Use AskUserQuestion when: classification is ambiguous (could be bug or feature, refactor or rewrite) Ask: "This looks like {type_A} but …
- Distinctive: line 68
Ask: "This looks like {type_A} but could be {type_B}.
- Distinctive: line 72
After classify: load matching workflow from workflows/{type}.md if it exists.
- Distinctive: line 77
IF type == resume (or a manifest path was supplied) → go to MANIFEST RESUME (below) IF familiar AND tier_likely_1 → skip to step 3 (scope), …
- Very specific: line 78
IF familiar AND tier_likely_1 → skip to step 3 (scope), mark research="skipped (familiar)" IF unfamiliar OR complex → proceed to step 2 …
- Very specific: line 79
IF unfamiliar OR complex → proceed to step 2 (research) ALWAYS: check _meta/research/ cache regardless (cache != full research) </branch>
- Very specific: line 80
ALWAYS: check _meta/research/ cache regardless (cache != full research) </branch>
- Very specific: line 108
Preflight: run "$KM" preflight <manifest>.
- Distinctive: line 135
Complete: when outputs.required are verified,
- Distinctive: line 152
RULE: Research without verification is theory fiction: Every research finding must be verified with a minimal test, prototype, or proof …
- Very specific: line 157
Check existing: ls _meta/research/, agentdb query
- Very specific: line 162
Write to: _meta/research/{topic}.md (include verification result) </substeps>
- Distinctive: line 178
Use AskUserQuestion when: research reveals multiple viable approaches or unknown risks Ask: "Research found {N} approaches.
- Distinctive: line 179
Ask: "Research found {N} approaches.
- Distinctive: line 198
Use AskUserQuestion when: tier classification is borderline (e.g., 2-3 files but complex coupling) Ask: "Scoped to {N} files — tier {X}.
- Distinctive: line 199
Ask: "Scoped to {N} files — tier {X}.
- Very specific: line 202
When the request itself is underspecified (any GOAL/CONSTRAINTS/INPUTS/OUTPUTS/DONE-WHEN field unknowable), run the structured interview …
- Distinctive: line 212
IF scope reveals unknowns not covered by research → loop to step 2 with narrowed query IF scope is clear → proceed to step 4 </branch>
- Distinctive: line 213
IF scope is clear → proceed to step 4 </branch>
- Distinctive: line 242
Before handing to surgeon (tier 2+) or starting execution (tier 1), the spec must answer:
- Distinctive: line 243
Exact file paths: every file that will change, by absolute path
- Very specific: line 244
Exact symbols: every function/class/type to add/modify/remove, by name
- Very specific: line 246
Exact configs/SQL/schemas: if the change touches them, paste the literal block
- Distinctive: line 257
Use AskUserQuestion when: the spec has a known gap and you need the user to decide which exact path to take (rather than letting the …
- Distinctive: line 259
Ask: "Spec gap at {location}: option A = {exact}, option B = {exact}.
- Distinctive: line 267
Write failing tests (edge cases!)
- Very specific: line 269
Check Big 5: skills/quality/SKILL.md
- Distinctive: line 270
Run evals → /kernel:validate before commit
- Distinctive: line 271
Commit when done_when satisfied </tier_1>
- Distinctive: line 289
IF adversary rejects (tier 3) → return to execute with adversary feedback, max 3 retries IF tests fail → /kernel:debug, fix, re-execute IF …
- Distinctive: line 290
IF tests fail → /kernel:debug, fix, re-execute IF blocked → checkpoint and STOP, ask human </branch>
- Distinctive: line 291
IF blocked → checkpoint and STOP, ask human </branch>
- Very specific: line 299
Update _meta/research/ if new findings.
- Distinctive: line 305
MUST run before session ends.
“Common” is measured: kept by at least 6 in 10 of the 72 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<skill id="ingest"><purpose>
Unified entry for new and resumed work.
New task: READ → CLASSIFY → RESEARCH → SCOPE → TESTS → EXECUTE → LEARN (human confirms each phase).
Resume: DISCOVER → VALIDATE → DIVERGENCE → COMPILE (bounded context + receipt) → RESUME AT PHASE.
For autonomous loop: /kernel:forgeAuthority order (highest wins) — a manifest is a map, not the territory:
- live verified repository state
- explicit current user instruction
- handoff or checkpoint manifest
- chronicle
- inferred conversation history
</purpose>
<skill_load> always: skills/debug/SKILL.md on_classify: bug: skills/debug/SKILL.md feature: skills/build/SKILL.md, skills/architecture/SKILL.md refactor: skills/architecture/SKILL.md review: skills/review/SKILL.md on_domain: frontend: skills/frontend/SKILL.md app: skills/app-dev/SKILL.md on_tier: 2+: skills/orchestration/SKILL.md reference: skills/build/reference/build-research.md </skill_load>
<on_start>
agentdb read-start
ls _meta/research/ # check prior workLoad /kernel:quality, /kernel:testing, /kernel:git immediately. After classify: load task-specific skills above. Do NOT proceed without loading them. After scope: if tier 2+, load /kernel:orchestration. If any domain detected (API, auth, frontend, backend): load domain skills. </on_start>
<step id="1_classify">
task: what user wants (one sentence)
type: bug|feature|refactor|question|verify|resume|review
familiar: yes|noSearch before asking: Glob, Grep, common paths.
<ask_user> Use AskUserQuestion when: classification is ambiguous (could be bug or feature, refactor or rewrite) Ask: "This looks like {type_A} but could be {type_B}. Which framing fits your intent?" Options: type_A, type_B, or clarify </ask_user>
After classify: load matching workflow from workflows/{type}.md if it exists.
Workflow steps guide the phase sequence. Human confirms at each step (ingest mode).
</step>
<branch after="classify">
IF type == resume (or a manifest path was supplied) → go to MANIFEST RESUME (below)
IF familiar AND tier_likely_1 → skip to step 3 (scope), mark research="skipped (familiar)"
IF unfamiliar OR complex → proceed to step 2 (research)
ALWAYS: check _meta/research/ cache regardless (cache != full research)
</branch><step id="1b_manifest_resume" trigger="classify.type == resume">
Resume from a kernel.handoff/v1 or kernel.checkpoint/v1 manifest. The runtime CLI:
`KM="${CLAUDE_PLUGIN_ROOT:-.}/orchestration/manifest/kernel-manifest"`- Discover: explicit path if the user gave one, else:
Legacy markdown handoffs (_meta/handoffs/*.md) remain readable this release: parse goal/decisions/next-steps from prose, note "legacy handoff (deprecated, no validation/divergence/budget)" and suggest regenerating as JSON. Removal path: docs/MIGRATION-8.md."$KM" latest # newest across _meta/checkpoints/ + _meta/handoffs/ - Validate — a manifest that does not validate is not resumed:
"$KM" validate <manifest> # exit 2 (no parser) on a sealed manifest = STOP - Divergence — live state wins over manifest claims:
Typed divergence events apply"$KM" divergence <manifest> --jsonworkflow.invalidation_rules[].whenand return recalculated phase statuses. Never trust an inherited phase whose inputs changed. - Preflight: run
"$KM" preflight <manifest>. Canonical state permits only typed current-branch, path-exists, and allowlisted argv checks; raw shell is invalid. - Compile bounded context — read the bundle, not the raw tree:
The receipt (kernel.context-receipt/v1) reports estimated tokens per layer and status: within_budget → proceed · target_exceeded → drop optional selectors, proceed with a note · maximum_exceeded (exit 3) → STOP, report the receipt, ask before loading anything."$KM" compile <manifest> --bundle-out /tmp/resume-bundle.md --receipt-out _meta/reports/receipt-{date}.json - Activate the policy (arms the guard-context hook for sealed/bounded):
sealed: forbidden globs are hook-BLOCKED; do not fight the hook — amend the manifest if access is genuinely needed. bounded: extra loads are allowed but ledgered; justify each in the receipt's loads_beyond_manifest."$KM" activate <manifest> - Resume at the declared position:
Skip inherited phases (already verified by divergence), execute required ones. Honor execution.stop_conditions and emit checkpoints at execution.checkpoints."$KM" resume <manifest> # entry_phase / entrypoint / next_operation - Complete: when outputs.required are verified,
Deactivate projects the receipt into AgentDB's observational context graph (shadow telemetry). Then outputs.completion (usually agentdb write-end), which records session outcome on that graph row when"$KM" deactivate --receipt _meta/reports/receipt-{date}.jsondid/blockedare present.
Optional advisory (never auto-loads):
bash
agentdb graph-suggest {task_type}
Output: "Resuming {manifest}: {goal}. Entry: {entry_phase}. Receipt: {total_estimated_tokens} tokens ({status})."
</step>
<step id="2_research" mandatory="true">
**RULE: Research without verification is theory fiction.** Every research finding must be verified
with a minimal test, prototype, or proof before it drives implementation. 8 research agents and
6 docs mean nothing if nobody built a test to prove the approach works. (LRN-F11)<substeps>
1. Check existing: ls _meta/research/, agentdb query
2. anti_patterns FIRST: "{tech} not working", "{tech} gotchas"
3. Solutions: official docs, GitHub issues, Stack Overflow
4. Built-in check: framework > stdlib > npm package
5. **Verify**: build minimal proof (test screen, script, unit test) before committing to approach
6. Write to: _meta/research/{topic}.md (include verification result)
</substeps><format>
# {Topic} Research
## Anti-Patterns
1. {pattern}: {why} → {fix}
## Proven Solution
- package: {name}@{version}
## Sources
- {urls}
</format>tier 2+: spawn kernel:researcher
<ask_user>
Use AskUserQuestion when: research reveals multiple viable approaches or unknown risks
Ask: "Research found {N} approaches. Proceed with {recommended}, or explore alternatives?"
Options: proceed, explore alternatives, skip research
</ask_user>
</step>
<step id="3_scope">
files:
1: {path} - {what changes}
count: N
tier: 1|2|3<tiers>
1: reversible + loud if wrong → execute inline
2: persistent or moderately quiet → plan, execute inline; delegate a surgeon only for heavy file-disjoint work; verify
3: hard to undo, quiet if wrong, or wide blast radius → contract + surgeon + adversary
ambiguous: assume higher. File count is only a weak hint, never the trigger.
</tiers><ask_user> Use AskUserQuestion when: tier classification is borderline (e.g., 2-3 files but complex coupling) Ask: "Scoped to {N} files — tier {X}. Confirm tier, or should I treat as tier {X+1}?" Options: confirm tier {X}, bump to tier {X+1}
When the request itself is underspecified (any GOAL/CONSTRAINTS/INPUTS/OUTPUTS/DONE-WHEN
field unknowable), run the structured interview from skills/build/SKILL.md "The
interview" BEFORE scoping: batched AskUserQuestion rounds over intent, implementation
forks, veto-risk UX, edge behavior, and tradeoffs. Bounded choices only; open-ended
direction stays prose. Answers are quoted into the spec/commission so each decision
carries its authority.
</ask_user>
</step>
<branch after="scope">
IF scope reveals unknowns not covered by research → loop to step 2 with narrowed query
IF scope is clear → proceed to step 4
</branch><step id="4_tests" mandatory="true">
<rule>Define success before coding. Tests first.</rule>
skill_ref: skills/build/reference/testing.mddone_when:
- observable outcome 1
- edge case handled
evals: code_grader: PASS/FAIL command regression: existing tests pass
<principles>
mock_boundaries_only: external APIs, DBs
edge_cases_first: null, empty, boundary, timeout
strong_assertions: specific values
</principles>
</step><step id="4b_spec_completeness" mandatory="true">
<rule>Spec framing > contract framing. Execution-ready, not goal-shaped.</rule>Specification prompts with exact code achieve 100% success across all scopes (modelmind H002/H003, 0.95 confidence). Contract framing ("achieve X under constraint Y") leaves interpretation gaps that agents fill incorrectly.
Before handing to surgeon (tier 2+) or starting execution (tier 1), the spec must answer:
- Exact file paths: every file that will change, by absolute path
- Exact symbols: every function/class/type to add/modify/remove, by name
- Exact code snippets for non-trivial logic (not pseudocode, not "implement X")
- Exact configs/SQL/schemas: if the change touches them, paste the literal block
- Exact verification commands: how a fresh agent confirms success without asking
Litmus test: could a fresh agent in a new session execute this spec with zero follow-up questions? If no, the spec is incomplete. Return to step 3 (scope) or step 4 (tests) and fill the gap before proceeding.
Anti-pattern: shipping a contract that says "the surgeon will figure out X." The surgeon will figure out X by guessing, and the guess will be wrong.
<ask_user>
Use AskUserQuestion when: the spec has a known gap and you need the user to decide which
exact path to take (rather than letting the surgeon guess).
Ask: "Spec gap at {location}: option A = {exact}, option B = {exact}. Which?"
Options: option A, option B, other
</ask_user>
</step>
<step id="5_execute">
<tier_1>
1. Reference research doc
2. Write failing tests (edge cases!)
3. Implement proven pattern
4. Check Big 5: skills/quality/SKILL.md
5. Run evals → /kernel:validate before commit
6. Commit when done_when satisfied
</tier_1><tier_2_plus> rule: you do NOT write code
- /kernel:tearitapart — review plan before implementation
- agentdb contract '{"goal":"X","files":["Y"],"tier":N}' 2b. If non-local profile: _gh_create_issue with contract goal + tier label
- git checkout -b {type}/{name}
- Spawn surgeon
- Wait for checkpoint
- (tier 3) spawn adversary
- /kernel:validate → verify evals
- /kernel:review — self-review before PR
</tier_2_plus>
</step>
<branch after="execute">
IF adversary rejects (tier 3) → return to execute with adversary feedback, max 3 retries
IF tests fail → /kernel:debug, fix, re-execute
IF blocked → checkpoint and STOP, ask human
</branch><step id="6_learn" mandatory="true">
<rule>Every task teaches. Capture or lose.</rule>agentdb learn pattern "{what worked}" "{evidence}" agentdb learn failure "{what broke}" "{evidence}" Update _meta/research/ if new findings. Suggest /kernel:retrospective if 5+ learnings accumulated since last synthesis. Long task still running? Emit /kernel:checkpoint at natural boundaries instead of letting context accumulate (EXP-L21).
<checkpoint>
agentdb write-end '{"task":"X","tier":N,"learned":["Z"]}'
MUST run before session ends.
</checkpoint>
</step><output_format> task: one sentence | type: bug|feature|refactor | tier: 1|2|3 | status: researching|scoping|testing|executing|complete </output_format>
<hard_stops> ask_file_location→search | code_without_research→step2 | code_without_tests→step4 | code_tier2+→surgeon | skip_agentdb→go_back </hard_stops>
</skill>Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

