said-it-already

# Said It Already ## Purpose A person's best content is what they already said out loud on a call and forgot by Thursday. The hot take that landed. The client story with the real number in it. The explanation that finally made it click for someone who did not get it. Those moments are better than anything invented at a blank page, because they were tested on a live human in real time. They are also gone. Nobody remembers what they said on Tuesday. This skill mines meeting transcripts and captured writing for those moments, screens them for who actually said them and whether they can be published, rebuilds them for reading, and hands back a content bank. **It drafts. It never posts, and it never publishes.** The scarce resource in personal content is not scheduling. It is raw material. An independent practitioner in the research archive reaches the same conclusion and solves it by asking people to record voice notes about client conversations (`references/research/distilled-content-mining-and-repurposing.md`, section 5). This skill solves it from capture that already happened. **It MINES many sources for seeds. `content-repurposer` takes ONE chosen artifact and expands it into a week.** They are siblings, not duplicates, and this skill's output is a natural input to that one. --- ## Littlebird MCP calls used Real tool names, verified against `references/littlebird-mcp-reference.md`. LIST the tools available in this session before calling anything and use the names you actually find. Do not assume a tool exists because it is named here. | Tool | Used for | |---|---| | `LB_INTERNAL_LIST_MEETINGS` | Step 3A. Enumerating the window with `start_date` and `end_date` to get the meeting inventory, including the unrecorded calendar events that carry no id and are therefore a named coverage gap. Also the correct tool for a lookup by NAME, using `name`. | | `LB_INTERNAL_SEARCH_MEETINGS` | Step 3B. TOPIC search, one pass per seed type, with `query` bounded by `start_date` and `end_date`. Using this for a name lookup, or `LIST_MEETINGS` for a topic lookup, is the most common retrieval mistake against this server. | | `LB_INTERNAL_GET_MEETING` | Step 3C. The structured summary on every meeting that returned a hit. `## For You` is the highest-attribution surface in the whole MCP; `## Decisions` and `## Action Items` carry explicit owner tagging. | | `LB_INTERNAL_GET_MEETING_TRANSCRIPT` | Step 3D. Exact wording only, and only for a meeting that already produced a candidate. Take wording from a transcript. Never take attribution from one. | | `search_user_context` | Step 3E. The sweep of the user's own written lines. `search_queries_messages` carries the four message queries and `filters.data_source` is set to `messages`; `search_queries` still carries at least one entry because that parameter is required even for a messages-scoped sweep. `date_range` is bounded to the window from step 1. `filters.data_source: snapshots` is also how a seed that lived on screen rather than in a call is reached. | | `LB_INTERNAL_LIST_ROUTINES` | Checking whether the weekly seed watcher already exists before offering to create one. | | `LB_INTERNAL_GET_ROUTINE_REPORTS` | Step 3F and the handoff. Reading the watcher's own past reports before extracting anything, so the same strong opinion is not re-surfaced every week. | | `LB_INTERNAL_GET_ROUTINE_CONFIG` | Reading the current routine before any update, because `prompt` and `schedule` each REPLACE the whole field. | | `LB_INTERNAL_CREATE_ROUTINE` | Creating the weekly seed watcher, from an interactive session only. | | `LB_INTERNAL_UPDATE_ROUTINE` | Rescheduling or retuning it later, from an interactive session only. | | `LB_INTERNAL_GET_SUBSCRIPTION_STATUS` | Explaining a plan gate or a routine-count limit. | There is no Littlebird tool that searches past Littlebird chat conversations, and there is no calendar tool. Anything that looks like `search_chats` or `get_calendar` is not real. Where a seed lives in a past chat, use `search_user_context` and say so. Upcoming calendar events, where they matter at all, come from `LB_INTERNAL_LIST_MEETINGS` with a future `end_date`. **Drafting through the user's voice is not an MCP call.** A personal voice skill is a SKILL installed in the session, not a tool on this server. Step 2 lists the available skills and looks for one. There is no `voice.apply`. --- ## Trigger Fires on: what should I post, I have nothing to write about, build my content bank, turn my calls into content, find my best quotes, I said something good on a call last week, mine my meetings for content, give me seeds for this week. Also fires when the user opens Cowork after a notification from the weekly seed watcher routine. Do NOT fire this when the user already has ONE artifact in hand and wants a week of derivatives from it. That is `content-repurposer`. --- ## Routine cadence **Weekly is the primary mode: the bank gets built once a week.** The on-demand themed mode runs whenever the user asks, over a 30 to 90 day window. The watcher runs `{"frequency": "weekly", "time": "16:00", "week_days": ["FR"]}` in the user's local timezone, so the candidate list lands before the weekend while the week is still fresh. Offer to create it rather than telling the user to go set it up by hand. `LB_INTERNAL_CREATE_ROUTINE` works from an interactive session and is only blocked from inside a running routine. Show the exact prompt text and the schedule, get approval with `AskUserQuestion`, then call it. The routine OBSERVES and notifies. The Cowork session ACTS (`references/littlebird-mcp-reference.md`, the Routines-observe Cowork-acts pattern). The attribution screen, the confidentiality screen, the spoken-to-written rebuild, the drafting and the approval gate all happen in the interactive session, because a routine cannot run an approval gate and cannot finish unattended work that requires one. Exact prompt text is in the routine wiring section below. --- ## Capability gate This skill requires the **Littlebird MCP on a Power or Pro plan**. 1. LIST the tools actually available in this session. Do not assume tool names. Use the real names you find. 2. If no Littlebird tools are present, stop and tell the user the skill needs the Littlebird MCP connected, with a link to https://support.littlebird.ai/docs/mcp/. Do not proceed from memory or guesswork. 3. If the tools are present but return plan errors, call the subscription status tool and report the plan gate. Tool surface, parameters, return shapes, and known limitations are in `references/littlebird-mcp-reference.md`. Read it before writing any query. --- ## Process ### 1. Frame the run Ask with `AskUserQuestion`, in one batch: 1. **Mode.** Weekly bank build, or on-demand for a specific theme or platform. 2. **The window.** Default is the last 7 days for a weekly run, the last 30 to 90 days for an on-demand themed run. 3. **The platform or platforms.** Which surfaces they publish to. This sets the format mix. 4. **Content pillars.** Three or four themes their content lives in. If they do not have them, propose a set from the meeting topics in the window and get agreement. Three to four pillars is standard practice (`references/research/distilled-content-mining-and-repurposing.md`, section 5). 5. **On-demand only: the theme.** The specific subject they want seeds for. Record all of it. It drives every query in step 3 and every draft in step 6. --- ### 2. Find the voice skill Do this early, not at drafting time, because the answer changes what the output is worth. LIST the skills available in this session and look for a personal voice skill: a name ending in `-voice` or `-voice-skill`, or a description saying it writes in the authentic voice of a named person. Follow `references/voice-skill-integration.md`. - **Found.** Note it. Every draft in step 6 goes through it. - **Not found.** Tell the user now, not in the final report, and offer the three voice creator skills in this marketplace: `littlebird-voice-creator`, `facebook-voice-creator`, `combined-voice-creator`. Offer to build one first, or to continue and produce drafts that carry their material but not their voice. Their choice, taken before the work happens. --- ### 3. Retrieval brief Run MULTIPLE NARROW queries, never one broad one. Broad queries return oversized results that get dumped to a file and score worse (`references/littlebird-mcp-reference.md`, retrieval patterns). Bound every query by the window from step 1. **A. Enumerate the window.** `LB_INTERNAL_LIST_MEETINGS` with `start_date` and `end_date`. This gives you the meeting inventory, including unrecorded calendar events. Only recorded meetings carry an id. Note the ones without ids as a coverage gap: those conversations happened and produced nothing minable. **B. Search by seed type.** `LB_INTERNAL_SEARCH_MEETINGS` with `query`, once per seed type, bounded by the window. The exact query sets, tuned per type, are in `references/seed-types-and-extraction.md`. In summary, search separately for: | Seed type | What the query is hunting | |---|---| | Hot take | A strong opinion stated with no hedge | | Client story | A specific situation with a specific outcome | | Objection handled | Someone pushed back and the user answered well | | Analogy or metaphor | A comparison reached for when the literal version failed | | Teaching explanation | The user explaining something to a person who did not know it | | Contrarian observation | A noticing that runs against consensus | | Number or result | A figure said out loud | Use `LB_INTERNAL_SEARCH_MEETINGS` for TOPIC lookups and `LB_INTERNAL_LIST_MEETINGS` with `name` for NAME lookups. Using the wrong one is the most common retrieval mistake against this server (`references/littlebird-mcp-reference.md`). **C. Pull the structured summaries.** `LB_INTERNAL_GET_MEETING` on every meeting that returned a hit. Read `## For You` first: it is the highest-attribution surface in the whole MCP and it is where the strongest seeds live. Then `## Decisions` and `## Action Items`, which carry explicit owner tagging. **D. Pull transcripts only where you need exact wording.** `LB_INTERNAL_GET_MEETING_TRANSCRIPT`, and only for meetings that produced a candidate seed needing a verbatim. Transcripts are long and weakly diarized. **Take wording from them. Never take attribution from them.** **E. Sweep the user's own written lines.** `search_user_context` with `filters.data_source: messages` and `search_queries_messages` populated: 1. "message where I explained how something works to someone" 2. "message where I disagreed with something and said why" 3. "message where I told someone about a client situation" 4. "message where I answered a question about pricing or process" Apply the attribution guardrail hard on this sweep. A message tagged `(From:[user])` is theirs. Everything else in the thread is not (`references/evidence-standards.md`, rule 4). **F. Read your own history.** If the weekly routine exists, call `LB_INTERNAL_GET_ROUTINE_REPORTS` before extracting anything. The same strong opinion recurs across many calls, and re-surfacing it every week is the most likely way this skill becomes useless. Read the relevance scores. Items scored 3 are maybes and do not carry a seed alone (`references/littlebird-mcp-reference.md`). --- ### 4. Attribution screening **Run this before anything else touches a candidate.** Follow `references/attribution-screening.md` exactly. A meeting has multiple speakers. Raw transcript chunks are frequently tagged `[Others]` rather than by name. Publishing someone else's line as the user's own is the highest risk in this skill and it does not degrade gracefully. Rank every candidate on the surface ladder in that guide. In short: - **High:** the summary's `## For You` section, or a Decision or Action Item tagged to the user. Draftable. - **Medium:** a transcript passage where the surrounding turns make the user unmistakably the speaker, or a two-person meeting where the other speaker is identified. Draftable, and flagged as Medium at the confirmation gate. - **Low:** anything tagged `[Others]`, anything in a meeting with three or more participants where the speaker is not independently established, and anything from screen snapshots. **Goes to the "Confirm this was you" bucket. Never drafted.** Never build a composite from two similar lines in two calls. One seed, one verbatim, one receipt. --- ### 5. The confidentiality screen **A distinct stage, and it runs before drafting, never after.** Follow `references/confidentiality-screen.md`. A meeting transcript turns a conversation that would have faded into a searchable record that can circulate well beyond its original context (`references/research/distilled-content-mining-and-repurposing.md`, section 7). The speaker did not know they were writing. Assign every surviving seed exactly one value: **Clear**, **Needs-scrub**, or **Do-not-publish**. Hard blocks, taken from a law firm's tiered meeting classification plus operating judgment: legal or privileged discussion, HR matters, trade secrets, accommodation and medical, performance and discipline, a deal in progress, a private complaint about a named person, and anything from a conversation with an implicit confidence. Scrub items: named clients, identifying detail clusters, unreleased products, a client's own numbers, a third party's words, a dropped hedge. **The do-not-publish list is a mandatory output.** A content bank shipped without one means the screen did not run. --- ### 6. Rebuild and draft Follow `references/spoken-to-written.md`, which is the craft core of this skill, then `references/voice-skill-integration.md` for the handoff. Spoken register and written register are different systems, not the same language at different tidiness levels. Only about 3% of common four-word phrase bundles overlap between conversation and written prose, and ordinary speech runs about 6% disfluent (`references/research/distilled-content-mining-and-repurposing.md`, section 1). **Extraction captures the idea and the energy. Drafting rebuilds it for reading. Never paste a transcript line as a post.** Expect the best seeds to read worst. Speakers doing the explaining are measurably more disfluent than speakers listening, and harder material produces more disfluency than familiar material (same source). The teaching explanation is the highest-value seed type and the roughest verbatim. Cut fillers, stumble repeats, dead false starts, verbal check-ins, and re-explanations. Keep word choice, emphasis repetition, dialect, concrete detail, hedges, and one rough edge. Rebuild pronoun density, clause chains, order, the opening, and paragraphing. **Do not inflate.** Material perceived as cheesy or oversentimental measurably reduces its own effect (`references/research/distilled-content-mining-and-repurposing.md`, section 4). If the user said "that was annoying", they did not say "a moment of profound frustration". Draft to the three format classes the voice skills in this repo already use: long form (500 words or more), short form (under three sentences), quick statement (eight words or fewer). Aim for a mix. Nobody publishes fifteen essays in a week. If a voice skill is installed, pass it the **verbatim** and let it own style. This skill keeps authority over facts: hedges stay, clients stay unnamed, screened seeds stay screened. --- ### 7. Confirmation gate Every seed gets user confirmation before it becomes a published draft (`references/evidence-standards.md`, rule 6). Use `AskUserQuestion`. Batch the seeds. Present, for each: the verbatim exactly as captured, the receipt, the tier and speaker confidence, and the drafted piece. The user approves the TEXT, not a plan and not a summary. Where a seed rests on Medium confidence, say so at the point of approval. A Low-rated claim never drives an irreversible action (`references/evidence-standards.md`, rule 3), and posting is irreversible. Then hand the approved drafts back. The skill does not post them. --- ## Output Write one file: **`content-bank-YYYY-MM-DD.md`**, dated to the end of the window, in the user's working directory unless they name another location. Sections, in this order: 1. **Run frame.** Mode, window, platforms, pillars, and whether a voice skill was found and used. If none was found, the offer to build one appears here. 2. **Do not publish.** Second, so nobody misses it. Every blocked and scrub-required seed with its id, its category, and a one-line reason. **The sensitive verbatim is not reproduced here** (`references/evidence-standards.md`, rule 7). 3. **Confirm this was you.** Every Low-confidence candidate with its verbatim, receipt, why the tier is Low, who else was in the meeting, and what it would become if confirmed. No drafts attached. 4. **The bank.** 10 to 15 seeds, grouped by type. Each one shows, in this order: id, type, register, theme, the verbatim, the receipt, speaker confidence, why it works, and the draft. Verbatim and draft appear together and labeled, always. 5. **Format mix.** How many long form, short form, and quick statement, so the user can see whether the week is publishable as a week. 6. **Coverage.** Which meetings in the window were mined, which had no id and therefore could not be mined, and which seed types came back empty. An empty type is information: it names a conversation the user did not have. 7. **Repeats.** Anything that appeared in a previous run's bank, with a note on how many times it has now recurred and whether it is worth a definitive piece. 8. **Method and gaps.** Which queries ran, over which window, what came back empty, and what the skill could not determine. Raw retrieved capture does not go in this file. Process it in temp space and let it go (`references/evidence-standards.md`, rule 7). --- ## Guardrail **The specific risk this skill carries: it takes words out of a private conversation and puts them under the user's name in public. Two of those moves can go wrong badly, and the third is what makes the output read as machine-written.** 1. **Publishing someone else's line as the user's own.** This is the highest risk in the skill and it does not degrade gracefully. A meeting has multiple speakers and the transcript is weakly diarized: raw chunks are frequently tagged `[Others]` rather than by name. A misattributed hot take published under the user's name is a reputational injury that a correction does not undo, and the person who actually said it will recognise it. The defense is the surface ladder in `references/attribution-screening.md`, run in step 4 BEFORE anything else touches a candidate. High comes from `## For You` or an owner-tagged Decision or Action Item and is draftable. Medium is draftable and flagged at the gate. **Low is never drafted.** It goes to the "Confirm this was you" bucket with the verbatim, the receipt, the reason the tier is Low, and who else was in the meeting. Never build a composite from two similar lines in two calls: one seed, one verbatim, one receipt. Capture proves a line was said, not who said it (`references/evidence-standards.md`, rule 4). 2. **Publishing something that was never meant to leave the room.** A transcript turns a conversation that would have faded into a searchable record that can circulate far beyond its original context, and the speaker did not know they were writing. The confidentiality screen in step 5 is mandatory and it runs BEFORE drafting, never after, because screening a finished draft invites the user to argue for keeping a good post. Every surviving seed gets exactly one value: Clear, Needs-scrub, or Do-not-publish. **The do-not-publish list is a mandatory output.** A content bank shipped without one means the screen did not run. The list names what it blocked and why; it does not reproduce the sensitive verbatim (`references/evidence-standards.md`, rule 7). Other people are in every one of these conversations, and a third party's words are a permission question rather than an editing problem (rule 10). 3. **The AI tell.** This output is published under the user's name, so a draft that reads as machine-written costs credibility the bank cannot repay. **Zero em dashes and zero en dashes in any drafted seed.** Draft through the user's voice skill where one is installed, say plainly when one is not and point at this marketplace's voice creator skills, and never infer a voice profile from a transcript or from screen capture. Do not inflate: material perceived as cheesy or oversentimental measurably reduces its own effect (`references/research/distilled-content-mining-and-repurposing.md`, section 4). If the user said "that was annoying", they did not say "a moment of profound frustration". Keeping one rough edge is the point of the rebuild, not a flaw in it. **The draft-never-send law.** Nothing is posted, published, scheduled, or written into a third-party system without the user approving the actual final text through `AskUserQuestion`. This holds even when a scheduling connector is present in the session and even when the user has approved the theme, the pillar, or the seed list, because approving a plan is not approving the words. Posting is irreversible, so a Medium-confidence seed is labeled as such at the point of approval. --- ## Empty retrieval If the searches return nothing for the window, **stop and report the gap. Do not fabricate seeds.** Say exactly which queries ran, over which window, with which filters, and that they came back empty. Then give the user the two likely causes: 1. **No recorded meetings in the window.** Check `LB_INTERNAL_LIST_MEETINGS`. Unrecorded calendar events carry no id, no summary, and no transcript, and are not searchable (`references/littlebird-mcp-reference.md`). A week of unrecorded calls produces nothing. 2. **The window is wrong.** A window off by a few days over a light meeting week returns nothing. A partial bank is reported as partial. An empty result ends the run (`references/evidence-standards.md`, rule 9). The same applies after screening: if attribution or confidentiality empties the bank, that is a real finding. Report how many candidates were blocked and why, and stop. --- ## Routine wiring: the weekly seed watcher The routine OBSERVES and notifies. The Cowork session ACTS (`references/littlebird-mcp-reference.md`, the Routines-observe Cowork-acts pattern). Drafting and the approval gate happen in Cowork, because a routine cannot run an approval gate and cannot finish unattended work that requires one. Offer it. Do not tell the user to go set it up by hand. `LB_INTERNAL_CREATE_ROUTINE` works from an interactive session and is only blocked from inside a running routine