argument-selfloop

SKILL.md

Argument Self-loop (write -> self-check -> ledger -> revise)

Purpose: upgrade C5 from “generate text” to “execute argument actions under explicit constraints”.

This skill operationalizes the mechanism you described as a reusable, pipeline-native component:

  • write section-by-section
  • self-check paragraph-by-paragraph
  • maintain a small argument ledger that makes dependencies explicit
  • revise only what fails until the chain is continuous

It complements (not replaces) the other self-loops:

  • evidence-selfloop: blocks writing when packs are not writeable (do not pad)
  • writer-selfloop: blocks template voice, missing sections/leads, scope/citation violations
  • argument-selfloop (this skill): blocks argument discontinuity and premise drift (even when prose is fluent)

Core idea: two intermediate artifacts (never in the paper)

This skill treats “argument structure” as a first-class intermediate artifact, like evidence packs.

Outputs:

  • output/SECTION_ARGUMENT_SUMMARIES.jsonl (structured; per-section/per-paragraph argument moves)
  • output/ARGUMENT_SKELETON.md (compact narrative + dependency map; not a prose restatement)
  • output/ARGUMENT_SELFLOOP_TODO.md (PASS/FAIL + actionable edits)

These files are not reader-facing and must never be merged into output/DRAFT.md.

Downstream:

  • paragraph-curator uses output/SECTION_ARGUMENT_SUMMARIES.jsonl (moves/outputs) + the ## Consistency Contract to run a controlled select->evaluate->subset->fuse pass without changing citation keys.

What this self-loop enforces (your 3 invariants)

After you complete a section (H3 or key front matter), the section must satisfy:

  1. Correct narrative linkage (paragraph-to-paragraph)
  • the relation between adjacent paragraphs is explicit (cause/contrast/refinement/boundary)
  • no silent topic-switch; no “jump cut”
  1. Closed argument loop (section-level) The section answers, in its own text (not in a hidden outline):
  • what question is it resolving?
  • what argument path does it take?
  • what is the conclusion?
  • what premises does the conclusion rely on?
  1. Premises + definitions are explicit and stable
  • new terms / protocol assumptions are defined at first use
  • the definition matches global usage (no drift)
  • task/metric/constraint assumptions do not silently change across sections

The self-check must result in concrete edits: add a missing definition, add a bridge sentence, add an explicit contrast, add a scope boundary, delete/reorder a paragraph, or strengthen the local conclusion.

Paragraph contract (argument actions)

Every paragraph must execute at least one argument action and be locally self-consistent. Use this action set (can be combined, but never empty):

  • Claim: a testable judgement/conclusion (avoid generic background)
  • Definition/Setup: introduce a concept, assumption, task definition, protocol, comparison set
  • Justification: reasoning chain or evidence support (including citations)
  • Contrast/Differentiation: clarify differences, remove ambiguity
  • Boundary/Failure: applicability limits, failure modes, threats to validity
  • Local Conclusion: a reusable takeaway / constraint that downstream paragraphs can rely on

One-sentence self-check (per paragraph):

  • "This paragraph’s action(s) are: <…>. Its output is: <…>."

If you cannot answer, the paragraph must be rewritten/merged/split until the action and output are clear.

How to run it (LLM-first workflow)

  1. Pick the scope of this pass
  • default: run it after writer-selfloop PASS, before merge
  • incremental: run it after finishing 1-2 H3s, so you catch drift early
  1. For each target section file (start with H3 bodies)
  • read the section
  • do a paragraph-by-paragraph action labeling in the ledger, not in the prose
  • identify failures (missing definition, missing bridge, missing conclusion, implicit premise)
  • apply the fix to the section file (sections/S<sub_id>.md) without changing citation keys
  1. Update the two-level ledger
  • write/update the record for that section in output/SECTION_ARGUMENT_SUMMARIES.jsonl
  • update output/ARGUMENT_SKELETON.md so it reflects:
    • the section’s functional role in the paper
    • what premises it consumes
    • what conclusions/definitions it produces for downstream sections
  1. Write output/ARGUMENT_SELFLOOP_TODO.md
  • - Status: FAIL + a list of concrete edits when any section fails
  • - Status: PASS only when all required sections are coherent and premises are stable
  1. Rerun until PASS

Output contract

output/ARGUMENT_SELFLOOP_TODO.md

Must exist and start with:

  • - Status: PASS|FAIL

Recommended structure (keep it short and debuggable):

  • ## Failures (blocking)
  • ## Fix plan (actionable edits) (per file)
  • ## Premise drift watchlist (non-blocking)

output/SECTION_ARGUMENT_SUMMARIES.jsonl

JSONL (one record per section/subsection).

Required fields per record:

  • kind: h3 | front_matter | discussion | conclusion (minimal set)
  • id: for H3 use the subsection id (e.g., "3.2")
  • title
  • section_id, section_title (for H3)
  • section_role: what this unit does in the paper (e.g., mechanism, evaluation_lens, risk_lens, synthesis)
  • depends_on: list of premises/definitions it assumes
  • adds: list of premises/definitions/conclusions it introduces
  • paragraphs: list of objects, each with:
    • i (1-based paragraph index)
    • moves (non-empty list; pick from: claim, definition_setup, justification, contrast, boundary_failure, local_conclusion)
    • output (one sentence: what this paragraph produces)

Notes:

  • This is an intermediate ledger: short, structural, no prose restatement.
  • Do not paste long sentences from the draft. Use short summaries.

output/ARGUMENT_SKELETON.md

A compact narrative/dependency map (not a retelling of the paper).

It should include:

  • each H2/H3's necessity (what gap it fills)
  • explicit dependencies (premises consumed, outputs produced)
  • a global Consistency Contract section (single source of truth) that must not drift across edits:
    • canonical terminology + synonym policy (what to call the same thing)
    • task/environment/threat-model boundary (what counts as in-scope)
    • evaluation protocol fields that make numbers interpretable (task + metric + constraint/budget/tool access)
    • comparison set naming policy (baseline families; avoid drifting labels)

Minimum format requirement:

  • output/ARGUMENT_SKELETON.md must contain a heading line: ## Consistency Contract

Change rule (regression trigger):

  • If you change any definition/protocol assumption/term naming, update the Consistency Contract first, then revise the affected sections/*.md to match, and rerun this self-loop until PASS.

Keep it "writer-facing": no reader signposting, no “in this section we…”.

Routing rules (avoid polishing around missing substance)

  • If a section cannot produce a justified claim without new evidence: STOP and route to evidence-selfloop.
  • If a section fails due to template voice / missing citations / out-of-scope keys: route to writer-selfloop / citation-* first.
  • This skill is for argument continuity and premise hygiene, not for adding new facts.

Script (validator-only)

This skill includes a validator script so the pipeline can block on missing ledgers. It does not write prose; it only checks that the required artifacts exist and that the ledger covers all H3s.

Quick Start

  • python .codex/skills/argument-selfloop/scripts/run.py --workspace workspaces/<ws>

All Options

  • --workspace <dir>
  • --unit-id <U###>
  • --inputs <semicolon-separated>
  • --outputs <semicolon-separated>
  • --checkpoint <C#>

Examples

  • Validate the ledgers exist + are PASS + cover all H3:
    • python .codex/skills/argument-selfloop/scripts/run.py --workspace workspaces/<ws>
Weekly Installs
21
GitHub Stars
296
First Seen
Jan 25, 2026
Installed on
gemini-cli20
codex19
opencode19
cursor18
claude-code18
antigravity16