defaults/project-template/STYLE.md

# STYLE.md

Use this file to define what your writing must do, contain, and prove. `STYLE.md` contains substantive rules for argument, evidence, article structure, and publication readiness.

## What belongs here

- **Argument:** thesis standards, stakes, reasoning, counterarguments, originality, and intellectual payoff.
- **Evidence:** sourcing, verification, examples, data, provenance, and the level of support consequential claims require.
- **Article structure:** openings, sequencing, sections, transitions at the level of ideas, development, endings, formats, and reader movement.
- **Publication readiness:** the substantive and structural conditions a piece must satisfy before it is ready to publish.

Do not put word choice, sentence construction, cadence, punctuation, verbal tics, or tone rules in this file. Those belong in `VOICE.md`.

Classification test: if a rule changes the claim, support, organization, or readiness standard of the article, it belongs here. If it changes wording, sentence construction, or tone, it belongs in `VOICE.md`. Split mixed feedback into separate rules.

Start with your reader promise, thematic territory, and one reliable structure. Keep durable reader knowledge in optional `AUDIENCE.md` or a maintained shared audience guide; use the assignment context when neither exists. Let the guide grow from real work.

## Writing identity

- **Body of work or publication:** [Name, if there is one]
- **What it is:** [One-sentence definition]
- **What it is for:** [The need it serves or problem it solves]
- **What makes it distinct:** [Why this writing deserves to exist]

## Audience Context

- **Governing audience guide, if maintained:** [Link to local or shared AUDIENCE.md]
- **Assignment-specific reader:** [Use the brief when the piece addresses a narrower audience]

The audience guide describes readers. This file specifies what the writing owes them. Do not duplicate the reader profile here or require an audience file before writing.

## Reader promise

Every piece should give the reader:

- [Promise one]
- [Promise two]
- [Promise three]

## Thematic territory

### Recurring themes

- [Theme or question the writing returns to]
- [Theme]

### Productive tensions

- [Value or force] versus [value or force]
- [Tension]

### Outside the territory

- [Topics or angles that belong elsewhere]
- [Subjects that require a different format or context]

## Intellectual posture

- **Claims:** [How bold, qualified, or provisional claims should be]
- **Complexity:** [How the writing handles uncertainty and contradiction]
- **Counterarguments:** [Whether and how to surface them]
- **Originality:** [What counts as a sufficiently new contribution]
- **Usefulness:** [What practical or conceptual payoff a piece should provide]

## Evidence and provenance

- [What kinds of evidence the writing expects]
- [Standards for links, citations, screenshots, examples, or data]
- [How to distinguish reported fact, personal experience, and inference]
- [Claims that require extra verification]
- [What unsupported authority sounds like and how to correct it]

## Structural principles

Treat structures as useful shapes, not compulsory formulas.

### Primary structure: [Name]

1. [Opening move]
2. [Development]
3. [Turn or complication]
4. [Payoff]

**Use when:** [Conditions that suit this structure]

**Do not force it when:** [Conditions that call for another shape]

### Alternate structure: [Name]

1. [Move]
2. [Move]
3. [Move]

## Openings

Strong openings tend to:

- [Establish a particular kind of tension, scene, claim, or need]
- [Clarify stakes by a specific point]
- [Create a reason to continue]

Avoid:

- [Common weak opening pattern]
- [Throat-clearing, context dumping, false suspense, etc.]

## Development and movement

- [How examples and ideas should alternate]
- [How quickly the argument should advance]
- [How sections earn their place]
- [Where practical instruction, narrative, or analysis belongs]
- [How the piece should handle the messy middle]

## Endings

Strong endings tend to:

- [Extend, reframe, challenge, hand over a tool, or name a tradeoff]
- [Return to or transform the opening]
- [Leave the reader with forward motion]

Avoid:

- [Summary-only endings]
- [Generic inspiration, false certainty, or sentimental drift]

## Recurring moves and formats

| Move or format | Purpose | When it works | Failure mode |
|---|---|---|---|
| [Name] | [Reader or argumentative job] | [Conditions] | [How it becomes formulaic] |

## Writing anti-patterns

| Pattern | Why it does not belong | Better move |
|---|---|---|
| [Pattern] | [Consequence for the writing] | [Revision principle] |

## Positive examples

Keep full exemplars in `examples/`. Use this section to link each example to the substantive rule it demonstrates.

### [Example title]

- **Source:** [File in `examples/` or link]
- **What it demonstrates:** [Specific substantive principle]
- **What not to imitate mechanically:** [Surface feature that is not the rule]

## Negative examples

### [Example or recurring miss]

- **Source:** [File in `examples/` or link]
- **What fails:** [Diagnosis]
- **Why it conflicts with this writing:** [Consequence]
- **Preferred direction:** [Revision principle]

## Publication readiness

Define the substantive threshold for calling a piece ready. Include unresolved argument problems, evidence gaps, structural failures, missing reader payoff, and publication-specific requirements that block publication. Sentence polish and tone checks remain governed by `VOICE.md`.

### Pre-publication checklist

- [ ] Does the piece fulfill the reader promise?
- [ ] Is the central claim clear and worth the reader's time?
- [ ] Does each section advance or complicate the piece?
- [ ] Are evidence and provenance sufficient?
- [ ] Does the structure serve this particular material?
- [ ] Is the practical or intellectual payoff earned?
- [ ] Does the ending extend rather than merely recap?
- [ ] Has the draft been checked against `VOICE.md`?

## Confirmed lessons

Add durable lessons supported by repeated publication results, editorial feedback, or explicit project decisions. Revise or remove rules that become too rigid.

- [Date or piece]: [Confirmed lesson and why it belongs in this durable guide]