{"id":"f951e231-4174-4227-8e71-03e178ff94eb","entityType":"agent","slug":"clawhub-c-narcissus-paper-deep-reading","name":"Paper Deep Reading","canonicalUrl":"https://www.xpersona.co/agent/clawhub-c-narcissus-paper-deep-reading","canonicalPath":"/agent/clawhub-c-narcissus-paper-deep-reading","generatedAt":"2026-10-11T04:35:42.171Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T01:58:42.247Z","emptyReason":null},"description":"Deep-read research papers into source-aware reports, traceable claim evidence, and research-direction seeds. Use for paper PDFs, LaTeX sources, appendices, c...","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.2K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s177jw27anm32qt3dm1c7dq0jh851mjz:paper-deep-reading","sourceUrl":"https://clawhub.ai/c-narcissus/paper-deep-reading","homepage":"https://clawhub.ai/c-narcissus/skills/paper-deep-reading","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/c-narcissus/paper-deep-reading","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/c-narcissus/skills/paper-deep-reading","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":62,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Paper Deep Reading technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T01:58:42.247Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T01:58:42.247Z","emptyReason":null},"stars":null,"forks":null,"downloads":1198,"packageName":null,"latestVersion":"1.2.0","tractionLabel":"1.2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T01:58:42.177Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T01:58:42.247Z","lastCrawledAt":"2026-10-11T01:58:42.177Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T01:58:42.177Z","lastVerifiedAt":null,"highlights":[{"version":"1.2.0","createdAt":"2026-05-01T13:30:51.284Z","changelog":"Version 1.2.0 introduces research-direction mining and new artifact support: - Added research-direction mining layer with best-practices reference and a structured direction board artifact. - New template and validation script for `direction_board.json` to formalize research seed and idea extraction. - Updated core deliverables to include research direction outputs alongside report and traceability artifacts. - Documentation now highlights three-pass direction-mining methodology and multi-source support (LaTeX/PDF/appendix/code/peer review). - Clarified package discipline, artifact contracts, and runtime expectations in skill manifest and instructions.","fileCount":20,"zipByteSize":40412},{"version":"1.1.3","createdAt":"2026-04-24T12:34:30.087Z","changelog":"**Summary:** Expanded research-generative capabilities and streamlined package discipline for deep-reading reports; improved appendix placement, artifact structure, and language flexibility. - Adds research-generative analysis guided by a new methodology and references. - Moves detailed claim-to-evidence locators to a final appendix, keeping the report body readable. - Introduces a machine-readable research lens artifact (research_lens.json). - Explicitly supports ClawHub/OpenClaw packaging and MIT-0 license compliance. - Tightens package by removing CHANGELOG.md and README.md; now includes LICENSE.txt and relevant templates only. - Improves language selection: report language matches user request, with consistent technical identifier treatment.","fileCount":16,"zipByteSize":23965},{"version":"1.1.2","createdAt":"2026-04-20T15:11:02.940Z","changelog":"paper-deep-reading v1.1.2 - Initial release of a traceable deep-reading pipeline for research papers. - Added scripts for extracting LaTeX paragraphs and validating traceability. - Introduced templates for artifact indexing and traceability manifests. - Now outputs both a detailed Markdown report and supporting JSON artifacts for claim-to-evidence mapping. - Provides reference files for artifact contracts and locator policies. - Includes a requirements.txt and comprehensive README for setup and usage.","fileCount":15,"zipByteSize":14347},{"version":"1.1.1","createdAt":"2026-04-17T17:46:41.941Z","changelog":"No changes detected in this version. - Version number remains 1.1.0 in both current and previous files. - No file changes detected; instructions and content are unchanged. - No new features, fixes, or documentation updates.","fileCount":3,"zipByteSize":6612},{"version":"1.1.0","createdAt":"2026-04-17T17:36:15.642Z","changelog":"**Major update: Now source-aware, with improved evidence-gathering and optional storyboard output.** - Attempts to gather the best available paper sources, preferring arXiv LaTeX, and clearly reports which sources were used. - Optionally generates a cartoon storyboard summarizing the main idea, if image generation is available. - Enhanced handling for ICLR papers: integrates OpenReview reviews and rebuttals when possible. - Explicitly distinguishes LaTeX-primary, PDF-primary, or mixed-source readings, and transparently documents any mismatches or missing sources. - Retains comprehensive, Markdown-only deep reading report, but is now more specific about input handling and source reliability.","fileCount":3,"zipByteSize":6611},{"version":"1.0.1","createdAt":"2026-04-17T15:49:27.157Z","changelog":"**Standalone skill now outputs only Markdown-based deep reading reports, removing dependencies and machine-readable artifacts.** - Now produces only Markdown reports: no JSON, YAML (except skill file), spreadsheets, code, or manifest outputs. - Changed focus to standalone use; removed requirements for upstream manifests, bundle contracts, or downstream processing. - Revised and condensed documentation for clearer instructions and mandatory report content. - All workflow scripts, JSON/YAML templates, and contract schemas have been removed from the repository. - Added a Markdown report template to guide consistent, formula-preserving outputs aligned with new requirements.","fileCount":4,"zipByteSize":6495},{"version":"1.0.0","createdAt":"2026-04-17T15:40:28.600Z","changelog":"Initial release of paper-deep-reading skill - Deeply reads one or a small batch of papers, producing formula-preserving, figure-aware, reviewer-aware reports and graph-ready artifacts. - Includes detailed rules for claim audits, formula explanation, theory-practice mapping, module critiques, and more. - Produces per-paper detailed reports and cross-paper comparison artifacts when needed. - Ensures all reports meet or exceed benchmark examples from top conferences. - Integrates reviewer and innovation-mining sections to support downstream graph-building and research direction discovery.","fileCount":28,"zipByteSize":56132}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s177jw27anm32qt3dm1c7dq0jh851mjz:paper-deep-reading","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s177jw27anm32qt3dm1c7dq0jh851mjz:paper-deep-reading` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/c-narcissus/paper-deep-reading before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-c-narcissus-paper-deep-reading/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-c-narcissus-paper-deep-reading/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-c-narcissus-paper-deep-reading/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-c-narcissus-paper-deep-reading/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-c-narcissus-paper-deep-reading/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-c-narcissus-paper-deep-reading/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T04:35:42.165Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-c-narcissus-paper-deep-reading/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-c-narcissus-paper-deep-reading/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-c-narcissus-paper-deep-reading/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-c-narcissus-paper-deep-reading/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T01:58:42.247Z","emptyReason":null},"readme":"Skill: Paper Deep Reading\n\nOwner: c-narcissus\n\nSummary: Deep-read research papers into source-aware reports, traceable claim evidence, and research-direction seeds. Use for paper PDFs, LaTeX sources, appendices, c...\n\nTags: latest:1.2.0\n\nVersion history:\n\nv1.2.0 | 2026-05-01T13:30:51.284Z | user\n\nVersion 1.2.0 introduces research-direction mining and new artifact support:\n\n- Added research-direction mining layer with best-practices reference and a structured direction board artifact.\n- New template and validation script for `direction_board.json` to formalize research seed and idea extraction.\n- Updated core deliverables to include research direction outputs alongside report and traceability artifacts.\n- Documentation now highlights three-pass direction-mining methodology and multi-source support (LaTeX/PDF/appendix/code/peer review).\n- Clarified package discipline, artifact contracts, and runtime expectations in skill manifest and instructions.\n\nv1.1.3 | 2026-04-24T12:34:30.087Z | user\n\n**Summary:**  \nExpanded research-generative capabilities and streamlined package discipline for deep-reading reports; improved appendix placement, artifact structure, and language flexibility.\n\n- Adds research-generative analysis guided by a new methodology and references.\n- Moves detailed claim-to-evidence locators to a final appendix, keeping the report body readable.\n- Introduces a machine-readable research lens artifact (research_lens.json).\n- Explicitly supports ClawHub/OpenClaw packaging and MIT-0 license compliance.\n- Tightens package by removing CHANGELOG.md and README.md; now includes LICENSE.txt and relevant templates only.\n- Improves language selection: report language matches user request, with consistent technical identifier treatment.\n\nv1.1.2 | 2026-04-20T15:11:02.940Z | user\n\npaper-deep-reading v1.1.2\n\n- Initial release of a traceable deep-reading pipeline for research papers.\n- Added scripts for extracting LaTeX paragraphs and validating traceability.\n- Introduced templates for artifact indexing and traceability manifests.\n- Now outputs both a detailed Markdown report and supporting JSON artifacts for claim-to-evidence mapping.\n- Provides reference files for artifact contracts and locator policies.\n- Includes a requirements.txt and comprehensive README for setup and usage.\n\nv1.1.1 | 2026-04-17T17:46:41.941Z | user\n\nNo changes detected in this version.\n\n- Version number remains 1.1.0 in both current and previous files.\n- No file changes detected; instructions and content are unchanged.\n- No new features, fixes, or documentation updates.\n\nv1.1.0 | 2026-04-17T17:36:15.642Z | user\n\n**Major update: Now source-aware, with improved evidence-gathering and optional storyboard output.**\n\n- Attempts to gather the best available paper sources, preferring arXiv LaTeX, and clearly reports which sources were used.\n- Optionally generates a cartoon storyboard summarizing the main idea, if image generation is available.\n- Enhanced handling for ICLR papers: integrates OpenReview reviews and rebuttals when possible.\n- Explicitly distinguishes LaTeX-primary, PDF-primary, or mixed-source readings, and transparently documents any mismatches or missing sources.\n- Retains comprehensive, Markdown-only deep reading report, but is now more specific about input handling and source reliability.\n\nv1.0.1 | 2026-04-17T15:49:27.157Z | auto\n\n**Standalone skill now outputs only Markdown-based deep reading reports, removing dependencies and machine-readable artifacts.**\n\n- Now produces only Markdown reports: no JSON, YAML (except skill file), spreadsheets, code, or manifest outputs.\n- Changed focus to standalone use; removed requirements for upstream manifests, bundle contracts, or downstream processing.\n- Revised and condensed documentation for clearer instructions and mandatory report content.\n- All workflow scripts, JSON/YAML templates, and contract schemas have been removed from the repository.\n- Added a Markdown report template to guide consistent, formula-preserving outputs aligned with new requirements.\n\nv1.0.0 | 2026-04-17T15:40:28.600Z | user\n\nInitial release of paper-deep-reading skill\n\n- Deeply reads one or a small batch of papers, producing formula-preserving, figure-aware, reviewer-aware reports and graph-ready artifacts.\n- Includes detailed rules for claim audits, formula explanation, theory-practice mapping, module critiques, and more.\n- Produces per-paper detailed reports and cross-paper comparison artifacts when needed.\n- Ensures all reports meet or exceed benchmark examples from top conferences.\n- Integrates reviewer and innovation-mining sections to support downstream graph-building and research direction discovery.\n\nArchive index:\n\nArchive v1.2.0: 20 files, 40412 bytes\n\nFiles: _meta.json (137b), agents/openai.yaml (791b), LICENSE.txt (926b), references/artifact_contract.md (3861b), references/research-direction-mining-best-practices.md (7399b), references/research-generative-methodology.md (6768b), references/synctex_locator_notes.md (824b), requirements.txt (26b), scripts/extract_latex_paragraphs.py (5648b), scripts/render_inline_trace_report.py (9672b), scripts/validate_direction_board.py (6031b), scripts/validate_traceability.py (5929b), skill-card.md (2529b), SKILL.md (25771b), templates/artifact_index.template.json (585b), templates/direction_board.template.json (2649b), templates/latex_paragraphs.template.json (376b), templates/report_template.md (12092b), templates/research_lens.template.json (3839b), templates/traceability_manifest.template.json (1057b)\n\nFile v1.2.0:SKILL.md\n\n---\nname: paper-deep-reading\ndescription: Deep-read research papers into source-aware reports, traceable claim evidence, and research-direction seeds. Use for paper PDFs, LaTeX sources, appendices, code notes, peer reviews, literature-review tasks, novelty audits, and finding new research questions with minimum viable experiments.\nlicense: MIT-0\nmetadata:\n  version: 1.2.0\n  openclaw:\n    emoji: \"📚\"\n    requires:\n      bins:\n        - python3\n    tags:\n      - research\n      - papers\n      - deep-reading\n      - ideation\n      - literature-review\n---\n\n# Paper Deep Reading: Source-Aware + Research-Generative Direction Mining\n\nUse this skill when the user wants a **deep, paper-grounded, auditable, idea-generative reading report** for one computer-science paper or a small paper batch.\n\nThe input may be:\n\n- a user-provided PDF\n- a user-provided LaTeX source tree or `.tex` files\n- supplementary material, appendix files, code notes, or OpenReview material\n- only the paper title, arXiv id, venue page, citation-like paper name, or PDF link\n\nThe default output is **text-first, audit-first, formula-preserving, and research-direction-oriented**.\nThis version does not require a dedicated webpage reader; when search/browsing tools are available, use them to assemble the best source package before writing.\n\n## 1) Core deliverables\n\n1. **Human-readable report**\n   - `report.md`\n\n2. **Machine-readable trace artifacts**\n   - `traceability_manifest.json`\n   - `latex_paragraphs.json`\n   - `artifact_index.json`\n\n3. **Machine-readable research artifacts**\n   - `research_lens.json`\n   - `direction_board.json`\n\nThe report is the primary user-facing deliverable.\nIt must read like a serious research mentor's deep-reading memo, not like a thin checklist dump.\nThe direction board is the primary idea-mining surface: it converts paper weaknesses, hidden assumptions, evidence gaps, proxy mismatches, successor-paper gaps, and reviewer objections into candidate research directions.\n\n## 2) ClawHub and MIT-0 package discipline\n\nThis skill package is intended to stay compatible with **ClawHub / OpenClaw skill packaging**.\n\nKeep the package lean:\n\n- keep `SKILL.md` as the main instruction file\n- keep only text-based support files, templates, and scripts that another agent needs to execute the workflow\n- do not reintroduce auxiliary docs such as `README.md` or `CHANGELOG.md`\n- do not add binary assets, vendored third-party repositories, or cached papers to the skill package\n- keep support files focused on execution, validation, and artifact contracts\n\nKeep the package license-safe:\n\n- this package follows ClawHub's `MIT-0` publication model\n- keep the local bundle license text in `LICENSE.txt`\n- do not add restrictive or conflicting license terms elsewhere in the package\n- do not vendor third-party projects or assets into the skill unless their license is compatible with `MIT-0` redistribution expectations\n- when external tooling is useful, document it or install it outside the skill instead of copying its source tree into the package\n\nRuntime discipline:\n\n- bundled scripts are local text-processing helpers and should not make network calls\n- if external search is needed, use the host agent's approved browsing/search capability rather than hidden scripts\n- declare runtime dependencies honestly in frontmatter and metadata\n\n## 3) Non-weakening rule and depth bar\n\nDo **not** treat the OpenClaw / ClawHub version as a lightweight summary mode.\nThe single-file constraint changes **presentation**, not **analysis quality**.\n\nNever remove, weaken, shorten, or bypass any existing deep-reading requirement, including:\n\n- source acquisition and disambiguation\n- LaTeX-first reading when source is available\n- PDF-assisted figure/table reading\n- formula preservation\n- proof-to-practice mapping\n- OpenReview / reviewer context when relevant\n- reviewer-lens audit\n- claim IDs and traceability manifest\n- final claim-to-evidence appendix\n- research-generative overlay\n- language policy\n- validation scripts\n\nThe report depth bar should stay close to a strong top-conference paper memo:\n\n- cover the full 25-section reading scope\n- preserve central equations instead of flattening them into prose\n- explain why modules exist, not only what they are called\n- reconstruct likely author-side reasoning when the evidence supports it\n- connect experiments back to claims, ablations, and alternative explanations\n- extract reusable research patterns and future ideas\n- produce concrete research seeds with minimum viable experiments, negative-result interpretation, killer objections, and killer results\n\nIf a tension appears between a shorter explanation and a more idea-generative one, choose the more useful research-direction analysis while keeping claims grounded.\nIf a tension appears between speculation about author intent and factual safety, label the reconstruction explicitly as `plausible inference` or `speculation` and anchor it to textual evidence.\n\n## 4) Research-generative overlay\n\nThis version keeps the original traceability and formula-preservation bar, but adds a **research-direction mining layer**.\n\nThe report must help the user answer not only:\n\n- what the paper did\n- whether the evidence supports the claims\n\nbut also:\n\n- how the authors may have found the direction\n- what hidden assumption `C` broke\n- what unavailable mechanism `Y` had to be replaced\n- what surrogate mechanism `Z` the paper constructed\n- how each module maps to a failure mode\n- why key citations matter in the story\n- what hidden assumption can seed the next paper\n- which new research directions are worth testing first\n\nUse [references/research-generative-methodology.md](references/research-generative-methodology.md) and [references/research-direction-mining-best-practices.md](references/research-direction-mining-best-practices.md) whenever the user wants:\n\n- author-perspective reading\n- idea mining\n- reverse story construction\n- module-level design logic\n- citation-function analysis\n- reviewer-grade critique\n- minimum viable experiment design\n- boundary-pushing future directions\n\n## 5) Research-direction mining three-pass method\n\nRead each paper in three direction-mining passes.\nThese passes are adapted for discovering new research points, not merely for comprehension.\n\n### Pass 1: Five-C triage + direction promise\n\nQuickly inspect title, abstract, introduction, section headings, conclusion, references, and visible figures/tables.\nAnswer the five triage questions:\n\n1. `Category`: What type of paper is this: method, benchmark, theory, measurement, system, dataset, analysis, survey, or position?\n2. `Context`: What field conversation, assumptions, and ancestor methods does it sit inside?\n3. `Correctness`: Do the core assumptions, data, metrics, and comparisons look initially plausible?\n4. `Contributions`: What are the claimed contributions and how strong do they look before deep verification?\n5. `Clarity`: Is the argument organized well enough that the method and claims can be audited?\n\nThen add a **direction-promise note**:\n\n- what hidden assumption seems most likely to be attackable\n- what omitted setting or stress condition appears promising\n- whether the paper is worth a full second and third pass\n\n### Pass 2: Evidence / method / figure chain reconstruction\n\nRead the paper carefully but keep the goal causal:\n\n`problem -> assumption break -> design principle -> module -> formula -> figure/table -> experiment -> claim`\n\nDuring this pass:\n\n- inspect key figures, diagrams, graphs, and tables as evidence, not decoration\n- preserve central equations and explain their role\n- build the challenge-to-module table\n- map each result to the claim it supports\n- mark missing controls, weak baselines, noisy metrics, unclear error bars, and unsupported narrative jumps\n- identify the `available proxy` that replaces an `unavailable ideal mechanism`\n\n### Pass 3: Virtual reimplementation + hidden-assumption attack\n\nRecreate the work as if you had to implement, prove, or reproduce it.\nAsk:\n\n- What exact assumptions must be made for each module to work?\n- Where would the method fail if one assumption were dropped?\n- What tiny example, special case, or counterexample exposes the key idea or fragility?\n- What proof step, algorithm step, data preprocessing choice, or metric definition carries the argument?\n- What implementation details are missing but necessary for reproduction?\n- What would a stronger, cleaner, or more decisive experiment look like?\n\nThis pass must produce future-work triggers.\nA trigger is not a generic suggestion; it is a statement of the form:\n\n`current method works if H -> under not-H it breaks -> new mechanism needed -> minimum experiment to test the opportunity`\n\n## 6) Successor-paper and reverse-citation reading\n\nWhen the user asks for new research directions, do not stop at the paper's own related work.\nIf tools are available and time permits, inspect a small set of successor papers, citation trails, follow-up discussions, code repositories, or public review threads.\n\nUse successor reading to answer:\n\n- how later papers describe this paper's real contribution\n- what later work treats as the bottleneck or limitation\n- what claims were ignored, weakened, or reframed by the community\n- which open gap remains after follow-up papers\n- which direction is already saturated and which remains underexplored\n\nIf successor-paper search was not possible, say so and keep direction confidence lower.\nDo not fabricate citation trends.\n\n## 7) Critical + creative reading rule\n\nEvery report must combine critical and creative reading.\n\nCritical reading asks:\n\n- Is the paper solving the right problem?\n- Are the assumptions reasonable?\n- Are the data, metrics, baselines, and controls sufficient?\n- Are the conclusions stronger than the evidence?\n- Are there simpler alternatives the authors did not rule out?\n- What limitations are admitted, hidden, or structurally unavoidable?\n\nCreative reading asks:\n\n- What good idea can be transplanted elsewhere?\n- What stronger setting makes the idea newly important?\n- What generalization or simplification would be more elegant?\n- What proxy can be replaced by a more direct signal?\n- What negative result would change community understanding?\n- What is the next research question a strong PhD student should test?\n\nThe final directions must be creative **and** falsifiable.\n\n## 8) Reviewer-grade audit integrated with direction mining\n\nUse reviewer thinking not just to judge acceptance, but to discover research seeds.\n\nAudit at least these dimensions when evidence allows:\n\n- novelty and relation to prior work\n- significance and likely community use\n- technical soundness\n- methodology rigor\n- statistical validity and uncertainty reporting\n- baseline and control completeness\n- reproducibility and implementation sufficiency\n- result-to-claim alignment\n- clarity of figures/tables/formulas\n- limitation honesty\n- ethics, safety, or societal concerns when relevant\n- specific constructive critique\n\nConvert reviewer objections into direction candidates:\n\n`reviewer objection -> why it matters -> what evidence would resolve it -> minimum viable experiment -> possible new paper`\n\n## 9) Full-loop research seed discipline\n\nThe skill does **not** replace the researcher or claim to have completed experiments.\nIt turns a paper into candidate directions that a researcher can test.\n\nEvery strong candidate direction must include:\n\n- `seed_type`: one of assumption violation, unavailable mechanism, proxy mismatch, evidence gap, tiny example, successor-paper gap, reviewer objection, negative result, or cross-domain transfer\n- `paper_anchor`: claim IDs and source evidence that triggered it\n- `research_question`: a question that can be answered\n- `hypothesis`: what might be true\n- `minimum_viable_experiment`: the smallest decisive test\n- `negative_result_interpretation`: what it would mean if the hypothesis fails\n- `killer_objection`: the strongest reason the idea might be uninteresting or invalid\n- `killer_result`: the result that would make the direction worth pursuing\n- `first_week_plan`: practical steps for a researcher's first week\n- `risk_level` and `expected_value`\n\nGeneric future-work lists are not enough.\nA direction without a test plan is an inspiration note, not a research seed.\n\n## 10) Verification surface: body first, appendix last\n\nThe report itself remains the primary verification surface, but the detailed evidence placement is:\n\n1. **Main body**\n   - readable section-by-section analysis\n   - `### Anchored Points` blocks near the relevant discussion\n   - concise claim bullets in the form `- [C5.2][evidence-backed interpretation] ...`\n\n2. **Final appendix**\n   - detailed claim-by-claim evidence records\n   - exact source files\n   - section paths\n   - line spans\n   - page hints when available\n   - quote snippets and excerpt windows\n   - notes that help a human verify the claim quickly\n\nDo **not** clutter the main narrative by inserting long locator bullets immediately after every claim.\nKeep the main body readable, and move detailed original-paragraph explanation to the final `# Appendix: Claim -> Evidence Index`.\n\nUse [scripts/render_inline_trace_report.py](scripts/render_inline_trace_report.py) after drafting the report and manifest to materialize or refresh that appendix.\n\n## 11) Formula-first preservation\n\nWhen the paper contains key formulas, the report must **not** compress them into prose-only summaries.\n\nFor each central equation, objective, theorem statement, update rule, estimator, metric, loss, or constraint, explicitly include:\n\n1. the equation itself in readable math form\n2. symbol-by-symbol explanation\n3. what optimization / estimation / filtering / proof role it plays\n4. why the authors likely wrote it in this form instead of a nearby alternative\n5. how it connects to the previous and next module\n6. what may be brittle, heuristic, under-justified, statistically weak, or computationally expensive about it\n7. how changing the equation creates possible new research directions\n\nDo not weaken equation detail for the sake of shorter presentation.\n\n## 12) Source acquisition policy\n\nAlways assemble the **best available evidence package** before writing.\n\nPreferred reading order:\n\n1. **arXiv LaTeX/source package**\n2. **user-provided LaTeX**\n3. **best available PDF**\n4. **supplementary material / appendix**\n5. **official code or implementation notes when the user asks for reproducibility**\n6. **OpenReview thread / rebuttal / meta-review when relevant**\n7. **successor papers or citation trails when the user asks for new research directions**\n\n### 12.1 When LaTeX is available\n\nTreat LaTeX as the primary structural source.\n\nUse PDF only as a visual and pagination aid for:\n\n- figure interpretation\n- table reading\n- page-local narrative flow\n- page anchors\n- visual sanity checks that cannot be recovered from source text\n\n### 12.2 When only PDF is available\n\nDo not stop at PDF summarization immediately.\n\nFirst check whether the same paper has a matching arXiv LaTeX/source package.\nIf it exists and matches the same paper, switch to **LaTeX-primary + PDF-assisted** reading.\n\nIf not, continue with the PDF and say explicitly that the reading is **PDF-primary**.\n\n### 12.3 When only title is available\n\nSearch for the paper and collect:\n\n1. arXiv source package if available\n2. the best PDF\n3. supplementary PDF or appendix if available\n4. OpenReview forum if venue is ICLR or otherwise OpenReview-hosted\n5. official code, successor papers, or citation context when needed for direction mining\n\nNever silently analyze the wrong paper.\nDisambiguate by title, authors, abstract, year, venue, and method keywords.\n\n### 12.4 OpenReview policy\n\nIf the paper is an ICLR or OpenReview-hosted paper, look for:\n\n- reviewer comments\n- meta-review or area-chair summary\n- author rebuttal or response\n- revision signals relevant to acceptance\n\nUse them to enrich:\n\n- reviewer-lens audit\n- confidence in claimed contributions\n- limitations and unresolved doubts\n- candidate directions derived from reviewer objections\n\n### 12.5 Missing source policy\n\nIf some sources cannot be found, do not abort.\nState clearly what was attempted, what was found, what was missing, and how that affects confidence.\nThen continue with the best grounded report possible.\n\nIf LaTeX cannot be found after an explicit search, say so clearly and use PDF-oriented evidence rows in `traceability_manifest.json` instead of pretending paragraph anchors exist.\n\n## 13) Language policy\n\nWrite the **skill instructions, internal prompts, and template skeletons in English**.\nChoose the **report language** from the user's current request language by default.\n\n- if the user's current request is primarily in Chinese, write the report in Chinese\n- if the user's current request is primarily not Chinese, write the report in English\n- if the user explicitly requests another language, follow that explicit instruction\n- if the request is mixed-language, follow the dominant user language in the current request\n\nWhen writing the report in Chinese:\n\n- keep proper nouns and fixed technical identifiers in English\n- this includes paper titles, method names, module names, datasets, baselines, theorem or object names, citation names, equation symbols, claim IDs, filenames, and JSON keys\n- translate section headings and explanatory prose into Chinese, but do not translate artifact filenames, schema fields, or claim IDs\n\n## 14) Mandatory artifacts\n\n### 14.1 `report.md`\n\nThe report must cover, whenever the evidence supports it:\n\n1. paper identification and source package used\n2. one-sentence thesis and research equation\n3. title interpretation\n4. what problem the paper really solves\n5. scientific problem ladder\n6. how the authors may have found the direction\n7. how the authors built the story\n8. related work, key citations, and what was still missing\n9. main idea\n10. symbols, assumptions, and notation\n11. key formulas and equation-by-equation explanation\n12. theory / proof / practice mapping\n13. algorithm or module walkthrough with concrete example\n14. method deep reading: the author-thinking behind each module\n15. figure explanation\n16. experimental design\n17. experiments as story evidence and claim alignment audit\n18. reviewer-lens audit\n19. innovation points and claim-by-claim support audit\n20. story-making pattern worth learning\n21. weaknesses and limitations\n22. innovation type and scientific-boundary judgment\n23. future directions and stronger idea paths\n24. vivid plain-language story summary\n25. exact sources used\n\nUse [templates/report_template.md](templates/report_template.md) as the default skeleton.\n\nFor each numbered section:\n\n- start with `### Anchored Points`\n- add one or more claim bullets in the exact form `- [C<section>.<index>][label] claim text`\n- keep the bullets concise\n- follow the bullets with a real explanatory section, not just more bullets\n- add tables, formulas, examples, reviewer-style critique, or story reconstruction when they help understanding\n\n### 14.2 `traceability_manifest.json`\n\nThis is the claim-to-evidence map.\n\nRules:\n\n- every claim id in the main report body must appear in the manifest\n- one bullet must not hide multiple independent claims under one id\n- if a claim depends on multiple paragraphs, equations, tables, appendix passages, figures, or reviews, list them separately\n- each claim entry should include `interpretation_type`\n- each claim entry should preferably include `research_role`\n- each claim entry should include human-friendly locator data when possible\n\n### 14.3 `latex_paragraphs.json`\n\nThis is the stable LaTeX anchor index.\n\nEach entry must keep:\n\n- `paragraph_id`\n- `source_path`\n- `line_start`\n- `line_end`\n- `section_path`\n- `kind`\n- `text`\n\n### 14.4 `artifact_index.json`\n\nA compact index for the generated text-first bundle.\n\nIt should list the locations of:\n\n- `report.md`\n- `traceability_manifest.json`\n- `latex_paragraphs.json`\n- `research_lens.json`\n- `direction_board.json`\n- main PDF if any\n- supplementary PDF if any\n- source package path if known\n\n### 14.5 `research_lens.json`\n\nThis is the compact idea-mining artifact.\nUse [templates/research_lens.template.json](templates/research_lens.template.json) and [references/artifact_contract.md](references/artifact_contract.md).\n\nIt should capture:\n\n- the paper's research equation\n- the likely direction-finding path\n- challenge-to-module mapping\n- per-module hidden assumptions\n- citation logic\n- reviewer-lens summary\n- reusable story pattern\n- strongest future idea directions\n- links to the most important direction seeds\n\n### 14.6 `direction_board.json`\n\nThis is the structured research-direction board.\nUse [templates/direction_board.template.json](templates/direction_board.template.json).\n\nIt should capture:\n\n- ranked candidate research directions\n- the evidence trigger for each direction\n- hidden assumption or missing mechanism\n- minimum viable experiment\n- negative-result interpretation\n- killer objection and killer result\n- first-week plan\n- score breakdown\n- relationship to existing paper claims\n\n## 15) Claim discipline\n\n### 15.1 Claim ids\n\nUse stable section-local ids such as:\n\n- `C3.1`\n- `C5.2`\n- `C14.4`\n\n### 15.2 Claim splitting rule\n\nDo not hide multiple judgments in one claim bullet.\n\n### 15.3 Evidence completeness rule\n\nList all materially relevant evidence for a claim, not just one convenient paragraph.\n\n### 15.4 Interpretation labels\n\nEach claim must declare exactly one of:\n\n- `evidence-backed interpretation`\n- `plausible inference`\n- `speculation`\n\n### 15.5 Research-generative honesty rule\n\nIf the report reconstructs likely author reasoning, it must still point to the exact paragraphs, equations, figures, tables, experiments, reviews, or successor-paper signals that motivate that reconstruction.\nIdea generation is required, but fabrication is forbidden.\n\n### 15.6 Direction trigger labels\n\nEach direction seed should also label the trigger as one of:\n\n- `evidence-backed interpretation`\n- `plausible inference`\n- `speculation`\n\nDo not rank speculative seeds as high-confidence unless the uncertainty is explicit.\n\n## 16) Writing style for verification and idea generation\n\nPrefer a report that is pleasant to read **and** easy to audit.\n\nFor every claim, the user should be able to answer:\n\n1. What section-level conclusion is being made?\n2. Is it direct evidence, plausible inference, or speculation?\n3. Where should I verify it in the appendix?\n\nFor the strongest research-direction sections, the report should also answer:\n\n1. What hidden assumption broke?\n2. What missing mechanism was replaced?\n3. What future paper becomes possible if that assumption fails harder?\n4. What minimum experiment would tell us whether this future paper is real?\n5. What result would kill the idea?\n6. What result would make the idea exciting?\n\nUse phrasing such as:\n\n- \"A plausible author-side thinking path is ...\"\n- \"This module is best understood as a surrogate for ...\"\n- \"The citation is not ornamental; it functions as ...\"\n- \"The deepest reusable lesson is ...\"\n- \"This weakness can be converted into a new research direction ...\"\n- \"The minimum viable experiment is ...\"\n- \"The killer objection is ...\"\n- \"A negative result would still be useful if it shows ...\"\n\nThe report should sound like a research mentor reconstructing how the work may have been invented and how it could become the next project, not like a generic summarizer.\n\n## 17) Grounded workflow\n\n1. Assemble the best source package.\n2. If LaTeX is available, extract paragraph anchors with `scripts/extract_latex_paragraphs.py`.\n3. Perform Pass 1 five-C triage and decide whether full deep reading is warranted.\n4. Perform Pass 2 evidence / method / figure chain reconstruction.\n5. Perform Pass 3 virtual reimplementation and hidden-assumption attack.\n6. Draft `report.md` using anchored claim IDs in the main body.\n7. Keep claim bullets concise and put longer explanation in prose, tables, formulas, examples, and story reconstructions after them.\n8. Fill `traceability_manifest.json` so each claim points to one or more paragraph IDs or fallback anchors.\n9. Fill `research_lens.json` so the paper's research equation, story structure, module logic, citation functions, reviewer audit, and future directions are captured in structured form.\n10. Fill `direction_board.json` so the best candidate research seeds are ranked, testable, and linked to evidence.\n11. Fill `artifact_index.json` so the bundle stays portable.\n12. Run `scripts/validate_traceability.py`.\n13. Run `scripts/validate_direction_board.py` when `direction_board.json` is present.\n14. Run `scripts/render_inline_trace_report.py` to append or refresh the final `Claim -> Evidence Index` appendix in `report.md`.\n15. Only then finalize the bundle.\n\n## 18) Small-batch policy\n\nFor a small paper batch:\n\n- produce one standalone `report.md`-style bundle per paper when the user expects detailed reading\n- do not collapse multiple papers into a shallow combined summary\n- optionally add a cross-paper direction board if the goal is choosing a new research direction\n- rank cross-paper directions by novelty, evidence gap, testability, expected impact, feasibility, and relationship to the user's research interests\n\n## 19) Failure handling\n\nIf some sources cannot be found, do not abort.\nState clearly:\n\n- what was attempted\n- what was found\n- what was missing\n- how the missing source changes confidence\n- which claims or direction seeds are affected\n\nThen continue with the best grounded report possible.\n\nIf the evidence does not support strong idea generation, say so and produce a conservative direction board.\nDo not invent novelty, successor trends, reviewer objections, or experimental feasibility.\n\nFile v1.2.0:_meta.json\n\n{\n  \"ownerId\": \"kn7fxns1xpr6z67w885my7d7k98506vv\",\n  \"slug\": \"paper-deep-reading\",\n  \"version\": \"1.2.0\",\n  \"publishedAt\": 1777642251284\n}\n\nFile v1.2.0:references/artifact_contract.md\n\n# Artifact Contract\n\n## `artifact_index.json`\n\nTop-level index for all outputs that belong to one paper reading bundle.\n\nRequired keys:\n\n- `schema_version`\n- `paper_id`\n- `report`\n- `traceability_manifest`\n- `latex_paragraphs`\n- `research_lens`\n- `direction_board`\n\nOptional keys:\n\n- `source_package`\n- `pdfs`\n- `notes`\n\n## `traceability_manifest.json`\n\nMaps report claims to source evidence.\n\nEach claim entry should include:\n\n- `claim_id`\n- `section_id`\n- `report_anchor`\n- `statement`\n- `interpretation_type`\n- `confidence`\n- `evidences`\n\nRecommended extra fields:\n\n- `research_role`\n- `human_locators`\n\nEach evidence entry may include:\n\n- `evidence_id`\n- `source_kind`\n- `source_file`\n- `paragraph_id`\n- `page`\n- `line_start`\n- `line_end`\n- `locator_method`\n- `synctex`\n- `quote_text`\n- `notes`\n\n## `latex_paragraphs.json`\n\nStable anchor list extracted from LaTeX.\n\nEach paragraph entry should include:\n\n- `paragraph_id`\n- `source_path`\n- `line_start`\n- `line_end`\n- `section_path`\n- `kind`\n- `text`\n\n## `research_lens.json`\n\nThis is the compact idea-mining layer.\nIt should capture:\n\n- research equation\n- direction reconstruction\n- challenge-to-module map\n- module hidden assumptions\n- citation logic\n- reviewer-lens summary\n- reusable story pattern\n- strongest future directions\n- links to top direction seeds\n\nEvery `claim_ids` entry inside `research_lens.json` must point to a real report claim.\nEvery seed referenced in `top_direction_seed_ids` should exist in `direction_board.json`.\n\n## `direction_board.json`\n\nThis is the structured research-direction board for finding new research points.\nIt should rank testable directions derived from the paper.\n\nRequired top-level keys:\n\n- `schema_version`\n- `paper_id`\n- `purpose`\n- `source_confidence`\n- `direction_seeds`\n- `ranking_notes`\n- `search_limitations`\n\nEach `direction_seeds` entry should include:\n\n- `seed_id`\n- `title`\n- `seed_type`\n- `trigger_interpretation_type`\n- `paper_anchor_claim_ids`\n- `trigger_evidence_summary`\n- `hidden_assumption_or_gap`\n- `research_question`\n- `hypothesis`\n- `proposed_mechanism`\n- `minimum_viable_experiment`\n- `negative_result_interpretation`\n- `killer_objection`\n- `killer_result`\n- `first_week_plan`\n- `score`\n- `risk_level`\n- `expected_value`\n- `confidence`\n\nAllowed `seed_type` values:\n\n- `assumption_violation`\n- `unavailable_mechanism`\n- `proxy_mismatch`\n- `evidence_gap`\n- `tiny_example`\n- `successor_paper_gap`\n- `reviewer_objection`\n- `negative_result`\n- `cross_domain_transfer`\n\nAllowed `trigger_interpretation_type` values:\n\n- `evidence-backed interpretation`\n- `plausible inference`\n- `speculation`\n\nRecommended `score` fields:\n\n- `novelty`\n- `significance`\n- `testability`\n- `feasibility`\n- `evidence_anchor`\n- `risk_adjusted_value`\n- `overall`\n\nEach score should be on a 0-5 scale, with a short reason when possible.\n\n## Report requirement\n\nIn `report.md`, every main-body claim bullet should appear in the form:\n\n- `[C<section>.<index>][interpretation label] statement`\n\nThe detailed locator material should live in the final `# Appendix: Claim -> Evidence Index`, not inside the middle of the narrative body.\n\nFor each claim entry in the appendix, provide enough detail for a human verifier to know:\n\n- which source file to open\n- which section / subsection to inspect\n- which line span or page span to inspect\n- what quote snippet or excerpt window to look for\n- what note or role explains why that evidence matters\n\n## Claim typing\n\nAllowed interpretation labels:\n\n- `evidence-backed interpretation`\n- `plausible inference`\n- `speculation`\n\n## Direction-board honesty\n\nDo not label a direction as high confidence unless it is grounded in specific paper evidence or verified successor/reviewer context.\nIf successor-paper search was not performed, state this in `search_limitations` and avoid claiming novelty beyond the current source package.\n\nFile v1.2.0:references/research-direction-mining-best-practices.md\n\n# Research-Direction Mining Best Practices\n\nThis reference strengthens the deep-reading workflow for users whose main goal is to find new research directions and research points.\nIt should be used together with `research-generative-methodology.md` and the main `SKILL.md`.\n\n## 1. Direction-Mining Three-Pass Reading\n\n### Pass 1: Five-C triage with research promise\n\nAnswer:\n\n1. `Category`: What kind of paper is this?\n2. `Context`: What field conversation and prior assumptions does it depend on?\n3. `Correctness`: Do the high-level assumptions, task, data, and comparisons look plausible?\n4. `Contributions`: What does the paper claim to add?\n5. `Clarity`: Is the argument readable and auditable?\n\nThen add:\n\n- likely hidden assumption\n- likely missing mechanism\n- likely weak evidence point\n- whether the paper deserves a full direction-mining read\n\n### Pass 2: Evidence / method / figure chain\n\nReconstruct the paper as:\n\n`problem -> broken assumption -> design principle -> module -> formula -> figure/table -> experiment -> claim`\n\nRequired outputs:\n\n- challenge-to-module table\n- claim-to-experiment map\n- formula role notes\n- figure/table support notes\n- proxy-vs-ideal mechanism notes\n\n### Pass 3: Virtual reimplementation and hidden-assumption attack\n\nRead as if you had to rebuild the paper.\n\nAsk:\n\n- What assumptions must be true for each module to work?\n- Which assumptions are implicit rather than stated?\n- What proof step, code step, data choice, or metric definition is carrying the argument?\n- What special case makes the method easy to understand?\n- What counterexample would break the method?\n- What experiment would settle the main uncertainty fastest?\n\nRequired output:\n\n- hidden-assumption list\n- tiny example or special-case explanation\n- dropped-assumption failure modes\n- future-work triggers\n\n## 2. Reverse Citation and Successor-Paper Reading\n\nWhen tools and time allow, inspect a small set of successor papers or citation trails.\n\nUse successor reading to distinguish:\n\n- what the original paper claimed\n- what later papers actually reused\n- what later papers criticized or avoided\n- what became a standard assumption\n- what remains under-tested\n- what has already become saturated\n\nDo not fabricate trends.\nIf successor search was not performed, mark successor-derived directions as unavailable or lower confidence.\n\n## 3. Critical + Creative Reading\n\nCritical reading checks:\n\n- Are the assumptions reasonable?\n- Are the data and metrics suitable?\n- Are baselines and controls sufficient?\n- Is the evidence aligned with the claims?\n- Are simpler explanations ruled out?\n- Are the limitations honest and complete?\n\nCreative reading asks:\n\n- What good idea can transfer to a new setting?\n- What stronger or cleaner assumption break would make a new paper?\n- What missing mechanism should replace a proxy?\n- What negative result would change how the community thinks?\n- What would a first-week experiment test?\n\n## 4. Reviewer-Grade Direction Audit\n\nUse reviewer objections as idea generators.\n\n| Audit dimension | What to ask | Direction trigger |\n|---|---|---|\n| Novelty | What is genuinely new relative to prior work? | If novelty is narrow, search for a broader mechanism or setting. |\n| Significance | Who would use or build on this? | If impact is local, find a more important stress condition. |\n| Soundness | Are claims technically supported? | If support is weak, propose decisive validation. |\n| Methodology rigor | Are baselines, ablations, and controls enough? | Missing control becomes an experiment seed. |\n| Statistical validity | Are uncertainty, variance, and sample size convincing? | Weak statistics becomes robustness or evaluation seed. |\n| Reproducibility | Are details sufficient to recreate results? | Missing detail becomes replication or protocol seed. |\n| Limitation honesty | Are structural weaknesses named? | Hidden limitation becomes assumption-violation seed. |\n| Constructive critique | What feedback would improve the paper? | Actionable critique becomes a new project plan. |\n\n## 5. Seed Types\n\nUse these seed types in `direction_board.json`.\n\n### 5.1 Assumption violation\n\n`current method works if H; under not-H it breaks; build method for not-H`\n\nExamples of `H`:\n\n- labels are reliable\n- data are IID\n- clients are honest\n- compute is sufficient\n- distribution shift is mild\n- proxy signal correlates with target mechanism\n- evaluation benchmark represents deployment\n\n### 5.2 Unavailable mechanism\n\nThe borrowed method normally needs an ideal mechanism `Y`, but the target setting lacks it.\nThe paper builds surrogate `Z`.\nA new direction appears when `Z` is weak and another surrogate is possible.\n\n### 5.3 Proxy mismatch\n\nThe paper optimizes a proxy signal.\nAsk whether the proxy can be gamed, become stale, or diverge from the real target.\n\n### 5.4 Evidence gap\n\nA main claim lacks the exact experiment, ablation, proof, or dataset needed to verify it.\nThe seed is a decisive test.\n\n### 5.5 Tiny example or counterexample\n\nA small special case exposes either the method's core insight or a failure mode.\nThe seed is to generalize from that case.\n\n### 5.6 Successor-paper gap\n\nLater work uses the paper but leaves a limitation unresolved.\nThe seed is to solve the unresolved limitation with updated tools or settings.\n\n### 5.7 Reviewer objection\n\nA reviewer-grade weakness becomes a concrete research plan.\n\n### 5.8 Negative result\n\nA surprising failure, if carefully analyzed, may be publishable because it changes understanding.\n\n### 5.9 Cross-domain transfer\n\nA mechanism works in one field but has not been tested in another field where the same hidden assumption fails.\n\n## 6. Minimum Viable Experiment Pattern\n\nEach strong seed should include:\n\n1. **Setup**: smallest dataset, benchmark, theorem case, synthetic environment, or controlled reproduction.\n2. **Intervention**: the one mechanism or assumption to change.\n3. **Comparison**: baseline, ablation, or prior method.\n4. **Metric**: the number, proof property, or qualitative outcome that decides the question.\n5. **Decision rule**: what result supports, weakens, or kills the direction.\n6. **Negative-result interpretation**: why failure still teaches something.\n\n## 7. Killer Objection and Killer Result\n\nA direction is stronger when it survives a serious objection.\n\nFor every top seed, write:\n\n- `killer_objection`: the best reason the idea may be trivial, already solved, untestable, too expensive, or not impactful\n- `killer_result`: the smallest result that would make the direction compelling\n\n## 8. Direction Board Output Contract\n\nEach seed in `direction_board.json` should include:\n\n- `seed_id`\n- `title`\n- `seed_type`\n- `trigger_interpretation_type`\n- `paper_anchor_claim_ids`\n- `trigger_evidence_summary`\n- `hidden_assumption_or_gap`\n- `research_question`\n- `hypothesis`\n- `proposed_mechanism`\n- `minimum_viable_experiment`\n- `negative_result_interpretation`\n- `killer_objection`\n- `killer_result`\n- `first_week_plan`\n- `score`\n- `risk_level`\n- `expected_value`\n- `confidence`\n\n## 9. Honesty Rules\n\n- Do not claim a direction is novel unless checked against available sources.\n- Do not claim author intent as fact.\n- Do not turn every weakness into a high-value idea; many weaknesses are merely engineering cleanup.\n- Do not ignore negative results; they can reveal the true boundary of a method.\n- Mark missing evidence and search limitations explicitly.\n\nFile v1.2.0:references/research-generative-methodology.md\n\n# Research-Generative Methodology\n\nUse this reference when the user wants more than grounded verification.\nIts goal is to turn a paper reading into a **research-generation exercise** while keeping every important statement source-aware.\n\nThe core move is:\n\n> Read the paper as a hidden design path.\n\n## 1. Research Equation\n\nCompress the paper into:\n\n`old success + broken assumption + hard setting + borrowed tool + surrogate mechanism`\n\nUseful questions:\n\n- What important paradigm already worked?\n- What hidden assumption made it work?\n- In what realistic setting does that assumption fail?\n- What neighboring method almost transfers?\n- What missing mechanism `Y` blocks direct transfer?\n- What surrogate `Z` does the paper build instead?\n\n## 2. How the Direction Was Likely Found\n\nUse evidence-backed phrasing:\n\n- \"The authors likely noticed that ...\"\n- \"A plausible thinking path is ...\"\n- \"The setup suggests ...\"\n\nTry to reconstruct:\n\n- starting dissatisfaction\n- tempting transferred method\n- blocking constraint\n- replacement logic\n\n## 3. How the Story Was Built\n\nLook for:\n\n`challenge -> failure mode -> design principle -> module -> ablation`\n\nStrong papers often create a loop instead of a bag of tricks.\nExplain whether one module creates the resource that the next module needs.\n\n## 4. Method Deep Reading\n\nFor each module, reconstruct:\n\n`failure + ideal unavailable solution + available proxy + design choice + hidden assumption + risk`\n\nThe most useful framing is usually:\n\n> This module is not just a trick; it is a surrogate for the missing mechanism `Y`.\n\n## 5. Reverse Citation Logic\n\nTreat citations as narrative functions:\n\n- field anchor\n- limitation evidence\n- method ancestor\n- neighboring inspiration\n- baseline pressure\n- protocol justification\n- contrast boundary\n\nExplain what permission each key citation gives the paper.\n\n## 6. Experiments as Story Evidence\n\nRead each result as:\n\n`claim + counterfactual + metric + stress condition`\n\nAsk:\n\n- what claim it supports\n- what alternative explanation it rules out\n- which module it validates\n- whether the stress condition really matches the paper's target difficulty\n\n## 7. Story Pattern Worth Learning\n\nExtract one reusable pattern, such as:\n\n- replacement story\n- three-module story\n- two-axis empty cell\n- closed-loop contribution\n- hidden-assumption break\n\n## 8. Weakness to New Idea Conversion\n\nUse:\n\n`future work = current method + violated assumption + new mechanism`\n\nFor each strong weakness, ask what next paper becomes possible if the key hidden assumption fails harder.\n\n## 9. Writing Rules\n\nPrefer phrasing like:\n\n- \"A plausible author-side thinking path is ...\"\n- \"This module is best understood as a surrogate for ...\"\n- \"The citation is not ornamental; it functions as ...\"\n- \"This weakness can be converted into a new research direction ...\"\n\nAvoid:\n\n- restating the abstract\n- listing sections without causal explanation\n- paraphrasing equations without saying why they exist\n- speaking as if private author intent were directly observed\n\n---\n\n# Direction-Mining Upgrade for v1.2.0\n\nThis upgrade adds explicit research-seed generation to the original research-generative reading method.\nThe original method asks how a paper was likely invented; this upgrade asks which next paper can be tested.\n\n## 10. Research Seed Equation\n\nTurn any strong weakness into:\n\n`Seed = evidence trigger + hidden assumption + violated setting + new mechanism + minimum viable experiment`\n\nA useful template is:\n\n```text\nThe paper's method works because H is usually true.\nIn setting S, H is false or unverifiable.\nCurrent proxy Z is insufficient because of failure F.\nA new mechanism Z' may solve F.\nThe minimum viable experiment is E.\nA negative result would mean N.\nA killer result would be K.\n```\n\n## 11. New Direction Templates\n\n### 11.1 Assumption-violation seed\n\n```text\nCurrent paper: M works if H.\nBreak: H fails under S.\nResearch question: Can M be redesigned for not-H?\nMechanism: replace proxy P with mechanism Q.\nMinimum viable experiment: compare M and Q under controlled not-H stress.\n```\n\n### 11.2 Proxy-mismatch seed\n\n```text\nCurrent paper: proxy P is used as a surrogate for ideal signal Y.\nBreak: P diverges from Y under condition S.\nResearch question: Can we estimate Y more directly or build a better surrogate?\nMinimum viable experiment: construct a stress test where P and Y disagree.\n```\n\n### 11.3 Reviewer-objection seed\n\n```text\nObjection: the paper does not rule out alternative explanation A.\nResearch question: Is the reported gain due to the proposed mechanism or A?\nMinimum viable experiment: isolate A with matched controls.\nKiller result: proposed mechanism wins when A is controlled.\n```\n\n### 11.4 Negative-result seed\n\n```text\nPopular belief: method family M should help in setting S.\nNegative result: M fails despite careful tuning.\nWhy this matters: failure reveals that assumption H is false.\nMinimum viable experiment: reproduce failure across small but representative cases.\n```\n\n### 11.5 Successor-gap seed\n\n```text\nOriginal paper: introduced mechanism Z.\nSuccessor papers: reuse Z but avoid setting S.\nGap: no one has tested Z under S or replaced it when it fails.\nMinimum viable experiment: benchmark Z in S against a simple robust alternative.\n```\n\n## 12. Scoring Candidate Directions\n\nScore top seeds on 0-5 scales:\n\n- `novelty`: Does this differ from direct follow-up work?\n- `significance`: Would the field care if the result is true?\n- `testability`: Can a first experiment decide anything useful?\n- `feasibility`: Can the user plausibly start it soon?\n- `evidence_anchor`: Is the seed grounded in paper evidence?\n- `risk_adjusted_value`: Is the upside worth the uncertainty?\n\nPrefer a diverse board:\n\n- one low-risk validation direction\n- one medium-risk mechanism direction\n- one high-risk boundary-pushing direction\n\n## 13. Minimum Viable Experiment Discipline\n\nA minimum viable experiment is not a full paper.\nIt is the smallest decisive test that reduces uncertainty.\n\nIt must specify:\n\n- dataset or synthetic setup\n- baseline or ablation\n- changed mechanism\n- metric or proof target\n- expected result\n- decision rule\n- negative-result interpretation\n\nDo not output research directions without at least a draft minimum viable experiment.\n\n## 14. Boundary-Pushing Direction Filter\n\nA direction is likely boundary-pushing only if it changes at least one of:\n\n- the assumption under which a method family works\n- the mechanism used to replace an unavailable ideal signal\n- the benchmark or stress condition used to define progress\n- the theory of why a method should work\n- the community's understanding through a surprising negative result\n\nEngineering cleanup is useful, but do not label it boundary-pushing unless it changes understanding.\n\nFile v1.2.0:references/synctex_locator_notes.md\n\n# SyncTeX Locator Notes\n\nThis bundle does not require SyncTeX for every run, but the reader and artifact contract are designed to use it whenever available.\n\n## Recommended workflow\n\n1. Compile the paper with SyncTeX enabled, for example:\n   - `latexmk -pdf -synctex=1 main.tex`\n2. Keep:\n   - the compiled PDF\n   - the generated `.synctex.gz`\n3. Preserve `source_path`, `line_start`, and `line_end` in `latex_paragraphs.json`\n4. During bundle enrichment, convert line anchors to PDF page / bbox coordinates\n5. Store the result under each evidence item, for example:\n\n```json\n\"synctex\": {\n  \"pdf\": \"paper.pdf\",\n  \"page\": 3,\n  \"bbox\": [70, 120, 480, 170]\n}\n```\n\n## Localization priority\n\n1. explicit SyncTeX page + bbox\n2. explicit PDF page + bbox already stored in manifest\n3. source path + line span\n4. text-search fallback\n\nFile v1.2.0:skill-card.md\n\n## Description:\n\nDeep-read research papers into source-aware reports, traceable claim evidence, and research-direction seeds.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[c-narcissus](https://clawhub.ai/user/c-narcissus)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nResearchers, developers, and technical reviewers use this skill to analyze computer-science papers or small paper batches from PDFs, LaTeX sources, appendices, code notes, review material, or citation-like identifiers. It produces source-grounded reading reports, traceability artifacts, and testable research-direction seeds.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill reads user-provided papers, source files, appendices, code notes, and review material.\n\nMitigation: Run it only on documents you are permitted to process, and avoid placing unrelated sensitive files in the working folder.\n\nRisk: The workflow can create multiple report and traceability files in the active workspace.\n\nMitigation: Run it in a project-specific workspace and review generated artifacts before sharing or committing them.\n\nRisk: Optional dependency installation may pull packages listed in requirements.txt.\n\nMitigation: Pin, review, or omit unused dependencies if the host automatically installs requirements.txt.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/c-narcissus/skills/paper-deep-reading)\n- [Artifact Contract](references/artifact_contract.md)\n- [Research-Generative Methodology](references/research-generative-methodology.md)\n- [Research-Direction Mining Best Practices](references/research-direction-mining-best-practices.md)\n- [SyncTeX Locator Notes](references/synctex_locator_notes.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, json, shell commands, guidance]\n\n**Output Format:** [Markdown report plus structured JSON artifacts and optional shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces report.md, traceability_manifest.json, latex_paragraphs.json, artifact_index.json, research_lens.json, and direction_board.json when the workflow is completed.]\n\n## Skill Version(s):\n\n1.2.0 (source: frontmatter, artifact metadata, release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v1.2.0:templates/report_template.md\n\n# Deep Reading Report: <paper-title>\n\nUse this template together with `traceability_manifest.json`, `research_lens.json`, and `direction_board.json`.\nWrite the final report in Chinese when the user's current request is primarily in Chinese; keep proper nouns, fixed technical identifiers, claim IDs, filenames, and JSON keys in English. Otherwise write the report in English.\n\nFor every numbered section below:\n\n- start with `### Anchored Points`\n- add one or more claims in the exact form `- [C<section>.<index>][label] claim text`\n- allowed labels are `evidence-backed interpretation`, `plausible inference`, and `speculation`\n- keep the claim bullets concise and judgment-focused\n- make sure every main-body claim ID appears in `traceability_manifest.json`\n- if a claim is reconstructive rather than directly stated, mark it as inferential in the manifest\n- if one claim depends on multiple source locations, list every materially necessary source location as separate evidence rows in `traceability_manifest.json`\n- if one bullet contains multiple independent claims, split it into multiple claim IDs before writing the manifest\n- after the anchored points, add the longer explanation, tables, formulas, critique, and author-side reconstruction as needed\n- do not paste detailed locator bullets in the middle of the body; reserve that for the final appendix\n\n## 1. Paper Identification and Source Package Used\n### Anchored Points\nAfter anchored points, state the title, authors, venue or status, reading mode (`LaTeX-primary`, `PDF-primary`, or mixed), exact source files used, what was searched for, what was missing, and how source limitations affect confidence.\n\n## 2. One-Sentence Thesis and Research Equation\n### Anchored Points\nAfter anchored points, summarize the paper in one sentence and express the research equation in the form: old success -> broken assumption -> hard setting -> borrowed tool -> unavailable mechanism -> surrogate mechanism. Also include the compact form `A(P) ∩ ¬C ∩ T ∩ M => Z≈Y` when applicable.\n\n## 3. Title Interpretation\n### Anchored Points\nAfter anchored points, interpret the title term by term and explain how each keyword maps to the actual method, setting, and claim scope.\n\n## 4. What Problem the Paper Really Solves\n### Anchored Points\nAfter anchored points, explain the direct problem, the practical pain point, the scientific question, and the larger pressure from the parent field.\n\n## 5. Scientific Problem Ladder\n### Anchored Points\nAfter anchored points, build the ladder explicitly from paper-local problem to broader AI or systems boundary, and note any upper-level bottlenecks introduced by the method itself.\n\n## 6. How the Authors May Have Found This Direction\n### Anchored Points\nAfter anchored points, reconstruct the likely dissatisfaction, near-transfer from neighboring methods, blocking constraint, and why the surrogate mechanism was worth trying. Keep uncertainty explicit.\n\nRecommended table:\n\n| Valuable field | Painful assumption | Borrowed/emerging tool | Blocking constraint | Conceptual replacement |\n|---|---|---|---|---|\n\n## 7. How the Authors Built the Story\n### Anchored Points\nAfter anchored points, map challenge -> failure mode -> design principle -> module -> ablation or evidence, and judge whether the story forms a coherent loop instead of a bag of modules.\n\nRecommended table:\n\n| Challenge | Failure mode | Design principle | Module | Evidence / claim IDs |\n|---|---|---|---|---|\n\n## 8. Related Work, Key Citations, and What Was Still Missing\n### Anchored Points\nAfter anchored points, explain what the key cited works solved, what they left open, and the narrative role of each citation cluster: field anchor, limitation evidence, method ancestor, baseline pressure, protocol justification, neighboring inspiration, or contrast boundary. Add successor-paper context when it was searched.\n\n## 9. Main Idea\n### Anchored Points\nAfter anchored points, explain the conceptual replacement or coordination logic that makes the method coherent, rather than repeating only module names.\n\n## 10. Symbols, Assumptions, and Notation\n### Anchored Points\nAfter anchored points, introduce the important symbols, operators, assumptions, and task-specific objects before relying on them heavily later. Mark hidden assumptions that may become direction seeds.\n\n## 11. Key Formulas and Equation-by-Equation Explanation\n### Anchored Points\nAfter anchored points, preserve the central formulas in readable math form. For each one, explain symbols, role, why this form was chosen, how it connects to adjacent modules, and what looks fragile, heuristic, under-justified, statistically weak, or expensive. Add direction triggers when modifying the formula could create a new mechanism.\n\n## 12. Theory / Proof / Practice Mapping\n### Anchored Points\nAfter anchored points, explain what is proved, why it is proved, what reviewer concern it addresses, how theory maps to implementation, and where theory and practice diverge. For proofs, identify assumptions and ask how the proof breaks if each assumption is dropped.\n\n## 13. Algorithm or Module Walkthrough with Concrete Example\n### Anchored Points\nAfter anchored points, give a step-by-step pipeline walkthrough with at least one concrete mini-example that instantiates inputs, intermediate states, and outputs. Use tiny examples or special cases to reveal the core idea or fragility.\n\n## 14. Method Deep Reading: The Author-Thinking Behind Each Module\n### Anchored Points\nAfter anchored points, explain for each major module: the failure being fixed, the ideal but unavailable solution, the proxy signal actually used, the hidden assumption, the risk, and the future idea that appears if the assumption breaks.\n\nRecommended table:\n\n| Module | Failure fixed | Ideal unavailable solution | Available proxy | Hidden assumption | Risk under violation | Future research point |\n|---|---|---|---|---|---|---|\n\n## 15. Figure Explanation\n### Anchored Points\nAfter anchored points, interpret the key figures or captions, explain what each figure is meant to demonstrate, and judge whether the visual evidence really supports the associated claim. When figures are unavailable, state that limitation.\n\n## 16. Experimental Design\n### Anchored Points\nAfter anchored points, explain datasets, tasks, baselines, metrics, ablations, implementation details, and how the compared methods map back to the related-work landscape. Note missing controls and statistical uncertainty.\n\n## 17. Experiments as Story Evidence and Claim Alignment Audit\n### Anchored Points\nAfter anchored points, explain what claim each main result is supposed to support, what alternative explanation it rules out, and whether the evidence strongly, partially, or weakly supports the claim.\n\nRecommended table:\n\n| Experiment | Claim | Counterfactual ruled out | Metric | Stress condition | Alignment judgment |\n|---|---|---|---|---|---|\n\n## 18. Reviewer-Lens Audit\n### Anchored Points\nAfter anchored points, assess novelty, significance, soundness, methodology rigor, statistical validity, reproducibility, clarity, missing controls, limitations honesty, and any OpenReview reviewer or rebuttal signal when available. Convert the strongest reviewer-grade objections into candidate direction seeds.\n\n## 19. Innovation Points and Claim-by-Claim Support Audit\n### Anchored Points\nAfter anchored points, list the paper's main contribution claims and judge whether each one is supported by theory, experiments, qualitative evidence, reviewer discussion, or only weak evidence.\n\n## 20. Story-Making Pattern Worth Learning\n### Anchored Points\nAfter anchored points, extract the reusable pattern from the paper, such as a replacement story, three-module story, closed loop, two-axis empty cell, negative-result reframing, or hidden-assumption break.\n\n## 21. Weaknesses and Limitations\n### Anchored Points\nAfter anchored points, discuss unresolved weaknesses, failure modes, scope limits, hidden costs, and where the current idea is likely to break. Distinguish engineering limitations from structural scientific limitations.\n\n## 22. Innovation Type and Scientific-Boundary Judgment\n### Anchored Points\nAfter anchored points, judge whether the work is incremental, cross-pollinated, conceptually reframing, negative-result informative, or potentially boundary-pushing, and explain why.\n\n## 23. Future Directions, Direction Board, and Stronger Idea Paths\n### Anchored Points\nAfter anchored points, propose next-step ideas, stronger boundary directions, alternative modules, negative-result opportunities, or more decisive experiments. Tie the best future ideas to hidden assumptions whose failure would break the current method.\n\nCreate a compact direction board in the report and mirror the full version in `direction_board.json`.\n\nRecommended table:\n\n| Seed ID | Seed type | Hidden assumption / gap | Research question | Minimum viable experiment | Killer objection | Killer result | Overall score |\n|---|---|---|---|---|---|---|---|\n\nFor each top seed, include:\n\n- why this direction is grounded in the current paper\n- what evidence or claim ID triggered it\n- what a negative result would teach\n- what a first-week plan would look like\n\n## 24. Vivid Plain-Language Story Summary\n### Anchored Points\nAfter anchored points, write a short memorable story that stays technically faithful while remaining accessible to a non-specialist.\n\n## 25. Exact Sources Used\n### Anchored Points\nAfter anchored points, list exactly which PDFs, LaTeX files, supplementary materials, OpenReview pages, successor papers, code notes, screenshots, or other sources were used, and explicitly mention missing or ambiguous sources.\n\n---\n\n## Optional Structured Notes for `research_lens.json`\n\n### Research Equation\n- old success / paradigm:\n- broken assumption:\n- hard setting:\n- borrowed tool:\n- ideal unavailable mechanism:\n- surrogate mechanism:\n\n### Three-Pass Direction Mining Notes\n- Pass 1 five-C triage:\n- Pass 2 evidence / method / figure chain:\n- Pass 3 virtual reimplementation and hidden-assumption attack:\n\n### Challenge-to-Module Map\n\n| Challenge | Failure mode | Design principle | Module | Evidence |\n|---|---|---|---|---|\n\n### Module Lens Table\n\n| Module | Failure fixed | Ideal unavailable solution | Available proxy | Hidden assumption | Risk | Future research point |\n|---|---|---|---|---|---|---|\n\n### Citation Function Table\n\n| Citation cluster | Narrative function | Assumption inherited | How the paper modifies it |\n|---|---|---|---|\n\n### Experiments-As-Story-Evidence Table\n\n| Experiment | Claim | Counterfactual | Metric | Stress condition | Alignment judgment |\n|---|---|---|---|---|---|\n\n### Reviewer-Lens Audit\n- novelty:\n- significance:\n- soundness:\n- methodology rigor:\n- statistical validity:\n- reproducibility:\n- limitation honesty:\n- actionable reviewer objections:\n\n### Story Pattern Worth Reusing\n- pattern name:\n- compact formula:\n- lesson:\n\n### Boundary-Pushing Idea List\n- hidden assumption:\n- what breaks:\n- next mechanism worth exploring:\n- minimum viable experiment:\n- negative result interpretation:\n- killer objection:\n- killer result:\n- linked claim ids:\n\n---\n\n## Optional Structured Notes for `direction_board.json`\n\nFor each direction seed:\n\n- seed_id:\n- title:\n- seed_type:\n- trigger_interpretation_type:\n- paper_anchor_claim_ids:\n- trigger_evidence_summary:\n- hidden_assumption_or_gap:\n- research_question:\n- hypothesis:\n- proposed_mechanism:\n- minimum_viable_experiment:\n- negative_result_interpretation:\n- killer_objection:\n- killer_result:\n- first_week_plan:\n- score:\n- risk_level:\n- expected_value:\n- confidence:\n\n---\n\n# Appendix: Claim -> Evidence Index\n\nRender this appendix only after the main body is complete.\nUse `scripts/render_inline_trace_report.py` to append or refresh the detailed evidence appendix.\n\nFor each claim ID from the main report body, create a subsection like:\n\n## C<section>.<index>\n- Interpretation type:\n- Statement:\n- Research role:\n- Confidence:\n\n### Evidence 1\n- Source file:\n- Section path:\n- Lines:\n- Page:\n- Locator method:\n- Quote:\n- Excerpt window:\n- Notes:\n\nFile v1.2.0:templates/artifact_index.template.json\n\n{\n  \"schema_version\": \"1.2\",\n  \"paper_id\": \"<paper_id>\",\n  \"report\": \"report.md\",\n  \"traceability_manifest\": \"traceability_manifest.json\",\n  \"latex_paragraphs\": \"latex_paragraphs.json\",\n  \"research_lens\": \"research_lens.json\",\n  \"direction_board\": \"direction_board.json\",\n  \"source_package\": \"<optional source package path>\",\n  \"pdfs\": {\n    \"main\": \"<optional main pdf path>\",\n    \"supplementary\": \"<optional supplementary pdf path>\"\n  },\n  \"notes\": \"Text-first bundle. Verify claims directly from report.md and source locators. Use direction_board.json for research seed ranking.\"\n}\n\nFile v1.2.0:templates/direction_board.template.json\n\n{\n  \"schema_version\": \"1.2\",\n  \"paper_id\": \"<paper_id>\",\n  \"purpose\": \"Ranked research-direction seeds derived from a source-aware deep reading.\",\n  \"source_confidence\": {\n    \"reading_mode\": \"<LaTeX-primary | PDF-primary | mixed>\",\n    \"latex_available\": false,\n    \"pdf_available\": false,\n    \"supplementary_available\": false,\n    \"openreview_available\": false,\n    \"successor_search_performed\": false,\n    \"confidence_notes\": \"<what source limitations affect direction confidence>\"\n  },\n  \"direction_seeds\": [\n    {\n      \"seed_id\": \"D1\",\n      \"title\": \"<short direction title>\",\n      \"seed_type\": \"<assumption_violation | unavailable_mechanism | proxy_mismatch | evidence_gap | tiny_example | successor_paper_gap | reviewer_objection | negative_result | cross_domain_transfer>\",\n      \"trigger_interpretation_type\": \"<evidence-backed interpretation | plausible inference | speculation>\",\n      \"paper_anchor_claim_ids\": [\"C21.1\", \"C23.1\"],\n      \"trigger_evidence_summary\": \"<which paper claim, figure, formula, limitation, review, or successor signal triggered the seed>\",\n      \"hidden_assumption_or_gap\": \"<the assumption, missing mechanism, proxy mismatch, or evidence gap>\",\n      \"research_question\": \"<falsifiable research question>\",\n      \"hypothesis\": \"<what may be true>\",\n      \"proposed_mechanism\": \"<candidate mechanism or experimental intervention>\",\n      \"minimum_viable_experiment\": {\n        \"setup\": \"<smallest dataset, benchmark, synthetic case, proof case, or reproduction setup>\",\n        \"intervention\": \"<one change to test>\",\n        \"comparison\": \"<baseline, ablation, or prior method>\",\n        \"metric_or_decision_rule\": \"<what result decides the question>\",\n        \"expected_supporting_result\": \"<what would support the hypothesis>\"\n      },\n      \"negative_result_interpretation\": \"<what a failure would teach>\",\n      \"killer_objection\": \"<strongest reason this direction may be weak>\",\n      \"killer_result\": \"<smallest result that would make the direction compelling>\",\n      \"first_week_plan\": [\n        \"<step 1>\",\n        \"<step 2>\",\n        \"<step 3>\"\n      ],\n      \"score\": {\n        \"novelty\": 0,\n        \"significance\": 0,\n        \"testability\": 0,\n        \"feasibility\": 0,\n        \"evidence_anchor\": 0,\n        \"risk_adjusted_value\": 0,\n        \"overall\": 0,\n        \"rationale\": \"<short reason for the ranking>\"\n      },\n      \"risk_level\": \"<low | medium | high>\",\n      \"expected_value\": \"<low | medium | high>\",\n      \"confidence\": \"<low | medium | high>\"\n    }\n  ],\n  \"ranking_notes\": \"<why the top seeds were ranked this way>\",\n  \"search_limitations\": \"<what was not searched or verified>\"\n}\n\nFile v1.2.0:templates/latex_paragraphs.template.json\n\n{\n  \"schema_version\": \"1.2.0\",\n  \"paper_id\": \"<paper-slug>\",\n  \"paragraphs\": [\n    {\n      \"paragraph_id\": \"P-sections-introduction-0001\",\n      \"source_path\": \"sections/introduction.tex\",\n      \"line_start\": 10,\n      \"line_end\": 18,\n      \"section_path\": [\"1 Introduction\"],\n      \"kind\": \"paragraph\",\n      \"text\": \"Sample paragraph text extracted from LaTeX.\"\n    }\n  ]\n}\n\nFile v1.2.0:templates/research_lens.template.json\n\n{\n  \"schema_version\": \"1.2\",\n  \"paper_id\": \"<paper_id>\",\n  \"research_equation\": {\n    \"old_success_or_paradigm\": \"<A(P)>\",\n    \"broken_assumption\": \"<C and not-C>\",\n    \"hard_setting_or_constraint\": \"<T>\",\n    \"borrowed_tool_or_method_family\": \"<M>\",\n    \"ideal_unavailable_mechanism\": \"<Y>\",\n    \"surrogate_mechanism\": \"<Z>\",\n    \"compact_formula\": \"A(P) ∩ ¬C ∩ T ∩ M => Z≈Y\",\n    \"claim_ids\": []\n  },\n  \"tri_pass_notes\": {\n    \"pass_1_five_c\": {\n      \"category\": \"<paper category>\",\n      \"context\": \"<field context and ancestor methods>\",\n      \"correctness\": \"<initial assumption and evidence plausibility>\",\n      \"contributions\": \"<claimed contributions>\",\n      \"clarity\": \"<argument clarity>\",\n      \"direction_promise\": \"<hidden assumption or research trigger noticed in triage>\"\n    },\n    \"pass_2_chain\": \"<problem -> assumption -> module -> formula -> figure/table -> experiment -> claim reconstruction>\",\n    \"pass_3_virtual_reimplementation\": \"<assumptions, missing details, special cases, dropped-assumption failures>\"\n  },\n  \"direction_reconstruction\": {\n    \"likely_starting_dissatisfaction\": \"<plausible pain point>\",\n    \"tempting_transfer\": \"<nearby method that almost transfers>\",\n    \"blocking_constraint\": \"<why direct transfer fails>\",\n    \"conceptual_replacement\": \"<what the paper uses instead>\",\n    \"interpretation_type\": \"<evidence-backed interpretation | plausible inference | speculation>\",\n    \"claim_ids\": []\n  },\n  \"challenge_to_module_map\": [\n    {\n      \"challenge\": \"<challenge>\",\n      \"failure_mode\": \"<failure mode>\",\n      \"design_principle\": \"<design principle>\",\n      \"module\": \"<module>\",\n      \"evidence\": \"<claim ids or evidence notes>\",\n      \"claim_ids\": []\n    }\n  ],\n  \"module_hidden_assumptions\": [\n    {\n      \"module\": \"<module>\",\n      \"failure_fixed\": \"<failure>\",\n      \"ideal_unavailable_solution\": \"<ideal solution>\",\n      \"available_proxy\": \"<proxy>\",\n      \"design_choice\": \"<choice>\",\n      \"hidden_assumption\": \"<assumption>\",\n      \"risk_if_assumption_fails\": \"<risk>\",\n      \"future_research_point\": \"<research seed>\",\n      \"claim_ids\": []\n    }\n  ],\n  \"citation_logic\": [\n    {\n      \"citation_cluster\": \"<cluster>\",\n      \"narrative_function\": \"<field anchor | limitation evidence | method ancestor | neighboring inspiration | baseline pressure | protocol justification | contrast boundary>\",\n      \"assumption_inherited\": \"<assumption>\",\n      \"how_paper_modifies_it\": \"<modification>\",\n      \"claim_ids\": []\n    }\n  ],\n  \"experiments_as_story_evidence\": [\n    {\n      \"experiment_block\": \"<experiment>\",\n      \"claim\": \"<supported claim>\",\n      \"counterfactual\": \"<alternative explanation ruled out>\",\n      \"metric\": \"<metric>\",\n      \"stress_condition\": \"<hard setting tested>\",\n      \"alignment_judgment\": \"<strong | partial | weak>\",\n      \"claim_ids\": []\n    }\n  ],\n  \"reviewer_lens_summary\": {\n    \"novelty\": \"<audit>\",\n    \"significance\": \"<audit>\",\n    \"soundness\": \"<audit>\",\n    \"methodology_rigor\": \"<audit>\",\n    \"reproducibility\": \"<audit>\",\n    \"limitations_honesty\": \"<audit>\",\n    \"actionable_objections\": []\n  },\n  \"story_pattern\": {\n    \"pattern_name\": \"<replacement story | closed loop | two-axis empty cell | other>\",\n    \"compact_formula\": \"<pattern formula>\",\n    \"reusable_lesson\": \"<lesson>\",\n    \"claim_ids\": []\n  },\n  \"future_directions\": [\n    {\n      \"direction\": \"<direction>\",\n      \"seed_type\": \"<seed type>\",\n      \"trigger\": \"<hidden assumption, proxy mismatch, evidence gap, successor gap, reviewer objection, or negative result>\",\n      \"minimum_viable_experiment\": \"<small test>\",\n      \"killer_objection\": \"<objection>\",\n      \"killer_result\": \"<decisive result>\",\n      \"direction_seed_id\": \"<D1>\",\n      \"claim_ids\": []\n    }\n  ],\n  \"top_direction_seed_ids\": [\"D1\"],\n  \"direction_board_path\": \"direction_board.json\"\n}\n\nArchive v1.1.3: 16 files, 23965 bytes\n\nFiles: _meta.json (137b), agents/openai.yaml (503b), LICENSE.txt (926b), references/artifact_contract.md (2057b), references/research-generative-methodology.md (3034b), references/synctex_locator_notes.md (824b), requirements.txt (26b), scripts/extract_latex_paragraphs.py (5648b), scripts/render_inline_trace_report.py (9672b), scripts/validate_traceability.py (5929b), SKILL.md (14007b), templates/artifact_index.template.json (488b), templates/latex_paragraphs.template.json (376b), templates/report_template.md (8769b), templates/research_lens.template.json (2281b), templates/traceability_manifest.template.json (1057b)\n\nFile v1.1.3:SKILL.md\n\n---\nname: paper-deep-reading\ndescription: Produce a source-aware, research-generative, MIT-0-compatible single-file deep-reading report for a research paper, with a rich narrative body, a final claim-to-evidence appendix, and the companion artifacts report.md, traceability_manifest.json, latex_paragraphs.json, artifact_index.json, and research_lens.json. Use for OpenClaw or ClawHub paper-reading tasks that need deep analysis without a webpage reader.\n---\n\n# Paper Deep Reading: Source-Aware + Research-Generative Single-File Pipeline\n\nUse this skill when the user wants a **deep, paper-grounded, auditable, idea-generative reading report** for one computer-science paper or a small paper batch.\n\nThe input may be:\n\n- a user-provided PDF\n- a user-provided LaTeX source tree or `.tex` files\n- only the paper title or citation-like paper name\n\nThe default output is **text-first, audit-first, and idea-oriented**.\nThis version intentionally **does not rely on a webpage reader**.\n\n## 1) Core deliverables\n\n1. **Human-readable report**\n   - `report.md`\n\n2. **Machine-readable trace artifacts**\n   - `traceability_manifest.json`\n   - `latex_paragraphs.json`\n   - `artifact_index.json`\n\n3. **Machine-readable research artifact**\n   - `research_lens.json`\n\nThe report is the primary user-facing deliverable.\nIt must read like a serious deep-reading memo, not a thin checklist dump.\n\n## 2) ClawHub and MIT-0 package discipline\n\nThis skill package is intended to stay compatible with **ClawHub / OpenClaw skill packaging**.\n\nKeep the package lean:\n\n- keep only files that another agent needs to execute the workflow\n- do not reintroduce auxiliary docs such as `README.md` or `CHANGELOG.md`\n- keep support files, templates, and scripts focused on execution\n\nKeep the package license-safe:\n\n- this package is prepared for ClawHub's `MIT-0` publication model, and the local bundle keeps the same text in `LICENSE.txt`\n- do not add restrictive or conflicting license terms elsewhere in the package\n- do not vendor third-party projects or assets into the skill unless their license is compatible with `MIT-0` redistribution expectations\n- when external tooling is useful, document it or install it outside the skill instead of copying its source tree into the package\n\n## 3) Depth bar: match the Codex version even in single-file mode\n\nDo **not** treat the OpenClaw / ClawHub version as a lightweight summary mode.\n\nThe report depth bar should stay close to the richer Codex version:\n\n- cover the full 25-section reading scope\n- preserve central equations instead of flattening them into prose\n- explain why modules exist, not only what they are called\n- reconstruct likely author-side reasoning when the evidence supports it\n- connect experiments back to claims, ablations, and alternative explanations\n- extract reusable research patterns and future ideas\n\nThe single-file constraint changes **presentation**, not **analysis quality**.\n\n## 4) Research-generative overlay\n\nThis version keeps the original traceability and formula-preservation bar, but adds the **research-generative reading layer** from the new methodology.\n\nThe report must now help the user answer not only:\n\n- what the paper did\n\nbut also:\n\n- how the authors may have found the direction\n- what hidden assumption `C` broke\n- what unavailable mechanism `Y` had to be replaced\n- what surrogate mechanism `Z` the paper constructed\n- how each module maps to a failure mode\n- why key citations matter in the story\n- what hidden assumption can seed the next paper\n\nUse [references/research-generative-methodology.md](references/research-generative-methodology.md) whenever the user wants:\n\n- author-perspective reading\n- idea mining\n- reverse story construction\n- module-level design logic\n- citation-function analysis\n- boundary-pushing future directions\n\n## 5) Verification surface: body first, appendix last\n\nThe report itself remains the primary verification surface, but the **detailed evidence placement** is:\n\n1. **Main body**\n   - readable section-by-section analysis\n   - `### Anchored Points` blocks near the relevant discussion\n   - concise claim bullets in the form `- [C5.2][evidence-backed interpretation] ...`\n\n2. **Final appendix**\n   - detailed claim-by-claim evidence records\n   - exact source files\n   - section paths\n   - line spans\n   - page hints when available\n   - quote snippets and excerpt windows\n   - notes that help a human verify the claim quickly\n\nDo **not** clutter the main narrative by inserting long locator bullets immediately after every claim.\nKeep the main body readable, and move the detailed original-paragraph explanation to the final `# Appendix: Claim -> Evidence Index`.\n\nUse [scripts/render_inline_trace_report.py](scripts/render_inline_trace_report.py) after drafting the report and manifest to materialize or refresh that appendix.\n\n## 6) Formula-first preservation\n\nWhen the paper contains key formulas, the report must **not** compress them into prose-only summaries.\n\nFor each central equation or objective, the report must explicitly include:\n\n1. the equation itself in readable math form\n2. symbol-by-symbol explanation\n3. what optimization / estimation / filtering role it plays\n4. why the authors likely wrote it in this form instead of a nearby alternative\n5. how it connects to the previous and next module\n6. what may be brittle, heuristic, under-justified, or computationally expensive about it\n\nDo not weaken equation detail for the sake of shorter presentation.\n\n## 7) Source acquisition policy\n\nAlways assemble the **best available evidence package** before writing.\n\nPreferred reading order:\n\n1. **arXiv LaTeX/source package**\n2. **user-provided LaTeX**\n3. **best available PDF**\n4. **supplementary material**\n5. **OpenReview thread / rebuttal / meta-review when relevant**\n\n### 7.1 When LaTeX is available\n\nTreat LaTeX as the primary structural source.\n\nUse PDF only as a visual and pagination aid for:\n\n- figure interpretation\n- table reading\n- page-local narrative flow\n- page anchors\n\n### 7.2 When only PDF is available\n\nDo not stop at PDF summarization immediately.\n\nFirst check whether the same paper has a matching arXiv LaTeX/source package.\nIf it exists and matches the same paper, switch to **LaTeX-primary + PDF-assisted** reading.\n\nIf not, continue with the PDF and say explicitly that the reading is **PDF-primary**.\n\n### 7.3 When only title is available\n\nSearch for the paper and collect:\n\n1. arXiv source package if available\n2. the best PDF\n3. supplementary PDF or appendix if available\n4. OpenReview forum if venue is ICLR or otherwise OpenReview-hosted\n\nNever silently analyze the wrong paper.\nDisambiguate by title, authors, abstract, year, and method keywords.\n\n### 7.4 OpenReview policy\n\nIf the paper is an ICLR or OpenReview-hosted paper, look for:\n\n- reviewer comments\n- meta-review or area-chair summary\n- author rebuttal or response\n- revision signals relevant to acceptance\n\nUse them to enrich:\n\n- reviewer-lens audit\n- confidence in claimed contributions\n- limitations and unresolved doubts\n\n## 8) Language policy\n\nWrite the **skill instructions, internal prompts, and template skeletons in English**.\nChoose the **report language** from the user's current request language by default.\n\n- if the user's current request is primarily in Chinese, write the report in Chinese\n- if the user's current request is primarily not Chinese, write the report in English\n- if the user explicitly requests another language, follow that explicit instruction\n- if the request is mixed-language, follow the dominant user language in the current request\n\nWhen writing the report in Chinese:\n\n- keep proper nouns and fixed technical identifiers in English\n- this includes paper titles, method names, module names, datasets, baselines, theorem or object names, citation names, equation symbols, claim IDs, filenames, and JSON keys\n- translate section headings and explanatory prose into Chinese, but do not translate artifact filenames, schema fields, or claim IDs\n\n## 9) Mandatory artifacts\n\n### 9.1 `report.md`\n\nThe report must cover, whenever the evidence supports it:\n\n1. paper identification and source package used\n2. one-sentence thesis and research equation\n3. title interpretation\n4. what problem the paper really solves\n5. scientific problem ladder\n6. how the authors may have found the direction\n7. how the authors built the story\n8. related work, key citations, and what was still missing\n9. main idea\n10. symbols, assumptions, and notation\n11. key formulas and equation-by-equation explanation\n12. theory / proof / practice mapping\n13. algorithm or module walkthrough with concrete example\n14. method deep reading: the author-thinking behind each module\n15. figure explanation\n16. experimental design\n17. experiments as story evidence and claim alignment audit\n18. reviewer-lens audit\n19. innovation points and claim-by-claim support audit\n20. story-making pattern worth learning\n21. weaknesses and limitations\n22. innovation type and scientific-boundary judgment\n23. future directions and stronger idea paths\n24. vivid plain-language story summary\n25. exact sources used\n\nUse [templates/report_template.md](templates/report_template.md) as the default skeleton.\n\nFor each numbered section:\n\n- start with `### Anchored Points`\n- add one or more claim bullets in the exact form `- [C<section>.<index>][label] claim text`\n- keep the bullets concise\n- follow the bullets with a **real explanatory section**, not just more bullets\n- add tables, formulas, examples, reviewer-style critique, or story reconstruction when they help understanding\n\n### 9.2 `traceability_manifest.json`\n\nThis is the claim-to-evidence map.\n\nRules:\n\n- every claim id in the main report body must appear in the manifest\n- one bullet must not hide multiple independent claims under one id\n- if a claim depends on multiple paragraphs / equations / tables / appendix passages, list them separately\n- each claim entry should include `interpretation_type`\n- each claim entry should preferably include `research_role`\n- each claim entry should include human-friendly locator data when possible\n\n### 9.3 `latex_paragraphs.json`\n\nThis is the stable LaTeX anchor index.\n\nEach entry must keep:\n\n- `paragraph_id`\n- `source_path`\n- `line_start`\n- `line_end`\n- `section_path`\n- `kind`\n- `text`\n\n### 9.4 `artifact_index.json`\n\nA compact index for the generated text-first bundle.\n\nIt should list the locations of:\n\n- `report.md`\n- `traceability_manifest.json`\n- `latex_paragraphs.json`\n- `research_lens.json`\n- main PDF if any\n- supplementary PDF if any\n- source package path if known\n\n### 9.5 `research_lens.json`\n\nThis is the compact idea-mining artifact.\nUse [templates/research_lens.template.json](templates/research_lens.template.json) and [references/artifact_contract.md](references/artifact_contract.md).\n\nIt should capture:\n\n- the paper's research equation\n- the likely direction-finding path\n- challenge-to-module mapping\n- per-module hidden assumptions\n- citation logic\n- story pattern worth reusing\n- strongest future idea directions\n\n## 10) Claim discipline\n\n### 10.1 Claim ids\n\nUse stable section-local ids such as:\n\n- `C3.1`\n- `C5.2`\n- `C14.4`\n\n### 10.2 Claim splitting rule\n\nDo not hide multiple judgments in one claim bullet.\n\n### 10.3 Evidence completeness rule\n\nList all materially relevant evidence for a claim, not just one convenient paragraph.\n\n### 10.4 Interpretation labels\n\nEach claim must declare exactly one of:\n\n- `evidence-backed interpretation`\n- `plausible inference`\n- `speculation`\n\n### 10.5 Research-generative honesty rule\n\nIf the report reconstructs likely author reasoning, it must still point to the exact paragraphs that motivate that reconstruction.\nIdea generation is required, but fabrication is forbidden.\n\n## 11) Writing style for verification and idea generation\n\nPrefer a report that is pleasant to read **and** easy to audit.\n\nFor every claim, the user should be able to answer:\n\n1. What section-level conclusion is being made?\n2. Is it direct evidence, plausible inference, or speculation?\n3. Where should I verify it in the appendix?\n\nFor the strongest sections, the report should also answer:\n\n1. What hidden assumption broke?\n2. What missing mechanism was replaced?\n3. What future paper becomes possible if that assumption fails harder?\n\nUse phrasing such as:\n\n- \"A plausible author-side thinking path is ...\"\n- \"This module is best understood as a surrogate for ...\"\n- \"The citation is not ornamental; it functions as ...\"\n- \"The deepest reusable lesson is ...\"\n- \"This weakness can be converted into a new research direction ...\"\n\nThe report should sound like a research mentor reconstructing how the work may have been invented, not like a generic summarizer.\n\n## 12) Grounded workflow\n\n1. Assemble the best source package.\n2. If LaTeX is available, extract paragraph anchors with `scripts/extract_latex_paragraphs.py`.\n3. Draft `report.md` using anchored claim IDs in the main body.\n4. Keep the claim bullets concise and put the longer explanation in prose, tables, and formula walkthroughs after them.\n5. Fill `traceability_manifest.json` so each claim points to one or more paragraph IDs or fallback anchors.\n6. Fill `research_lens.json` so the paper's research equation, story structure, module logic, citation functions, and future directions are captured in structured form.\n7. Fill `artifact_index.json` so the bundle stays portable.\n8. Run `scripts/validate_traceability.py`.\n9. Run `scripts/render_inline_trace_report.py` to append or refresh the final `Claim -> Evidence Index` appendix in `report.md`.\n10. Only then finalize the bundle.\n\n## 13) Failure handling\n\nIf some sources cannot be found, do not abort.\nState clearly what was attempted, what was found, what was missing, and how that affects confidence.\nThen continue with the best grounded report possible.\n\nIf LaTeX cannot be found after an explicit search, say so clearly and use PDF-oriented evidence rows in `traceability_manifest.json` instead of pretending paragraph anchors exist.\n\nFile v1.1.3:_meta.json\n\n{\n  \"ownerId\": \"kn7fxns1xpr6z67w885my7d7k98506vv\",\n  \"slug\": \"paper-deep-reading\",\n  \"version\": \"1.1.3\",\n  \"publishedAt\": 1777034070087\n}\n\nFile v1.1.3:references/artifact_contract.md\n\n# Artifact Contract\n\n## `artifact_index.json`\n\nTop-level index for all outputs that belong to one paper reading bundle.\n\nRequired keys:\n\n- `schema_version`\n- `paper_id`\n- `report`\n- `traceability_manifest`\n- `latex_paragraphs`\n- `research_lens`\n\nOptional keys:\n\n- `source_package`\n- `pdfs`\n- `notes`\n\n## `traceability_manifest.json`\n\nMaps report claims to source evidence.\n\nEach claim entry should include:\n\n- `claim_id`\n- `section_id`\n- `report_anchor`\n- `statement`\n- `interpretation_type`\n- `confidence`\n- `evidences`\n\nRecommended extra fields:\n\n- `research_role`\n- `human_locators`\n\nEach evidence entry may include:\n\n- `evidence_id`\n- `source_kind`\n- `source_file`\n- `paragraph_id`\n- `page`\n- `line_start`\n- `line_end`\n- `locator_method`\n- `synctex`\n- `quote_text`\n- `notes`\n\n## `latex_paragraphs.json`\n\nStable anchor list extracted from LaTeX.\n\nEach paragraph entry should include:\n\n- `paragraph_id`\n- `source_path`\n- `line_start`\n- `line_end`\n- `section_path`\n- `kind`\n- `text`\n\n## `research_lens.json`\n\nThis is the compact idea-mining layer.\nIt should capture:\n\n- research equation\n- direction reconstruction\n- challenge-to-module map\n- module hidden assumptions\n- citation logic\n- reusable story pattern\n- strongest future directions\n\nEvery `claim_ids` entry inside `research_lens.json` must point to a real report claim.\n\n## Report requirement\n\nIn `report.md`, every main-body claim bullet should appear in the form:\n\n- `[C<section>.<index>][interpretation label] statement`\n\nThe detailed locator material should live in the final `# Appendix: Claim -> Evidence Index`, not inside the middle of the narrative body.\n\nFor each claim entry in the appendix, provide enough detail for a human verifier to know:\n\n- which source file to open\n- which section / subsection to inspect\n- which line span or page span to inspect\n- what quote snippet or excerpt window to look for\n- what note or role explains why that evidence matters\n\n## Claim typing\n\nAllowed interpretation labels:\n\n- `evidence-backed interpretation`\n- `plausible inference`\n- `speculation`\n\nFile v1.1.3:references/research-generative-methodology.md\n\n# Research-Generative Methodology\n\nUse this reference when the user wants more than grounded verification.\nIts goal is to turn a paper reading into a **research-generation exercise** while keeping every important statement source-aware.\n\nThe core move is:\n\n> Read the paper as a hidden design path.\n\n## 1. Research Equation\n\nCompress the paper into:\n\n`old success + broken assumption + hard setting + borrowed tool + surrogate mechanism`\n\nUseful questions:\n\n- What important paradigm already worked?\n- What hidden assumption made it work?\n- In what realistic setting does that assumption fail?\n- What neighboring method almost transfers?\n- What missing mechanism `Y` blocks direct transfer?\n- What surrogate `Z` does the paper build instead?\n\n## 2. How the Direction Was Likely Found\n\nUse evidence-backed phrasing:\n\n- \"The authors likely noticed that ...\"\n- \"A plausible thinking path is ...\"\n- \"The setup suggests ...\"\n\nTry to reconstruct:\n\n- starting dissatisfaction\n- tempting transferred method\n- blocking constraint\n- replacement logic\n\n## 3. How the Story Was Built\n\nLook for:\n\n`challenge -> failure mode -> design principle -> module -> ablation`\n\nStrong papers often create a loop instead of a bag of tricks.\nExplain whether one module creates the resource that the next module needs.\n\n## 4. Method Deep Reading\n\nFor each module, reconstruct:\n\n`failure + ideal unavailable solution + available proxy + design choice + hidden assumption + risk`\n\nThe most useful framing is usually:\n\n> This module is not just a trick; it is a surrogate for the missing mechanism `Y`.\n\n## 5. Reverse Citation Logic\n\nTreat citations as narrative functions:\n\n- field anchor\n- limitation evidence\n- method ancestor\n- neighboring inspiration\n- baseline pressure\n- protocol justification\n- contrast boundary\n\nExplain what permission each key citation gives the paper.\n\n## 6. Experiments as Story Evidence\n\nRead each result as:\n\n`claim + counterfactual + metric + stress condition`\n\nAsk:\n\n- what claim it supports\n- what alternative explanation it rules out\n- which module it validates\n- whether the stress condition really matches the paper's target difficulty\n\n## 7. Story Pattern Worth Learning\n\nExtract one reusable pattern, such as:\n\n- replacement story\n- three-module story\n- two-axis empty cell\n- closed-loop contribution\n- hidden-assumption break\n\n## 8. Weakness to New Idea Conversion\n\nUse:\n\n`future work = current method + violated assumption + new mechanism`\n\nFor each strong weakness, ask what next paper becomes possible if the key hidden assumption fails harder.\n\n## 9. Writing Rules\n\nPrefer phrasing like:\n\n- \"A plausible author-side thinking path is ...\"\n- \"This module is best understood as a surrogate for ...\"\n- \"The citation is not ornamental; it functions as ...\"\n- \"This weakness can be converted into a new research direction ...\"\n\nAvoid:\n\n- restating the abstract\n- listing sections without causal explanation\n- paraphrasing equations without saying why they exist\n- speaking as if private author intent were directly observed\n\nFile v1.1.3:references/synctex_locator_notes.md\n\n# SyncTeX Locator Notes\n\nThis bundle does not require SyncTeX for every run, but the reader and artifact contract are designed to use it whenever available.\n\n## Recommended workflow\n\n1. Compile the paper with SyncTeX enabled, for example:\n   - `latexmk -pdf -synctex=1 main.tex`\n2. Keep:\n   - the compiled PDF\n   - the generated `.synctex.gz`\n3. Preserve `source_path`, `line_start`, and `line_end` in `latex_paragraphs.json`\n4. During bundle enrichment, convert line anchors to PDF page / bbox coordinates\n5. Store the result under each evidence item, for example:\n\n```json\n\"synctex\": {\n  \"pdf\": \"paper.pdf\",\n  \"page\": 3,\n  \"bbox\": [70, 120, 480, 170]\n}\n```\n\n## Localization priority\n\n1. explicit SyncTeX page + bbox\n2. explicit PDF page + bbox already stored in manifest\n3. source path + line span\n4. text-search fallback\n\nFile v1.1.3:templates/report_template.md\n\n# Deep Reading Report: <paper-title>\n\nUse this template together with `traceability_manifest.json` and `research_lens.json`.\nWrite the final report in Chinese when the user's current request is primarily in Chinese; keep proper nouns, fixed technical identifiers, claim IDs, filenames, and JSON keys in English. Otherwise write the report in English.\n\nFor every numbered section below:\n\n- start with `### Anchored Points`\n- add one or more claims in the exact form `- [C<section>.<index>][label] claim text`\n- keep the claim bullets concise and judgment-focused\n- make sure every main-body claim ID appears in `traceability_manifest.json`\n- if a claim is reconstructive rather than directly stated, mark it as inferential in the manifest\n- if one claim depends on multiple source locations, list every materially necessary source location as separate evidence rows in `traceability_manifest.json`\n- if one bullet contains multiple independent claims, split it into multiple claim IDs before writing the manifest\n- after the anchored points, add the longer explanation, tables, formulas, critique, and author-side reconstruction as needed\n- do not paste detailed locator bullets in the middle of the body; reserve that for the final appendix\n\n## 1. Paper Identification and Source Package Used\n### Anchored Points\nAfter anchored points, state the title, authors, venue or status, reading mode (`LaTeX-primary`, `PDF-primary`, or mixed), exact source files used, what was searched for, and what was missing.\n\n## 2. One-Sentence Thesis and Research Equation\n### Anchored Points\nAfter anchored points, summarize the paper in one sentence and express the research equation in the form: old success -> broken assumption -> hard setting -> borrowed tool -> unavailable mechanism -> surrogate mechanism.\n\n## 3. Title Interpretation\n### Anchored Points\nAfter anchored points, interpret the title term by term and explain how each keyword maps to the actual method, setting, and claim scope.\n\n## 4. What Problem the Paper Really Solves\n### Anchored Points\nAfter anchored points, explain the direct problem, the practical pain point, the scientific question, and the larger pressure from the parent field.\n\n## 5. Scientific Problem Ladder\n### Anchored Points\nAfter anchored points, build the ladder explicitly from paper-local problem to broader AI or systems boundary, and note any upper-level bottlenecks introduced by the method itself.\n\n## 6. How the Authors May Have Found This Direction\n### Anchored Points\nAfter anchored points, reconstruct the likely dissatisfaction, near-transfer from neighboring methods, blocking constraint, and why the surrogate mechanism was worth trying. Keep uncertainty explicit.\n\n## 7. How the Authors Built the Story\n### Anchored Points\nAfter anchored points, map challenge -> failure mode -> design principle -> module -> ablation or evidence, and judge whether the story forms a coherent loop instead of a bag of modules.\n\n## 8. Related Work, Key Citations, and What Was Still Missing\n### Anchored Points\nAfter anchored points, explain what the key cited works solved, what they left open, and the narrative role of each citation cluster: field anchor, limitation evidence, method ancestor, baseline pressure, protocol justification, or contrast boundary.\n\n## 9. Main Idea\n### Anchored Points\nAfter anchored points, explain the conceptual replacement or coordination logic that makes the method coherent, rather than repeating only module names.\n\n## 10. Symbols, Assumptions, and Notation\n### Anchored Points\nAfter anchored points, introduce the important symbols, operators, assumptions, and task-specific objects before relying on them heavily later.\n\n## 11. Key Formulas and Equation-by-Equation Explanation\n### Anchored Points\nAfter anchored points, preserve the central formulas in readable math form. For each one, explain symbols, role, why this form was chosen, how it connects to adjacent modules, and what looks fragile, heuristic, or expensive.\n\n## 12. Theory / Proof / Practice Mapping\n### Anchored Points\nAfter anchored points, explain what is proved, why it is proved, what reviewer concern it addresses, how theory maps to implementation, and where theory and practice diverge.\n\n## 13. Algorithm or Module Walkthrough with Concrete Example\n### Anchored Points\nAfter anchored points, give a step-by-step pipeline walkthrough with at least one concrete mini-example that instantiates inputs, intermediate states, and outputs.\n\n## 14. Method Deep Reading: The Author-Thinking Behind Each Module\n### Anchored Points\nAfter anchored points, explain for each major module: the failure being fixed, the ideal but unavailable solution, the proxy signal actually used, the hidden assumption, the risk, and the future idea that appears if the assumption breaks.\n\n## 15. Figure Explanation\n### Anchored Points\nAfter anchored points, interpret the key figures or captions, explain what each figure is meant to demonstrate, and judge whether the visual evidence really supports the associated claim.\n\n## 16. Experimental Design\n### Anchored Points\nAfter anchored points, explain datasets, tasks, baselines, metrics, ablations, implementation details, and how the compared methods map back to the related-work landscape.\n\n## 17. Experiments as Story Evidence and Claim Alignment Audit\n### Anchored Points\nAfter anchored points, explain what claim each main result is supposed to support, what alternative explanation it rules out, and whether the evidence strongly, partially, or weakly supports the claim.\n\n## 18. Reviewer-Lens Audit\n### Anchored Points\nAfter anchored points, assess novelty, significance, soundness, rigor, reproducibility, clarity, missing controls, limitations honesty, and any OpenReview reviewer or rebuttal signal when available.\n\n## 19. Innovation Points and Claim-by-Claim Support Audit\n### Anchored Points\nAfter anchored points, list the paper's main contribution claims and judge whether each one is supported by theory, experiments, qualitative evidence, reviewer discussion, or only weak evidence.\n\n## 20. Story-Making Pattern Worth Learning\n### Anchored Points\nAfter anchored points, extract the reusable pattern from the paper, such as a replacement story, three-module story, closed loop, empty-cell positioning, or hidden-assumption break.\n\n## 21. Weaknesses and Limitations\n### Anchored Points\nAfter anchored points, discuss unresolved weaknesses, failure modes, scope limits, hidden costs, and where the current idea is likely to break.\n\n## 22. Innovation Type and Scientific-Boundary Judgment\n### Anchored Points\nAfter anchored points, judge whether the work is incremental, cross-pollinated, conceptually reframing, or potentially boundary-pushing, and explain why.\n\n## 23. Future Directions and Stronger Idea Paths\n### Anchored Points\nAfter anchored points, propose next-step ideas, stronger boundary directions, alternative modules, or more decisive experiments. Tie the best future ideas to hidden assumptions whose failure would break the current method.\n\n## 24. Vivid Plain-Language Story Summary\n### Anchored Points\nAfter anchored points, write a short memorable story that stays technically faithful while remaining accessible to a non-specialist.\n\n## 25. Exact Sources Used\n### Anchored Points\nAfter anchored points, list exactly which PDFs, LaTeX files, supplementary materials, OpenReview pages, or screenshots were used, and explicitly mention missing or ambiguous sources.\n\n---\n\n## Optional Structured Notes for `research_lens.json`\n\n### Research Equation\n- old success / paradigm:\n- broken assumption:\n- hard setting:\n- borrowed tool:\n- unavailable mechanism:\n- surrogate mechanism:\n\n### Challenge-to-Module Map\n\n| Challenge | Failure mode | Design principle | Module | Evidence |\n|---|---|---|---|---|\n\n### Module Lens Table\n\n| Module | Failure fixed | Ideal unavailable solution | Available proxy | Hidden assumption | Future research point |\n|---|---|---|---|---|---|\n\n### Citation Function Table\n\n| Citation cluster | Narrative function | Assumption inherited | How the paper modifies it |\n|---|---|---|---|\n\n### Story Pattern Worth Reusing\n- pattern name:\n- compact formula:\n- lesson:\n\n### Boundary-Pushing Idea List\n- hidden assumption:\n- what breaks:\n- next mechanism worth exploring:\n- linked claim ids:\n\n---\n\n# Appendix: Claim -> Evidence Index\n\nRender this appendix only after the main body is complete.\nUse `scripts/render_inline_trace_report.py` to append or refresh the detailed evidence appendix.\n\nFor each claim ID from the main report body, create a subsection like:\n\n## C<section>.<index>\n- Interpretation type:\n- Statement:\n- Research role:\n- Confidence:\n\n### Evidence 1\n- Source file:\n- Section path:\n- Lines:\n- Page:\n- Locator method:\n- Quote:\n- Excerpt window:\n- Notes:\n\nFile v1.1.3:templates/artifact_index.template.json\n\n{\n  \"schema_version\": \"1.1\",\n  \"paper_id\": \"<paper_id>\",\n  \"report\": \"report.md\",\n  \"traceability_manifest\": \"traceability_manifest.json\",\n  \"latex_paragraphs\": \"latex_paragraphs.json\",\n  \"research_lens\": \"research_lens.json\",\n  \"source_package\": \"<optional source package path>\",\n  \"pdfs\": {\n    \"main\": \"<optional main pdf path>\",\n    \"supplementary\": \"<optional supplementary pdf path>\"\n  },\n  \"notes\": \"Text-first bundle. Verify claims directly from report.md and source locators.\"\n}\n\nFile v1.1.3:templates/latex_paragraphs.template.json\n\n{\n  \"schema_version\": \"1.2.0\",\n  \"paper_id\": \"<paper-slug>\",\n  \"paragraphs\": [\n    {\n      \"paragraph_id\": \"P-sections-introduction-0001\",\n      \"source_path\": \"sections/introduction.tex\",\n      \"line_start\": 10,\n      \"line_end\": 18,\n      \"section_path\": [\"1 Introduction\"],\n      \"kind\": \"paragraph\",\n      \"text\": \"Sample paragraph text extracted from LaTeX.\"\n    }\n  ]\n}\n\nFile v1.1.3:templates/research_lens.template.json\n\n{\n  \"schema_version\": \"paper-research-lens/1.0\",\n  \"paper_id\": \"<paper-id>\",\n  \"research_equation\": {\n    \"one_sentence_thesis\": \"<A works under C, T breaks C, M needs Y, so the paper builds Z>\",\n    \"valuable_paradigm\": \"<old success>\",\n    \"broken_assumption\": \"<hidden assumption>\",\n    \"hard_setting\": \"<realistic constraint>\",\n    \"borrowed_tool\": \"<neighboring method>\",\n    \"unavailable_mechanism\": \"<missing Y>\",\n    \"surrogate_mechanism\": \"<replacement Z>\",\n    \"claim_ids\": [\"C2.1\", \"C6.1\"]\n  },\n  \"direction_reconstruction\": {\n    \"starting_dissatisfaction\": \"<likely starting dissatisfaction>\",\n    \"almost_worked_transfer\": \"<method that almost transferred>\",\n    \"blocking_constraint\": \"<why it still failed>\",\n    \"replacement_logic\": \"<how Y was replaced by Z>\",\n    \"claim_ids\": [\"C6.1\", \"C7.1\"]\n  },\n  \"challenge_module_map\": [\n    {\n      \"challenge\": \"<challenge>\",\n      \"failure_mode\": \"<failure mode>\",\n      \"design_principle\": \"<design principle>\",\n      \"module\": \"<module>\",\n      \"ablation_or_evidence\": \"<evidence>\",\n      \"claim_ids\": [\"C7.1\", \"C17.2\"]\n    }\n  ],\n  \"module_lenses\": [\n    {\n      \"module\": \"<module>\",\n      \"failure_fixed\": \"<failure fixed>\",\n      \"ideal_unavailable_solution\": \"<ideal unavailable solution>\",\n      \"available_proxy\": \"<available proxy>\",\n      \"hidden_assumption\": \"<hidden assumption>\",\n      \"future_direction\": \"<next idea if the assumption breaks>\",\n      \"claim_ids\": [\"C14.1\", \"C23.1\"]\n    }\n  ],\n  \"citation_logic\": [\n    {\n      \"citation_cluster\": \"<citation cluster>\",\n      \"narrative_function\": \"<field anchor / limitation / ancestor / baseline / contrast>\",\n      \"assumption_inherited\": \"<assumption from prior work>\",\n      \"paper_move\": \"<how this paper modifies it>\",\n      \"claim_ids\": [\"C8.1\"]\n    }\n  ],\n  \"story_patterns\": [\n    {\n      \"pattern_name\": \"<replacement story / closed loop / empty cell>\",\n      \"formula\": \"<compact formula>\",\n      \"lesson\": \"<reusable lesson>\",\n      \"claim_ids\": [\"C20.1\", \"C23.1\"]\n    }\n  ],\n  \"boundary_directions\": [\n    {\n      \"title\": \"<future direction>\",\n      \"hidden_assumption\": \"<assumption>\",\n      \"what_breaks\": \"<what fails if it breaks>\",\n      \"new_direction\": \"<new mechanism or setting>\",\n      \"claim_ids\": [\"C21.1\", \"C23.1\"]\n    }\n  ]\n}\n\nFile v1.1.3:templates/traceability_manifest.template.json\n\n{\n  \"schema_version\": \"1.3.0\",\n  \"paper_id\": \"<paper-slug>\",\n  \"claims\": [\n    {\n      \"claim_id\": \"C5.2\",\n      \"section_id\": \"5\",\n      \"report_anchor\": \"## 5. Scientific Problem Ladder\",\n      \"statement\": \"The paper turns representation drift under heterogeneous clients into an explicit design target.\",\n      \"interpretation_type\": \"evidence-backed interpretation\",\n      \"research_role\": \"problem framing\",\n      \"confidence\": \"high\",\n      \"evidences\": [\n        {\n          \"evidence_id\": \"E5.2.a\",\n          \"source_kind\": \"latex_paragraph\",\n          \"source_file\": \"sections/introduction.tex\",\n          \"paragraph_id\": \"P-sections-introduction-0008\",\n          \"line_start\": 41,\n          \"line_end\": 56,\n          \"locator_method\": \"synctex_preferred\",\n          \"quote_text\": \"representation drift across heterogeneous clients\",\n          \"synctex\": {\n            \"pdf\": \"paper.pdf\",\n            \"page\": 2,\n            \"bbox\": [76, 145, 480, 238]\n          },\n          \"notes\": \"Gap statement in introduction.\"\n        }\n      ]\n    }\n  ]\n}\n\nFile v1.1.3:agents/openai.yaml\n\ninterface:\r\n  display_name: \"Paper Deep Reading\"\r\n  short_description: \"Deep single-file paper reading for ClawHub.\"\r\n  brand_color: \"#2563EB\"\r\n  default_prompt: \"Deep-read this paper, produce a rich narrative report.md, keep main-body claims anchored with claim IDs, move detailed evidence into the final Claim -> Evidence Index appendix, emit traceability_manifest.json, latex_paragraphs.json, artifact_index.json, and research_lens.json, and match the report language to the user request language.\"\n\nFile v1.1.3:LICENSE.txt\n\nMIT No Attribution\n\nCopyright 2026 paper-deep-reading contributors\n\nPermission is hereby granted, free of charge, to any person obtaining a copy of\nthis software and associated documentation files (the \"Software\"), to deal in\nthe Software without restriction, including without limitation the rights to\nuse, copy, modify, merge, publish, distribute, sublicense, and/or sell copies\nof the Software, and to permit persons to whom the Software is furnished to do\nso.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n\nArchive v1.1.2: 15 files, 14347 bytes\n\nFiles: agents/openai.yaml (397b), CHANGELOG.md (305b), README.md (938b), references/artifact_contract.md (1383b), references/synctex_locator_notes.md (824b), requirements.txt (26b), scripts/extract_latex_paragraphs.py (5648b), scripts/render_inline_trace_report.py (3438b), scripts/validate_traceability.py (5547b), SKILL.md (7039b), templates/artifact_index.template.json (446b), templates/latex_paragraphs.template.json (376b), templates/report_template.md (1112b), templates/traceability_manifest.template.json (1654b), _meta.json (137b)\n\nFile v1.1.2:SKILL.md\n\n---\nname: paper-deep-reading-source-aware\ndescription: Produce a traceable deep-reading report for a research paper, with inline paragraph locators after every claim, plus report.md, traceability_manifest.json, latex_paragraphs.json, and artifact_index.json.\nversion: 1.2.2\nmetadata: {\"openclaw\":{\"emoji\":\"📘\"}}\n---\n\n# Paper Deep Reading — Source-Aware + Formula-First Single-File Report Pipeline\n\nUse this skill when the user wants a **deep, paper-grounded, auditable reading report** for one computer-science paper or a small paper batch.\n\nThe input may be:\n\n- a user-provided PDF\n- a user-provided LaTeX source tree or `.tex` files\n- only the paper title or citation-like paper name\n\nThe default output is **text-first and audit-first**.  \nThis version intentionally **does not rely on a webpage reader**.\n\n## 1) Core deliverables\n\n1. **Human-readable report**\n   - `report.md`\n\n2. **Machine-readable trace artifacts**\n   - `traceability_manifest.json`\n   - `latex_paragraphs.json`\n   - `artifact_index.json`\n\n## 2) Key change in 1.2.1\n\nThe report itself is now the primary verification surface.\n\nEvery important claim in `report.md` must:\n\n- have a stable claim id such as `C5.2`\n- have an interpretation label:\n  - `evidence-backed interpretation`\n  - `plausible inference`\n  - `speculation`\n- be followed immediately by one or more **inline original-paragraph locators**\n\n### Required inline locator format\n\nAfter each claim bullet, add nested bullets such as:\n\n- `[C5.2][evidence-backed interpretation] <claim text>`\n  - `原文定位 1：main.tex → Methodology > Neighborhood Pseudo-Labeling，行 343–349；从“<start excerpt>”到“<end excerpt>”。`\n  - `原文定位 2：supplementary.tex → Experimental Setup，行 262–266；从“<start excerpt>”到“<end excerpt>”。`\n\nThe inline locator must make it easy for a human reader to verify the claim directly from LaTeX or PDF.\n\n\n\n## 2.1) Formula-first strengthening in 1.2.2\n\nThis version restores the formula-preservation bar expected by the original deep-reading skill.\n\nWhen the paper contains key formulas, the report must **not** compress them into prose-only summaries.\n\nFor each central equation or objective, the report must explicitly include:\n\n1. the equation itself in readable math form\n2. symbol-by-symbol explanation\n3. what optimization / estimation / filtering role it plays\n4. why the authors likely wrote it in this form instead of a nearby alternative\n5. how it connects to the previous and next module\n6. what may be brittle, heuristic, under-justified, or computationally expensive about it\n\nIf the user requests a **single Markdown file**, the preferred format is:\n\n- main report in the front\n- a consolidated **claim → evidence index** at the end\n\nDo not weaken equation detail for the sake of shorter presentation.\n\n## 2.2) Single-file report mode\n\nWhen the user explicitly says:\n\n- no webpage\n- one markdown file only\n- evidence can go at the end\n\nthen produce one authoritative `.md` file whose body is easy to read continuously, and whose final appendix contains the locator index for all major claim ids.\n\n\n## 3) Source acquisition policy\n\nAlways assemble the **best available evidence package** before writing.\n\nPreferred reading order:\n\n1. **arXiv LaTeX/source package**\n2. **user-provided LaTeX**\n3. **best available PDF**\n4. **supplementary material**\n5. **OpenReview thread / rebuttal / meta-review when relevant**\n\n### 3.1 When LaTeX is available\n\nTreat LaTeX as the primary structural source.\n\nUse PDF only as a visual and pagination aid for:\n\n- figure interpretation\n- table reading\n- page-local narrative flow\n- page anchors\n\n### 3.2 When only PDF is available\n\nDo not stop at PDF summarization immediately.\n\nFirst check whether the same paper has a matching arXiv LaTeX/source package.  \nIf it exists and matches the same paper, switch to **LaTeX-primary + PDF-assisted** reading.\n\nIf not, continue with the PDF and say explicitly that the reading is **PDF-primary**.\n\n### 3.3 When only title is available\n\nSearch for the paper and collect:\n\n1. arXiv source package if available\n2. the best PDF\n3. supplementary PDF or appendix if available\n4. OpenReview forum if venue is ICLR or otherwise OpenReview-hosted\n\nNever silently analyze the wrong paper. Disambiguate by title, authors, abstract, year, and method keywords.\n\n## 4) Mandatory artifacts\n\n### 4.1 `report.md`\n\nThe report must cover, whenever the evidence supports it:\n\n1. paper identification and source package used\n2. title interpretation\n3. what problem the paper really solves\n4. scientific problem ladder\n5. related-work gap audit\n6. main idea\n7. likely author reasoning path\n8. symbols, assumptions, and notation\n9. key formulas and equation-by-equation explanation (formula preserved, term-by-term explained, critiqued, and linked to adjacent modules)\n10. theory / proof / practice mapping\n11. algorithm or module walkthrough with concrete example\n12. figure explanation\n13. experimental design\n14. table / chart / claim alignment audit\n15. reviewer-lens audit\n16. innovation points and claim-by-claim support audit\n17. weaknesses and limitations\n18. innovation type and scientific-boundary judgment\n19. future directions\n20. vivid plain-language story summary\n21. exact sources used\n\n### 4.2 `traceability_manifest.json`\n\nThis is the claim-to-evidence map.\n\nRules:\n\n- every claim id in the report must appear in the manifest\n- one bullet must not hide multiple independent claims under one id\n- if a claim depends on multiple paragraphs / equations / tables / appendix passages, list them separately\n- each claim entry should also include a human-friendly locator summary when possible\n\n### 4.3 `latex_paragraphs.json`\n\nThis is the stable LaTeX anchor index.\n\nEach entry must keep:\n\n- `paragraph_id`\n- `source_path`\n- `line_start`\n- `line_end`\n- `section_path`\n- `kind`\n- `text`\n\n### 4.4 `artifact_index.json`\n\nA compact index for the generated text-first bundle.\n\nIt should list the locations of:\n\n- `report.md`\n- `traceability_manifest.json`\n- `latex_paragraphs.json`\n- main PDF if any\n- supplementary PDF if any\n- source package path if known\n\n## 5) Claim discipline\n\n### 5.1 Claim ids\n\nUse stable section-local ids such as:\n\n- `C3.1`\n- `C5.2`\n- `C14.4`\n\n### 5.2 Claim splitting rule\n\nDo not hide multiple judgments in one claim bullet.\n\n### 5.3 Evidence completeness rule\n\nList all materially relevant evidence for a claim, not just one convenient paragraph.\n\n### 5.4 Interpretation labels\n\nEach claim must declare exactly one of:\n\n- `evidence-backed interpretation`\n- `plausible inference`\n- `speculation`\n\n## 6) Writing style for verification\n\nPrefer a report that is pleasant to read **and** easy to audit.\n\nFor every claim, the user should be able to answer three questions immediately:\n\n1. Which source file supports this?\n2. Which section or subsection is it in?\n3. From which paragraph span or line span should I start checking?\n\nThis skill is successful only if the user can verify the report without needing a separate webpage reader.\n\nFile v1.1.2:README.md\n\n# paper-deep-reading-openclaw-source-aware-skill v1.2.2\n\nA formula-first, source-aware paper deep-reading skill for OpenClaw / ClawHub style packaging.\n\n## What changed in 1.2.2\n\n- restored a stronger **formula-preservation** requirement\n- supports a **single Markdown report** as the default final reading surface\n- allows all evidence locators to be grouped in a **final appendix**\n- requires each core equation to be explained at four levels:\n  - what the symbols mean\n  - what the equation is doing\n  - why the authors likely chose this form\n  - what the weaknesses / alternatives are\n\n## Default outputs\n\n- `report.md`\n- `traceability_manifest.json`\n- `latex_paragraphs.json`\n- `artifact_index.json`\n\n## Preferred use\n\nUse this skill when the user wants:\n\n- a traceable deep-reading report\n- no webpage reader\n- equation-level explanation that does not collapse into short prose\n- a final appendix for claim-to-evidence verification\n\nFile v1.1.2:_meta.json\n\n{\n  \"ownerId\": \"kn7fxns1xpr6z67w885my7d7k98506vv\",\n  \"slug\": \"paper-deep-reading\",\n  \"version\": \"1.1.2\",\n  \"publishedAt\": 1776697862940\n}\n\nFile v1.1.2:references/artifact_contract.md\n\n# Artifact Contract\n\n## `artifact_index.json`\nTop-level index for all outputs that belong to one paper reading bundle.\n\nRequired keys:\n\n- `schema_version`\n- `paper_id`\n- `report`\n- `traceability_manifest`\n- `latex_paragraphs`\n\nOptional keys:\n\n- `source_package`\n- `pdfs`\n- `notes`\n\n## `traceability_manifest.json`\nMaps report claims to source evidence.\n\nEach claim entry should include:\n\n- `claim_id`\n- `section_id`\n- `report_anchor`\n- `statement`\n- `interpretation_type`\n- `confidence`\n- `evidences`\n\nRecommended extra field:\n\n- `human_locators`\n\nEach evidence entry may include:\n\n- `evidence_id`\n- `source_kind`\n- `source_file`\n- `paragraph_id`\n- `page`\n- `line_start`\n- `line_end`\n- `locator_method`\n- `synctex`\n- `quote_text`\n- `notes`\n\n## `latex_paragraphs.json`\nStable anchor list extracted from LaTeX.\n\nEach paragraph entry should include:\n\n- `paragraph_id`\n- `source_path`\n- `line_start`\n- `line_end`\n- `section_path`\n- `kind`\n- `text`\n\n## Report requirement\n\nIn `report.md`, every claim bullet must be followed by one or more nested `原文定位` bullets that tell the reader:\n\n- which source file to open\n- which section / subsection to inspect\n- which line span to inspect\n- roughly from which excerpt to which excerpt the relevant paragraph runs\n\n## Claim typing\nAllowed interpretation labels:\n\n- `evidence-backed interpretation`\n- `plausible inference`\n- `speculation`\n\nFile v1.1.2:references/synctex_locator_notes.md\n\n# SyncTeX Locator Notes\n\nThis bundle does not require SyncTeX for every run, but the reader and artifact contract are designed to use it whenever available.\n\n## Recommended workflow\n\n1. Compile the paper with SyncTeX enabled, for example:\n   - `latexmk -pdf -synctex=1 main.tex`\n2. Keep:\n   - the compiled PDF\n   - the generated `.synctex.gz`\n3. Preserve `source_path`, `line_start`, and `line_end` in `latex_paragraphs.json`\n4. During bundle enrichment, convert line anchors to PDF page / bbox coordinates\n5. Store the result under each evidence item, for example:\n\n```json\n\"synctex\": {\n  \"pdf\": \"paper.pdf\",\n  \"page\": 3,\n  \"bbox\": [70, 120, 480, 170]\n}\n```\n\n## Localization priority\n\n1. explicit SyncTeX page + bbox\n2. explicit PDF page + bbox already stored in manifest\n3. source path + line span\n4. text-search fallback\n\nFile v1.1.2:CHANGELOG.md\n\n# Changelog\n\n## 1.2.2\n- strengthen formula-preservation and equation-by-equation explanation\n- add single-file markdown mode with end-of-report evidence appendix\n- explicitly forbid over-compressing core formulas into short prose summaries\n\n## 1.2.1\n- inline trace report and text-first verification mode\n\nFile v1.1.2:templates/report_template.md\n\n# Deep Reading Report: <paper-title>\n\n## 1. 论文信息\n## 2. 论文标题解读\n## 3. 这篇论文真正解决的是什么\n## 4. 论文中提到的其他论文做了什么、留下了什么空白、与本文是什么关系\n## 5. 核心方法到底在干什么\n## 6. 公式保留与逐式解释\n> 对每个核心公式，至少写清楚：\n> - 公式本体\n> - 符号解释\n> - 这条公式在方法链路中的作用\n> - 为什么作者会这样写\n> - 可能的问题、脆弱性与替代方案\n\n## 7. 理论、证明与实现步骤对照\n## 8. 具体公式、模块与设计假设的不足及可改进空间\n## 9. 创新点、核心主张与证据逐条核对\n## 10. 这篇论文为什么重要 / 为什么值得被接收\n## 11. 实验是如何被设计出来的\n## 12. 倒推作者怎么想到这个 idea\n## 13. 审稿人最关注什么\n## 14. 额外审稿视角审计\n## 15. 强点 / 弱点 / 不足\n## 16. 创新类型判断\n## 17. 对选题的直接启示\n## 18. 可能的新研究方向或新创新点\n## 19. 最后一段通俗故事总结\n## 20. 参考来源\n\n---\n\n# 附录：claim → evidence 索引\n\nFile v1.1.2:templates/artifact_index.template.json\n\n{\n  \"schema_version\": \"1.0\",\n  \"paper_id\": \"<paper_id>\",\n  \"report\": \"report.md\",\n  \"traceability_manifest\": \"traceability_manifest.json\",\n  \"latex_paragraphs\": \"latex_paragraphs.json\",\n  \"source_package\": \"<optional source package path>\",\n  \"pdfs\": {\n    \"main\": \"<optional main pdf path>\",\n    \"supplementary\": \"<optional supplementary pdf path>\"\n  },\n  \"notes\": \"Text-first bundle. Verify claims directly from report.md and source locators.\"\n}\n\nFile v1.1.2:templates/latex_paragraphs.template.json\n\n{\n  \"schema_version\": \"1.2.0\",\n  \"paper_id\": \"<paper-slug>\",\n  \"paragraphs\": [\n    {\n      \"paragraph_id\": \"P-sections-introduction-0001\",\n      \"source_path\": \"sections/introduction.tex\",\n      \"line_start\": 10,\n      \"line_end\": 18,\n      \"section_path\": [\"1 Introduction\"],\n      \"kind\": \"paragraph\",\n      \"text\": \"Sample paragraph text extracted from LaTeX.\"\n    }\n  ]\n}\n\nFile v1.1.2:templates/traceability_manifest.template.json\n\n{\n  \"schema_version\": \"1.2.0\",\n  \"paper_id\": \"<paper-slug>\",\n  \"claims\": [\n    {\n      \"claim_id\": \"C5.2\",\n      \"section_id\": \"5\",\n      \"report_anchor\": \"## 5. Related Work and What Was Still Missing\",\n      \"statement\": \"The paper moves beyond prior personalized FL baselines by explicitly targeting representation drift across heterogeneous clients.\",\n      \"interpretation_type\": \"evidence-backed interpretation\",\n      \"confidence\": \"high\",\n      \"evidences\": [\n        {\n          \"evidence_id\": \"E5.2.a\",\n          \"source_kind\": \"latex_paragraph\",\n          \"source_file\": \"sections/introduction.tex\",\n          \"paragraph_id\": \"P-sections-introduction-0008\",\n          \"line_start\": 41,\n          \"line_end\": 56,\n          \"locator_method\": \"synctex_preferred\",\n          \"quote_text\": \"representation drift across heterogeneous clients\",\n          \"synctex\": {\n            \"pdf\": \"paper.pdf\",\n            \"page\": 2,\n            \"bbox\": [76, 145, 480, 238]\n          },\n          \"notes\": \"Gap statement in introduction.\"\n        },\n        {\n          \"evidence_id\": \"E5.2.b\",\n          \"source_kind\": \"figure_caption\",\n          \"source_file\": \"sections/method.tex\",\n          \"paragraph_id\": \"P-sections-method-0014\",\n          \"line_start\": 98,\n          \"line_end\": 105,\n          \"locator_method\": \"synctex_preferred\",\n          \"quote_text\": \"representation drift across heterogeneous clients\",\n          \"synctex\": {\n            \"pdf\": \"paper.pdf\",\n            \"page\": 3,\n            \"bbox\": [70, 510, 500, 565]\n          },\n          \"notes\": \"Figure caption describing the cross-client drift mechanism.\"\n        }\n      ]\n    }\n  ]\n}\n\nFile v1.1.2:agents/openai.yaml\n\ninterface:\n  display_name: \"Paper Deep Reading (Traceable)\"\n  short_description: \"Generate report.md plus traceable evidence artifacts and reader-ready bundles.\"\n  brand_color: \"#2563EB\"\n  default_prompt: \"Deep-read this paper and produce report.md, reader_artifacts.json, traceability_manifest.json, and latex_paragraphs.json.\"\npolicy:\n  allow_implicit_invocation: true\ndependencies:\n  tools: []\n\nFile v1.1.2:requirements.txt\n\nmarkdown>=3.6\npyyaml>=6.0\n\nArchive v1.1.1: 3 files, 6612 bytes\n\nFiles: SKILL.md (13602b), templates/report_template.md (991b), _meta.json (137b)\n\nFile v1.1.1:SKILL.md\n\n---\nname: paper-deep-reading-source-aware\ndescription: Deeply read a computer-science paper from a user-provided PDF, paper title, or LaTeX source. Prefer arXiv LaTeX when available, use OpenReview reviews and rebuttals for ICLR papers, produce a detailed Markdown report, and optionally generate a cartoon storyboard when an image API is available.\nversion: 1.1.0\nmetadata:\n  openclaw:\n    emoji: \"📘\"\n---\n\n# Paper Deep Reading — Source-Aware Standalone Skill\n\nUse this skill when the user wants a **deep, paper-grounded reading report** for one computer-science paper or a small paper batch, starting from any of these inputs:\n\n- a user-provided PDF\n- a user-provided LaTeX source tree or `.tex` files\n- only the paper title or citation-like paper name\n\nThe primary deliverable is a **detailed Markdown report**.\nA secondary, optional deliverable is a **small sequence of connected cartoon images** that narrate the author’s idea, but only when an image-generation API or tool is available in the runtime and the user has not asked to suppress images.\n\n## Scope\n\nThis is a **standalone** skill.\nDo **not** assume any upstream collection stage, bundle manifest, graph stage, canvas stage, spreadsheet stage, or downstream workflow.\nWork directly from the paper materials currently available in the workspace, conversation, or fetchable from the web with the tools already available in the runtime.\n\n## Core source-acquisition policy\n\nAlways try to assemble the **best available reading package** before writing the report.\nThe preferred evidence order is:\n\n1. **LaTeX source from arXiv**, if available and relevant to the same paper version\n2. **User-provided LaTeX source**\n3. **User-provided PDF**\n4. **Official paper PDF from arXiv, OpenReview, proceedings, or author page**\n5. **Supplementary material, appendices, review threads, and rebuttals**\n\n### A. When the user provides LaTeX\n\nUse the provided LaTeX as the primary source.\nAlso use the compiled PDF if available, because figures, layout, and page-local argument flow are often easier to interpret in PDF form.\n\n### B. When the user provides a PDF but not LaTeX\n\nTreat the PDF as the initial source, but first check whether the same paper has an **arXiv source / LaTeX package** available.\nIf yes, prefer the arXiv LaTeX as the primary structural source and keep the PDF as a visual and pagination reference.\nIf no matching arXiv LaTeX is available, continue with the PDF and explicitly say that the analysis is PDF-primary.\n\n### C. When the user provides only the paper title or a citation-like name\n\nSearch for the paper.\nTry to obtain:\n\n1. arXiv LaTeX/source package first\n2. if no LaTeX is available, the best paper PDF\n3. supplementary material if relevant\n4. OpenReview thread if the venue is ICLR\n\nWhen title matching is ambiguous, use authors, year, venue, abstract snippets, or method keywords to disambiguate.\nDo not silently analyze the wrong paper.\n\n### D. Matching discipline\n\nWhen switching from a PDF or title to an arXiv source package, verify that the source corresponds to the same paper by checking as many of the following as possible:\n\n- exact or near-exact title\n- author list\n- abstract\n- venue / year / version notes\n- core method names\n- section structure\n\nIf there is a mismatch or uncertainty, say so explicitly and choose the most reliable source set.\n\n## ICLR / OpenReview policy\n\nIf the target paper is an **ICLR paper**, try to retrieve the **same-year OpenReview submission page**.\nUse it to collect, when available:\n\n- reviewer comments\n- meta-review or area-chair summary\n- author rebuttal / response\n- revision signals relevant to acceptance\n\nUse these materials to enrich the deep reading report, especially for:\n\n- what reviewers found convincing or weak\n- which claims were challenged\n- whether the rebuttal resolved those concerns\n- how the review discussion changes confidence in the paper’s claims\n\nIf the OpenReview thread cannot be found, state that clearly and continue with the best grounded report possible.\n\n## Output policy\n\nGenerate a **Markdown report** as the primary output.\nDo **not** create JSON, YAML, spreadsheets, slides, canvases, code files, manifests, or graph bundles as separate artifacts.\nIf structure is useful, keep it **inside the Markdown report** using sections, subsections, tables, blockquotes, and fenced code blocks.\n\n### Optional storyboard output\n\nIf an image-generation API or tool is available in the runtime, and the user has not opted out, generate a **small sequence of connected cartoon-style storyboard images** after the report.\nThe storyboard should:\n\n- narrate the author’s main idea step by step\n- use recurring characters, objects, or visual metaphors across frames\n- stay faithful to the report’s explanation\n- simplify without distorting the method\n- avoid adding scientific claims not supported by the paper\n\nWhen no image-generation capability is available, do not fail the task. Instead, include a short Markdown storyboard prompt set that could be used later.\n\n## Language policy\n\nWrite the **skill instructions, internal prompts, and default report headings in English**.\nDefault to **English** for the report unless the user explicitly requests another language.\n\n## Style policy\n\nStay close to the actual paper.\nDo **not** drift into generic commentary.\nName the actual modules, formulas, assumptions, theorem objects, datasets, baselines, figures, captions, tables, empirical observations, and reviewer comments used in the paper.\nDo not be overly brief.\nKeep the report specific, evidence-backed, and somewhat concrete with paper-local details.\nWhen inferring the author’s likely intentions or subjective judgments, distinguish clearly between:\n\n- evidence-backed interpretation\n- plausible inference\n- speculation\n\n## Mandatory report requirements\n\nThe report must explicitly cover the following whenever the available materials support it.\n\n### 1. Paper identification and source package used\n\nReport:\n\n- title\n- authors if available\n- venue / year / status if available\n- whether the reading was LaTeX-primary, PDF-primary, or mixed-source\n- what sources were actually used\n- whether arXiv LaTeX was searched for and whether it was found\n- whether OpenReview materials were used\n\n### 2. Title interpretation\n\nInterpret the title term by term.\nExplain what each keyword means, why the title is phrased that way, and how the title maps to the actual method, setting, and claims.\n\n### 3. What problem the paper really solves\n\nExplain:\n\n- the direct paper-level problem\n- the practical pain point\n- the scientific question behind the method\n- the upper multi-layer problem ladder\n\nPrefer a continuous ladder such as:\n\n- direction-native problem\n- parent-field problem\n- broader AI / ML problem\n\nAlso discuss upper problems suggested by:\n\n- borrowed algorithm families\n- bottlenecks introduced by the proposed method itself\n\n### 4. Related work and cited-paper expansion\n\nDo not only list cited papers.\nFor the key papers repeatedly discussed by the target paper, explain:\n\n- what they solved\n- what they still left open\n- why the current paper needed to move beyond them\n- how each one relates to the current paper\n  - inherited\n  - contrasted\n  - generalized\n  - specialized\n  - hybridized\n  - problem-shifted\n\n### 5. Main idea and likely author reasoning path\n\nExplain the core idea in paper-grounded terms.\nThen reconstruct the likely reasoning path that led the authors from observed pain points and prior work to the final design.\nWhen appropriate, discuss whether parts of the idea, theory choice, proof strategy, algorithm, or modules appear connected to the authors’ subjective judgments, research taste, heuristics, engineering preferences, or broader research style.\n\n### 6. Symbols, concepts, and notation\n\nIntroduce important symbols, operators, assumptions, and problem-specific concepts before heavily relying on them.\nExplain them in beginner-friendly language while remaining faithful to the paper.\n\n### 7. Formula preservation and explanation\n\nDo **not** omit key equations.\nPreserve and explain the important:\n\n- objective functions\n- update rules\n- constraints\n- estimators\n- bounds\n- theorem statements\n\nFor each key formula, explain:\n\n- what each symbol means\n- why the formula is introduced\n- what role it plays in the method\n- which algorithm step or system behavior it corresponds to\n- whether the formula itself appears limited, heuristic, fragile, or improvable\n\n### 8. Theory, proof, and practice mapping\n\nIf the paper contains theory or proofs, explain:\n\n- what is being proved\n- why the authors chose to prove it\n- what scientific or reviewer concern the proof addresses\n- what practical meaning the theorem has\n\nThen map theory to practice:\n\n- theorem assumptions -> implementation assumptions\n- proved objects -> implemented objects\n- proof conclusions -> expected practical behavior\n\nJudge whether theory and implementation are:\n\n- exactly aligned\n- approximately aligned\n- only loosely connected\n\nAlso explain where theory stops being faithful to the actual implementation and whether that gap seems acceptable.\n\n### 9. Algorithm or module walkthrough with concrete examples\n\nDo not stop at equations.\nGive a step-by-step explanation of the algorithm or module pipeline.\nWhenever possible, include at least one concrete mini-example that instantiates:\n\n- inputs\n- states\n- intermediate quantities\n- outputs\n- updates\n\n### 10. Fine-grained critique of formulas, modules, and assumptions\n\nDo not discuss only overall limitations.\nEvaluate specific formulas, modules, and assumptions.\nFor central design elements, ask whether they are:\n\n- brittle\n- under-justified\n- overly heuristic\n- computationally expensive\n- hard to optimize\n- weakly identified\n- mismatched to the claimed scientific goal\n\nThen discuss:\n\n- possible improvements\n- alternative formulations\n- likely trade-offs\n\n### 11. Figures from both PDF and LaTeX\n\nFor **PDF papers**, explicitly interpret key figures instead of merely summarizing them.\nFor **LaTeX sources**, also reconstruct and explain important figures from figure environments, captions, labels, referenced text, and included image paths when possible.\n\nFor each important figure, explain:\n\n- what the figure is trying to show\n- how to read it\n- what claim it supports\n- whether the figure really supports that claim\n- whether anything in the visual presentation is unclear, weak, or potentially misleading\n\n### 12. Experimental design\n\nExplain:\n\n- datasets\n- tasks\n- baselines\n- metrics\n- ablations\n- implementation details when available\n\nAlso connect the compared methods back to the related-work landscape in the introduction and related-work sections.\n\n### 13. Table / chart / claim alignment audit\n\nFor each important table, plot, or result block, explain:\n\n- what question it is answering\n- what claim it is supposed to support\n- whether it strongly supports, partially supports, or fails to support that claim\n- whether there is any tension or inconsistency between results and claims\n- plausible reasons for the mismatch, if any\n\n### 14. Reviewer-lens audit\n\nInclude an explicit reviewer-style audit that comments on:\n\n- novelty\n- significance\n- technical soundness\n- methodology rigor\n- reproducibility\n- clarity of figures and tables\n- results-claims alignment\n- missing baselines or controls\n- honesty about limitations\n\nIf ICLR OpenReview material is available, integrate reviewer concerns and author responses into this audit.\n\n### 15. Innovation points and claim-by-claim support audit\n\nList the paper’s main claimed contributions and judge, for each one, whether it is supported by:\n\n- theory\n- experiments\n- qualitative evidence\n- reviewer discussion\n- only weak evidence\n\n### 16. Weaknesses, limitations, and improvement room\n\nDiscuss:\n\n- unresolved weaknesses\n- failure modes\n- scope limits\n- strong assumptions\n- hidden costs\n- where the idea might break\n\n### 17. Innovation type and boundary judgment\n\nJudge whether the paper is mainly:\n\n- incremental\n- cross-pollinated\n- conceptually reframing\n- potentially boundary-pushing\n\nExplain why.\nAlso discuss whether it actually crosses subfield or disciplinary boundaries, or mainly recombines known ideas inside the same lane.\n\n### 18. Future directions\n\nPropose future directions inspired by the paper, including:\n\n- native next-step ideas\n- cross-domain transfers\n- stronger scientific-boundary directions\n- alternative formulations or modules\n- more decisive experiments\n\n### 19. Simple vivid story summary\n\nEnd with a simple, vivid, technically faithful story that helps a non-specialist remember the paper’s core idea.\n\n### 20. Sources used\n\nEnd with a short source list stating exactly which materials were used, such as:\n\n- user PDF\n- arXiv source package\n- paper PDF\n- supplementary PDF\n- OpenReview thread\n- author rebuttal\n- screenshots\n\n## Optional final step: storyboard generation\n\nAfter the Markdown report is finished, check whether image generation is available.\n\n- If yes, create a concise storyboard plan with 4–8 sequential panels and then generate the cartoon-style images.\n- If no, provide only the storyboard plan and prompts in Markdown.\n\nThe storyboard should stay synchronized with the report’s explanation of:\n\n- the original pain point\n- the key intuition\n- the core mechanism\n- the training or inference flow\n- the main empirical takeaway\n\n## Failure handling\n\nIf some sources cannot be found, do not abort.\nState clearly what was attempted, what was found, what was missing, and how that affects confidence.\nThen continue with the best grounded report possible.\n\nFile v1.1.1:_meta.json\n\n{\n  \"ownerId\": \"kn7fxns1xpr6z67w885my7d7k98506vv\",\n  \"slug\": \"paper-deep-reading\",\n  \"version\": \"1.1.1\",\n  \"publishedAt\": 1776448001941\n}\n\nFile v1.1.1:templates/report_template.md\n\n# Deep Reading Report: <Paper Title>\n\n## 1. Paper Identification and Source Package Used\n## 2. Title Interpretation\n## 3. What Problem the Paper Really Solves\n## 4. Scientific Problem Ladder\n## 5. Related Work and What Was Still Missing\n## 6. Main Idea\n## 7. Likely Author Reasoning Path\n## 8. Symbols, Concepts, and Notation\n## 9. Key Formulas and Equation-by-Equation Explanation\n## 10. Theory, Proof, and Practice Mapping\n## 11. Algorithm / Module Walkthrough with Concrete Example\n## 12. Figure Explanations (PDF and/or LaTeX)\n## 13. Experimental Design\n## 14. Tables, Charts, and Claim Alignment Audit\n## 15. Reviewer-Lens Audit\n## 16. Innovation Points and Claim-by-Claim Support Audit\n## 17. Weaknesses, Limitations, and Improvement Room\n## 18. Innovation Type and Boundary Judgment\n## 19. Future Directions\n## 20. Simple Vivid Story Summary\n## 21. Sources Used\n\n---\n\n## Optional Storyboard Plan (Only if image generation is available)\n### Panel 1\n### Panel 2\n### Panel 3\n### Panel 4\n\nArchive v1.1.0: 3 files, 6611 bytes\n\nFiles: SKILL.md (13602b), templates/report_template.md (991b), _meta.json (137b)\n\nFile v1.1.0:SKILL.md\n\n---\nname: paper-deep-reading-source-aware\ndescription: Deeply read a computer-science paper from a user-provided PDF, paper title, or LaTeX source. Prefer arXiv LaTeX when available, use OpenReview reviews and rebuttals for ICLR papers, produce a detailed Markdown report, and optionally generate a cartoon storyboard when an image API is available.\nversion: 1.1.0\nmetadata:\n  openclaw:\n    emoji: \"📘\"\n---\n\n# Paper Deep Reading — Source-Aware Standalone Skill\n\nUse this skill when the user wants a **deep, paper-grounded reading report** for one computer-science paper or a small paper batch, starting from any of these inputs:\n\n- a user-provided PDF\n- a user-provided LaTeX source tree or `.tex` files\n- only the paper title or citation-like paper name\n\nThe primary deliverable is a **detailed Markdown report**.\nA secondary, optional deliverable is a **small sequence of connected cartoon images** that narrate the author’s idea, but only when an image-generation API or tool is available in the runtime and the user has not asked to suppress images.\n\n## Scope\n\nThis is a **standalone** skill.\nDo **not** assume any upstream collection stage, bundle manifest, graph stage, canvas stage, spreadsheet stage, or downstream workflow.\nWork directly from the paper materials currently available in the workspace, conversation, or fetchable from the web with the tools already available in the runtime.\n\n## Core source-acquisition policy\n\nAlways try to assemble the **best available reading package** before writing the report.\nThe preferred evidence order is:\n\n1. **LaTeX source from arXiv**, if available and relevant to the same paper version\n2. **User-provided LaTeX source**\n3. **User-provided PDF**\n4. **Official paper PDF from arXiv, OpenReview, proceedings, or author page**\n5. **Supplementary material, appendices, review threads, and rebuttals**\n\n### A. When the user provides LaTeX\n\nUse the provided LaTeX as the primary source.\nAlso use the compiled PDF if available, because figures, layout, and page-local argument flow are often easier to interpret in PDF form.\n\n### B. When the user provides a PDF but not LaTeX\n\nTreat the PDF as the initial source, but first check whether the same paper has an **arXiv source / LaTeX package** available.\nIf yes, prefer the arXiv LaTeX as the primary structural source and keep the PDF as a visual and pagination reference.\nIf no matching arXiv LaTeX is available, continue with the PDF and explicitly say that the analysis is PDF-primary.\n\n### C. When the user provides only the paper title or a citation-like name\n\nSearch for the paper.\nTry to obtain:\n\n1. arXiv LaTeX/source package first\n2. if no LaTeX is available, the best paper PDF\n3. supplementary material if relevant\n4. OpenReview thread if the venue is ICLR\n\nWhen title matching is ambiguous, use authors, year, venue, abstract snippets, or method keywords to disambiguate.\nDo not silently analyze the wrong paper.\n\n### D. Matching discipline\n\nWhen switching from a PDF or title to an arXiv source package, verify that the source corresponds to the same paper by checking as many of the following as possible:\n\n- exact or near-exact title\n- author list\n- abstract\n- venue / year / version notes\n- core method names\n- section structure\n\nIf there is a mismatch or uncertainty, say so explicitly and choose the most reliable source set.\n\n## ICLR / OpenReview policy\n\nIf the target paper is an **ICLR paper**, try to retrieve the **same-year OpenReview submission page**.\nUse it to collect, when available:\n\n- reviewer comments\n- meta-review or area-chair summary\n- author rebuttal / response\n- revision signals relevant to acceptance\n\nUse these materials to enrich the deep reading report, especially for:\n\n- what reviewers found convincing or weak\n- which claims were challenged\n- whether the rebuttal resolved those concerns\n- how the review discussion changes confidence in the paper’s claims\n\nIf the OpenReview thread cannot be found, state that clearly and continue with the best grounded report possible.\n\n## Output policy\n\nGenerate a **Markdown report** as the primary output.\nDo **not** create JSON, YAML, spreadsheets, slides, canvases, code files, manifests, or graph bundles as separate artifacts.\nIf structure is useful, keep it **inside the Markdown report** using sections, subsections, tables, blockquotes, and fenced code blocks.\n\n### Optional storyboard output\n\nIf an image-generation API or tool is available in the runtime, and the user has not opted out, generate a **small sequence of connected cartoon-style storyboard images** after the report.\nThe storyboard should:\n\n- narrate the author’s main idea step by step\n- use recurring characters, objects, or visual metaphors across frames\n- stay faithful to the report’s explanation\n- simplify without distorting the method\n- avoid adding scientific claims not supported by the paper\n\nWhen no image-generation capability is available, do not fail the task. Instead, include a short Markdown storyboard prompt set that could be used later.\n\n## Language policy\n\nWrite the **skill instructions, internal prompts, and default report headings in English**.\nDefault to **English** for the report unless the user explicitly requests another language.\n\n## Style policy\n\nStay close to the actual paper.\nDo **not** drift into generic commentary.\nName the actual modules, formulas, assumptions, theorem objects, datasets, baselines, figures, captions, tables, empirical observations, and reviewer comments used in the paper.\nDo not be overly brief.\nKeep the report specific, evidence-backed, and somewhat concrete with paper-local details.\nWhen inferring the author’s likely intentions or subjective judgments, distinguish clearly between:\n\n- evidence-backed interpretation\n- plausible inference\n- speculation\n\n## Mandatory report requirements\n\nThe report must explicitly cover the following whenever the available materials support it.\n\n### 1. Paper identification and source package used\n\nReport:\n\n- title\n- authors if available\n- venue / year / status if available\n- whether the reading was LaTeX-primary, PDF-primary, or mixed-source\n- what sources were actually used\n- whether arXiv LaTeX was searched for and whether it was found\n- whether OpenReview materials were used\n\n### 2. Title interpretation\n\nInterpret the title term by term.\nExplain what each keyword means, why the title is phrased that way, and how the title maps to the actual method, setting, and claims.\n\n### 3. What problem the paper really solves\n\nExplain:\n\n- the direct paper-level problem\n- the practical pain point\n- the scientific question behind the method\n- the upper multi-layer problem ladder\n\nPrefer a continuous ladder such as:\n\n- direction-native problem\n- parent-field problem\n- broader AI / ML problem\n\nAlso discuss upper problems suggested by:\n\n- borrowed algorithm families\n- bottlenecks introduced by the proposed method itself\n\n### 4. Related work and cited-paper expansion\n\nDo not only list cited papers.\nFor the key papers repeatedly discussed by the target paper, explain:\n\n- what they solved\n- what they still left open\n- why the current paper needed to move beyond them\n- how each one relates to the current paper\n  - inherited\n  - contrasted\n  - generalized\n  - specialized\n  - hybridized\n  - problem-shifted\n\n### 5. Main idea and likely author reasoning path\n\nExplain the core idea in paper-grounded terms.\nThen reconstruct the likely reasoning path that led the authors from observed pain points and prior work to the final design.\nWhen appropriate, discuss whether parts of the idea, theory choice, proof strategy, algorithm, or modules appear connected to the authors’ subjective judgments, research taste, heuristics, engineering preferences, or broader research style.\n\n### 6. Symbols, concepts, and notation\n\nIntroduce important symbols, operators, assumptions, and problem-specific concepts before heavily relying on them.\nExplain them in beginner-friendly language while remaining faithful to the paper.\n\n### 7. Formula preservation and explanation\n\nDo **not** omit key equations.\nPreserve and explain the important:\n\n- objective functions\n- update rules\n- constraints\n- estimators\n- bounds\n- theorem statements\n\nFor each key formula, explain:\n\n- what each symbol means\n- why the formula is introduced\n- what role it plays in the method\n- which algorithm step or system behavior it corresponds to\n- whether the formula itself appears limited, heuristic, fragile, or improvable\n\n### 8. Theory, proof, and practice mapping\n\nIf the paper contains theory or proofs, explain:\n\n- what is being proved\n- why the authors chose to prove it\n- what scientific or reviewer concern the proof addresses\n- what practical meaning the theorem has\n\nThen map theory to practice:\n\n- theorem assumptions -> implementation assumptions\n- proved objects -> implemented objects\n- proof conclusions -> expected practical behavior\n\nJudge whether theory and implementation are:\n\n- exactly aligned\n- approximately aligned\n- only loosely connected\n\nAlso explain where theory stops being faithful to the actual implementation and whether that gap seems acceptable.\n\n### 9. Algorithm or module walkthrough with concrete examples\n\nDo not stop at equations.\nGive a step-by-step explanation of the algorithm or module pipeline.\nWhenever possible, include at least one concrete mini-example that instantiates:\n\n- inputs\n- states\n- intermediate quantities\n- outputs\n- updates\n\n### 10. Fine-grained critique of formulas, modules, and assumptions\n\nDo not discuss only overall limitations.\nEvaluate specific formulas, modules, and assumptions.\nFor central design elements, ask whether they are:\n\n- brittle\n- under-justified\n- overly heuristic\n- computationally expensive\n- hard to optimize\n- weakly identified\n- mismatched to the claimed scientific goal\n\nThen discuss:\n\n- possible improvements\n- alternative formulations\n- likely trade-offs\n\n### 11. Figures from both PDF and LaTeX\n\nFor **PDF papers**, explicitly interpret key figures instead of merely summarizing them.\nFor **LaTeX sources**, also reconstruct and explain important figures from\n\nArchive v1.0.1: 4 files, 6495 bytes\n\nFiles: README.md (1023b), SKILL.md (11392b), templates/report_template.md (843b), _meta.json (137b)\n\nArchive v1.0.0: 28 files, 56132 bytes\n\nFiles: CHANGES_CN.md (5304b), README.md (992b), schemas/claim_support_audit.template.json (488b), schemas/delivery_bundle_manifest.template.json (1057b), schemas/detailed_report_contract.md (6768b), schemas/detailed_report_required_sections.json (21678b), schemas/extended_deepread_checklist_cn.md (3452b), schemas/motivation_bridge_analysis.md (544b), schemas/paper_focus_spec.template.json (11868b), schemas/per_paper_output_layout.md (884b), schemas/project_directory_annotations.template.json (3787b), schemas/project_directory_index_spec.md (490b), schemas/routing_status_template.json (783b), schemas/sources_refresh_templates.md (386b), schemas/sources_zip_layout.md (1123b), scripts/build_canvas_deepread_intermediate.py (1415b), scripts/build_paper_deep_reading_bundle.py (12927b), scripts/init_paper_deep_reading_scaffold.py (40285b), scripts/update_project_directory_index.py (8881b), scripts/update_routing_status.py (4065b), scripts/validate_detailed_report_structure.py (6404b), SKILL.md (24141b), workflow/01_request_sources.md (315b), workflow/02_extract_structure.md (477b), workflow/03_figure_and_table_analysis.md (1440b), workflow/04_gap_mining_and_graph.md (281b), workflow/05_extended_argument_and_innovation_audit.md (1652b), _meta.json (137b)","readmeExcerpt":"Skill: Paper Deep Reading Owner: c-narcissus Summary: Deep-read research papers into source-aware reports, traceable claim evidence, and research-direction seeds. Use for paper PDFs, LaTeX sources, appendices, c... Tags: latest:1.2.0 Version history: v1.2.0 | 2026-05-01T13:30:51.284Z | user Version 1.2.0 introduces research-direction mining and new artifact support: - Added research-direction mining layer with best-p","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"The paper's method works because H is usually true.\nIn setting S, H is false or unverifiable.\nCurrent proxy Z is insufficient because of failure F.\nA new mechanism Z' may solve F.\nThe minimum viable experiment is E.\nA negative result would mean N.\nA killer result would be K."},{"language":"text","snippet":"Current paper: M works if H.\nBreak: H fails under S.\nResearch question: Can M be redesigned for not-H?\nMechanism: replace proxy P with mechanism Q.\nMinimum viable experiment: compare M and Q under controlled not-H stress."},{"language":"text","snippet":"Current paper: proxy P is used as a surrogate for ideal signal Y.\nBreak: P diverges from Y under condition S.\nResearch question: Can we estimate Y more directly or build a better surrogate?\nMinimum viable experiment: construct a stress test where P and Y disagree."},{"language":"text","snippet":"Objection: the paper does not rule out alternative explanation A.\nResearch question: Is the reported gain due to the proposed mechanism or A?\nMinimum viable experiment: isolate A with matched controls.\nKiller result: proposed mechanism wins when A is controlled."},{"language":"text","snippet":"Popular belief: method family M should help in setting S.\nNegative result: M fails despite careful tuning.\nWhy this matters: failure reveals that assumption H is false.\nMinimum viable experiment: reproduce failure across small but representative cases."},{"language":"text","snippet":"Original paper: introduced mechanism Z.\nSuccessor papers: reuse Z but avoid setting S.\nGap: no one has tested Z under S or replaced it when it fails.\nMinimum viable experiment: benchmark Z in S against a simple robust alternative."}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: paper-deep-reading\ndescription: Deep-read research papers into source-aware reports, traceable claim evidence, and research-direction seeds. Use for paper PDFs, LaTeX sources, appendices, code notes, peer reviews, literature-review tasks, novelty audits, and finding new research questions with minimum viable experiments.\nlicense: MIT-0\nmetadata:\n  version: 1.2.0\n  openclaw:\n    emoji: \"📚\"\n    requires:\n      bins:\n        - python3\n    tags:\n      - research\n      - papers\n      - deep-reading\n      - ideation\n      - literature-review\n---\n\n# Paper Deep Reading: Source-Aware + Research-Generative Direction Mining\n\nUse this skill when the user wants a **deep, paper-grounded, auditable, idea-generative reading report** for one computer-science paper or a small paper batch.\n\nThe input may be:\n\n- a user-provided PDF\n- a user-provided LaTeX source tree or `.tex` files\n- supplementary material, appendix files, code notes, or OpenReview material\n- only the paper title, arXiv id, venue page, citation-like paper name, or PDF link\n\nThe default output is **text-first, audit-first, formula-preserving, and research-direction-oriented**.\nThis version does not require a dedicated webpage reader; when search/browsing tools are available, use them to assemble the best source package before writing.\n\n## 1) Core deliverables\n\n1. **Human-readable report**\n   - `report.md`\n\n2. **Machine-readable trace artifacts**\n   - `traceability_manifest.json`\n   - `latex_paragraphs.json`\n   - `artifact_index.json`\n\n3. **Machine-readable research artifacts**\n   - `research_lens.json`\n   - `direction_board.json`\n\nThe report is the primary user-facing deliverable.\nIt must read like a serious research mentor's deep-reading memo, not like a thin checklist dump.\nThe direction board is the primary idea-mining surface: it converts paper weaknesses, hidden assumptions, evidence gaps, proxy mismatches, successor-paper gaps, and reviewer objections into candidate research directions.\n\n## 2) ClawHub and MIT-0 package discipline\n\nThis skill package is intended to stay compatible with **ClawHub / OpenClaw skill packaging**.\n\nKeep the package lean:\n\n- keep `SKILL.md` as the main instruction file\n- keep only text-based support files, templates, and scripts that another agent needs to execute the workflow\n- do not reintroduce auxiliary docs such as `README.md` or `CHANGELOG.md`\n- do not add binary assets, vendored third-party repositories, or cached papers to the skill package\n- keep support files focused on execution, validation, and artifact contracts\n\nKeep the package license-safe:\n\n- this package follows ClawHub's `MIT-0` publication model\n- keep the local bundle license text in `LICENSE.txt`\n- do not add restrictive or conflicting license terms elsewhere in the package\n- do not vendor third-party projects or assets into the skill unless their license is compatible with `MIT-0` redistribution expectations\n- when external tooling is useful, document it or install it outside the skil"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7fxns1xpr6z67w885my7d7k98506vv\",\n  \"slug\": \"paper-deep-reading\",\n  \"version\": \"1.2.0\",\n  \"publishedAt\": 1777642251284\n}"},{"path":"references/artifact_contract.md","content":"# Artifact Contract\n\n## `artifact_index.json`\n\nTop-level index for all outputs that belong to one paper reading bundle.\n\nRequired keys:\n\n- `schema_version`\n- `paper_id`\n- `report`\n- `traceability_manifest`\n- `latex_paragraphs`\n- `research_lens`\n- `direction_board`\n\nOptional keys:\n\n- `source_package`\n- `pdfs`\n- `notes`\n\n## `traceability_manifest.json`\n\nMaps report claims to source evidence.\n\nEach claim entry should include:\n\n- `claim_id`\n- `section_id`\n- `report_anchor`\n- `statement`\n- `interpretation_type`\n- `confidence`\n- `evidences`\n\nRecommended extra fields:\n\n- `research_role`\n- `human_locators`\n\nEach evidence entry may include:\n\n- `evidence_id`\n- `source_kind`\n- `source_file`\n- `paragraph_id`\n- `page`\n- `line_start`\n- `line_end`\n- `locator_method`\n- `synctex`\n- `quote_text`\n- `notes`\n\n## `latex_paragraphs.json`\n\nStable anchor list extracted from LaTeX.\n\nEach paragraph entry should include:\n\n- `paragraph_id`\n- `source_path`\n- `line_start`\n- `line_end`\n- `section_path`\n- `kind`\n- `text`\n\n## `research_lens.json`\n\nThis is the compact idea-mining layer.\nIt should capture:\n\n- research equation\n- direction reconstruction\n- challenge-to-module map\n- module hidden assumptions\n- citation logic\n- reviewer-lens summary\n- reusable story pattern\n- strongest future directions\n- links to top direction seeds\n\nEvery `claim_ids` entry inside `research_lens.json` must point to a real report claim.\nEvery seed referenced in `top_direction_seed_ids` should exist in `direction_board.json`.\n\n## `direction_board.json`\n\nThis is the structured research-direction board for finding new research points.\nIt should rank testable directions derived from the paper.\n\nRequired top-level keys:\n\n- `schema_version`\n- `paper_id`\n- `purpose`\n- `source_confidence`\n- `direction_seeds`\n- `ranking_notes`\n- `search_limitations`\n\nEach `direction_seeds` entry should include:\n\n- `seed_id`\n- `title`\n- `seed_type`\n- `trigger_interpretation_type`\n- `paper_anchor_claim_ids`\n- `trigger_evidence_summary`\n- `hidden_assumption_or_gap`\n- `research_question`\n- `hypothesis`\n- `proposed_mechanism`\n- `minimum_viable_experiment`\n- `negative_result_interpretation`\n- `killer_objection`\n- `killer_result`\n- `first_week_plan`\n- `score`\n- `risk_level`\n- `expected_value`\n- `confidence`\n\nAllowed `seed_type` values:\n\n- `assumption_violation`\n- `unavailable_mechanism`\n- `proxy_mismatch`\n- `evidence_gap`\n- `tiny_example`\n- `successor_paper_gap`\n- `reviewer_objection`\n- `negative_result`\n- `cross_domain_transfer`\n\nAllowed `trigger_interpretation_type` values:\n\n- `evidence-backed interpretation`\n- `plausible inference`\n- `speculation`\n\nRecommended `score` fields:\n\n- `novelty`\n- `significance`\n- `testability`\n- `feasibility`\n- `evidence_anchor`\n- `risk_adjusted_value`\n- `overall`\n\nEach score should be on a 0-5 scale, with a short reason when possible.\n\n## Report requirement\n\nIn `report.md`, every main-body claim bullet should appear in the form:\n\n- `[C<section>.<index>][interpretation label] statement`\n\nThe detailed lo"},{"path":"references/research-direction-mining-best-practices.md","content":"# Research-Direction Mining Best Practices\n\nThis reference strengthens the deep-reading workflow for users whose main goal is to find new research directions and research points.\nIt should be used together with `research-generative-methodology.md` and the main `SKILL.md`.\n\n## 1. Direction-Mining Three-Pass Reading\n\n### Pass 1: Five-C triage with research promise\n\nAnswer:\n\n1. `Category`: What kind of paper is this?\n2. `Context`: What field conversation and prior assumptions does it depend on?\n3. `Correctness`: Do the high-level assumptions, task, data, and comparisons look plausible?\n4. `Contributions`: What does the paper claim to add?\n5. `Clarity`: Is the argument readable and auditable?\n\nThen add:\n\n- likely hidden assumption\n- likely missing mechanism\n- likely weak evidence point\n- whether the paper deserves a full direction-mining read\n\n### Pass 2: Evidence / method / figure chain\n\nReconstruct the paper as:\n\n`problem -> broken assumption -> design principle -> module -> formula -> figure/table -> experiment -> claim`\n\nRequired outputs:\n\n- challenge-to-module table\n- claim-to-experiment map\n- formula role notes\n- figure/table support notes\n- proxy-vs-ideal mechanism notes\n\n### Pass 3: Virtual reimplementation and hidden-assumption attack\n\nRead as if you had to rebuild the paper.\n\nAsk:\n\n- What assumptions must be true for each module to work?\n- Which assumptions are implicit rather than stated?\n- What proof step, code step, data choice, or metric definition is carrying the argument?\n- What special case makes the method easy to understand?\n- What counterexample would break the method?\n- What experiment would settle the main uncertainty fastest?\n\nRequired output:\n\n- hidden-assumption list\n- tiny example or special-case explanation\n- dropped-assumption failure modes\n- future-work triggers\n\n## 2. Reverse Citation and Successor-Paper Reading\n\nWhen tools and time allow, inspect a small set of successor papers or citation trails.\n\nUse successor reading to distinguish:\n\n- what the original paper claimed\n- what later papers actually reused\n- what later papers criticized or avoided\n- what became a standard assumption\n- what remains under-tested\n- what has already become saturated\n\nDo not fabricate trends.\nIf successor search was not performed, mark successor-derived directions as unavailable or lower confidence.\n\n## 3. Critical + Creative Reading\n\nCritical reading checks:\n\n- Are the assumptions reasonable?\n- Are the data and metrics suitable?\n- Are baselines and controls sufficient?\n- Is the evidence aligned with the claims?\n- Are simpler explanations ruled out?\n- Are the limitations honest and complete?\n\nCreative reading asks:\n\n- What good idea can transfer to a new setting?\n- What stronger or cleaner assumption break would make a new paper?\n- What missing mechanism should replace a proxy?\n- What negative result would change how the community thinks?\n- What would a first-week experiment test?\n\n## 4. Reviewer-Grade Direction Audit\n\nUse reviewer objections"},{"path":"references/research-generative-methodology.md","content":"# Research-Generative Methodology\n\nUse this reference when the user wants more than grounded verification.\nIts goal is to turn a paper reading into a **research-generation exercise** while keeping every important statement source-aware.\n\nThe core move is:\n\n> Read the paper as a hidden design path.\n\n## 1. Research Equation\n\nCompress the paper into:\n\n`old success + broken assumption + hard setting + borrowed tool + surrogate mechanism`\n\nUseful questions:\n\n- What important paradigm already worked?\n- What hidden assumption made it work?\n- In what realistic setting does that assumption fail?\n- What neighboring method almost transfers?\n- What missing mechanism `Y` blocks direct transfer?\n- What surrogate `Z` does the paper build instead?\n\n## 2. How the Direction Was Likely Found\n\nUse evidence-backed phrasing:\n\n- \"The authors likely noticed that ...\"\n- \"A plausible thinking path is ...\"\n- \"The setup suggests ...\"\n\nTry to reconstruct:\n\n- starting dissatisfaction\n- tempting transferred method\n- blocking constraint\n- replacement logic\n\n## 3. How the Story Was Built\n\nLook for:\n\n`challenge -> failure mode -> design principle -> module -> ablation`\n\nStrong papers often create a loop instead of a bag of tricks.\nExplain whether one module creates the resource that the next module needs.\n\n## 4. Method Deep Reading\n\nFor each module, reconstruct:\n\n`failure + ideal unavailable solution + available proxy + design choice + hidden assumption + risk`\n\nThe most useful framing is usually:\n\n> This module is not just a trick; it is a surrogate for the missing mechanism `Y`.\n\n## 5. Reverse Citation Logic\n\nTreat citations as narrative functions:\n\n- field anchor\n- limitation evidence\n- method ancestor\n- neighboring inspiration\n- baseline pressure\n- protocol justification\n- contrast boundary\n\nExplain what permission each key citation gives the paper.\n\n## 6. Experiments as Story Evidence\n\nRead each result as:\n\n`claim + counterfactual + metric + stress condition`\n\nAsk:\n\n- what claim it supports\n- what alternative explanation it rules out\n- which module it validates\n- whether the stress condition really matches the paper's target difficulty\n\n## 7. Story Pattern Worth Learning\n\nExtract one reusable pattern, such as:\n\n- replacement story\n- three-module story\n- two-axis empty cell\n- closed-loop contribution\n- hidden-assumption break\n\n## 8. Weakness to New Idea Conversion\n\nUse:\n\n`future work = current method + violated assumption + new mechanism`\n\nFor each strong weakness, ask what next paper becomes possible if the key hidden assumption fails harder.\n\n## 9. Writing Rules\n\nPrefer phrasing like:\n\n- \"A plausible author-side thinking path is ...\"\n- \"This module is best understood as a surrogate for ...\"\n- \"The citation is not ornamental; it functions as ...\"\n- \"This weakness can be converted into a new research direction ...\"\n\nAvoid:\n\n- restating the abstract\n- listing sections without causal explanation\n- paraphrasing equations without saying why they exist\n- speaking as if private aut"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":2505,"uniquenessScore":42,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T01:58:42.247Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T01:58:42.247Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T04:35:42.171Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}