@research-copilot/plugin 1.1.17 → 1.1.19

package/dist/skills/vibe-research-workflow/references/vibe-writing.md

@@ -0,0 +1,181 @@
+# Vibe Writing: red-line rules and recommended flow
+
+## Table of contents
+
+1. The resolved contradiction
+2. Red-line rules
+3. Recommended flow
+4. What AI does well
+5. What AI does badly
+6. Integration with pre-submission-reviewer
+
+## 1. The resolved contradiction
+
+The project's v1 content contains a surface contradiction: section
+3.5 strictly forbids AI-generated content; section 5.1 embraces
+Vibe Writing. The v2 resolution is:
+
+- AI-assisted writing is permitted for mechanical acceleration
+  (grammar, phrasing, structure suggestions).
+- AI-generated drafts are not acceptable as final submitted text
+  unless verified sentence by sentence by the user.
+- The mechanical writing rules in section 3.5 (no em-dashes, no
+  banned AI-tone vocabulary, no Chinglish) are enforced by the
+  `pre-submission-reviewer` skill.
+- The behavioural rules in section 5.1 govern the process.
+
+In practical terms: write first in the user's own words; polish
+with AI; verify after polish; scan for banned patterns before
+submitting.
+
+## 2. Red-line rules
+
+Do not:
+
+- Copy AI-generated paragraphs verbatim into the paper. Rewrite
+  in the user's own words.
+- Let AI fabricate or pre-fill citations. Every reference is the
+  user's own confirmed read.
+- Send a partial prompt and accept whatever AI returns; context
+  must include the paper's method, problem, background, and
+  relevant experimental data.
+- Use AI to hide plagiarism or to paraphrase another group's
+  work.
+- Submit AI-assisted prose to a venue that forbids AI-assisted
+  content without disclosure.
+
+Violations of any red-line rule are academic misconduct. See
+`references/behavior-guidelines.md` for the full context.
+
+## 3. Recommended flow
+
+### Step A: write the core claim and logic in the user's own words
+
+- Produce the paragraph skeleton: topic sentence, evidence
+  sentences, closing sentence.
+- Do this first; do not outsource it.
+- The skeleton encodes the user's thinking, which is the
+  contribution.
+
+### Step B: polish with AI (correct-by-construction)
+
+- Paste the user's paragraph to AI with an explicit polish
+  prompt that inlines the banned-vocabulary and punctuation
+  rules. This prevents drift at the polish step rather than
+  relying on a downstream reviewer to catch violations. Template:
+
+```
+Polish the language in the paragraph below. Hard rules:
+
+1. Preserve every technical claim exactly. Do not add content,
+   do not remove content, do not add citations.
+2. Do not use any of these banned words or phrases: innovative,
+   pioneering, revolutionary paradigm, transformative framework,
+   superior, surpass, excel, remarkable, unprecedented, achieves
+   SOTA, breakthrough performance, general-purpose, is capable
+   of, notably, yet, yielding, at its essence, encompass,
+   differentiate, reveal, underscore, pave the way for, highlight
+   the potential of, profound challenges, stems from, rigid,
+   impede.
+3. Do not use em-dashes as sentence connectors or parenthetical
+   breaks. Use commas, colons, or periods instead.
+4. Use logical quotation punctuation: punctuation goes inside
+   quotation marks only if it is part of the quoted material.
+5. Prefer short sentences, active voice, and concrete technical
+   verbs (propose, introduce, design, show, demonstrate, report,
+   observe).
+6. Keep the paragraph length roughly equal to the input.
+
+Paragraph to polish:
+<paste paragraph here>
+```
+
+- AI returns a polished version that is already style-compliant
+  at submission time, not merely grammatical.
+- The user still compares word by word in Step C to catch any
+  content drift, but the banned-vocabulary and em-dash checks
+  in Step D should now return empty sets in the common case.
+
+### Step C: verify sentence by sentence
+
+- For each sentence in the polished version, ask: does this match
+  the user's intended claim?
+- Replace any drift with the user's phrasing.
+- Flag any hallucinated content and remove.
+
+### Step D: scan for banned patterns (backstop)
+
+Step B's inlined rules prevent most violations at the polish step.
+Step D is the backstop for anything that slipped through.
+
+- Run the banned-vocabulary scan (see
+  `pre-submission-reviewer`'s `references/forbidden-patterns.md`
+  for the canonical list and severity heuristics).
+- Remove any AI-tone word that survived Step B.
+- Remove any em-dash used as a sentence connector; replace with
+  comma, colon, or period.
+- Verify punctuation follows logical (not American) quotation
+  conventions.
+
+If Step D finds significant violations, the Step B polish prompt
+template was under-specified; update the prompt rather than
+accepting repeated Step D cleanup.
+
+### Step E: final integrity check
+
+- Read the full paragraph aloud. Does it sound like the user?
+- If the voice has drifted, rewrite.
+- The final text should be the user's voice, not an AI-polished
+  version that loses the user's style.
+
+## 4. What AI does well
+
+- Grammar correction: article usage, subject-verb agreement,
+  tense consistency.
+- Sentence length and splitting long sentences.
+- Paragraph flow: suggesting transitions.
+- Translation between idiomatic English and user's first
+  language.
+- Finding overly long passive constructions.
+- Suggesting phrasing for a known concept.
+
+For these tasks, AI is a net positive; sentence-by-sentence
+verification is still required but rarely surfaces issues.
+
+## 5. What AI does badly
+
+- Technical accuracy: AI may subtly misrepresent the user's
+  method.
+- Citations: AI confidently invents references.
+- Novelty framing: AI defaults to generic inflation language.
+- Voice: AI smooths the user's voice into a neutral register
+  that lacks personality and distinguishability.
+- Section-appropriate tense: AI mixes tenses within a paragraph.
+- Avoiding AI-tone vocabulary: AI gravitates to its own banned
+  words.
+
+For these tasks, AI is a net negative; the user must catch and
+correct at verification time.
+
+## 6. Integration with pre-submission-reviewer
+
+Vibe Writing and pre-submission-reviewer are complementary:
+
+- Vibe Writing governs the drafting process.
+- pre-submission-reviewer audits the final draft.
+
+Typical sequence:
+
+1. User drafts Section X in own voice.
+2. User polishes with AI (Vibe Writing Step B).
+3. User verifies sentence by sentence (Step C).
+4. User runs `pre-submission-reviewer` on the completed section.
+5. User fixes any MAJOR findings before submission.
+6. Before final submission, `pre-submission-reviewer` runs on the
+   full paper with banned-vocabulary and em-dash scan enabled.
+
+Running pre-submission-reviewer without the Vibe Writing discipline
+tends to produce many findings that require rewriting the section
+from scratch; running Vibe Writing without pre-submission-reviewer
+leaves some issues (banned vocabulary, em-dash misuse) for reviewers
+to find first.

package/dist/skills/wiki-enrich/SKILL.md

@@ -0,0 +1,254 @@
+---
+name: wiki-enrich
+description: "Fill in the per-paper TODO sections of research-wiki/papers/<slug>.md pages that literature-ingest skills leave as bare scaffolds. Use when user says 'enrich wiki', 'fill paper TODOs', 'wiki body 補完', '把 paper 摘要寫進 wiki', 'research-wiki 自動填', or after a batch ingest that left papers/ as TODO scaffolds."
+argument-hint: "[target: slug|missing|all] [--source alphaxiv|deepxiv|arxiv|auto] [--force] [--max N]"
+allowed-tools: Bash(*), Read, Write, Edit, Glob, Grep, WebFetch
+---
+
+# Wiki Enrich: Fill Paper TODO Sections (Karpathy LLM-Wiki)
+
+Target: **$ARGUMENTS**
+
+## Why this skill exists
+
+`ingest_paper` (called by `/research-lit`, `/arxiv`, `/alphaxiv`, `/deepxiv`, `/semantic-scholar`, `/exa-search`) only renders the per-paper scaffold — frontmatter + abstract + **10 fillable** `_TODO._` placeholder sections (plus two protected sections: `## Connections` is graph-summary and `## Abstract (original)` is auto-populated when `--arxiv-id` is given). No downstream skill in ARIS fills those 10 sections; the wiki sits as TODO until someone reads each paper.
+
+This contradicts the Karpathy LLM-wiki design (https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f):
+
+> "You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. … The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. … LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass."
+
+`/wiki-enrich` is the missing back half of `ingest_paper`: it reads each scaffolded paper page, fetches paper content from external sources via a graceful fallback chain (see Phase 2.3 for the full 5-source chain), and rewrites the 10 fillable TODO sections into 1-3 sentence prose summaries.
+
+## Constants
+
+- **WIKI_ROOT = `research-wiki/`** — Resolved relative to git root. Skill hard-fails if not a directory.
+- **TARGET_DEFAULT = `missing`** — When no target is given, enrich only papers with ≥1 TODO section. Other targets: `<slug>` (one paper) or `all` (every paper, even ones already enriched — usually combined with `--force` to overwrite).
+- **SOURCE_DEFAULT = `auto`** — Fetch order: alphaxiv overview → alphaxiv abs → deepxiv brief → arXiv API abstract → page abstract fallback. First non-empty wins (full chain documented in Phase 2.3 table). Override with `--source` to pin one source.
+- **MAX_PAPERS = 20** — Hard cap per invocation; LLMs touch many files but token budgets are real. Override with `--max N`.
+- **FORCE = false** — When `false` (default), skip sections that already have non-TODO content. When `true`, overwrite every fillable section, but **never** touch the two protected sections: `## Connections` (auto-generated from `edges.jsonl`) and `## Abstract (original)` (immutable arXiv-fetched source data).
+- **SECTIONS_TO_FILL** — 10 fillable sections + 2 protected. `ingest_paper` (`research_wiki.py:436-473`) scaffolds 11 section headers unconditionally and a 12th — `## Abstract (original)` — only when arXiv returns an abstract for the given `--arxiv-id` (`research_wiki.py:469-473`). Of these, 10 carry a `_TODO._` (or `_TODO: fill in after reading._`) marker and need filling. The other 2 — `## Connections` (position 10 in the enumeration below) and `## Abstract (original)` (position 12, conditional) — are protected by construction: `Connections` is auto-generated from `graph/edges.jsonl`, `Abstract (original)` is immutable source data from the arXiv API. This skill writes to the 10, never the 2.
+  1. `One-line thesis` (marker: `_TODO: fill in after reading._`)
+  2. `Problem / Gap` (marker: `_TODO._`)
+  3. `Method` (marker: `_TODO._`)
+  4. `Key Results` (marker: `_TODO._`)
+  5. `Assumptions` (marker: `_TODO._`)
+  6. `Limitations / Failure Modes` (marker: `_TODO._`)
+  7. `Reusable Ingredients` (marker: `_TODO._`)
+  8. `Open Questions` (marker: `_TODO._`)
+  9. `Claims` (marker: `_TODO._`) — fill with `_No claims tracked yet._` if no `claim:` edges point to this paper; otherwise list them.
+  10. `Connections` — **NEVER edit** (auto-generated from `graph/edges.jsonl`).
+  11. `Relevance to This Project` (marker: `_TODO._`) — use `RESEARCH_BRIEF.md`, `AGENTS.md` (or legacy `CLAUDE.md`), or `gap_map.md` for project context. If no project context exists, leave as TODO and report it.
+  12. `Abstract (original)` — leave alone (already populated by `ingest_paper` when `--arxiv-id` was used).
+
+> 💡 Examples:
+> - `/wiki-enrich` — enrich every paper with ≥1 TODO section (most common usage)
+> - `/wiki-enrich vllm` — enrich a single paper by slug
+> - `/wiki-enrich all --force` — rewrite every paper from scratch (use when you've adopted a new style)
+> - `/wiki-enrich --source alphaxiv --max 5` — only use alphaxiv, only do 5 papers
+> - `/wiki-enrich missing --max 50` — bigger batch (watch token budget)
+
+## Pre-flight
+
+Resolve `$WIKI_ROOT` and `$WIKI_SCRIPT` (canonical chain — see `shared-references/wiki-helper-resolution.md`):
+
+```bash
+cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
+[ -d research-wiki/ ] || { echo "ERROR: research-wiki/ not found. Run /research-wiki init first." >&2; exit 1; }
+
+ARIS_REPO="${ARIS_REPO:-$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null)}"
+WIKI_SCRIPT=".aris/tools/research_wiki.py"
+[ -f "$WIKI_SCRIPT" ] || WIKI_SCRIPT="tools/research_wiki.py"
+[ -f "$WIKI_SCRIPT" ] || { [ -n "${ARIS_REPO:-}" ] && WIKI_SCRIPT="$ARIS_REPO/tools/research_wiki.py"; }
+[ -f "$WIKI_SCRIPT" ] || { echo "ERROR: research_wiki.py not found." >&2; exit 1; }
+```
+
+If either fails, **hard-fail** — this skill manipulates wiki state and must not run blind.
+
+## Workflow
+
+### Phase 1: Parse target + discover candidates
+
+Parse `$ARGUMENTS` for the first positional (target) and flags (`--source`, `--force`, `--max`).
+
+Build the candidate paper list:
+
+```bash
+case "$TARGET" in
+  all)
+    PAPERS=( research-wiki/papers/*.md )
+    ;;
+  missing|"")
+    # only papers with at least one TODO marker line
+    PAPERS=( $(grep -lE "^_TODO(\._?|: fill in after reading\._?)$" research-wiki/papers/*.md 2>/dev/null) )
+    ;;
+  *)
+    P="research-wiki/papers/${TARGET}.md"
+    [ -f "$P" ] || { echo "ERROR: paper not found: $P" >&2; exit 1; }
+    PAPERS=( "$P" )
+    ;;
+esac
+echo "Candidate papers: ${#PAPERS[@]} (cap ${MAX_PAPERS})"
+PAPERS=( "${PAPERS[@]:0:${MAX_PAPERS}}" )
+```
+
+If the candidate list is empty, print `"✓ Nothing to enrich."` and exit 0. Do not error.
+
+### Phase 2: For each paper — read, fetch, fill
+
+Iterate **one paper at a time**. For each `$PAPER` in `$PAPERS`:
+
+**Step 2.1 — Read the page and project context.** Use the `Read` tool on the full paper file. Extract from the YAML frontmatter:
+- `node_id` (e.g. `paper:vllm`) — slug = part after `paper:`
+- `arxiv` from `external_ids.arxiv` — empty string if absent
+- `title`
+- existing `## Abstract (original)` blockquote (if present) — fallback content source
+
+Additionally, on the FIRST paper of the batch (cache for the rest), read project-context files needed for the `Claims` and `Relevance to This Project` sections:
+- `research-wiki/graph/edges.jsonl` — scan for `claim:` edges pointing to the current paper's `node_id`
+- `RESEARCH_BRIEF.md` (project root) — if present, source for project goals
+- `AGENTS.md` (project root, Codex CLI primary) or legacy `CLAUDE.md` — if present, fallback for project context
+- `research-wiki/gap_map.md` — if non-empty, source for gap framing
+
+If none of the project-context files exist, the `Relevance to This Project` section will be filled with the literal "context not yet set" line (see Step 2.4 table).
+
+**Step 2.2 — Identify which sections are TODO.**
+
+Match each section header against its marker:
+- A header followed by exactly `_TODO._` → fill
+- A header followed by `_TODO: fill in after reading._` → fill (One-line thesis)
+- A header followed by any other content → skip (unless `--force`)
+- `## Connections` → **always skip** (auto-generated)
+- `## Abstract (original)` → **always skip** (immutable source data)
+
+If no fillable sections remain, log `"skip: <slug> (already enriched)"` and continue.
+
+**Step 2.3 — Fetch source content.**
+
+The fetch chain runs **in order** until one returns usable content (>200 chars of text):
+
+| Order | Source | How |
+|-------|--------|-----|
+| 1 | **alphaxiv overview** (`auto` default; `--source alphaxiv` to pin) | `WebFetch https://alphaxiv.org/overview/<arxiv_id>.md` — LLM-optimized summary, often best for filling sections |
+| 2 | **alphaxiv abs** (fallback within alphaxiv) | `WebFetch https://alphaxiv.org/abs/<arxiv_id>.md` |
+| 3 | **deepxiv brief** (`--source deepxiv` to pin) | `python3 "$DEEPXIV_FETCHER" paper-brief <arxiv_id>` if helper resolves |
+| 4 | **arXiv API abstract — fresh fetch** (`--source arxiv` to pin) | `curl http://export.arxiv.org/api/query?id_list=<arxiv_id>` — log label: `arxiv-api-abstract` |
+| 5 | **Page abstract — fallback** (last resort) | Reuse the existing `## Abstract (original)` blockquote already present in the page body from a prior `ingest_paper` run — log label: `page-abstract-fallback` |
+| — | **No arxiv id + no page abstract** | Skip this paper, log `"skip: <slug> (no arxiv id, no abstract)"`, continue |
+
+When trying alphaxiv: if WebFetch returns 404 / "Paper not found" / a redirect to the homepage, treat as miss and fall through.
+
+When trying deepxiv: resolve `$DEEPXIV_FETCHER` per `shared-references/integration-contract.md`. If the helper or `deepxiv` CLI is missing, fall through silently.
+
+Save the fetched content as `$SOURCE_TEXT`. Record which source succeeded for the log entry.
+
+**Step 2.4 — Generate per-section content.**
+
+You (the executor agent) are the LLM doing the grunt work. Given:
+- `$SOURCE_TEXT` (the fetched overview / brief / abstract)
+- `$TITLE`
+- the list of fillable section headers
+
+Write each TODO section's body following these rules:
+
+| Section | Length | Style | What to extract |
+|---------|--------|-------|-----------------|
+| One-line thesis | 1 sentence, ≤25 words | Declarative | The paper's core contribution in one sentence — what they built / proved / improved |
+| Problem / Gap | 1-2 sentences | Declarative | What problem the field had, why prior work fell short |
+| Method | 2-4 sentences | Technical, name the technique | Core mechanism — algorithm name + key idea + how it differs from baselines |
+| Key Results | 1-3 bullets OR 2-3 sentences | Quantitative | Headline numbers from the abstract / overview (X% improvement, Yx speedup, etc.). Keep units verbatim. |
+| Assumptions | 1-3 bullets | Declarative | What the paper takes for granted (workload type, hardware, model class, distribution shape) |
+| Limitations / Failure Modes | 1-3 bullets | Honest | What the paper explicitly admits OR what's structurally absent (e.g. "no multi-node evaluation", "assumes uniform request length") |
+| Reusable Ingredients | 1-3 bullets | Concrete | Techniques / datasets / insights from this paper that could be ported elsewhere. **Highest value for `/idea-creator` — write carefully.** |
+| Open Questions | 1-2 bullets | Question form | What the paper does NOT answer but raises |
+| Claims | 1 line | Static | If no `claim:` edges in `graph/edges.jsonl` reference this paper, write the literal italic line: `_No claims tracked yet — populate via /result-to-claim._`. Else list claim node IDs. |
+| Relevance to This Project | 1-2 sentences | Project-contextual | Use `RESEARCH_BRIEF.md` / `AGENTS.md` (or legacy `CLAUDE.md`) / `gap_map.md` to phrase the connection. If no project context, write the literal italic line: `_Project context not yet set — populate RESEARCH_BRIEF.md or gap_map.md to enable this section._` and report. |
+
+**Rules** (Karpathy fidelity):
+- **Faithful to source.** If the paper doesn't say it, don't invent it. Prefer `_Not stated in source._` over hallucination.
+- **No filler.** "This paper presents an approach to..." — don't write that. Start with the noun.
+- **Keep technical terms in English.** vLLM, KV cache, prefill, decode, TTFT, etc. stay verbatim.
+- **Quantitative when possible.** If the abstract has numbers, use them; don't paraphrase as "significant".
+- **Bilingual support.** If the project's `AGENTS.md` declares a language preference (`language: zh` or `language: bilingual`), match it. Otherwise default to English (or follow `shared-references/output-language.md`).
+
+**Step 2.5 — Edit the file.**
+
+For each fillable section, use the `Edit` tool to replace the TODO marker with the generated body. Match the exact section header + marker pair to keep edits unique, e.g.:
+
+```
+## Problem / Gap
+_TODO._
+```
+
+→
+
+```
+## Problem / Gap
+<generated body>
+```
+
+**Never** touch the YAML frontmatter, `## Connections`, or `## Abstract (original)`.
+
+**Step 2.6 — Append log entry.**
+
+```bash
+python3 "$WIKI_SCRIPT" log research-wiki/ "wiki-enrich: enriched paper:<slug> from <source> (filled N/M sections)"
+```
+
+Record which source provided content (`alphaxiv-overview`, `alphaxiv-abs`, `deepxiv-brief`, `arxiv-api-abstract`, or `page-abstract-fallback`) so the audit trail is honest about provenance.
+
+### Phase 3: Final report
+
+After processing all candidates, print:
+
+```
+✓ wiki-enrich complete
+
+Processed:  N
+Enriched:   X (sections filled: total)
+Skipped:    Y  (reasons: already enriched / no arxiv id / fetch failed)
+Failed:     Z  (with paper + reason)
+
+Source breakdown:
+  alphaxiv-overview: A
+  alphaxiv-abs:      B
+  deepxiv-brief:     C
+  arxiv-api-abstract:     D
+  page-abstract-fallback: E
+
+Re-ideation suggestion: <if ≥5 papers were enriched, recommend `/idea-creator "topic"` so the freshly-filled `Reusable Ingredients` and `Limitations` feed brainstorming. `query_pack.md` is already rebuilt below — the user does NOT need to call `/research-wiki query` manually.>
+```
+
+Also rebuild `query_pack.md` once at the end (single `python3 "$WIKI_SCRIPT" rebuild_query_pack research-wiki/` call) so `/idea-creator` sees the new bodies on its next run.
+
+## Output Protocols
+
+> Follow the shared protocols:
+> - **No `MANIFEST.md` entry.** This skill edits existing scaffolded pages in place rather than generating new artifacts. The audit trail lives in `research-wiki/log.md` (Step 2.6), with provenance per paper. Adding a `wiki-enrich` stage to `shared-references/output-manifest.md` is out of scope for this PR.
+> - **[Output Language Protocol](../shared-references/output-language.md)** — respect the project's language setting.
+
+## Key Rules
+
+- **Idempotent by default.** Re-running without `--force` only touches still-TODO sections. Safe to invoke as a cron.
+- **Never touch frontmatter, `## Connections`, or `## Abstract (original)`.** Frontmatter is metadata, Connections is graph-generated, Abstract is immutable source data.
+- **Hard-fail on missing wiki / missing helper.** Do not silently create `research-wiki/` — if it's missing, the user is in the wrong cwd or hasn't run `/research-wiki init`.
+- **Track provenance.** Every log entry records which source actually filled the body. If a future audit shows alphaxiv hallucinated for a paper, you can find every page touched by that source.
+- **Don't auto-trigger `/idea-creator`.** This skill builds the substrate; the user decides when to brainstorm next. Only *suggest* re-ideation in the final report.
+- **Gracefully degrade.** If `WebFetch` is rate-limited, fall through to next source. If all sources miss, skip the paper and continue — don't abort the whole batch.
+- **Karpathy fidelity above completeness.** It is better to leave a section as `_Not stated in source._` than to hallucinate. The wiki's value is that it doesn't lie.
+
+## Composing with Other Skills
+
+```
+/research-lit "topic"               ← ingests papers as scaffolds (Step 6)
+/wiki-enrich                        ← THIS — fills paper bodies (you are here)
+/research-wiki lint                 ← health-check (orphans, contradictions, dead ideas)
+/idea-creator "direction"           ← reads query_pack, ideates on top of enriched wiki
+/research-wiki query "topic"        ← rebuild query_pack after big wiki changes
+```
+
+After a fresh `/research-pipeline` run leaves Stage 1 Phase 1 done but Phase 2 not started (the failure mode that prompted this skill), the recovery path is:
+
+```
+/wiki-enrich              # fill the paper TODOs ingest_paper left behind
+/idea-creator "..."        # now ideate with a wiki that actually has content
+```

package/dist/skills/writing-systems-papers/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: writing-systems-papers
+description: "Paragraph-level structural blueprint for 10-12 page systems papers targeting OSDI, SOSP, ASPLOS, NSDI, and EuroSys. Provides page allocation, paragraph templates, and writing patterns. Use when user says \"写系统论文\", \"systems paper structure\", \"OSDI paper\", \"SOSP paper\", or wants fine-grained structural guidance for a systems conference submission."
+argument-hint: [venue-or-section]
+allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob, WebSearch, WebFetch
+---
+
+# Writing Systems Papers: Paragraph-Level Blueprint
+
+Structural guidance for **$ARGUMENTS**
+
+## Relationship to Other ARIS Skills
+
+- **paper-write**: General paper generation workflow with citation verification. This skill complements it with systems-specific structural blueprints.
+- **paper-slides**: Conference presentation generation (Beamer+PPTX). Already covers talks — no overlap.
+- **paper-plan**: Research outline creation. Use paper-plan first, then this skill for paragraph-level structure.
+
+**Boundary**: paper-write handles the generation workflow (LaTeX output, DBLP verification, section-by-section drafting). This skill provides the **structural skeleton** — page budgets, paragraph roles, and writing patterns specific to systems venues.
+
+---
+
+## Page Allocation: 12-Page Systems Paper
+
+| Section | Pages | Key Content |
+|---------|-------|-------------|
+| Abstract | ~0.25 | 150–250 words, 5 sentences |
+| S1 Introduction | 1.5–2 | Problem → Gap → Insight → Contributions |
+| S2 Background & Motivation | 1–1.5 | Terms + Production observations |
+| S3 Design | 3–4 | Architecture + Modules + Alternatives |
+| S4 Implementation | 0.5–1 | Prototype, LOC, engineering |
+| S5 Evaluation | 3–4 | Setup + E2E + Ablation + Scalability |
+| S6 Related Work | 1 | By methodology, explicit comparison |
+| S7 Conclusion | 0.5 | 3-sentence summary |
+
+---
+
+## Section Blueprints
+
+### Abstract (5 sentences)
+
+```text
+S1: Problem context and importance
+S2: Gap in existing approaches
+S3: Thesis — "X is better for Y in environment Z" (Irene Zhang formula)
+S4: Approach summary + headline results
+S5: Impact or availability
+```
+
+Sources: Levin & Redell — "Can you state the new idea concisely?"; Irene Zhang — "abstract cannot use terms introduced in the paper."
+
+### S1 Introduction (1.5–2 pages)
+
+1. **Problem** (~0.5p) — Domain + concrete numbers + why it matters
+2. **Gap analysis** (~0.5p) — G1–Gn: specific shortcomings with evidence
+3. **Key insight** (1 para) — Thesis: "X is better for Y in Z"
+4. **Contributions** (~0.5p) — 3–5 numbered, testable claims with §N references
+
+Pattern: hzwer Move 1 (territory) → Move 2 (niche) → Move 3 (occupy).
+
+### S2 Background & Motivation (1–1.5 pages)
+
+1. **Technical background** (~0.5p) — Define-before-use (Gernot Heiser)
+2. **Observations** (~0.5–1p) — O1, O2, O3 from production data → design insights
+
+### S3 Design (3–4 pages)
+
+1. **Architecture overview** (~0.5p) — Diagram first (Yi Ding: "draw a picture first")
+2. **Module details** (~2–2.5p) — Per module: choice, alternatives, why
+3. **Trade-offs** (~0.5–1p) — Summary of design decisions
+
+Rule: "Every design choice must discuss alternatives" (Irene Zhang).
+
+### S4 Implementation (0.5–1 page)
+
+Language, LOC, framework, key engineering decisions. Keep concise.
+
+### S5 Evaluation (3–4 pages)
+
+1. **Setup** (~0.5p) — Hardware, baselines, workloads, metrics
+2. **End-to-end** (~1–1.5p) — X vs baselines for Y on Z
+3. **Ablation** (~1–1.5p) — Remove each component, measure impact
+4. **Scalability** (~0.5p) — Behavior at increasing scale
+
+**Three-statement rule** (Irene Zhang): Every conclusion stated as:
+- Hypothesis (section opening)
+- Conclusion (section closing)
+- Caption (figure caption)
+
+### S6 Related Work (1 page)
+
+Group by methodology. For each group: what they do, limitation, how we differ.
+
+### S7 Conclusion (0.5 page)
+
+Three sentences: problem, solution, result. No new information.
+
+---
+
+## Writing Patterns
+
+### Pattern 1: Gap Analysis
+Enumerate G1–Gn in intro → A1–An in design → verify in evaluation.
+*Example*: Lucid (ASPLOS'23) — 5 gaps mapped to 5 answers.
+
+### Pattern 2: Observation-Driven
+O1–O3 from production data → insights → design components.
+*Example*: GFS (arXiv 2025) — 3 observations drive 3 components.
+
+### Pattern 3: Contribution List
+Numbered contributions in intro, each with §N cross-reference.
+*Example*: Blox (EuroSys'24) — 7 contributions; Sia (SOSP'23) — 5 contributions.
+
+### Pattern 4: Thesis Formula
+"X is better for Y in Z" structures the entire paper.
+Combine with other patterns for maximum impact.
+
+---
+
+## Conference Differences
+
+> Always verify against current CFP — rules change yearly.
+
+| Venue | Format | Pages | Camera-Ready |
+|-------|--------|-------|-------------|
+| OSDI | USENIX | 12 | 14 |
+| NSDI | USENIX | 12 | 14 |
+| SOSP | ACM SIGOPS | 12 | — |
+| ASPLOS | ACM SIGPLAN | 11 | 13 |
+| EuroSys | ACM | 12 | — |
+
+Based on 2025/2026 CFPs.
+
+---
+
+## Workflow
+
+```text
+1. Determine venue and page limit
+2. Choose writing pattern (Gap/Observation/Contribution/Thesis)
+3. Allocate pages per section using the table above
+4. Draft Abstract following 5-sentence template
+5. Draft Introduction: Problem → Gap → Insight → Contributions
+6. Draft Motivation with production observations (if available)
+7. Draw architecture figure, then write Design
+8. Draft Implementation (concise)
+9. Draft Evaluation: setup → E2E → ablation → scalability
+10. Draft Related Work by methodology groups
+11. Draft Conclusion: 3 sentences
+12. Run pre-submission checklist
+13. Hand off to /paper-write for LaTeX generation and citation verification
+```
+
+---
+
+## Quick Self-Check
+
+- [ ] Thesis follows "X is better for Y in Z"
+- [ ] 3–5 numbered contributions with §N references
+- [ ] Design discusses alternatives for every major choice
+- [ ] Eval conclusions stated 3 times (hypothesis, result, caption)
+- [ ] Related work grouped by methodology
+- [ ] Page budget within venue limits
+- [ ] No fabricated observations, traces, or results
+- [ ] All citations verified (delegate to /paper-write)
+
+---
+
+## Academic Integrity
+
+- Never fabricate observations, traces, or experimental results
+- Never generate citations from memory — use /paper-write citation workflow
+- Disclose LLM use per venue policy
+- This blueprint provides structural guidance, not copy-paste text
+
+---
+
+## Authoritative Sources
+
+1. Levin & Redell — "How (and How Not) to Write a Good Systems Paper" (USENIX)
+2. Irene Zhang — "Hints on how to write an SOSP paper"
+3. Gernot Heiser — Style Guide + Paper Writing Talk
+4. Timothy Roscoe — "Writing reviews for systems conferences"
+5. Yi Ding — "How to write good systems papers?"
+6. hzwer & DingXiaoH — WritingAIPaper (GitHub)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@research-copilot/plugin",
-  "version": "1.1.17",
+  "version": "1.1.19",
   "description": "Research Copilot plugin for Claude Code - AI research automation skills and agents",
   "type": "module",
   "main": "dist/index.js",