Menu
Read sources on a foreign system, translate claims into Natural Framework terminology, and stream each into Synopsis for filing. Fan-out on thin sources. Elicit human judgment on ambiguous mappings.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | intake |
| description | Read sources on a foreign system, translate claims into Natural Framework terminology, and stream each into Synopsis for filing. Fan-out on thin sources. Elicit human judgment on ambiguous mappings. |
| argument-hint | <system-name-or-url> |
| allowed-tools | Read, Grep, Glob, Bash, Agent, Skill, WebFetch, WebSearch |
Read sources on a foreign system, translate into framework-speak, and file incrementally via Synopsis. When sources are thin, fan out parallel agents to build richer evidence before asking the human.
A system name, URL, paper link, or repo path. The user may also provide initial reading material.
Before reading sources, ask the human: what stage is this system? (proof of concept / prototype / production / legacy). Record the answer in S.md metadata as stage: <answer>. Development stage determines whether gaps are failures or expected — a PoC missing Consolidate is on-schedule, not broken. This propagates to Diagnose and Prescribe automatically via S.md.
For each source:
Read. Fetch or open the source. Extract key claims, architecture decisions, and stated limitations. For code sources, cite file paths and function/symbol names — run_soar.cpp is not enough; do_one_top_level_phase() in Core/SoarKernel/src/decision_process/run_soar.cpp is. For repositories: also scan notable PRs (merged and rejected). PRs reveal design decisions, debates, and rejected alternatives that don't survive in the final code. Use gh pr list --state all --limit 100 --json title,body,state,labels or search for PRs touching key subsystems. Filter for PRs that changed architecture, added/removed learning mechanisms, or debated design trade-offs. Rejected PRs are especially valuable — they document paths not taken.
Translate. For each claim, produce a translation record:
source: source ID and section/page referenceoriginal: the claim in the system's own vocabulary (quoted or paraphrased)system_term: the foreign term being translated (e.g., "elaboration," "chunking")mapped_roles: one or more framework roles. If ambiguous, list all candidates with a rationale for each — do not force a single choice. Ambiguous mappings are resolved at elicitation, not here. Ambiguity triggers: a term participates in two functionally distinct operations (e.g., RL both updates policy and biases selection), or the term spans two phases of the system's own processing.rationale: why this mapping (one sentence)confidence: high / medium / low. Calibration: if the term does double duty across distinct functions, confidence cannot be high for a single-role mapping — mark medium and flag as ambiguous.E.g., "Soar's 'elaboration' → Cache (parallel feature extraction) with competing hypothesis Cache+Filter (operator proposal as relevance gate)."
File. Write the claim directly to soap/S.md in the subject's own vocabulary, organized by the subject's own structural categories (not framework roles). Dedupe against existing entries — if a semantically similar claim exists, merge as convergent evidence. Update the glossary if the claim introduces a new system term. The translation record stays in Intake's cache — it informs the glossary's proposed mappings and feeds the elicitation quiz, but does not overwrite the subject's words in S.md. For large intakes (200+ claims), use /synopsis as a library function for mechanical dedupe and glossary updates.
Repeat across all sources. By the time Phase 1 finishes, the synopsis document is already built — in the subject's own terms.
After filing all sources, assess source thickness per glossary term: how many independent sources provide evidence for the mapping?
Compute the thin-coverage ratio: (thin terms) / (total glossary terms).
Well-documented systems skip this phase. Under-documented systems need it. The goal is to build richer evidence for thin-coverage terms so that elicitation questions are informed, not blind.
Run /fan-out on thin-coverage terms with three agent roles per term: code (grep implementation, trace call chains), intent (issues, PRs, commit messages), pattern (Parts Bin lookup). All agents share S.md as their research log via Synopsis dedup.
After agents return, codex filters for consensus. Update glossary: all agree → promote to medium; two agree → flag dissent; no agreement → competing_hypotheses; all empty → insufficient_evidence. Log dead ends in open_questions — a well-characterized dead end is worth more than an untested hypothesis.
Parameters: k=3 agents per term, one round only, max 10 thin terms per batch. The /fan-out skill handles shared memory, convergence, and pruning mechanics.
Before presenting to the human, send S.md to codex for review. Apply obvious improvements directly (framework leaks, weak provenance, miscalibrated confidence, missing discrepancy flags). Present only the ambiguous or debatable points to the human alongside the elicitation questions. This narrows the human's Attend to what actually requires judgment. If codex is unavailable, perform a self-review pass applying the same criteria. Log which reviewer was used or skipped.
The agent does Perceive (read sources), Cache+Filter (translate, dedupe, file), and optionally fan-out (diverge/converge on thin sources). But mapping foreign vocabulary to framework roles is a judgment call. The agent proposes candidates; the human selects. This step is Attend — without it, the pipeline emits unattended Cache. If the human is unavailable, the pipeline stops. There is no fallback.
Present one question at a time. Don't dump the full quiz. Let the human think about each mapping before seeing the next.
Each answer gets a confidence tag from the human: high, medium, low, or unsure.
competing_hypotheses and examine the source directly.insufficient_evidence.Write an ## elicitation section to soap/S.md (replacing any prior elicitation section on re-run) with:
Oracle reliability below 50% is a stop signal — the translations are too uncertain for Diagnose to proceed without re-examining sources.
soap/S.md — built by writing claims directly, organized by the subject's own structure. For large intakes (200+ claims), use /synopsis for mechanical dedupe and glossary updates.blocked).If Synopsis is unavailable or soap/S.md cannot be written, Intake stops and reports the failure. Do not buffer claims in conversation context as a workaround.
After completing all phases (including elicitation), re-read S.md and run a self-check: are there claims in the sources that aren't in S.md? Glossary terms without mappings? Ambiguities that weren't elicited? If yes, run another pass (phases 1-4). If no, converged. Report what changed each pass so the human can see the delta shrinking. Hard stop at 10 passes — if still changing, the skill is oscillating. Stop, report what's fluctuating, and let the human decide.
Filter recent Hacker News for live threads on June's topics and hand him the list. Separately, flag the rare subset where work he has already done settles a specific quoted claim, and draft that comment as a plain argument with no link to his own writing. Use when June asks to check HN or find threads worth reading or commenting on.
Scan blog posts for AI writing tics and missed opportunities for human voice. Reports subtractions (AI patterns to remove) and additions (wordplay, arc, and claims to strengthen).
Poll June's Hacker News feeds, report what is new since the last run, and idempotently arm a background watch for replies to his comments. State persists in ~/Documents/sweep/ so it survives across sessions. Use when June asks what is new on HN, whether anyone replied, or to start watching a thread.
Argument-level compression by a strengthened absence test (does the argument stand with the same force, clarity, evidence, scope, pacing, and misreading-resistance?). Removes passages that fail it (self-referential cruft, cross-section restatement, self-recap, re-derivation, scaffolding, expired reader-orientation, stakes inflation, inert hedges, redundant examples); grafts good rhetoric onto an adjacent essential point rather than deleting. Idempotent. The structural cousin of /tighten (word-level) and /not-but (negation).
Audit a technical candidate's resume/CV by verifying its claims against the public contribution graph instead of taking the text at face value. Sorts every claim onto the self/peer/world attestation lattice, applies a cost-and-stake filter so cheap proxies (stars, downloads, backlinks) don't count, runs LIVE checks (GitHub, arXiv, package registries, CVEs), and reports two separate axes — merit (staked acceptance of the candidate's specific work) and attention (timestamped output) — plus a verifiability score in [0,1]. For technical recruiters and hiring managers. Invoke when given a candidate — a GitHub handle, a resume/CV, an arXiv author, a personal site — and asked to verify, audit, vet, or check their claims. Runs at two depths — a quick triage scan or a deep per-claim audit — and elicits which. Checks the provenance of a personal site or self-hosted resume (Internet Archive + git history) as an un-backdatable anti-tailoring anchor. Needs tool access (Bash/curl or WebFetch).
Find and defuse "not X but Y" / "isn't X; it's Y" / "X — not Y" constructions. Deterministic grep for detection (no LLM blind spot), the not-but subagent for triage. Split-or-cut tail negations ("X, not Y") aggressively — promote the point to its own sentence or delete it; recast in place only mid-clause "not X but Y" that genuinely can't be split; keep just the rare iconic thesis line literal.