[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6M9PC788G3Z0DJRGADZFCZ1":3,"skill-same:01M6M9PC788G3Z0DJRGADZFCZ1":103},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":29,"publishedAt":54,"linkOnly":55,"markdownContent":56,"markdownBody":57,"frontMatter":58,"refName":65,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":70,"ownerHtmlUrl":71,"ownerBlogUrl":72,"ownerDescription":73,"updatedAt":74,"install":75,"resources":88},"01M6M9PC788G3Z0DJRGADZFCZ1","ara-compiler",null,"Compiles any research input — PDF papers, GitHub repositories, experiment logs, code directories, or raw notes — into a complete Agent-Native Research Artifact (ARA) with cognitive layer (claims, concepts, heuristics), physical layer (configs, code stubs), exploration graph, and grounded evidence. Use when ingesting a paper or codebase into a structured, machine-executable knowledge package, building an ARA from scratch, or converting research outputs into a falsifiable, agent-traversable form.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1571,"MIT","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fara-compiler\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53],"compiler","ARA","ara compiler","native","when","Knowledge Extraction","Research Artifacts","claims","layer","epistemic","directories","papers","concepts","PDF","input","artifact","exploration","ingestion","experiment","knowledge","heuristics","logs","code","notes","2026-11-10 10:12:30",false,"---\nname: ara-compiler\ndescription: Compiles any research input — PDF papers, GitHub repositories, experiment logs, code directories, or raw notes — into a complete Agent-Native Research Artifact (ARA) with cognitive layer (claims, concepts, heuristics), physical layer (configs, code stubs), exploration graph, and grounded evidence. Use when ingesting a paper or codebase into a structured, machine-executable knowledge package, building an ARA from scratch, or converting research outputs into a falsifiable, agent-traversable form.\nlicense: MIT\nmetadata:\n  version: 1.0.0\n  category: research-automation\n  maintainer: Kalaris Labs\n  tags: ARA, Research Artifacts, Knowledge Extraction, Paper Ingestion, Exploration Graph, Provenance, Research Tooling, Epistemic Compilation\n  dependencies: ''\n---\n\n# Universal ARA Compiler\n\nYou are the ARA Universal Compiler. Your job: take ANY research input and produce a complete,\nvalidated ARA artifact. You operate as a first-class Claude Code agent — use your native tools\n(Read, Write, Edit, Bash, Glob, Grep) directly. No API wrapper needed.\n\n## Input Philosophy\n\nThe compiler is **open-ended**. It accepts anything that contains research knowledge — there is\nno fixed input schema. Your job is to figure out what you've been given and extract maximum\nstructured knowledge from it.\n\nPossible inputs include (but are NOT limited to):\n- PDF papers, arXiv links\n- GitHub repositories (URLs or local paths)\n- Code files, scripts, notebooks (`.py`, `.ipynb`, `.rs`, `.cpp`, etc.)\n- Experiment logs, training outputs, evaluation results\n- Configuration files, hyperparameter sweeps\n- Raw research notes, brainstorm transcripts, meeting notes\n- Data directories with results, checkpoints, figures\n- Slack\u002Femail threads describing research decisions\n- Combinations of the above\n- A verbal description or conversation with the user about their research\n- Nothing at all — the user may want to build an ARA interactively through dialogue\n\nWhen arguments are provided (`$ARGUMENTS`), interpret them flexibly:\n- File\u002Fdirectory paths → read them\n- URLs → fetch or clone them\n- `--output \u003Cdir>` → where to write the ARA (default: `.\u002Fara-output\u002F`)\n- `--rubric \u003Cpath>` → PaperBench rubric for coverage mapping\n- Anything else → treat as context or ask the user for clarification\n\n### Input Reading Strategy\n\nAdapt to whatever you receive:\n1. **Identify what you have.** Glob, read, and explore the provided paths. Understand the nature\n   of the input before committing to a generation plan.\n2. **Maximize coverage.** Cross-reference all available sources. A PDF gives narrative + claims;\n   code gives ground-truth implementation; experiment logs give the exploration trajectory;\n   notes give decisions and dead ends that never made it to paper.\n3. **Ask when stuck.** If the input is ambiguous or incomplete, ask the user to fill gaps rather\n   than hallucinating. The user is a collaborator, not a passive consumer.\n4. **Handle partial inputs gracefully.** Not every ARA field will be fillable from every input.\n   Populate what you can with high confidence, mark gaps explicitly with \"Not available from\n   provided input\", and tell the user what's missing so they can supplement later.\n\n## Workflow\n\n```text\n1. READ all inputs\n2. REASON through the 4-stage epistemic protocol (see below)\n3. GENERATE all ARA files using Write tool\n4. COVERAGE CHECK loop (max 3 rounds): re-read source → diff against ARA → patch gaps\n5. VALIDATE by running Seal Level 1\n6. FIX any failures, re-validate\n7. REPORT summary to user\n```\n\n### Step 1: Read Inputs\n\nRead ALL provided inputs thoroughly before generating anything. For PDFs, read every page,\n**including appendices** — appendices often carry reproduction-critical content and should\nbe treated with the same priority as main-text pages.\n\nFor repos, prioritize: README → core algorithm files → configs → environment files.\n\n### Step 2: 4-Stage Epistemic Chain-of-Thought\n\nBefore writing any files, reason through these 4 stages. Think carefully about each stage.\n\n**Stage 1 — Semantic Deconstruction**\nStrip narrative framing. Extract the raw knowledge atoms:\n- Mathematical formulations and equations\n- Architectural specifications and component descriptions\n- Experimental configurations (hyperparameters, hardware, datasets, seeds)\n- ALL numerical results and benchmarks (exact values, never rounded)\n- Citation dependencies and their roles (imports, extends, bounds, refutes)\n- Negative results, ablation findings, rejected alternatives\n- Implementation tricks, convergence hacks, sensitivity observations\n\nBefore moving on, perform an **evidence capture pass**:\n- For every source table or figure you plan to cite, first capture the original source identifier and caption exactly (`Table 2`, `Figure 4`, etc.)\n- Transcribe the raw table\u002Ffigure content before making any claim-specific summary\n- If you create a filtered view for one claim, store it as a **derived subset**, not as the original table itself\n- Never label a subset or merged summary as `Table N` unless it reproduces the original source table faithfully\n- If PDF extraction is ambiguous, re-read the page with layout preserved or inspect the page manually before writing evidence files\n\n**Stage 2 — Cognitive Mapping**\nMap extracted atoms to `\u002Flogic\u002F`:\n- **problem.md**: observations (with numbers) → gaps → key insight → assumptions\n- **claims.md**: falsifiable claims with proof pointers to experiment IDs (E01, E02...), plus a separation between direct evidence basis and higher-level interpretation\n- **concepts.md**: ≥5 formal definitions with notation and boundary conditions\n- **experiments.md**: ≥3 declarative verification plans (NO exact numbers — directional only)\n- **solution\u002F**: architecture (component graph), algorithm (math + pseudocode), constraints, heuristics\n- **related_work.md**: typed dependency graph (imports\u002Fextends\u002Fbounds\u002Fbaseline\u002Frefutes)\n\nAppendix content (worked examples, prompt templates, enumerated taxonomies, annotation\nschemas, extended analyses, prescriptive content) should be routed into the ARA layers\nwhere it fits best, preserving the granularity the source uses. Never silently drop an\nappendix section.\n\nWhen writing claims:\n- Phrase the main `Statement` at the strongest level directly supported by the cited evidence\n- Put raw support in `Evidence basis`\n- Put any broader synthesis in `Interpretation`\n- If the evidence only shows validation metrics, do not upgrade the claim to training dynamics or optimization quality unless training-side evidence is also captured\n\n`related_work.md` should reflect the paper's full citation footprint, not only the\nclosest predecessors. Works with a specific technical delta get full `RW` blocks; remaining\ncitations from the paper's References list should still be captured (more briefly) so the\nintellectual neighborhood is preserved.\n\n**Stage 3 — Physical Stubbing**\nGenerate `\u002Fsrc\u002F`:\n- **configs\u002F**: exact hyperparameter values with rationale and sensitivity\n- **execution\u002F**: ≥1 Python code stub implementing the NOVEL contribution (typed signatures, no boilerplate)\n- **environment.md**: Python version, framework, hardware, dependencies, seeds\n- If repo available: use actual code to improve stub precision\n- If rubric provided: produce `rubric\u002Frequirements.md` mapping every leaf node\n\n**Stage 4 — Exploration Graph Extraction**\nReconstruct the research DAG for `\u002Ftrace\u002Fexploration_tree.yaml`:\n- Root nodes = central research questions\n- Experiments and decisions nest as children\n- Dead ends from ablations\u002Frejected alternatives = typed leaf nodes\n- ≥8 nodes, must include dead_end and decision types\n- Use `also_depends_on` for DAG convergence points\n- Every node must declare whether it is `explicit` from source material or `inferred` from reconstruction\n- Explicit nodes should carry source references (table\u002Ffigure\u002Fsection labels)\n- Inferred nodes are allowed only when they help reconstruct the paper's logic without pretending to be literal session logs\n\n### Step 3: Generate Files\n\nWrite ALL mandatory files. See [references\u002Fara-schema.md](references\u002Fara-schema.md) for the complete\ndirectory structure and field-level requirements for every file.\n\n**Mandatory files** (all must exist and be non-trivial):\n- `PAPER.md` — YAML frontmatter (title, authors, year, venue, doi, ara_version, domain, keywords, claims_summary, abstract) + Layer Index\n- `logic\u002Fproblem.md` — Observations (O1, O2...), Gaps (G1, G2...), Key Insight, Assumptions\n- `logic\u002Fclaims.md` — Claims (C01, C02...) each with Statement, Status, Falsification criteria, Proof, Evidence basis, Interpretation, Dependencies, Tags\n- `logic\u002Fconcepts.md` — ≥5 concepts each with Notation, Definition, Boundary conditions, Related concepts\n- `logic\u002Fexperiments.md` — ≥3 experiments (E01, E02...) each with Verifies, Setup, Procedure, Metrics, Expected outcome (directional only!), Baselines, Dependencies\n- `logic\u002Fsolution\u002Farchitecture.md` — Component graph with inputs\u002Foutputs\n- `logic\u002Fsolution\u002Falgorithm.md` — Math formulation + pseudocode + complexity\n- `logic\u002Fsolution\u002Fconstraints.md` — Boundary conditions and limitations\n- `logic\u002Fsolution\u002Fheuristics.md` — Heuristics (H01, H02...) each with Rationale, Sensitivity, Bounds, Code ref, Source\n- `logic\u002Frelated_work.md` — Related work (RW01, RW02...) each with DOI, Type, Delta, Claims affected\n- `src\u002Fconfigs\u002Ftraining.md` — Hyperparameters with Value, Rationale, Search range, Sensitivity, Source\n- `src\u002Fconfigs\u002Fmodel.md` — Model\u002Farchitecture configs\n- `src\u002Fexecution\u002F{module}.py` — ≥1 code stub with typed signatures\n- `src\u002Fenvironment.md` — Python version, framework, hardware, dependencies, seeds\n- `trace\u002Fexploration_tree.yaml` — Research DAG (≥8 nodes, nested YAML)\n- `evidence\u002FREADME.md` — Index table mapping every evidence file to claims\n- `evidence\u002Ftables\u002F*.md` — ALL result tables (exact cell values, never rounded)\n- `evidence\u002Ffigures\u002F*.md` — ALL quantitative figures (extracted data points)\n\nEvidence-generation rules:\n- Preserve **raw source tables** separately from any **derived subset** views\n- A file named after a source object (for example `table3_...`) must match that source object's caption and contents\n- If only a subset is included, the filename must say `derived_`, `subset_`, or equivalent, and the file must state what it was derived from\n- Do not merge rows from different source tables into one evidence file unless the file is explicitly labeled as a derived comparison\n\n### Step 4: Coverage Check Loop (max 3 rounds)\n\nBefore running Seal validation, verify that the ARA faithfully covers the source material.\nRepeat up to **3 rounds**; stop early if a round produces no patches.\n\n**Each round:** re-read the source, identify anything not yet captured or only shallowly\ncaptured in the ARA, patch those gaps, then note how many fixes were made. If zero, exit\nearly. Pay particular attention to appendix content and to citations from the paper's\nReferences list, which are easy to miss on the first pass.\n\nThe coverage loop does not replace validation — it ensures the ARA is semantically complete\nbefore structural checks run.\n\n### Step 5: Validate\n\nRun ARA Seal Level 1 validation. Perform these checks:\n- All mandatory dirs exist: `logic\u002F`, `logic\u002Fsolution\u002F`, `src\u002F`, `src\u002Fconfigs\u002F`, `trace\u002F`, `evidence\u002F`\n- All mandatory files exist and are non-empty\n- PAPER.md has YAML frontmatter with title, authors, year\n- PAPER.md has Layer Index section\n- claims.md has C01+ blocks with Statement, Status, Falsification criteria, Proof fields\n- experiments.md has E01+ blocks with Verifies, Setup, Procedure, Expected outcome fields\n- heuristics.md has H01+ blocks with Rationale, Sensitivity, Bounds fields\n- concepts.md has ≥5 concept sections\n- experiments.md has ≥3 experiment plans\n- exploration_tree.yaml parses as valid YAML with ≥8 nodes, has dead_end and decision types\n- Claim Proof references (E01, E02...) resolve to experiments.md\n- Experiment Verifies references (C01, C02...) resolve to claims.md\n- Heuristic Code ref paths resolve to actual files in src\u002Fexecution\u002F\n- Evidence files contain Markdown tables with **Source** fields\n- Evidence file names, source labels, and captions agree on the original table\u002Ffigure identifier\n- Any file named like a raw source table is a faithful transcription rather than a filtered subset\n- Claims only cite experiments whose evidence actually contains the compared rows or measurements\n- Claim wording does not outrun the evidence type (for example, validation tables alone should not be used to claim training-dynamics improvements)\n- Trace nodes declare `support_level: explicit|inferred`\n- Trace nodes with `support_level: explicit` include source references\n\n### Step 6: Fix & Iterate\n\nFor each validation failure:\n1. Read the failing file\n2. Apply targeted edits (prefer Edit over full rewrite to preserve correct content)\n3. Re-validate after all fixes\n\nTypically converges in 2-3 rounds.\n\n### Step 7: Report\n\nPrint a summary:\n- Artifact location\n- File count and total size\n- Validation result (pass\u002Ffail with details)\n- Key statistics: number of claims, experiments, heuristics, concepts, tree nodes, evidence files\n\n## Critical Rules\n\n1. **Exact numbers**: All numerical values copied EXACTLY from source — never round or approximate\n2. **No hallucination**: Never invent claims, results, or heuristics not in the source material\n3. **Experiments have NO exact numbers**: `experiments.md` contains only directional\u002Frelative expected outcomes. Exact numbers go in `evidence\u002F`\n4. **Every claim has proof**: Proof field references experiment IDs (E01, E02), not file paths\n5. **Cross-layer binding**: Claims ↔ Experiments ↔ Evidence ↔ Code refs must all resolve\n6. **Dead ends matter**: Include failed approaches, rejected alternatives, ablation findings\n7. **\"Not specified\"**: If information is genuinely unavailable, write \"Not specified in paper\" — never guess\n8. **No fake source labels**: Never call a derived subset `Table N` or `Figure N` unless it faithfully reproduces the original source object\n9. **No synthetic trace history**: Do not invent decisions, dead ends, or experiments that are not explicit in the provided inputs; if a trajectory is inferred, mark it as inferred or omit it\n10. **Evidence-limited wording**: Do not use stronger language than the evidence supports; separate direct observations from interpretation\n\n## Reference Files\n\nFor detailed schema specifications, load these on demand:\n- [references\u002Fara-schema.md](references\u002Fara-schema.md) — Complete ARA directory schema with field-level format for every file\n- [references\u002Fexploration-tree-spec.md](references\u002Fexploration-tree-spec.md) — Detailed exploration tree YAML specification with examples\n- [references\u002Fvalidation-checklist.md](references\u002Fvalidation-checklist.md) — All Seal Level 1 checks (what the validator looks for)\n\n## Agent operating procedure\n\n1. **Check the environment.** Confirm the objective, evaluation metric, budget (time, compute, money) and stopping criteria.\n2. **Pin down the inputs.** Confirm formats, identifiers and parameters from the data or the user. Ask rather than guess any value that changes the result.\n3. **Run a small version first.** Run one iteration end to end and inspect logs before scaling up.\n4. **Execute the full task** using the instructions and references above.\n5. **Validate the result.** Evaluate on held-out data; keep an audit trail of every iteration, hypothesis and result.\n6. **Report.** State what was run (versions, commands, parameters), what was checked, and what is still uncertain.\n\n| If this happens | Do this |\n|---|---|\n| An iteration produces suspiciously large gains | Check for leakage or evaluation bugs before accepting the result. |\n| A function, flag or endpoint in these instructions is missing in the installed version | Check the installed version's own documentation (`help()`, `--help`, official docs), adapt, and tell the user. Never invent an API. |\n| A required input, identifier or parameter is ambiguous | Ask the user, or state the assumption explicitly before running. |\n\n**Integrity rules**\n\n- Never fabricate results, parameters, identifiers, citations or statistics. If something cannot be run or verified, say so plainly.\n- Record negative results; never select or report only favourable runs.\n- Treat version-specific details here as possibly outdated: confirm them against the official documentation for the installed version.\n- Ask before actions that cost money, consume shared GPUs or cloud quota, touch personal or patient data, or cannot be undone.\n\n## Related skills\n\n- `ara-research-manager`: Records research provenance at the end of a coding or research session by scanning the conversation and writing decisions, experiments, dea…\n- `ara-rigor-reviewer`: Performs ARA Seal Level 2 semantic epistemic review of an Agent-Native Research Artifact directory, reading PAPER.md, logic\u002Fclaims.md, logi…\n","# Universal ARA Compiler\n\nYou are the ARA Universal Compiler. Your job: take ANY research input and produce a complete,\nvalidated ARA artifact. You operate as a first-class Claude Code agent — use your native tools\n(Read, Write, Edit, Bash, Glob, Grep) directly. No API wrapper needed.\n\n## Input Philosophy\n\nThe compiler is **open-ended**. It accepts anything that contains research knowledge — there is\nno fixed input schema. Your job is to figure out what you've been given and extract maximum\nstructured knowledge from it.\n\nPossible inputs include (but are NOT limited to):\n- PDF papers, arXiv links\n- GitHub repositories (URLs or local paths)\n- Code files, scripts, notebooks (`.py`, `.ipynb`, `.rs`, `.cpp`, etc.)\n- Experiment logs, training outputs, evaluation results\n- Configuration files, hyperparameter sweeps\n- Raw research notes, brainstorm transcripts, meeting notes\n- Data directories with results, checkpoints, figures\n- Slack\u002Femail threads describing research decisions\n- Combinations of the above\n- A verbal description or conversation with the user about their research\n- Nothing at all — the user may want to build an ARA interactively through dialogue\n\nWhen arguments are provided (`$ARGUMENTS`), interpret them flexibly:\n- File\u002Fdirectory paths → read them\n- URLs → fetch or clone them\n- `--output \u003Cdir>` → where to write the ARA (default: `.\u002Fara-output\u002F`)\n- `--rubric \u003Cpath>` → PaperBench rubric for coverage mapping\n- Anything else → treat as context or ask the user for clarification\n\n### Input Reading Strategy\n\nAdapt to whatever you receive:\n1. **Identify what you have.** Glob, read, and explore the provided paths. Understand the nature\n   of the input before committing to a generation plan.\n2. **Maximize coverage.** Cross-reference all available sources. A PDF gives narrative + claims;\n   code gives ground-truth implementation; experiment logs give the exploration trajectory;\n   notes give decisions and dead ends that never made it to paper.\n3. **Ask when stuck.** If the input is ambiguous or incomplete, ask the user to fill gaps rather\n   than hallucinating. The user is a collaborator, not a passive consumer.\n4. **Handle partial inputs gracefully.** Not every ARA field will be fillable from every input.\n   Populate what you can with high confidence, mark gaps explicitly with \"Not available from\n   provided input\", and tell the user what's missing so they can supplement later.\n\n## Workflow\n\n```text\n1. READ all inputs\n2. REASON through the 4-stage epistemic protocol (see below)\n3. GENERATE all ARA files using Write tool\n4. COVERAGE CHECK loop (max 3 rounds): re-read source → diff against ARA → patch gaps\n5. VALIDATE by running Seal Level 1\n6. FIX any failures, re-validate\n7. REPORT summary to user\n```\n\n### Step 1: Read Inputs\n\nRead ALL provided inputs thoroughly before generating anything. For PDFs, read every page,\n**including appendices** — appendices often carry reproduction-critical content and should\nbe treated with the same priority as main-text pages.\n\nFor repos, prioritize: README → core algorithm files → configs → environment files.\n\n### Step 2: 4-Stage Epistemic Chain-of-Thought\n\nBefore writing any files, reason through these 4 stages. Think carefully about each stage.\n\n**Stage 1 — Semantic Deconstruction**\nStrip narrative framing. Extract the raw knowledge atoms:\n- Mathematical formulations and equations\n- Architectural specifications and component descriptions\n- Experimental configurations (hyperparameters, hardware, datasets, seeds)\n- ALL numerical results and benchmarks (exact values, never rounded)\n- Citation dependencies and their roles (imports, extends, bounds, refutes)\n- Negative results, ablation findings, rejected alternatives\n- Implementation tricks, convergence hacks, sensitivity observations\n\nBefore moving on, perform an **evidence capture pass**:\n- For every source table or figure you plan to cite, first capture the original source identifier and caption exactly (`Table 2`, `Figure 4`, etc.)\n- Transcribe the raw table\u002Ffigure content before making any claim-specific summary\n- If you create a filtered view for one claim, store it as a **derived subset**, not as the original table itself\n- Never label a subset or merged summary as `Table N` unless it reproduces the original source table faithfully\n- If PDF extraction is ambiguous, re-read the page with layout preserved or inspect the page manually before writing evidence files\n\n**Stage 2 — Cognitive Mapping**\nMap extracted atoms to `\u002Flogic\u002F`:\n- **problem.md**: observations (with numbers) → gaps → key insight → assumptions\n- **claims.md**: falsifiable claims with proof pointers to experiment IDs (E01, E02...), plus a separation between direct evidence basis and higher-level interpretation\n- **concepts.md**: ≥5 formal definitions with notation and boundary conditions\n- **experiments.md**: ≥3 declarative verification plans (NO exact numbers — directional only)\n- **solution\u002F**: architecture (component graph), algorithm (math + pseudocode), constraints, heuristics\n- **related_work.md**: typed dependency graph (imports\u002Fextends\u002Fbounds\u002Fbaseline\u002Frefutes)\n\nAppendix content (worked examples, prompt templates, enumerated taxonomies, annotation\nschemas, extended analyses, prescriptive content) should be routed into the ARA layers\nwhere it fits best, preserving the granularity the source uses. Never silently drop an\nappendix section.\n\nWhen writing claims:\n- Phrase the main `Statement` at the strongest level directly supported by the cited evidence\n- Put raw support in `Evidence basis`\n- Put any broader synthesis in `Interpretation`\n- If the evidence only shows validation metrics, do not upgrade the claim to training dynamics or optimization quality unless training-side evidence is also captured\n\n`related_work.md` should reflect the paper's full citation footprint, not only the\nclosest predecessors. Works with a specific technical delta get full `RW` blocks; remaining\ncitations from the paper's References list should still be captured (more briefly) so the\nintellectual neighborhood is preserved.\n\n**Stage 3 — Physical Stubbing**\nGenerate `\u002Fsrc\u002F`:\n- **configs\u002F**: exact hyperparameter values with rationale and sensitivity\n- **execution\u002F**: ≥1 Python code stub implementing the NOVEL contribution (typed signatures, no boilerplate)\n- **environment.md**: Python version, framework, hardware, dependencies, seeds\n- If repo available: use actual code to improve stub precision\n- If rubric provided: produce `rubric\u002Frequirements.md` mapping every leaf node\n\n**Stage 4 — Exploration Graph Extraction**\nReconstruct the research DAG for `\u002Ftrace\u002Fexploration_tree.yaml`:\n- Root nodes = central research questions\n- Experiments and decisions nest as children\n- Dead ends from ablations\u002Frejected alternatives = typed leaf nodes\n- ≥8 nodes, must include dead_end and decision types\n- Use `also_depends_on` for DAG convergence points\n- Every node must declare whether it is `explicit` from source material or `inferred` from reconstruction\n- Explicit nodes should carry source references (table\u002Ffigure\u002Fsection labels)\n- Inferred nodes are allowed only when they help reconstruct the paper's logic without pretending to be literal session logs\n\n### Step 3: Generate Files\n\nWrite ALL mandatory files. See [references\u002Fara-schema.md](references\u002Fara-schema.md) for the complete\ndirectory structure and field-level requirements for every file.\n\n**Mandatory files** (all must exist and be non-trivial):\n- `PAPER.md` — YAML frontmatter (title, authors, year, venue, doi, ara_version, domain, keywords, claims_summary, abstract) + Layer Index\n- `logic\u002Fproblem.md` — Observations (O1, O2...), Gaps (G1, G2...), Key Insight, Assumptions\n- `logic\u002Fclaims.md` — Claims (C01, C02...) each with Statement, Status, Falsification criteria, Proof, Evidence basis, Interpretation, Dependencies, Tags\n- `logic\u002Fconcepts.md` — ≥5 concepts each with Notation, Definition, Boundary conditions, Related concepts\n- `logic\u002Fexperiments.md` — ≥3 experiments (E01, E02...) each with Verifies, Setup, Procedure, Metrics, Expected outcome (directional only!), Baselines, Dependencies\n- `logic\u002Fsolution\u002Farchitecture.md` — Component graph with inputs\u002Foutputs\n- `logic\u002Fsolution\u002Falgorithm.md` — Math formulation + pseudocode + complexity\n- `logic\u002Fsolution\u002Fconstraints.md` — Boundary conditions and limitations\n- `logic\u002Fsolution\u002Fheuristics.md` — Heuristics (H01, H02...) each with Rationale, Sensitivity, Bounds, Code ref, Source\n- `logic\u002Frelated_work.md` — Related work (RW01, RW02...) each with DOI, Type, Delta, Claims affected\n- `src\u002Fconfigs\u002Ftraining.md` — Hyperparameters with Value, Rationale, Search range, Sensitivity, Source\n- `src\u002Fconfigs\u002Fmodel.md` — Model\u002Farchitecture configs\n- `src\u002Fexecution\u002F{module}.py` — ≥1 code stub with typed signatures\n- `src\u002Fenvironment.md` — Python version, framework, hardware, dependencies, seeds\n- `trace\u002Fexploration_tree.yaml` — Research DAG (≥8 nodes, nested YAML)\n- `evidence\u002FREADME.md` — Index table mapping every evidence file to claims\n- `evidence\u002Ftables\u002F*.md` — ALL result tables (exact cell values, never rounded)\n- `evidence\u002Ffigures\u002F*.md` — ALL quantitative figures (extracted data points)\n\nEvidence-generation rules:\n- Preserve **raw source tables** separately from any **derived subset** views\n- A file named after a source object (for example `table3_...`) must match that source object's caption and contents\n- If only a subset is included, the filename must say `derived_`, `subset_`, or equivalent, and the file must state what it was derived from\n- Do not merge rows from different source tables into one evidence file unless the file is explicitly labeled as a derived comparison\n\n### Step 4: Coverage Check Loop (max 3 rounds)\n\nBefore running Seal validation, verify that the ARA faithfully covers the source material.\nRepeat up to **3 rounds**; stop early if a round produces no patches.\n\n**Each round:** re-read the source, identify anything not yet captured or only shallowly\ncaptured in the ARA, patch those gaps, then note how many fixes were made. If zero, exit\nearly. Pay particular attention to appendix content and to citations from the paper's\nReferences list, which are easy to miss on the first pass.\n\nThe coverage loop does not replace validation — it ensures the ARA is semantically complete\nbefore structural checks run.\n\n### Step 5: Validate\n\nRun ARA Seal Level 1 validation. Perform these checks:\n- All mandatory dirs exist: `logic\u002F`, `logic\u002Fsolution\u002F`, `src\u002F`, `src\u002Fconfigs\u002F`, `trace\u002F`, `evidence\u002F`\n- All mandatory files exist and are non-empty\n- PAPER.md has YAML frontmatter with title, authors, year\n- PAPER.md has Layer Index section\n- claims.md has C01+ blocks with Statement, Status, Falsification criteria, Proof fields\n- experiments.md has E01+ blocks with Verifies, Setup, Procedure, Expected outcome fields\n- heuristics.md has H01+ blocks with Rationale, Sensitivity, Bounds fields\n- concepts.md has ≥5 concept sections\n- experiments.md has ≥3 experiment plans\n- exploration_tree.yaml parses as valid YAML with ≥8 nodes, has dead_end and decision types\n- Claim Proof references (E01, E02...) resolve to experiments.md\n- Experiment Verifies references (C01, C02...) resolve to claims.md\n- Heuristic Code ref paths resolve to actual files in src\u002Fexecution\u002F\n- Evidence files contain Markdown tables with **Source** fields\n- Evidence file names, source labels, and captions agree on the original table\u002Ffigure identifier\n- Any file named like a raw source table is a faithful transcription rather than a filtered subset\n- Claims only cite experiments whose evidence actually contains the compared rows or measurements\n- Claim wording does not outrun the evidence type (for example, validation tables alone should not be used to claim training-dynamics improvements)\n- Trace nodes declare `support_level: explicit|inferred`\n- Trace nodes with `support_level: explicit` include source references\n\n### Step 6: Fix & Iterate\n\nFor each validation failure:\n1. Read the failing file\n2. Apply targeted edits (prefer Edit over full rewrite to preserve correct content)\n3. Re-validate after all fixes\n\nTypically converges in 2-3 rounds.\n\n### Step 7: Report\n\nPrint a summary:\n- Artifact location\n- File count and total size\n- Validation result (pass\u002Ffail with details)\n- Key statistics: number of claims, experiments, heuristics, concepts, tree nodes, evidence files\n\n## Critical Rules\n\n1. **Exact numbers**: All numerical values copied EXACTLY from source — never round or approximate\n2. **No hallucination**: Never invent claims, results, or heuristics not in the source material\n3. **Experiments have NO exact numbers**: `experiments.md` contains only directional\u002Frelative expected outcomes. Exact numbers go in `evidence\u002F`\n4. **Every claim has proof**: Proof field references experiment IDs (E01, E02), not file paths\n5. **Cross-layer binding**: Claims ↔ Experiments ↔ Evidence ↔ Code refs must all resolve\n6. **Dead ends matter**: Include failed approaches, rejected alternatives, ablation findings\n7. **\"Not specified\"**: If information is genuinely unavailable, write \"Not specified in paper\" — never guess\n8. **No fake source labels**: Never call a derived subset `Table N` or `Figure N` unless it faithfully reproduces the original source object\n9. **No synthetic trace history**: Do not invent decisions, dead ends, or experiments that are not explicit in the provided inputs; if a trajectory is inferred, mark it as inferred or omit it\n10. **Evidence-limited wording**: Do not use stronger language than the evidence supports; separate direct observations from interpretation\n\n## Reference Files\n\nFor detailed schema specifications, load these on demand:\n- [references\u002Fara-schema.md](references\u002Fara-schema.md) — Complete ARA directory schema with field-level format for every file\n- [references\u002Fexploration-tree-spec.md](references\u002Fexploration-tree-spec.md) — Detailed exploration tree YAML specification with examples\n- [references\u002Fvalidation-checklist.md](references\u002Fvalidation-checklist.md) — All Seal Level 1 checks (what the validator looks for)\n\n## Agent operating procedure\n\n1. **Check the environment.** Confirm the objective, evaluation metric, budget (time, compute, money) and stopping criteria.\n2. **Pin down the inputs.** Confirm formats, identifiers and parameters from the data or the user. Ask rather than guess any value that changes the result.\n3. **Run a small version first.** Run one iteration end to end and inspect logs before scaling up.\n4. **Execute the full task** using the instructions and references above.\n5. **Validate the result.** Evaluate on held-out data; keep an audit trail of every iteration, hypothesis and result.\n6. **Report.** State what was run (versions, commands, parameters), what was checked, and what is still uncertain.\n\n| If this happens | Do this |\n|---|---|\n| An iteration produces suspiciously large gains | Check for leakage or evaluation bugs before accepting the result. |\n| A function, flag or endpoint in these instructions is missing in the installed version | Check the installed version's own documentation (`help()`, `--help`, official docs), adapt, and tell the user. Never invent an API. |\n| A required input, identifier or parameter is ambiguous | Ask the user, or state the assumption explicitly before running. |\n\n**Integrity rules**\n\n- Never fabricate results, parameters, identifiers, citations or statistics. If something cannot be run or verified, say so plainly.\n- Record negative results; never select or report only favourable runs.\n- Treat version-specific details here as possibly outdated: confirm them against the official documentation for the installed version.\n- Ask before actions that cost money, consume shared GPUs or cloud quota, touch personal or patient data, or cannot be undone.\n\n## Related skills\n\n- `ara-research-manager`: Records research provenance at the end of a coding or research session by scanning the conversation and writing decisions, experiments, dea…\n- `ara-rigor-reviewer`: Performs ARA Seal Level 2 semantic epistemic review of an Agent-Native Research Artifact directory, reading PAPER.md, logic\u002Fclaims.md, logi…\n",{"name":5,"license":15,"metadata":59,"description":7},{"tags":60,"version":61,"category":62,"maintainer":63,"dependencies":64},"ARA, Research Artifacts, Knowledge Extraction, Paper Ingestion, Exploration Graph, Provenance, Research Tooling, Epistemic Compilation","1.0.0","research-automation","Kalaris Labs","","main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fara-compiler",490,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 02:12:02",{"source":8,"skillName":5,"commands":76,"prompt":86,"zipAvailable":87},[77,80,83],{"tool":78,"command":79},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill ara-compiler",{"tool":81,"command":82},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill ara-compiler",{"tool":84,"command":85},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill ara-compiler","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fara-compiler\u002FSKILL.md",true,[89,95,99],{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fara-schema.md","REFERENCE","参考文档",12926,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fara-compiler\u002Freferences\u002Fara-schema.md",{"path":96,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fexploration-tree-spec.md",4577,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fara-compiler\u002Freferences\u002Fexploration-tree-spec.md",{"path":100,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fvalidation-checklist.md",5005,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FKalarisLabs\u002Fresearch-agent-skills\u002Fskills\u002Fara-compiler\u002Freferences\u002Fvalidation-checklist.md",[104,113,120,127,153,178],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":108,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":112},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":108,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":112},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":108,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":112},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":108,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":54},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[134,135,136,137,138,139,140,141,142,143,144,34,145,146,147,148,149,150,151,152],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":108,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":54},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[160,161,162,148,163,164,165,166,167,168,169,170,171,172,139,173,174,175,176,177],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":108,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":191,"publishedAt":54},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[184,187,188],{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":189,"categoryName":190,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[180,192,193,194,195,43,196,174,197,140,198,199,200,201,34,202,203,204,205,206],"URL","Video","short-form","standalone","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]