Skip to main content
ClaudeWave
Skill4.1k estrellas del repoactualizado today

paper-section-author

paper-section-author generates a single research paper section as publication-ready LaTeX code, constrained by word count, citation budget, and narrative requirements specified in the writing plan. Use this skill when you need to write an individual section (abstract through conclusion) that maintains consistency with the paper's overall story, outline, and citation assignments while remaining compilable alongside other sections.

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/opensquilla/opensquilla /tmp/paper-section-author && cp -r /tmp/paper-section-author/src/opensquilla/skills/bundled/paper-section-author ~/.claude/skills/paper-section-author
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

# paper-section-author

You are drafting one section of a research paper as a LaTeX fragment.
Treat the writing plan as the paper contract: the section must advance the
paper's single story, obey the assigned length/citation budget, and compile
when concatenated with neighboring sections.

## Inputs you'll receive

- `section`: one of `abstract`, `introduction`, `related_work`, `method`,
  `results`, `experiments`, `discussion`, `conclusion`. Each section has a
  fixed convention — follow it.
- `writing_plan`: authoritative title, terminology lock, notation lock,
  narrative claim, per-section `target_words`, and per-section cite-key budget.
- `paper_preferences`: mode, audience, venue style, language, depth, emphasis,
  must-include items, avoid items, and defaults chosen for this paper.
- `outline`: the full 5-section outline from `paper-outline-author`.
  Use the line that matches your section as your prompt.
- `citation_plan`: claim-to-citation assignments from `paper-citation-planner`.
  Use the line(s) for your section to place citations on supported claims.
- `cite_keys_hint`: available BibTeX entries and citation keys. Cite only
  keys that appear here, using `\cite{ref1}` style.
- `previous_section_tail` (may be absent): only use it for local continuity.
  Do not summarize or rewrite the previous section.
- `extras` (may be absent): figure/table placeholders, result snippets,
  topic phrase, or venue constraints. Cite figures/tables with their provided
  labels only.

## Output contract

Pure LaTeX fragment that can be concatenated into a paper body. Each
section starts with the appropriate environment:

| section       | opener                                   | target length    |
|---------------|------------------------------------------|------------------|
| abstract      | `\begin{abstract}` ... `\end{abstract}`  | from writing plan |
| introduction  | `\section{Introduction}`                 | from writing plan |
| related_work  | `\section{Related Work}`                 | from writing plan |
| method        | `\section{Method}`                       | from writing plan |
| results       | `\section{Results}` or `\section{Experiments}` | from writing plan |
| experiments   | `\section{Experiments}`                  | from writing plan |
| discussion    | `\section{Discussion}`                   | from writing plan |
| conclusion    | `\section{Conclusion}`                   | from writing plan |

### Structure expectations

Before writing, identify the paper's one-sentence thesis from `writing_plan`.
Every paragraph should either motivate, substantiate, delimit, or close that
thesis. Do not add side topics merely to increase length.

- **Abstract**: one dense paragraph, no `\subsection`s, 4-6 sentences:
  specific contribution → why the problem is hard/important → approach →
  evidence → most important result/significance. Do not open with generic
  field hype.
- **Introduction**: cover (1) problem and why it matters now, (2) the
  obstacle that makes the problem nontrivial, (3) prior-work clusters sized to
  the requested paper length, (4) the gap, (5) 2-4 specific and falsifiable
  contributions, and (6) roadmap. Use the citation budget assigned in the
  writing plan.
- **Related Work**: organize by methodology or claim axis, not paper-by-paper.
  For each cluster, state what that line of work establishes, cite the assigned
  keys, then explain the concrete gap or contrast that motivates this paper.
  Avoid unsupported claims about what prior work "fails" to do.
- **Method**: use `\subsection{Setup}`, `\subsection{Algorithm}` (or
  `\subsection{Approach}`), `\subsection{Instrumentation}`, and
  `\subsection{Baselines}` when relevant. Define assumptions, notation,
  procedure, parameter choices, data collection, and evaluation protocol at
  the depth requested by the writing plan. Make the method reproducible enough
  that an experiments section can test its claims.
- **Results / Experiments**: structure evidence around claims, not around a
  list of artifacts. Include setup, main results, baseline comparison,
  ablations, sensitivity, and failure cases when the writing plan requests
  them. Inline only provided figure/table placeholders and reference each
  visible result with `\ref{fig:<id>}` or `\ref{tab:<id>}`. Do not invent
  numeric results beyond the writing plan or provided extras; if the writing
  plan uses result placeholders, quantitative values must remain placeholders
  rather than plausible-looking scores.
- **Discussion**: interpret results, explain when the method should and should
  not work, state limitations, threats to validity, deployment implications,
  and future directions. End with a one-sentence takeaway tied to the thesis.
- **Conclusion**: close the loop with the abstract. Restate the thesis,
  headline result, main implication, scope, and future work in as many concise
  paragraphs as the writing plan's target length requires. Add no new
  citations, figures, tables, or claims.

### Writing quality bar

- Make the section read like one part of a coherent paper, not a standalone
  blog post. Preserve terminology and notation from `writing_plan`.
- Put old information before new information. Keep grammatical subjects close
  to verbs. Put the important result or contrast at the end of the sentence.
- Use active, concrete sentences: "We evaluate..." / "The method reduces..."
  rather than "It is important to note..." or "There are several aspects...".
- Use one paragraph for one function. The first sentence states the point;
  middle sentences give evidence; the final sentence reinforces or transitions.
- Prefer precise nouns and measured claims. Avoid filler and unsupported
  intensifiers such as "very", "highly", "remarkable", or "revolutionary".

### Hard rules

- Do not call tools, inspect files, run commands, or create artifacts. Compose
  the requested LaTeX fragment from the inputs only.
- The complete paper must follow the user-requeste
advanced-dubbing-studioSkill

Submit audio or video for multilingual dubbing, poll status, and download dubbed audio. Use when the user asks for dubbing, 多语言配音, 视频翻译配音, 译制片, or wants a source clip dubbed into another language.

ai-video-scriptSkill

Generate a structured short-video shooting script from a topic. Emits a strict, machine-parseable shot list (3 shots by default) with image prompt + video prompt + voiceover + on-screen text per shot. Trigger when the user asks for a video script, 分镜, 短视频文案, AI视频, 短剧脚本, or wants visual prompts ready for image/video generation.

cronSkill

Use when the user asks to schedule recurring tasks, one-off reminders, timers, or cron-style jobs through the OpenSquilla cron tool.

deep-researchSkill

Multi-round research with explicit methodology, evidence tracking, and citation-tagged synthesis. Trigger on 'deep dive', 'research report', 'literature review', 'investigate X across sources', 'multi-round investigation'. Distinct from the `summarize` skill, which is a single-pass condensation; this skill maintains a state file across iterations, tracks coverage, and produces a long-form report with per-claim citations. Three execution stages: plan (scope into sub-questions), iterate (record evidence per round), compile (synthesize report). The skill itself does not fetch the web — it tells the host agent which fetches to perform via OpenSquilla's existing web tools, and records what comes back.

docxSkill

Read, edit, or create Microsoft Word `.docx` files. Trigger this skill whenever the user mentions a Word document, .docx file, contract, report, brief, memo, or asks to extract text, modify an existing doc, generate one from a brief, or audit tracked changes. Three execution paths: text-and-structure extraction, in-place edit-by-run (preserves styles), and create-from-scratch with python-docx. Falls back to OOXML unzip-and-patch for layout work python-docx cannot reach.

git-diffSkill

Capture the current git diff (staged, working-tree, or staged file list) as text. Direct shell call for workflows that need repository diffs without an LLM agent loop.

githubSkill

GitHub operations via `gh` CLI: issues, PRs, CI runs, code review, API queries. Use when: (1) checking PR status or CI, (2) creating/commenting on issues, (3) listing/filtering PRs or issues, (4) viewing run logs. NOT for: complex web UI interactions requiring manual browser flows (use browser tooling when available), bulk operations across many repos (script with gh api), or when gh auth is not configured.

history-explorerSkill

Query the per-turn DecisionEntry log for skill co-occurrence patterns, meta-skill usage stats, and the router fixture corpus. Returns a JSON summary suitable for downstream LLM consumption. Used by meta-skill-creator's harvest step but also useful standalone for 'which skills did I use most this week?'