Writing Article Plans

Writing Article Plans

Overview

Write a comprehensive article plan assuming the drafter has zero context for the project and will write the manuscript one section at a time. The plan carries the whole argument down to the level of individual argument moves, so the drafter produces prose that realizes a decided argument rather than inventing one. This is the planning half of an academic-writing pipeline that mirrors the superpowers writing-plans → subagent-driven-development pattern.

Structure is first order here: the plan inherits its architecture — section skeleton, proportions, intro moves, footnote policy — from a per-genre structural profile extracted from a candidate manuscript (see "Genre Structural Profiles"). Prose style is entirely downstream: the drafter writes plain, correct prose and style-emulation restyles it later. A structural mistake, unlike a stylistic one, cannot be fixed downstream. In standalone mode there is no later restyle, so the drafter's plain, correct prose is the final prose: it still avoids authorial-voice mimicry, but its clarity and polish must reach delivery quality rather than a draft awaiting a restyle.

Position in the pipeline:

spec ──▶ [writing-article-plans]  ──▶ plan.md
                                        │
                                        ▼
                          section-drafter subagents ──▶ draft .tex (with % CITE slots)
                                        │
                                        ▼
                          lit-review-orchestrator   (find the literature; keyed pipeline, defaults)
                                        │
                                        ▼
                          cite-placement               (fill every % CITE slot; mode per the profile's citation architecture)
                                        │
                                        ▼
                          style-emulation           (restyle to author voice — the refinement)

The plan is always Markdown. The manuscript the drafter writes is LaTeX (main.tex + \input{sections/.tex}), so it drops straight into the existing estout / latex-results pipeline.

The deliverable is a written .md plan file on disk — not an outline pasted into the chat. The interview and the skeleton happen in conversation, but the skill is not done until the full, expanded, task-decomposed plan has been written to a .md file with the Write tool and its path reported to the user. Producing the plan only in the chat, or stopping at the skeleton, is a failure to complete the skill. Drafting the manuscript is a separate, later step that the user opts into after the plan file exists.

Announce at start: "I'm using the writing-article-plans skill to build the article plan."

Standalone Mode (style-emulation optional)

style-emulation is an optional downstream companion, not a required dependency. Before the interview, check once whether it is available: the folder ~/.claude/skills/style-emulation/ exists, or style-emulation appears in the session's available-skills list. If it is absent, standalone mode is in effect for the whole run; every other mention of style-emulation in this document is written for the installed case and is read through this switch. Standalone mode changes three things:

• The interview does not pin a restyle style, and the plan header records

Restyle style: n/a (standalone — style-emulation not installed) (with the Restyle genre line likewise for the review type).

• The downstream pipeline ends after cite-placement: the drafters' prose is

the final prose, with no restyle stage after it.

• The section-drafters are told their prose is final, so its clarity and polish

must be delivery-quality rather than a plain draft awaiting a restyle.

When style-emulation is installed the skill behaves exactly as documented, and the restyle is the pipeline's final refinement step.

Two Modes: New Article and Revision

The skill has two entry points that share the same pipeline.

new — no manuscript exists; the plan is built from a spec and drafted from scratch. Everything below applies as written.

revision — a draft already exists and the user wants it restructured or substantively revised: sections reorganized, the argument changed or sharpened, the manuscript conformed to a genre structure. The draft plays two roles: it is the spec (evidence of the argument already committed) and it is raw material (prose, citations, and numbers to preserve). Mode detection: an explicit "revise / restructure this draft" is revision mode; a draft supplied merely as background for a new paper is new; when ambiguous, ask.

Boundary with style-emulation. This skill owns changes to what is said and where — structure, argument, sections, footnote architecture. style-emulation owns changes to how it is said — authorial voice and purging AI writing patterns. A request that is purely "make this read better" routes there, even though this skill can touch existing drafts. This boundary applies when style-emulation is installed; in standalone mode the same division holds — this skill still owns only structure and argument — but there is no downstream restyle stage, so authorial-voice work is simply out of scope.

Draft inventory + gap analysis (revision mode's first step). Before the interview, run the same structural extraction used for profile ingestion on the user's draft: section inventory with word shares, the argument moves each section actually makes, evidence anchors and citations present, the footnote layer. Diff it against the selected structure profile. The gaps — an oversized intro, a missing counterarguments Part, results ahead of methodology, inline proofs the profile sends to an appendix — are what the interview and skeleton are built on. Show the inventory-vs-profile diff alongside the skeleton at approval.

Dispositions. In revision mode every existing section gets exactly one disposition, and every planned section names its source material:

• KEEP — carried over verbatim; the drafter copies, never rewrites.
• REVISE — the moves state what changes and what is retained ("keep ¶2–4's

argument on X; replace the opening; add a move on Y").

• MERGE / SPLIT — with the target sections named on both sides.
• NEW — drafted from scratch, exactly as in new mode.
• CUT — with a note on where any salvageable content goes (a footnote, an

appendix, another section, or explicitly nowhere).

Preservation discipline (the revision analog of No Placeholders):

• Existing real citations are carried through verbatim, never converted to

% CITE: slots. Slots appear only for claims new to this revision.

• Existing numbers stay; the source draft anchors them.
• KEEP text is copied byte-for-byte. A drafter who believes a kept passage

conflicts with a move flags it in a % comment instead of rewriting it.

• The original manuscript is never modified. The revision is drafted into a

fresh main.tex + sections/ tree beside it; a monolithic source draft gets a mechanical split step in the plan's file layout so the per-section drafter contract is unchanged.

Workflow

1. Interview the user to lock intent (below). This is a gate — do not write

the plan until the thesis and article type are settled. In revision mode, run the draft inventory (see Two Modes) before the interview so the questions address the actual gaps.

1. Show the skeleton in chat — thesis, contribution, argumentative spine, and

a one-line-per-section outline — and get the user's approval. This is the only part shown inline.

1. Write the full plan to a .md file. Expand the approved skeleton into the

complete task-decomposed plan (per-section move blocks below) and write it to disk with the Write tool. This file is the skill's deliverable; do not paste the expanded plan into the chat instead of writing it.

1. Write the prompt-and-choices companion .md (below) beside the plan,

recording the initial spec and every interview question with the option chosen.

1. Self-review, then run the plan red-team gate (see Self-Review below):

dispatch codex-plan-redteam.md and fix any BLOCKING findings in the plan, one round. Then report the path to the user for approval and offer the drafter handoff. Only draft the manuscript if the user then opts in.

Interview First (do not skip)

Like the superpowers brainstorming → writing-plans flow, the plan is only as good as the intent behind it. Before writing anything, interview the user to settle the decisions that most change the plan. A plan built on an unexamined thesis wastes the drafter's entire pass.

Gate: Do not write the plan skeleton until the thesis and the article type are settled with the user. This holds even when the spec looks complete — a short confirmation is cheap; a plan on the wrong thesis is not.

How to ask:

• One question at a time, in priority order. Do not dump a long questionnaire.
• Prefer multiple choice (use the AskUserQuestion tool in Claude Code) when the

options are enumerable; open-ended is right for the thesis and contribution.

• Read the spec and the project first (existing .tex, .bib, computed tables),

and ask only what is genuinely open — never re-ask what the spec already answers.

• Stop once you can state the thesis, type, structure, and evidence back to the

user without guessing.

What to settle (rough priority):

1. Thesis — the single central claim. Never invent this; if the user has not

committed to one, that is the first question. Everything else hangs on it.

1. Contribution / gap — what is new, and which alternative explanations the

paper must rule out.

1. Article type — empirical / theory / law_review / review. Default to

empirical unless the spec or the user says otherwise. The type selects the structural profile and the downstream style-emulation genre; when the genre folder holds several profiles and the choice is live, ask which structure to follow. Also pin the restyle style (installed mode only — in standalone mode skip this step and record Restyle style: n/a (standalone — style-emulation not installed) in the header): run style-emulation's pipeline.py --styles --json (a pure read, no model calls) and apply its asking rule — a sole style or a marked default resolution is recorded without asking; several styles with no marked default → ask which to use (AskUserQuestion, options carrying each style's author / source_corpus provenance). Record the result in the plan header's Restyle style line; an empty extraction tree records unpinned.

1. Evidence in hand — tables/figures computed, data available, or theory only.

This decides what is an anchor versus a % RESULT slot.

1. Target venue and length — sets section proportions and depth. Length is

always a soft guideline. When the user names no target: empirical defaults ex ante to the median Journal of Law & Economics article absent all appendixes (~14,000 words of main text); theory to the median Journal of Law, Economics, and Organization article absent all appendixes (~13,000 words of main text); law_review has no silent default — ask the user to choose between two scales (AskUserQuestion): (a) OJLS scale — the median Oxford Journal of Legal Studies article, ~13,000 words including footnotes (OJLS caps submissions at 15,000); (b) US law review scale — the median US law review article, ~27,000 words including footnotes (top journals state a ≤25,000 preference but publish 30,000+). These are approximate medians, not journal rules — record whichever default or choice was used in the plan header. The content sets the length, never the reverse: when the settled argument cannot fill the default, plan the shorter article. Do not stretch moves, add filler sections, or restate claims to approach a target — padding costs more to remove downstream than it saves, since every repeated claim must later be found and deflated.

1. Framing / positioning — the literature to engage and the causal-language

ceiling the design earns, so the plan never over-claims.

1. Constraints — coauthor directives, required structure, word limits.
2. Revision scope (revision mode) — what must change and what is

sacrosanct; whether the thesis itself moves; which structure profile to restructure toward. Anchor these questions in the draft-inventory diff, not in abstractions.

Then propose two or three structural approaches — for example, separating institutional background from the identification section versus folding them together, or a combined results-and-discussion versus a split — with a recommendation and reasoning, and let the user choose.

Inputs

The typical spec is a research proposal or an existing manuscript (the latter usually triggers revision mode — see Two Modes). Anything else that pins down intent also works: a one-line topic, a research question, an abstract, rough notes, or a results summary (tables/figures already computed). Read whatever the user gives; the interview fills the rest.

Accepted formats: Markdown (.md), LaTeX (.tex), and Word (.docx). Read .md and .tex directly. For .docx, invoke the word-docx skill to parse the document (body, footnotes, and any comments or tracked changes) before planning; do not hand-roll the extraction. Save the parsed output as a stable text artifact beside the plan (docs/plans/YYYY-MM-DD--source-parsed.md) — in revision mode this artifact, never the .docx itself, is what every anchor uses: the plan header's Source draft records the original .docx as provenance plus the parsed artifact as the working source, and all Source material / disposition-map / drafter anchors point at the artifact's section/paragraph positions, so KEEP text can be located and copied deterministically.

Citations are handled as slots only. This skill never runs a web search. A claim that needs a source is marked with a typed slot (% CITE: ), and any keys the user already provided are used as-is. Finding and verifying references is left to the user or a later lit-review-orchestrator pass.

Article-Type Detection

Pick the type from the spec; it selects the structural profile (next section) and the downstream style-emulation genre. Default to empirical unless the spec or the user states otherwise — an ambiguous spec is an empirical article, and the user corrects if that read is wrong.

| Type | Fallback sections (used only when no structural profile exists) | |------|------------------| | empirical | introduction, literature, data, methodology/identification, results, discussion, conclusion | | theory | introduction, related literature, model, analysis, extensions, implications, conclusion | | law_review | introduction, background, problem, analysis, proposal, counterarguments, implications, conclusion | | review | introduction, scope/method, thematic sections (one per theme), synthesis, agenda, conclusion |

The type names match the style-emulation genres (empirical, theory, law_review) so the downstream restyle uses the right voice spec; record the type in the plan header. review has no style-emulation genre and no structural profile; it uses the fallback row, and the plan header notes which genre the eventual restyle should borrow. In standalone mode this type-to-genre mapping is informational only — no restyle consumes it — but the structural profile the type selects still applies in full.

Genre Structural Profiles (structure is first order)

Structure is the first-order concern of this skill. The downstream style-emulation pass can fix prose but cannot restructure a draft, so the plan must get the architecture right at planning time. Each g

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: kennethkhoocy
• Source: kennethkhoocy/legal-scholarship-skills
• License: MIT

Install and usage instructions live in the source repository linked above.