How to scope every prompt, revise at paragraph level, and keep analytical control across months of iterative work
The style sheet defines what good prose looks like. The build discipline defines how an analyst produces good prose at scale — session by session, paragraph by paragraph, without losing the analytical architecture the report exists to defend. This module documents the scoping principle, the four standard prompts, and the session-close ritual that held the Stellaris project together across forty-seven weeks of iterative development.
What scope determines in a prompt
The analyst who scopes a prompt to one paragraph and the analyst who scopes a prompt to the full document produce different kinds of work. Not different quality — different kinds. The full-document prompt produces a document where every section looks revised. The paragraph prompt produces a paragraph where every sentence holds. At thirty thousand words, "looks revised" and "holds" represent two entirely different reports — one the analyst can describe, one the analyst can defend.
A scoping failure in early Stellaris sessions: a prompt asked Claude to revise the introduction for clarity. Claude revised the introduction. The revised introduction no longer aligned with Section 3, where an earlier session had established specific causal relationships the introduction now contradicted. No single session saw both simultaneously. No prompt flagged the contradiction. The report looked more polished and carried a new internal conflict the analyst couldn't locate without reading both sections back to back.
Paragraph-level revision prevents this class of error — not by making Claude smarter, but by keeping each analytical unit fully visible. A paragraph fits within a single prompt's scope. A full section rarely does. A full document never does. The discipline of scoping each prompt to the smallest unit that completes one analytical task produces work the analyst can verify before the session closes.
One prompt, one task. The task names a specific unit — one paragraph, one gap, one claim — and the prompt delivers that unit only. "Revise this paragraph for passive constructions" produces a revised paragraph the analyst can accept or reject as a single unit. "Improve the writing in Section 3" produces Section 3 with distributed changes the analyst cannot evaluate as a single unit. One prompt produces a decision. The other produces a session.
The three scoping levels
Every prompt in the Stellaris workflow operates at one of three levels. Session scope defines what the session produces — one section draft, one gap-fill, one style-check pass. Prompt scope defines what the specific instruction addresses — one paragraph, one claim, one comparison. Output scope defines what Claude delivers — the revised paragraph only, not commentary on the revision, not a summary of changes, not additional improvements the prompt didn't request.
Output scope receives the least attention and causes the most problems. A prompt that doesn't specify the output format invites Claude to deliver the revision embedded in commentary, or to summarize the changes made, or to flag additional issues the prompt didn't request. The analyst reads the commentary, evaluates the suggestions, and loses the thread of what the session set out to produce. One phrase closes the escape route: "Deliver only the revised paragraph. No commentary. No summary of changes."
| Level | The question to answer before starting | Example |
|---|---|---|
| Session | What does this session produce? | Gap-fill for the Wright's Law paragraph in Section 3 |
| Prompt | What does this specific instruction address? | One paragraph · passive constructions only · no other changes |
| Output | What does Claude deliver? | The revised paragraph only — no commentary, no summary |
Claude follows the instruction as stated. A prompt that says "revise this paragraph and flag anything else in the section that might need attention" will flag other things. The session expands. The analyst addresses the flagged items. A session scoped to one paragraph becomes a session scoped to one section — and closes ninety minutes later with a version that reflects multiple partial revisions the analyst approved under momentum rather than deliberate judgment. The output scope statement prevents the drift before it starts.
The session close discipline
Every session closes with three steps in order. Step one: run the style check on all new material the session produced. Not a full-document review — the new material only. Paste each new paragraph into the style prompt and verify the output before accepting the paragraph into the live document. Step two: increment the version. Claude's draft increments the whole number (v2 → v3). The analyst's manual revisions increment the decimal (v3 → v3.1). One rule, applied consistently, means the analyst never questions which file reflects which state. Step three: log the gaps the session surfaced. Every research session surfaces new questions the draft doesn't answer. Every revision session surfaces structural gaps the existing content doesn't resolve. The gap log captures these before the session closes — one line per gap, one sentence stating what the gap requires.
Three steps. In order. Every session. The discipline produces a project history the analyst can read three months later and understand precisely — and a project state the next session builds from without re-establishing context the previous session already resolved.
File confusion costs more than sessions. The Stellaris project ran forty-seven weeks of iterative development. At that scale, a naming convention of "final," "final_v2," and "final_ACTUAL" produces a question at the start of every session: which file does Claude read? The authorship rule — whole number for Claude's drafts, decimal for the analyst's revisions — answers that question without a file directory review. One live file in the active directory. All prior versions archived. The next session opens with a single unambiguous answer to the question of what to read.
The anatomy of a scoped prompt
A scoped prompt carries four components. The reference: which file, which version, which section. The task: what to produce — one paragraph, one gap-fill, one revision. The constraint: what to fix and what to leave unchanged. The output format: exactly what Claude delivers, stated explicitly.
The reference matters because Claude reads the file the prompt points to. "Revise the introduction" sent without a file reference produces revision from Claude's working context of previous session output — which may or may not match the current live version. "Read [file path], Section 2, the introduction paragraph beginning 'The Compressed Spring mechanism.' Revise for passive constructions only" sends Claude to the specific text in the current version and constrains the revision to one type of violation.
The constraint matters as much as the task. A revision prompt without a constraint authorizes Claude to improve anything Claude considers improvable. The analyst's intention and Claude's judgment may align on the main issue and diverge on everything else. "Revise for passive constructions only. Do not alter vocabulary, restructure sentences for other reasons, or add analytical content" keeps the revision to the single task the prompt names — and keeps the session's output within the scope the session started with.
The four standard prompts
The Stellaris workflow uses four standard prompts across the full project. Session-to-session variation comes from the content the prompts reference — not from the prompt structure itself. Stable prompt structure means the analyst evaluates Claude's output against a consistent standard rather than interpreting what Claude understood from a loosely worded instruction.
-
1The gap-fill prompt — adds content that addresses a specific gapRead [file path]. The gap log entry states: [exact gap statement]. Write one paragraph to address this gap. Place the paragraph at [location — section and after which paragraph]. The paragraph states [claim] and supports the claim with [evidence type]. Deliver the paragraph only.
-
2The revision prompt — applies the style standard to existing materialRead the Master Writing Style Sheet. Apply all rules to the following passage: [paste passage]. Specifically: replace all "it" and "its" with the specific noun; replace all passive constructions with active forms; eliminate auxiliary "had" and "would"; break any em-dash construction separating subject from verb into two sentences. Deliver only the revised passage.
-
3The continuation prompt — extends a section in progressRead [file path], Section [X]. The last paragraph ends with [last sentence]. Write the next paragraph. The paragraph advances the argument by [direction — state what the argument needs next]. Do not restate what the preceding paragraph establishes. Deliver one paragraph only.
-
4The gap-check prompt — finds inconsistencies, repetitions, and unsupported claimsRead [file path], Section [X] through Section [Y]. Identify: (1) any claim that appears in more than one location stated differently; (2) any analytical assertion without supporting evidence; (3) any term from the Dictionary of Terms used inconsistently. List each instance by paragraph number. Do not revise any text. Deliver the list only.
The gap-check prompt in practice
The gap-check prompt does the work no linear session can do: it reads across the full document and finds the conflicts that paragraph-level revision introduces. A gap-fill in Session 12 may contradict a claim established in Session 4. The sessions addressed different sections under different analytical assumptions. No individual session caught the conflict because no individual session saw both sections simultaneously. The gap-check prompt sees both.
The Stellaris project ran the gap-check prompt after every major revision cycle — not every session, but every time a set of sessions substantially changed a section's analytical claims. The output from the gap-check prompt populated the gap log directly: each inconsistency or unsupported claim became a new gap-log entry with a one-sentence description of what the gap required.
What the gap log does for the next session
The gap log functions as the session-to-session memory the project requires. Each entry states three things: what the gap addresses (the topic), where in the document the gap lives (section and paragraph), and what resolves the gap (a research source, an analytical step, or a missing claim). The log accumulates across sessions. The analyst reads the log at the start of each session and selects the highest-priority gap as the session's task.
The gap log serves a second function: it catches what linear sessions miss. A session running from introduction to conclusion encounters gaps and continues past them — momentum carries the analyst forward rather than stopping to record the gap for the next session. The log breaks that momentum deliberately. A gap that surfaces at paragraph eight belongs in the log, not in the current session's scope if the session didn't start with that task.
One line per gap. Three fields: Topic — where it lives — what resolves it. Example: "Wright's Law mechanism — Section 3, paragraph 4 — needs empirical data on cost-per-watt trajectory 2010–2024 from IRENA or BloombergNEF." One minute to write. Thirty minutes saved at the next session's opening.
The discipline scales to any project length
The Stellaris project ran forty-seven weeks from first session to SSRN publication. Hundreds of prompts across two research reports, a vocabulary document, a reader's guide, and a CLAUDE.md operating manual. The build discipline — one task per prompt, paragraph-level scope, session-close ritual — held the project together across that span. Without the discipline, Session 50 produces work that conflicts with Session 12 and the analyst has no reliable way to locate where the conflict lives.
The discipline doesn't require Stellaris-scale work to produce value. A project of five sessions benefits from scoped prompts in the first session. A project of five weeks benefits from the session-close ritual in the first week. The tools don't change at scale — only the number of sessions and the depth of the gap log. Start the discipline in Session 1. The compounding benefit appears in Session 10.
Five questions to establish your build discipline
-
1What does this session produce?Name the output before the session starts. Not "work on Section 3" — "write the gap-fill paragraph for the claim that Wright's Law drives the second deployment phase." A named output carries a definition of done. "Work on Section 3" carries no definition of done and produces whatever the session's momentum determines. Name the output. The session ends when the output exists.
-
2What file does Claude read?State the file path. State the version. If the project runs in Cowork, confirm the file path before the first prompt of the session. "Read v4.2 of [file path], Section 3" tells Claude exactly what to work from. "Look at the document I shared earlier" invites ambiguity about which version Claude references — and produces revision against a version that may not reflect the analyst's latest manual edits.
-
3What constraint does the prompt carry?Name what to fix and what to leave unchanged. A gap-fill prompt authorizes adding content. A revision prompt authorizes changing existing sentences. A style-check prompt authorizes correcting prose constructions. None of these prompts authorizes the other two tasks. Stating the constraint explicitly keeps each prompt to its single function — and keeps the session's output within the scope the session started with.
-
4What does Claude deliver?State the output format before the instruction closes: "Deliver the revised paragraph only. No commentary. No summary of changes." The output format statement closes the prompt and tells Claude where the task ends. Without the statement, Claude decides where the task ends — and Claude's judgment about what the analyst finds helpful may not match what the analyst needs to evaluate the output efficiently.
-
5What does the session close capture?Before closing: run style check on new material, increment the version, log new gaps. Three steps. Each gap-log entry takes one minute to write and saves thirty minutes of context re-establishment at the next session's opening. A gap that doesn't make the log before the session closes disappears into the project's accumulated context — and resurfaces weeks later as a structural inconsistency the analyst can't locate precisely.
The session-close checklist
The Stellaris project ran this checklist at the close of every session that produced new material. Sessions that only reviewed or researched without producing a new version skipped the version increment but still ran the gap-log update. Three minutes per session close. Across forty-seven weeks of sessions, the discipline accumulated into a project history the analyst can read at any point and understand without reconstructing what the sessions produced.
- Session task named at opening — one specific output, definition of done stated
- File path and version confirmed before the first prompt
- Each prompt carries a constraint (what to fix) and an output format (what to deliver)
- Style check run on all new material before accepting the output into the live document
- Version incremented by authorship rule — Claude's draft increments whole number, analyst's revisions increment decimal
- Gap log updated — one line per gap surfaced, three fields: topic, location, what resolves it
- One live file in active directory — all prior versions archived
- Next session's task identified before closing — drawn from the gap log
What the build discipline produces at the end
A project that runs the build discipline produces something an undisciplined project cannot: a report the analyst can account for completely. Not just describe — account for. Every paragraph traces to a session. Every session traces to a gap-log entry. Every version increment traces to an authorship event. The analyst who built the Stellaris reports this way can explain any sentence in any section: what prompted the sentence, what gap the sentence addresses, what version the sentence first appeared in.
That level of accountability produced the SSRN reviews the reports received. Reviewers ask where a claim originates. The analyst who ran the discipline answers immediately. The analyst who ran undisciplined sessions describes the argument correctly but can't locate the evidentiary trail behind specific sentences — and that inability signals to specialist readers that the author commissioned the report rather than built the report.
The learning curve produced the discipline. The cold-start problem produced CLAUDE.md. The generic output problem produced the style sheet. The scope-drift problem produced the scoped prompt. Each failure named a gap, and each gap produced a tool. The tools together produce a system that runs sustainably across months of work — and produces a report the analyst can defend, not just describe. That difference — between a report you commissioned and a report you built — runs through every module in this series. The build discipline makes the difference permanent.