Project Memory

What This Skill Does

Generates a structured context file from a short project brief so that an AI assistant loads your editorial voice, audience, constraints, and quality bar at the start of every session — without you re-explaining the project each time.

When To Use This Skill

• At the start of a new editorial project (magazine, podcast series, documentary, newsletter, YouTube channel) when you want every future AI session to respect the same voice, rules, and standards
• When you have been re-explaining the same constraints — tone, audience, terminology, house rules — at the beginning of each chat session and want to stop
• When a project has multiple contributors or freelancers who all need to work within the same editorial frame, and you want a single reference document the assistant can load
• After a significant editorial pivot (new audience, rebrand, format change) when the old context file no longer reflects how the project works
• When onboarding a new editor, writer, or producer onto a project and you want them to see, in one place, how the project thinks and talks
• When you notice that AI-generated drafts for your project are inconsistent — some match the voice, some do not — and you want to eliminate that variance by giving the assistant a stable reference point

What You Need To Provide

Required:

• A short project brief: what the project is, the format (magazine, podcast, newsletter, documentary series, YouTube channel, etc.), and what it covers
• Who the audience is — even a rough sketch helps ("urban professionals in their 30s who read on the train" is more useful than "general audience")
• The editorial voice and tone you want — either described in your own words or shown by example ("like the tone in this paragraph," or "think of how The Atlantic writes features, but shorter and funnier")

Optional:

• Specific do/don't rules ("never use the word 'content' to describe our journalism," "always capitalise Indigenous," "no listicles")
• Key terminology or a glossary — words the project uses in a specific way, or terms that must always appear in a particular form
• Recurring tasks you use AI for on this project (drafting headlines, editing transcripts, writing show notes, generating image prompts)
• Source and reference preferences (preferred citation format, trusted sources, sources to avoid)
• Quality benchmarks — published pieces, episodes, or issues that represent the standard you are aiming for
• Any legal or ethical constraints (anonymisation rules, embargo policies, advertising/editorial separation requirements)
• Format constraints — word counts, segment lengths, episode durations, or other hard limits the project works within
• Team structure notes — who signs off on what, how many writers contribute, whether the project has a single voice or multiple distinct voices within a shared framework

How the Assistant Approaches This

1. Reads the brief for structure. Identifies the project type (magazine, podcast, newsletter, documentary, YouTube channel), format specifics (print or digital, audio or video, long-form or short), publication rhythm (weekly, monthly, seasonal), and subject territory. If the brief is thin on any of these four, asks one round of clarifying questions — never more than one round, and never more than five questions total. The goal is to establish enough context to write a file that a cold AI session can act on, not to conduct a full editorial consultation. If the brief already covers all four, the assistant proceeds without questions.

2. Extracts the voice profile. This is the most important step and the one most likely to determine whether the context file is useful or generic. Pulls the tone, register, vocabulary level, and narrative posture from whatever the user provided — their own description, a benchmark piece, or both. If the user supplied a benchmark publication or example text, analyses it for: sentence length distribution, use of contractions, formality markers, emotional register, use of first or second person, density of jargon, and paragraph rhythm. Translates all of this into concrete, reusable instructions — not descriptions of the voice ("warm and engaging") but operational parameters ("use contractions in features; average sentence length 15-20 words; avoid rhetorical questions; first person only in columns and editor's notes"). The distinction matters: a description tells the assistant how the voice feels; operational parameters tell it how to produce that feeling.

3. Defines the audience in operational terms. Converts the audience description into parameters an AI can act on. This means answering four questions:

   • What does the audience already know? (assumed knowledge — determines the jargon threshold)
   • What do they need explained? (context requirements — how much background to provide)
   • What do they care about? (editorial priorities — what makes a piece relevant to them)
   • How do they consume the content? (format constraints — reading on phones means shorter paragraphs; listening on commutes means signposted structure)

   The audience section should be specific enough that the assistant knows, for any given reference or term, whether to explain it, name-drop it, or skip it entirely. The best audience definitions include a calibration example: a reference the audience would recognise and one they would not. This gives the assistant a concrete threshold to work from.

4. Builds the do/don't ruleset. Organises all explicit rules the user provided into two testable lists: things the project always does, and things the project never does. Then infers additional rules from the voice profile and audience definition — for example, if the voice profile says "avoid jargon," the assistant might infer "do not use 'praxis,' 'liminal,' or 'discourse' outside direct quotes." Inferred rules are marked clearly with a comment or annotation so the user can approve, modify, or remove them before the file goes into production. The test for every rule: could an editor read a finished piece and objectively determine whether the rule was followed? If not, the rule is too vague and needs sharpening. "Write accessibly" fails this test. "Explain any term that would require a Google search for a university-educated reader outside the field" passes it.

5. Structures the terminology section. Collects any terms the user specified — house-style spellings, capitalisation preferences, banned words, field-specific vocabulary — and arranges them in a three-column table (Term, Usage, Notes). Adds a framework note at the bottom encouraging the user to extend the glossary over time, so the context file grows with the project rather than going stale after the first session. For projects with significant technical or domain-specific vocabulary, this section may be the longest in the file. Even for lighter projects, the glossary establishes a shared vocabulary that prevents drift — if the project calls its introductory paragraph a "standfirst" and not a "subheading," recording that in the glossary saves repeated corrections.

6. Maps recurring tasks. If the user listed tasks they regularly use AI for, writes a structured instruction block for each one. Each block specifies: what the task is, what inputs the assistant should expect, what the output should look like (format, length, tone), and any task-specific rules that override or supplement the general voice guidelines. Task blocks should be self-contained — a future session should be able to read just one block and produce the right output without cross-referencing other sections. If the user did not specify any recurring tasks, the assistant suggests three to five likely ones based on the project type — clearly marked as suggestions rather than mandates — so the user has a starting point to edit rather than a blank section to fill.

7. Assembles the context file. Writes the complete file in the structure described below, using plain language throughout. The file is addressed to the AI assistant that will read it at the start of future sessions. Every instruction is specific enough that a different AI instance — with no memory of this conversation — could follow it and produce work consistent with the project's standards. Includes HTML comments throughout explaining how to update each section as the project evolves. Closes with an empty update log so the user has a built-in mechanism for tracking editorial drift. Before delivering the file, the assistant reviews it against the quality criteria listed below — particularly the testability of every instruction and the clarity of the inferred-rule markings.

Output Format

A single Markdown file (titled CLAUDE.md or whatever the user's system requires) structured in clearly labelled sections. The file is written in second person, addressed to the AI assistant that will read it. All instructions are concrete and testable — no vague directives like "be creative" or "maintain high quality." The tone of the file itself is direct and editorial: it reads like a briefing document from a senior editor, not like a technical specification or a marketing persona deck.

Length varies with the complexity of the project. A straightforward newsletter might produce a 100-line file. A magazine with multiple sections, format types, and a detailed house style might run 250-350 lines. The example below runs roughly 200 lines — a realistic middle-ground.

The file includes HTML comments (<!-- -->) at key points, explaining how to update each section as the project evolves. These comments are part of the deliverable — they turn the context file from a static snapshot into a living document that the user can maintain without needing to re-run this skill.

The structure adapts to the project type. A print magazine's context file will emphasise voice dimensions, format constraints, and terminology. A podcast's file will focus more on conversational register, segment structure, and the distinction between the host's voice and the show's brand voice. A documentary series will need sections on narrative arc, interview treatment, and the balance between narration and verité. The nine-section structure remains the same across all project types, but the depth and emphasis within each section shifts to match what matters most for the format.

One important constraint: the context file is designed to be read by an AI assistant, not by a human editor. While a human could read it and find it useful, its primary audience is the machine — and that shapes how instructions are written. Human style guides can rely on shared taste and editorial intuition ("you'll know it when you see it"). A context file cannot. Every instruction must be explicit enough to follow without editorial judgement, because the reader has none.

Context File Structure

The generated file contains these sections, in this order. Each section has a specific purpose, and the assistant fills it with project-specific content drawn from the user's brief. The order is deliberate: the file opens with the broadest context (what the project is) and narrows progressively to operational detail (how specific tasks should be handled). An AI assistant reading the file from top to bottom absorbs the editorial identity before encountering the rules and tasks — which mirrors how a new editor would be onboarded to a publication.

Not every section will be equally long for every project. A podcast with a simple format might have a thin Terminology section but a detailed Recurring Tasks section. A literary magazine might have a long Voice and Tone section but few recurring tasks. The structure accommodates both — what matters is that every section is present, even if some are brief.

1. Project Overview

Three to five sentences. States what the project is, what format it takes, how often it publishes, and what territory it covers. Written so that an AI assistant reading this cold understands the editorial landscape immediately.

Guidance: Be specific about format and scope. "A monthly arts and culture magazine" is better than "a publication." "Covers visual art, architecture, design, film, and music — but not theatre or literary fiction" is better than "covers culture." Include the publication rhythm (weekly, biweekly, monthly, seasonal) and the primary distribution channel (print, web, email, audio, video). If the project has scope boundaries — topics it does not cover, formats it does not produce — state them here.

Good: "Foyer is a monthly arts and culture magazine covering visual art, architecture, design, film, and music. It does not cover theatre or literary fiction. Print-first, with a web edition. Ten issues per year." Bad: "Foyer is an arts publication that covers culture." Also bad: "Foyer is a dynamic new magazine at the intersection of art and culture." (Press-release language tells the assistant nothing operational.)

2. Audience

A paragraph defining who reads, watches, or listens — and what that means for the work. Covers: demographics (age range, professional context, location if relevant), assumed knowledge level, what they come to this project for, and how they typically encounter it (morning commute, weekend reading, background listening).

Guidance: The audience section is not a marketing persona. It is an operational definition that tells the assistant how to calibrate vocabulary, explanation depth, and cultural references. The most useful audience descriptions anchor on specific knowledge boundaries: "Assume the reader knows who Gerhard Richter is but would appreciate a one-sentence context line on Hilma af Klint" is more useful than "educated, culturally aware." Describe how the audience consumes the content — this affects paragraph length, sentence complexity, and structural signposting.

Good: "They read on commutes and lunch breaks, often on their phones. Assume they know who Ai Weiwei is but would appreciate a one-line reminder of why Vkhutemas matters." Bad: "Our readers are smart, curious people who care about the arts." (This describes the audience's self-image, not their knowledge boundaries. It gives the assistant no basis for deciding what to explain.) Also good: "Listeners are parents with young children who play the podcast during the school run. Episodes over 25 minutes lose them. Assume familiarity with mainstream parenting advice but not with child development research." (Concrete consumption context plus a knowledge boundary.)

3. Editorial Voice and Tone

The most detailed section. Defines the project's voice across five dimensions:

• Register: Where on the spectrum from academic to conversational. Not a single adjective ("warm") but a positioned description with boundaries on both sides ("informed but not scholarly; the voice of a well-read friend, not a professor and not a blogger").
• Sentence style: Average length, rhythm preferences, use of fragments, tolerance for long sentences. Quantify where possible: "average 15-20 words," "no sentence over 35 words."
• Vocabulary level: What words are welcome, what words are off-limits. This is about the jargon threshold — how specialised the vocabulary can get before the assistant should pause and explain.
• Emotional temperature: How much feeling the writing carries. Where enthusiasm is welcome and where it tips into promotion. Where scepticism is valued and where it turns cynical.
• Narrative posture: Point of view, use of "I" or "we," direct address to the reader. May vary by section or format within the project — if so, specify which posture applies where.

Guidance: Specificity here prevents voice drift across sessions. "Write naturally" tells the assistant nothing. "Use contractions, keep sentences under 25 words on average, avoid rhetorical questions, and never open a piece with a question" tells it everything. The most common failure mode in this section is vagueness disguised as style direction. Pressure-test each instruction: if two writers followed it, would they produce recognisably similar work? If not, it needs tightening.

When the user describes the voice with comparisons ("like The Atlantic but funnier"), the assistant should unpack that comparison into the five dimensions above. What, specifically, makes The Atlantic's voice what it is? Long sentences, third person, expert-to-expert register, low emotional temperature, high vocabulary level. What does "funnier" change? Probably the emotional temperature (warmer), possibly the register (slightly less formal), maybe the sentence style (shorter for comic timing). The context file should capture the unpacked version, not the shorthand — because the shorthand works only for people who already read The Atlantic.

If the project has multiple formats (features, columns, social posts, newsletters), each format may need its own voice parameters. The context file should define a base voice and then note how each format departs from it. For example: "Social posts use first person and direct address. The newsletter is warmer than print features and may use humour more freely. Reviews are the most opinionated format — the voice is still Foyer's, but the emotional temperature runs higher."

4. Do / Don't Rules

Two lists — one of explicit dos, one of explicit don'ts. Each rule is one sentence and testable against an output. Rules cover editorial policy, style conventions, ethical guardrails, and format requirements.

Guidance: Rules work best when they are observable. An editor should be able to read a finished piece and determine, for each rule, whether it was followed. "Do: Capitalise Indigenous when used as an adjective or noun referring to peoples" is testable. "Do: Write with integrity" is not.

Include both the rules the user stated explicitly and the ones inferred from the voice profile — marked differently (e.g., with a comment or italic annotation) so the user can review the inferences. Inferred rules are the assistant's best guesses based on the stated voice and audience; they need human approval before becoming permanent policy.

Group rules by type when the list exceeds ten items: style rules, editorial policy rules, format rules, ethical rules. This makes the list easier to scan and maintain.

Good rule: "Never open a feature with a rhetorical question." (Observable, testable, unambiguous.) Bad rule: "Write engaging openings." (What does "engaging" mean? Two editors would disagree.) Good rule: "Every feature must include at least one concrete detail the reader could not find on Wikipedia." (Testable against a specific source.) Bad rule: "Include original reporting." (Too broad — does not specify what counts or how to verify.)

5. Key Terminology

A glossary table with three columns: Term, Usage, Notes. Contains words the project uses in a specific way, words that must be spelled or capitalised in a particular form, and words that are banned or restricted.

Guidance: Start with whatever the user provided, then add a framework note at the bottom: "Add new terms to this table as they arise during the project. Review quarterly." This keeps the context file alive rather than frozen at the moment of creation. For domain-heavy projects (medical journalism, architecture criticism, tech reporting), this section may grow to be the longest in the file — and that is fine. A precise glossary prevents more errors than any amount of voice guidance.

6. Recurring Tasks

A numbered list of tasks the user regularly asks the AI to perform on this project. Each task entry includes:

• A one-line description of the task
• The typical inputs the assistant should expect
• The expected output format (length, structure, tone)
• Any task-specific rules that override or supplement the general voice and tone

Guidance: Not every project has recurring tasks defined at the start. If the user did not specify any, include three to five likely tasks based on the project type — for a magazine: drafting headlines, editing interview transcripts, writing social teasers, generating image prompts, summarising research; for a podcast: writing show notes, drafting episode descriptions, preparing guest research briefs, writing ad-read scripts — and mark them as suggestions the user can keep, modify, or remove.

Each task block should be self-contained: a future AI session should be able to read just that block and know exactly what to produce, without needing to cross-reference other sections. However, all task blocks inherit the general voice and tone unless they explicitly override it.

7. Quality Bar

A short section that defines the minimum standard for work on this project. References a benchmark if the user provided one. States what "good enough to publish" means in concrete terms — not aspirational language, but a checklist the assistant can self-evaluate against before presenting output.

Guidance: The quality bar should be honest about the project's actual standards, not an idealised version. A daily news podcast has different quality requirements from a quarterly literary journal. A YouTube channel posting three times a week operates under different constraints from a monthly documentary series. Both are valid. The context file should reflect the real bar, not the aspirational one.

Frame criteria as pass/fail checks rather than quality scales. "Every claim is grounded in a concrete detail — a date, a place, a name" is a pass/fail check. "The writing should be high quality" is a quality scale that tells the assistant nothing actionable.

If the user provided a benchmark publication or piece, reference it here by name. The benchmark gives the quality bar a concrete anchor: instead of defining excellence in the abstract, the context file says "if this draft would not hold its own next to a piece from [benchmark], it needs more work." That comparison is more useful than any checklist — but include the checklist too, because the comparison requires editorial judgement while the checklist can be applied mechanically.

8. Sources and References

Defines how the project handles sourcing: preferred citation format (if any), trusted sources, sources to avoid or treat with caution, and any rules about attribution or linking.

Guidance: For journalism projects, this section is critical — it shapes how the assistant handles claims, quotes, and factual grounding. For creative projects (scripting, image prompting), it may be minimal. Either way, include it — even a single line ("No specific sourcing requirements for this project") prevents the assistant from inventing a policy or applying conventions from a different domain.

Organise sources into three tiers: trusted (use freely), caution (use with caveats), and avoid (do not cite unless the source itself is the story). This gives the assistant a clear decision framework when it encounters a reference it has not seen before.

For projects that handle sensitive material — investigative journalism, health reporting, legal affairs — this section should also address: anonymisation rules (when and how to protect sources), embargo policies (how to handle pre-release information), and the separation between editorial and commercial interests (whether advertiser-adjacent topics require disclosure or recusal). Even if the project is a lifestyle magazine with no investigative mandate, stating "no specific sensitivity constraints apply" is better than leaving the section silent — silence invites the assistant to make assumptions.

9. Update Log

An empty table with columns for Date, Section Changed, and What Changed. Placed at the end of the file so the user has a built-in mechanism for tracking how the context file evolves.