mcpbeat

Limitation Weaver

willoscar/limitation-weaver

| Rewrite limitation passages so the paper keeps limitations without falling into count-based slot phrases (e.g., \"Two limitations…\") across many H3s.

938 tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
496
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/WILLOSCAR/research-units-pipeline-skills --skill limitation-weaver

The instruction itself

9 sections, as written by the author

Limitation Weaver (keep caveats, lose the slot phrase)

Purpose: keep survey-grade intellectual honesty without triggering a strong generator-voice tell:

  • repeated count-based openers (\"Two limitations…\", \"Three takeaways…\")

This is not about removing limitations.

It is about expressing them in a paper-like way that varies naturally across sections.

Inputs

Required:

  • output/WRITER_SELFLOOP_TODO.md (Style Smells section)
  • the referenced sections/S<sub_id>.md files

Optional (helps keep limitations grounded):

  • outline/writer_context_packs.jsonl (use failures_limitations / limitation_hooks / verify_fields when present)

Workflow (explicit inputs)

  • Start from output/WRITER_SELFLOOP_TODO.md (Style Smells) to locate the exact sections/S*.md files to rewrite.
  • Use outline/writer_context_packs.jsonl to keep limitations grounded in the subsection's evidence boundary (no guessing).

Outputs

  • Updated sections/S<sub_id>.md files (still body-only; no headings)

Role prompt: Caveat Editor (paper voice)

You are editing the limitation content of a survey subsection.

Goal:
- preserve the subsection-specific limitation(s)
- remove count-based opener slots and repetitive cadence
- keep limitations tied to the protocol/evidence boundary (what changes interpretation)

Constraints:
- do not invent facts
- do not add/remove/move citation keys
- do not weaken the section by deleting real limitations

Anti-pattern (rewrite immediately)

  • Two limitations stand out. First, ... Second, ...
  • Three key takeaways are ...

Why it hurts: it creates a reusable template slot that repeats across H3s and reads auto-generated.

Rewrite moves (choose one; vary across H3s)

1) Fold caveat into a contrast paragraph (preferred)

  • Put one caveat sentence as the last sentence of the A-vs-B paragraph.
  • Shape: “However, …; this matters because …”

2) Single caveat paragraph without counting

  • Start with a natural opener (rotate across H3s; avoid repeating the same stem):
  • “These results hinge on …”
  • “Interpretation depends on …”
  • “Evidence is thin when …”
  • “A caveat is that …” (use sparingly)
  • Then add one sentence that explains why it changes interpretation.

3) Verification-target framing (when evidence is abstract-only / underspecified)

  • Convert the limitation into a checkable condition:
  • “To make this comparison robust, evaluations need to report …”
  • Keep it concrete (budget/tool access/logging/threat model), and do not repeat this pattern across many H3s.

Mini examples (paraphrase; do not copy)

Bad:

  • Two limitations temper strong conclusions. First, budgets differ. Second, ablations are missing.

Better (folded into contrast):

  • ...; however, reported budgets and retry policies vary widely, which makes head-to-head comparisons fragile unless those constraints are normalized.

Better (single caveat paragraph):

  • These results hinge on under-specified verification and retry policies; this matters because success rates can shift substantially along the success–cost frontier.

Done checklist

  • [ ] No rewritten subsection uses count-based limitation openers as a default structure.
  • [ ] Limitations still exist and remain subsection-specific.
  • [ ] Citation keys are unchanged.
  • [ ] writer-selfloop remains PASS and Style Smells shrink.

How to use it

Copy the folder

Take willoscar/limitation-weaver from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.