Creative briefs that write themselves (almost)

I'm setting up a context layer for an always-on creative briefs system. I need your help building my context document — it'll be used to generate every brief from here on, so getting it specific matters. Walk me through these one at a time — ask one question, wait for my answer, then move to the next: 1. Product — what's the name, what does it do in one sentence, and what stage is it at? (e.g. "50 customers", "just launched", "scaling to enterprise") 2. Audience — who is the primary audience? Describe their role, what they're trying to achieve, and what they currently use instead of your product. 3. Differentiators — what are the 2–4 things that make your product genuinely different? Be specific — not "easy to use", but what specifically is easier and why it matters to your audience. 4. Voice and tone — how should content sound? Give me: 3 adjectives that describe the voice, one person or publication whose writing style you want to match, and one thing to actively avoid in the writing. 5. Who receives the briefs — is this going to an in-house marketing team, an external creative agency, or a freelance copywriter? How much product context do they already have? What does a useful brief look like to them? 6. Brief types — what are the main content formats you need briefs for? (e.g. LinkedIn posts, email campaigns, paid social, objection response scripts, event announcements, partner comms) 7. Current context — what's happening right now that should shape the next round of briefs? (features just shipped, campaigns running, objections coming up repeatedly in sales conversations, key metrics you're tracking) Once we've covered all seven, output a complete "Context brief" document — specific enough that every brief generated from it would clearly belong to this product and couldn't have been written for a generic brand. Format it for pasting directly into a Claude Project as system instructions.Copy

When I ask you to generate a brief, structure it like this: **Brief type:** [e.g. LinkedIn post, Email, Objection response] **Trigger:** [what caused this — e.g. "Feature shipped", "Objection spiked", "Weekly digest"] **Context used:** Key facts from my context brief relevant to this brief (2–3 sentences) **Opening hook options (3):** Three alternative opening lines — different angles, same quality **Content outline:** — Main message (1 sentence) — Story arc or flow (3–5 bullet points) — Call to action **Tone notes:** Specific reminders for this piece Keep briefs practical. I'm going to use this to write, not read. Be direct.Copy

Generate a LinkedIn post brief for today's [feature name] launch. We shipped this at [time]. Key facts: [1–2 sentences about what it does and why users wanted it].Copy

Generate an objection response brief for "[exact objection]". This has come up [N] times this week. Key context: [anything specific about who's raising it or when].Copy

Generate my weekly LinkedIn post brief. This week: [3–4 bullets of what happened — shipped, learned, heard from users]. Aim for a "here's my week" format that invites engagement.Copy

I want to build an always-on creative briefs system. Before we build anything, help me architect it properly. Work through these with me one at a time — ask the question, wait for my answer, move to the next: 1. Trigger design — what are the events that should generate a brief? For each: what's the source (e.g. product deployment webhook, customer conversation signal, scheduled cron, Slack keyword threshold), what's the condition that fires it (not every deployment should trigger a brief), and how do we avoid over-triggering? 2. Context layer — how is the context document stored and versioned? When someone updates the voice or sprint context, how does that propagate? Should different brief types use different context slices, or is it always the full document? 3. Brief prompt design — how should the Claude prompt be structured for each brief type? What's the system prompt vs. the per-brief dynamic content? How do we inject the triggering event's data (e.g. the specific feature name, the objection text) cleanly alongside the context layer? 4. Output quality and consistency — what's the evaluation loop? How does the team flag a brief as "not good enough" and what happens to that signal? Should there be a confidence threshold before a brief is sent, or does everything go to the queue for human review? 5. Output routing — where do briefs land? (Slack channel, Notion database, email, a custom queue) What format does each destination need? What metadata travels with the brief — trigger source, context version, timestamp? 6. Brief queue and lifecycle — how are briefs stored, status-tracked, and consumed? What states does a brief move through (generated → reviewed → used / archived)? Who can see and action briefs, and how? 7. Automation stack — given the triggers and output routing above, what's the right technical stack? Walk me through the tradeoffs between: (a) Zapier/Make for the whole flow, (b) a Claude agent via the Anthropic API with a cron scheduler, (c) a hybrid where Zapier handles triggers and the Claude API handles generation. What would you recommend for a team that wants to ship fast and maintain it themselves? Once we've worked through all seven, output: — A trigger schema (each trigger: name, source, condition, cool-down period, brief type it maps to) — A context document structure with versioning approach — The Claude API prompt chain: system prompt template, dynamic injection pattern per brief type, example for one brief type end-to-end — Output routing plan with the format each destination needs — Recommended automation stack with reasoning, and what the build order should beCopy

Based on the architecture we designed, help me build the Zapier (or Make) automation flows for the creative briefs system. Architecture doc: [paste your Step 1 output here] For each trigger in the architecture: 1. Map out the full Zap/scenario step by step — trigger app and event, any filter conditions, the Anthropic API action (model, prompt structure, how context is injected), and the output delivery step 2. Flag any steps where Zapier's built-in Anthropic integration is sufficient vs. where I'd need a webhook to a custom endpoint for more control 3. Identify the context layer approach — since Zapier can't maintain persistent state easily, where should the context document live? (e.g. a Google Doc that's fetched each run, a Zapier Storage key, a Notion page) Then give me the exact Claude prompt text for each brief type, formatted as it would appear in the Zapier "Prompt" field — with placeholders clearly marked for the dynamic trigger data that gets injected at runtime. Finally, tell me what I can't do well in Zapier that would push me toward a custom Claude agent instead — so I know when to revisit that decision.Copy

Build a creative briefs automation platform based on the architecture below. Start with a working prototype — single Node.js service, no frontend needed for v1 unless specified. Architecture to implement: [Paste your Step 1 architecture document here] Core system components to build: 1. Context manager — Load context document from a local JSON file (structure per architecture doc) — Support versioned updates: each save creates a new version with timestamp — Expose getContext(briefType) that returns the relevant context slice for a given brief type — Log which context version was used for each brief generation 2. Trigger engine — Define triggers in a config file (triggers.json): each entry has name, type (webhook/cron/threshold), condition, cooldown period, and mapped brief type — Webhook handler: Express endpoint that receives POST events (GitHub, Slack, custom), evaluates the trigger condition, checks cooldown, and fires brief generation if conditions met — Cron scheduler (node-cron): register all scheduled triggers on startup — Threshold tracker: maintain a rolling count per signal type, fire when threshold is crossed within the configured window 3. Brief generator — briefGenerator(triggerEvent, briefType) function — Constructs the Claude API call: system prompt = context layer, user message = brief type instructions + trigger event data — Uses claude-3-5-sonnet, streaming preferred so output can be shown progressively — Returns structured brief object: { id, type, trigger, contextVersion, generatedAt, content: { hook, outline, toneNotes } } — Store each generated brief to briefs.json with full metadata 4. Output router — deliverBrief(brief, destinations[]) function — Destinations configured per trigger in triggers.json — Slack: post to configured channel using Slack Bolt, format as Block Kit with brief summary and "Open full brief" link — Notion: create a page in a configured database via Notion API, structured blocks per brief section — Queue: always write to briefs.json regardless of other destinations — this is the source of truth 5. Brief queue API — GET /briefs — list all briefs with status, type, trigger, timestamp — GET /briefs/:id — full brief content — PATCH /briefs/:id — update status (pending / reviewed / used / archived) — POST /briefs/:id/feedback — add feedback note (feeds future prompt iteration) Build in this order: context manager → trigger config loader → brief generator (with Claude API working end to end) → output router → brief queue API. Get each working before moving to the next. Use TypeScript. Include a .env.example with required keys: ANTHROPIC_API_KEY, SLACK_BOT_TOKEN, SLACK_CHANNEL_ID, NOTION_API_KEY, NOTION_DATABASE_ID.Copy