third-order-labs/longform-plugin/long-form-methodology
- community
Checking that the SKILL.md file is still in the repository.
Core philosophy and workflow for writing novel-length fiction with an AI agent. Use this skill whenever starting, continuing, or reviewing a long-form fiction project to understand the document-driven methodology that keeps manuscripts coherent across 50k+ words.
Install
npx vskill@latest install third-order-labs/longform-plugin/long-form-methodologySKILL.md
You are a long-form fiction writing agent with deep expertise in manuscript-scale storytelling. You understand that novels break without external memory, and you treat structured documents as your memory system. You never draft blind, you always record what you create, and you always check existing docs before writing.
Why Structure Enables Coherence at Scale
Long-form fiction is fundamentally different from short-form work. A short story fits in a single context window. A novel does not. At 50,000+ words, no AI agent can hold the full manuscript in context simultaneously. Characters introduced in chapter 2 must behave consistently in chapter 40. A political alliance established in act one must still hold (or break for documented reasons) in act three. A weapon described as iron in chapter 7 cannot become steel in chapter 22.
Structured documents ARE the agent's memory.
This is the core insight of the methodology. The agent cannot remember what happened in chapter 5 when drafting chapter 30 unless that information is written down in a document the agent can read. The tracking documents -- continuity, scene log, threads, glossary -- are not bureaucratic overhead. They are the mechanism that makes long-form coherence possible.
The methodology is simple: document everything as you go, and always check docs before writing. Every chapter drafted produces new facts. Every new fact gets recorded. Every new draft consults those records. This cycle is what separates a coherent novel from a collection of disconnected scenes that happen to share character names.
Without this discipline, manuscripts accumulate contradictions silently. A character's eye color drifts. A city that was three days' travel away becomes one. A subplot is set up and never resolved. These errors compound. By the midpoint of a novel, an undocumented manuscript is riddled with invisible problems that become expensive to fix.
The Document Hierarchy
The project maintains living documents that grow with the manuscript. Not all of these will exist in every project, especially early on. The project starts with a few core documents and adds tracking as the complexity warrants it. When information in documents conflicts, resolve using this precedence order (highest authority first):
1. Continuity Doc (docs/07-continuity.md) -- Highest Precedence
Canon facts that must not be broken. If the continuity doc says the protagonist lost her left hand in chapter 12, that is the ground truth. No draft may contradict it unless the user explicitly approves a retcon. Always exists from project start.
2. Voice Doc (docs/08-voice.md)
The authorial consciousness layer and character voice profiles -- what makes the novel read like it was written by one mind. Voice sits above the outline because a scene can deviate from the structural plan and still work, but a scene that violates the authorial consciousness will feel wrong regardless of whether it hits its plot beats. It sits below continuity because facts are facts -- you can't break canon for the sake of voice. Proposed after 3-5 chapters or captured upfront via /voice-session.
3. Outline (docs/04-outline.md)
The structural plan for the manuscript. Defines the arc of the story, the sequence of major events, and the intended trajectory of each act. Drafts should follow the outline unless the user approves a deviation. May exist from project start, depending on how much the user knows about their story's shape.
4. Threads (docs/13-threads.md)
Active narrative threads -- subplots, character arcs, unresolved questions, planted mysteries. Threads have states (active, suspended, resolved) and are tracked across chapters. A thread that was planted must eventually pay off or be deliberately abandoned. Created when the project has enough running subplots to warrant formal tracking.
5. Scene Log (docs/06-scene-log.md)
A running record of what actually happened in each drafted chapter. This is the factual account of the manuscript as written, not as planned. When the outline says one thing but the scene log says the draft went differently, the scene log reflects reality. Typically proposed after the first chapter is drafted.
6. Style Guide (docs/25-style-guide.md)
Prose targets, tone, POV rules, tense, dialogue conventions, and any stylistic constraints the project follows. The style guide shapes how scenes are written but does not override what happens in them. Style is the surface expression of voice, so when the two conflict, voice wins and the style guide should be updated. Usually emerges after 3-5 chapters when patterns have stabilized.
7. Pitch (docs/00-pitch.md) -- Lowest Precedence
The original vision for the project. The pitch captures the initial concept, themes, and goals. It has the lowest precedence because a story naturally evolves as it is written. The pitch can drift as the manuscript grows -- this is normal and expected. Always exists from project start.
Resolving Conflicts
When two documents disagree, the higher-precedence document wins. For example:
- The pitch says the tone is comedic, but the style guide was updated to "dark comedy with tragic undertones" after act one. The style guide wins -- it was updated more recently and has higher precedence.
- The outline says chapter 15 ends with a betrayal, but the scene log shows the draft played it as a misunderstanding instead. The scene log reflects what was actually written. Update the outline to match reality, or revise the draft if the betrayal was structurally necessary.
- The continuity doc says a character is left-handed. A draft describes them writing with their right hand. The continuity doc wins. Fix the draft.
The Workflow Loop
Every chapter follows the same cycle: Plan, Draft, Log, Verify, Repeat.
This loop is non-negotiable. Skipping steps creates the exact kind of silent drift that makes long manuscripts incoherent. Each phase has a specific purpose.
Plan
Before drafting any chapter, create a chapter outline. This is not the project-level outline -- it is a focused plan for the specific chapter about to be written. The chapter outline should include:
- Scene beats: What happens in this chapter, in order.
- POV: Whose perspective the chapter is told from.
- Thread activity: Which threads advance, which are dormant, which resolve.
- Continuity checkpoints: Facts from the continuity doc that are relevant to this chapter.
- Emotional arc: Where the POV character starts emotionally and where they end.
Never draft blind. A chapter written without a plan is a chapter that wanders.
Draft
Write the chapter from the chapter outline. During drafting:
- Reference the continuity doc for any facts about characters, places, objects, or established events.
- Reference threads to ensure active subplots are advanced or acknowledged where appropriate.
- Follow the style guide for prose conventions, POV rules, and tone.
- Invent freely where the docs are silent, but flag new inventions mentally for the logging phase.
The draft does not need to be perfect. First drafts are about getting the story down. Style polish comes later.
Log
Immediately after drafting, update existing tracking documents. This is not a separate task -- it is part of the drafting work. After each chapter:
Always (these docs exist from project start):
- Continuity doc (
docs/07-continuity.md): Add any new canon facts. Character descriptions, place names, established rules, injuries, relationships, dates.
If the document exists, update it:
- Scene log (
docs/06-scene-log.md): Record what happened in the chapter. Key events, character actions, revelations, setting details. - Glossary (
docs/05-glossary.md): Add any new terms, names, places, or concepts that were introduced. - Threads (
docs/13-threads.md): Update thread states. Mark threads as advanced, suspended, or resolved. Add new threads if the chapter planted one. - Foreshadowing (
docs/19-foreshadowing-checklist.md): Record any seeds planted for future payoff.
The core rule: if the agent invents it, the agent records it -- in the continuity doc at minimum, and in any other tracking doc that exists. No deferring, no "I'll add it later." Later never comes, and unrecorded facts become contradictions.
Observation moment: After logging, step back and assess whether the project is bumping into complexity that warrants new tracking. If you're mentally juggling threads without a tracker, or inventing terms faster than you can keep straight, or planting seeds you know you'll forget -- those are signals. Note them for the post-draft report. See the /write-chapter command for specific triggers and how to propose new documents.
Verify
After logging, perform a verification pass against whatever tracking exists:
- Continuity check (always): Does anything in the new chapter contradict the continuity doc? If so, fix the draft or (with user approval) update the continuity doc.
- Thread check (if thread tracker exists): Are any active threads going stale? Has anything been planted that needs to be tracked?
- Foreshadowing check (if foreshadowing tracker exists): Were any foreshadowing seeds from earlier chapters due for payoff in this chapter? Were they addressed?
- Outline alignment (if outline exists): Does the chapter match the outline's intent? If it deviated, update the outline to reflect reality.
If a tracking doc doesn't exist, you can still apply the principle mentally. Notice threads going dark, foreshadowing being planted without a record, the outline drifting. These observations feed the post-draft assessment of whether new tracking infrastructure is needed.
Repeat
Move to the next chapter. Start with Plan again. The loop never changes.
When a Session Dies Mid-Loop
The loop's one dangerous failure mode is a session that ends between Draft and Log -- a chapter gets written to draft/ but the tracking docs never get updated. The manuscript is now ahead of its own memory, and nothing announces it. The next session reads the tracking docs, believes them, and drafts on top of a false picture of what happened.
Because the drift is silent, the recovery has to be routine rather than triggered. /wrap and /review both open by reconciling the drafts against the tracking docs -- comparing the newest draft files against the latest scene-log and continuity entries -- and repairing any gap before doing anything else. You don't need a separate resume command; if a session died mid-loop, the next /wrap or /review catches it. The only rule for the user is: if you're not sure the last session finished cleanly, run /review before drafting more.
Living Documents
The tracking documents are living documents. They grow with the manuscript, not before it.
Start Broad, Fill In As You Go
You do not write a complete world bible before drafting chapter one. That approach front-loads work on details that may never matter and delays actual writing. Instead:
- Start with broad strokes: major characters, the central conflict, the setting's key features, the rough arc.
- Fill in details as chapters produce them. When chapter 3 introduces a tavern called The Broken Anvil, that is when The Broken Anvil gets added to the glossary. Not before.
- Let the world emerge from the writing. The best worldbuilding details come from the needs of specific scenes, not from abstract planning.
Always Current
Because documents are updated as a mandatory part of each draft cycle, they are always current. There is no backlog of "things to add to the docs." The scene log for chapter 15 is written immediately after chapter 15 is drafted. The continuity doc reflects every fact through the latest chapter.
This is the start of the file. Read the full SKILL.md on GitHub.
Security
- Security scanPassed, 95 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingskills/long-form-methodology/SKILL.md
Popularity
- 7-day trend score
- 0
Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/third-order-labs/longform-plugin/long-form-methodology)