# Writing Article Plans

> Produce a detailed .md plan for an academic article that a separate drafter agent then writes section-by-section in LaTeX. This is the academic-writing analog of the superpowers brainstorming → writing-plans workflow: it first interviews the user one question at a time (thesis, contribution, article type, structure, scope), gets approval on a skeleton, then emits a task-decomposed plan that hands…

- **Type:** Skill
- **Install:** `agentstack add skill-kennethkhoocy-legal-scholarship-skills-writing-article-plans`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [kennethkhoocy](https://agentstack.voostack.com/s/kennethkhoocy)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [kennethkhoocy](https://github.com/kennethkhoocy)
- **Source:** https://github.com/kennethkhoocy/legal-scholarship-skills/tree/main/plugins/legal-scholarship/skills/writing-article-plans

## Install

```sh
agentstack add skill-kennethkhoocy-legal-scholarship-skills-writing-article-plans
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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.
2. **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.
3. **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.
4. **Write the prompt-and-choices companion `.md`** (below) beside the plan,
   recording the initial spec and every interview question with the option chosen.
5. **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.
2. **Contribution / gap** — what is new, and which alternative explanations the
   paper must rule out.
3. **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`.
4. **Evidence in hand** — tables/figures computed, data available, or theory only.
   This decides what is an anchor versus a `% RESULT` slot.
5. **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.
6. **Framing / positioning** — the literature to engage and the causal-language
   ceiling the design earns, so the plan never over-claims.
7. **Constraints** — coauthor directives, required structure, word limits.
8. **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](https://github.com/kennethkhoocy)
- **Source:** [kennethkhoocy/legal-scholarship-skills](https://github.com/kennethkhoocy/legal-scholarship-skills)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-kennethkhoocy-legal-scholarship-skills-writing-article-plans
- Seller: https://agentstack.voostack.com/s/kennethkhoocy
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.