Genia JacquesWebsite

Ask first

• Where do you write? (default email, direct messages, posts and comments)
• Do you have 20 or more pieces you sent to learn from? (default yes)

Needs

- Your voice rules: who you are and are not as a writer, tone by context, and words you never use. Mine stay private; have your assistant interview you for 20 minutes and study 20 sent emails and five posts.

- A generic starter, not mine, to replace after your first week of edits:

Tone: write it the way you would say it to the person across a table.

Never: "per my last email".

Mechanics: one ask per message, on its own line.

- A log for your corrections.

- If your assistant can only chat: paste your rules at the top of each chat and say "voice check this".

Build

1. Read: your rules and the rules still on watch, every time, plus real examples of this kind of message and the facts about your work (from your context layer).
2. Decide: pick the context (formality, energy, depth), then apply your constants, your tone and the mechanics.
3. Check: a script fails anything never allowed (banned phrases, unfilled placeholders) and flags patterns to judge. A second scan scores how machine-written it sounds and flags any number, date or link lost or invented.
4. Deliver: the draft, one line per change, and a list of claims. Every commitment, date, number, cause, or thing you did needs a source; anything unsourced means not ready to send.
5. Learn: every correction that changes meaning, tone or structure is logged. Repeated corrections become a rule on watch, then a candidate, and a rule changes only with your approval, one at a time (see the Find Patterns run).

Check

• Feed it a draft with a banned opener and an unsourced number: it fails and says it is not ready to send. Make one edit and confirm it was logged.

In my version

• MyVoice, my own Claude skill, used in Cowork and Claude Code. Rules on watch sit in a file it reads on every run, so they apply at once; a rule promoted into the skill itself lands when I reinstall it. Find Patterns proposes promotions when I run it from weekly planning. The first draft of every email is saved, so I can measure how much I edit before I send.

Ask first

• Whose profile? (default your own; someone else's only from a link they gave you, and that rating stays private)
• Who is your buyer? (default the one in your positioning file; otherwise four questions: who you help, what you fix, the alternatives, why you)
• Audit, rewrite or re-rate? (default audit first, then rewrite the weakest parts)

Needs

• Read access to the profile through a browser you are signed into, read-only. Pasted text works too.
• Your positioning: who you help, what you fix, why you. Mine stays private.
• A short list of profile calls you have already made, so it does not argue them again.
• A folder for dated profile snapshots and a one-line score log.
• If your assistant can only chat: paste your headline, About, Featured and current role and say "rate this out of seven as a demanding magazine editor, then tell me whether my buyer would know it is for them."

Build

1. Read: the live profile in the order a visitor sees it, banner text included, plus your positioning, your calls, and the last snapshot and score.
2. Decide (structure): each part green, yellow or red against plain rules: a banner that works as a billboard, a headline that says who you help and the outcome, an About that opens with the buyer's problem and ends with a next step, outcomes in Experience, recent and specific recommendations, a booking path, and a sweep of the small fields.
3. Decide (reader test): an editor reads it and scores 1 to 7, Threadbare to Unforgettable, with story, personality and memorable each 1 to 5. The overall has to agree with the three, and most profiles land at 3 or 4.
4. Decide (buyer fit): a second score, 1 to 5, for whether your buyer sees in the first lines that it is for them and knows what to do next. My checks stay private.
5. Decide (your calls): where a rule disagrees with a call on file, it shows once as "your call" with a recommendation, never as red.
6. Rewrite: two options for the headline and the About opening, one for the rest, in your voice (see the voice run), each with a line on why it works.
7. Deliver: the scores in one line, then ten actions at most: this week, the next two weeks, every quarter.
8. Record: a dated snapshot of the text and, for the live profile, one row in the score log. The next rating starts from it and says what moved.

Check

• Rate a profile you know well, then a deliberately weak one: the weak one scores lower on every lens, and no rewrite appears before the scores.

In my version

• A Claude skill in Claude Code and Cowork that reads LinkedIn through my own Chrome, read-only. The 1 to 7 reader test comes from the run this one is built on, with step definitions I wrote. The buyer-fit score is mine. The structure rules come from my earlier skill, built on Justin Welsh and Richard Moore.

Ask first

• In person or online? (default in person)
• Who matters most? (default founders, then people who refer work, then product leaders)
• Any filters? (default your region first, vendors in your field last)
• A phone page? (default yes when the event is within 48 hours)

Needs

• The event page, read in a browser you are signed into, read-only. Screenshots work as a fallback.
• Your contact list, your pipeline and a recent export of your network connections.
• Who your best-fit people are, in two or three lines.
• If your assistant can only chat: paste the guest list and say who you want to meet.

Build

1. Read: page text first. Agenda images are read and transcribed word for word. Guest lists by scrolling; never a script on LinkedIn. A login wall gets one line and no more time. Date every list.
2. Decide (known): match every name against your pipeline, contacts and export, exact names only. Anyone you are already working who is there goes first. Near misses are listed separately and never counted.
3. Decide (shortlist): by room in the order of your day, then by priority: 15 to 20 for one room, 5 to 10 per room, 30 at most for a full day. Never research the whole list.
4. Decide (research): light web research on the shortlist only. A profile link comes from the event page, your export or a search result; otherwise "not found".
5. Draft: one or two spoken opening questions per person, about their work, not yours.
6. Deliver: one prep note; a script check (headings, links, no missed matches); a fresh reviewer for facts, at most three rounds; a pinned phone page for the day.
7. Hand off: anyone you write to, before or after the event, joins your pipeline when you log the note, which sets when to follow up (see the pipeline run).
8. Memory: the note, the list, and a log of every click.

Check

• Run it on a past event into a scratch folder: everyone you knew there is under "You already know", and every title matches the event page.

In my version

• A Claude skill in Claude Code, reading Luma and LinkedIn events through my own Chrome. My network comes from a LinkedIn export and my contact notes. The phone page is a pinned claude.ai artifact.

Ask first

• What should every session know before it starts? (default who you are, what you sell and to whom, what you are focused on now, and how you like to work)
• How should it be split? (default one file per topic, so each fact lives in one place)
• When is a file stale? (default a window you choose)
• Who approves an edit? (default you, every edit, except a plain fact gone stale, which is corrected and reported)

Needs

• Your context files. Mine stay private; start by having your assistant interview you on who you are, what you sell and to whom, and what you are focused on now, and keep only what you would stand behind.
• A short instruction file your assistant loads every time, pointing at those files.
• A notes file for corrections.
• If your assistant can only chat: paste your files into its project instructions, or at the top of each chat.

Build

1. Shape: one file per topic, each with a last-updated date at the top. A fact lives in one file; everything else points at it.
2. Load: the instruction file tells every session to read the context files first. It points at them rather than restating them, so there is one version.
3. Read: the runs that need them start there: the overnight routines behind your morning brief, meeting prep, drafting in your voice, planning.
4. Flag: a file past your stale window gets one line saying so. Not a proposal, just the fact.
5. Propose: when a session turns up something that contradicts a file, or a lasting change (what you offer, when you are available), it proposes the specific edit at the end and asks before writing. A stale fact it can check on the spot, like a trip that has ended, is corrected and reported (see the Retro run).
6. Close out: when a task that changes your situation closes, the task system proposes the edit.
7. Learn: a mistake is written down once in the notes file, so it is not made again. One that repeats is proposed as a rule for the file that owns it (see the Find Patterns run).
8. Rule: a rule that must hold on every answer goes in the instruction file, because a rule kept in a log is not open when the answer is written.

Check

• Ask a new session something only your files can answer: it answers from them and names the file.
• Backdate one file: the next session says it is stale in one line and proposes nothing.

In my version

• Nine markdown files and a memory folder, read by Claude Code and Cowork, each pointed at them by its own instructions. Find Patterns proposes rules when I run it from weekly planning, and no rule is written without my yes.

Ask first

• Which newsletters, and which matter most? (default about 10 you always read, plus your newsletter inbox)
• When should it arrive? (default 4am daily, so it is ready when you wake; a roll-up on Mondays)
• How many actions a day? (default 8 at most: up to 3 each of act, post idea and keep)
• How many times should an unanswered item show? (default 3)
• How fast do you read? (default 230 words a minute)

Needs

• Read access to your newsletters through a browser you are signed into, read-only.
• Your task list, your list of post ideas, and what you have already saved.
• A short list of the topics that matter to you now, and a post test (who it is for, what you can show). Write your own.
• A small ledger the routine updates through a script, so showings and expiry are enforced, not remembered.
• If your assistant can only chat: paste the week's subject lines on Monday and ask for three themes and three actions.

Build

1. Read: everything published since the last run, padded by two hours. If it already ran in the last 16 hours, stop and write nothing.
2. Decide (summary): two or three sentences per post, grouped under a few themes, with read time and a paid flag.
3. Decide (actions): A is an addition to a task you already have; a new task only if it is one concrete action you would start within four weeks. B is a post angle that passes your post test; with no proof of your own it says "comment first". C is a source worth keeping, pointing at the original study when a post rests on one.
4. Decide (dedupe and score): drop anything already in the ledger, your ideas or your saved sources. Score fit 0 to 3, urgency 0 to 2, ease 0 to 1, and show the top eight.
5. Deliver: a pinned page and an email draft to yourself, never sent, with a "ten minutes: stop here" marker. Keep the three newest pages pinned.
6. Review (with you): reply in one line. Each yes becomes a dated note on the task, an idea on your list or a staged source. Nothing is written until you reply. "Done" retires everything you did not name, except "later".
7. Memory: the ledger, one row per showing and decision. An item shown three times without an answer expires.

Check

• Point the ledger script at a copy and run a fake reply: labels are unique and a fourth showing is refused.
• Run the routine into a scratch file: at most eight items, each decidable from its own line.
• Quiet run: a day with no new posts shows only carried items, or says there is nothing in your queue.

In my version

• A Claude scheduled task in Cowork at 4am, bound to my Mac, reading Substack through my own browser and newsletters that arrive by email through Gmail. The review is a Claude skill in chat. The page is a pinned claude.ai artifact, and a second task at 4:45 keeps the three newest pinned.

Ask first

• Neutral capture? (default yes; your opinions go in your own section)
• An analysis section? (default yes, labeled as the assistant's read and never saved as a source)
• Photos? (default ask after every in-person event)
• Where do ideas go? (default things to cite go to your second brain, things to act on go to your playbooks)

Needs

• The prep note from the event scout run, the agenda, your recorder's notes and your own words.
• Slides and photos, with location data stripped.
• A keep test for your second brain.
• If your assistant can only chat: paste your notes and say "write the event note".

Build

1. Read: the agenda first, before naming anyone; then the recorder; then your words; then every image.
2. Decide: sort into said, shown and asked; shown wins over said. Never attribute a question to you from the transcript alone. Unchecked spellings and unsourced numbers are marked.
3. Decide (people): a contact file only after a real one-to-one, proposed, not created. Host and speaker: connected, worth it, or not worth it, with a reason.
4. Decide (keep): run the keep test. Sales pitches go nowhere, and anything marked do-not-share never becomes a source.
5. Deliver: one message with the note, the people and the tasks, after a script check and a fresh reviewer for neutrality. Write only on your yes.
6. Memory: the note with its check line, and which shortlist picks you met.

Check

• Run it on a past event into a scratch folder: no sentence puts an opinion in your mouth, and every number has a source or a mark.

In my version

• A Claude skill in Claude Code or Cowork, reading Granola. Event notes live in my Obsidian vault, kept apart from meeting notes.

Ask first

• Which columns? (default this week, next 2 to 4 weeks, holding, done)
• How many big projects at once? (default 5, counting a project once however many tracks it has)
• What counts as quick? (default one sitting, under 30 minutes)
• When is the sweep? (default Friday, early morning)
• Where do you capture on the go? (default your phone's reminders)

Needs

• A folder of plain text files, one per task, each with a short header: title, status, category, owner, created date, and optionally who it waits on, its parent project and a due date.
• A board that reads the folder: any app that reads files, or a small one your coding agent builds.
• Your calendar and your phone reminders.
• If your assistant can only chat: keep one list in a document and ask each Friday "what can you do, and what needs me?"

Build

1. Capture (daily): each phone reminder becomes a task file after a duplicate check; a garbled one is left in place and flagged. A reminder is deleted only once its file exists.
2. Who has the ball: worked out from the owner and who it waits on: mine, queued for AI, agent running, my call, waiting on others.
3. Needs you: when a task waits on you, the top of the file says exactly what: at most three asks, each with a recommendation, what to open and rough minutes.
4. Register work: any AI starting real work on a task adds a dated note first, so another tool or session does not redo it. At the end of the session, the retro adds a dated note on what the session did (see the Retro run).
5. Sweep (Friday): every active task ends with a plan backed by evidence, a proposed plan, staged prep, a surfaced decision, or a stated reason to skip. Up to eight AI tasks are worked. Tasks waiting on others are left alone; agent tasks with no note in 3 days are flagged.
6. Plan (weekly, with you): see the weekly planning run.
7. Close: a finished task gets a line in a completed log and a short completion note: what happened, lessons, what it spawned. Anything it spawned is proposed, never filed on its own.
8. Big AI tasks: before working past planning, the agent asks three to six questions with recommended answers, writes a short say-back, and waits for "go".

Check

• Copy the folder, point the sweep at the copy, and compare: every active task ends in one of the five outcomes, and nothing was marked done or moved.

In my version

• Markdown files on Google Drive, a React board my coding agent built, and Obsidian as a viewer. The Friday sweep is a Claude scheduled task in Cowork at 4am, Apple Reminders are captured daily, and weekly planning is a Claude skill.

Ask first

• Where should the archive live? (default a folder outside any synced drive; ask before creating it)
• From what date? (default today)
• How long did each kind of task take you by hand? (default a short interview, one task at a time, answers recorded word for word)

Needs

• Your AI tools' local session logs.
• A coding agent to build the script once.
• If your assistant can only chat: note start and end times for a week, then divide AI time by your time.

Build

1. Read (nightly): copy new or changed session logs into a compressed archive outside any sync. Never delete.
2. Decide (time): AI time is every gap ending in the AI's own activity, up to 60 minutes. Your attention is every gap ending in your message, if 5 minutes or shorter, so it is a lower bound.
3. Decide (ratios): AI hours divided by your hours, three ways: one tool only, only the work you direct, and everything including scheduled routines. Always say which.
4. Decide (output): count what the system produced per kind of work against your baselines. AI hours are never called hours saved.
5. Deliver: a dated report and a dashboard. A shareable version replaces session titles with themes and is republished to a pinned page when you choose.
6. Memory: a ledger with one row per session: times, counts, model, tokens, tool names. Never message text.

Check

• Recompute one week's ratio from the ledger in a scratch script and match it to the report.

In my version

• A Claude Code scheduled task at 3:30am running one Python command, a weekly task that pulls my cloud routines' run history, and Cowork chats that add their own row when they close. The shareable dashboard is a pinned claude.ai artifact.

Ask first

• What time and days should the brief arrive? (default 8am on weekdays, in your time zone)
• Which calendars are your commitments, and which only block time? (default all personal and work calendars; public feeds excluded)
• When is someone late? (default 5 business days waiting on them, 1 business day owed by you)
• Whose mail always counts as urgent or important? (default whoever you are working for now and your closest referrers, from your contact notes)
• How should travel time look? (default 60 minutes in a big city, 30 elsewhere, inside business hours)
• Should the page have a cap? (default no; a long page means a rule is wrong)

Needs

• Your sent mail and inbox, read by full thread.
• Every calendar you keep.
• A short written list of what deserves your attention right now (part of your context layer), and your task list. Write your own; mine stays private.
• A place each overnight routine can leave a note for the brief. I use a dated draft addressed to myself, one per routine.
• Connecting mail: "It reads threads and writes notes to you; it never sends, archives or replies."
• If your assistant can only chat: paste yesterday's sent subjects and today's calendar each morning and ask "who owes whom, and what is today?"

Build

1. Read (open loops, before dawn): sent mail from the last 45 days and inbox threads from people you know from the last 14. If the search returns far fewer threads than usual, stop, change nothing, and say the search failed.
2. Decide (open loops): always read the full thread. Classify from the last message addressed to the other person: your ask means waiting on them, their ask means waiting on you, an acknowledgment closes it. Age is never the reason. A call that already happened closes the thread.
3. Decide (what makes the page): you owe something, your own date is due, a nudge is due, or someone is blocked on your decision. A date the other person named overrides the defaults.
4. Read and decide (new mail): only threads you have not written in and open loops does not already hold, from the last day (three on Mondays). It keeps urgent mail (the sender is on today's calendar, a deadline is today or tomorrow, you owe them something this week, or a client is asking) and important mail (a direct question, a referrer, someone blocked on you).
5. Read and decide (communities and events): score each post or invitation against your list; show the clear yeses, with any doubt stated.
6. Deliver (open loops and new mail): a note in a fixed shape, one block per item: who, the state in a short phrase, the one next move, a link. Communities and events can be short prose. An empty note means it ran and found nothing.
7. Deliver (calendar): travel time before and after in-person meetings, on your personal calendar only, never over another event. Orphan blocks are flagged, never deleted.
8. Watch (overnight): a check compares your other routines with their schedules and leaves one line for any that missed a run or is stuck waiting on an approval nobody gave. When nothing is wrong, it leaves nothing.
9. Deliver (brief): the calendar, then each note in order, word for word. A missing note prints "has not run yet". The brief never runs its own inbox search to fill a gap.
10. Memory: a ledger of each thread's state, plus drops you mark with a mail label and snoozes you set in one sentence. Each routine keeps one note at a time; today's replaces yesterday's.

Check

• Run each routine with "dry run: write no note, label or event; print the note here." Every block has who, state and move, and no thread appears twice.
• Delete one note and run the brief: it says that routine has not run yet.
• Quiet run: a day with nothing owed shows an empty Open loops section and a time stamp for each routine.

In my version

• Claude scheduled tasks in Cowork, bound to my Mac, with Gmail and Google Calendar connected. Travel time at 3:30am, open loops at 4:00, new mail at 4:30, communities and events at 4:45, the stopped-routine line at 4:50, the brief at 8:00. Notes travel as dated Gmail drafts to myself, never sent. Eleven calendars.

Ask first

• Which meetings get a brief? (default any with someone outside your household and your own team)
• When? (default 5:30pm on weekdays, for the next business day; Friday covers Monday)
• How long? (your own word count for the part you read first; detail goes below a fold)
• Coaching from past debriefs? (default yes; you set how many items)

Needs

- Your calendar, your notes on people and past meetings (your person files), recent email and web search.

- A scorecard of what good looks like for each kind of meeting, and a log of past debriefs scored against it (from the meeting debrief). These are my method and stay private; build yours by having your assistant interview you for 20 minutes about your last five meetings.

- A generic starter, not mine, to replace after five debriefs:

First call with a possible customer: they described the problem in their own words; you learned who else decides; you left with a dated next step.

Someone who could refer you: they can say in one line who you help; you asked for one specific kind of introduction; you offered something useful back.

Catch-up with a peer or adviser: you brought one question you could not answer alone; you shared something you are working on; you agreed on one thing to send or try.

- Connecting mail: "It reads recent threads with the people you meet; it never writes to them."

- If your assistant can only chat: say "prep me for X tomorrow" and paste the last thread.

Build

1. Read: tomorrow's calendar. Skip meetings that already have a brief, travel blocks and internal holds.
2. Read: your notes on the person first, then recent email, then their public pages. Research until your own minimum is met.
3. Decide (type): sort the meeting into a type from your notes. Run unattended, it states the type it assumed and what changes if that is wrong.
4. Decide (coaching): read your recent debriefs and keep only what your scorecard scores for this type of meeting. Pick what to practice by your own rule. Each item gives an exact line to say and the moment to say it.
5. Decide (write): tag every claim by how well it is sourced, on your own scale. Ask a few questions sized to the length of the call, and give one recommendation, never a menu. Before saving, check that the brief tells you something new, or go back to research.
6. Deliver: save the brief beside your meeting notes, run a script check on length and format, and rebuild one phone page for tomorrow, overwritten nightly.
7. Memory: the briefs, and a link line in each person's notes.

Check

• Run it on yesterday's meeting into a scratch folder: every claim traces to a source, and the coaching names a past debrief.
• A day with no outside meetings: the phone page says so.

In my version

• A Claude scheduled task in Cowork at 5:30pm calling my meeting-prep skill, unattended. Gmail and Google Calendar connected, my notes in Obsidian, seven meeting types. The phone page is a pinned claude.ai artifact.

Ask first

• How many posts a week? (default one)
• What do you want to be known for? (default three topics)
• Which formats? (default two or three lengths you actually write)

Needs

• Your second brain or idea list, your voice guide and a panel to test against, each its own run on this page.
• My topics, formats and lessons file stay private; start by naming three things you want to be known for and one post you wish you had written.
• If your assistant can only chat: paste your idea and say "ask me three questions, then draft".

Build

1. AI pitches. Your idea list fills from your own work and reading: lessons captured at the end of working sessions, the beliefs in your experience records, and post angles from your reading and events. You can also name a topic. For each idea it pulls your topic pages, your first-hand records, any position you have argued, and what you already published, then ranks a short list on four tests: is the claim clear, do outside sources support it, have you lived it, and have you said it before. Repeats drop out; a changed mind ranks first. You pick one, and the format sets how many steps follow.
2. AI asks three questions: the tension, one specific moment, the proof. You answer, and your words are kept word for word.
3. AI drafts in your voice from your answers, after reading what you changed last time.
4. You give all your notes on a version in one batch. Each version gets a mechanical check and a character count.
5. For a longer post, AI runs the panel at the outline stage; otherwise near the end. Disagreements come to you; it never settles them for you.
6. AI checks the hook fits before "see more". For longer posts it reads the opening, the quotable line and every reference once more, then asks three reader questions: does it answer what a reader would ask next, does every paragraph serve the reader, and does it meet the obvious objection?
7. Before you post: three to five people who may want to see it, a reason for each, and a short note you can send if you choose.
8. You post and answer comments yourself. AI never posts.
9. "Log it" records the live text, not the last draft, plus who you messaged.

Check

• Run one short idea through without posting: your answers are kept word for word, the hook is within about 140 characters, and the notes to people are drafted, not sent.

In my version

• My second brain's pitch me command, then Claude skills in sequence in Claude Code: a drafting guide, my voice skill (MyVoice), a final LinkedIn read with three reader checks adapted from Ann Handley's nine-qualities audit, my focus group, and a logging step.

Ask first

• Who is in your universe? (default your network connections, each tagged as could hire you, could refer you, or peer)
• What counts as outreach? (default a note that opens or restarts a relationship with someone who could hire or refer you)
• Which stages? (default a handful, from first noticed to met or closed)
• How much can a week hold? (default three effort levels, full, reduced and minimum, set from client work and meetings already booked)
• How do you follow up? (default a few nudges, spaced further apart, then a soft close)

Needs

• A recent export of your network, your person files, calendar, sent mail, and a log of your posts and comments.
• Start with three tags and one question per person: could they hire you or refer you? My scoring and timing rules are my own; yours will come from who actually replies.
• A drafting guide and a voice guide (see the voice run).
• If your assistant can only chat: keep the list in a document and ask each Monday "who is due, and who should I add?"

Build

1. Universe (monthly): import the network export, find new connections and changed jobs, tag each one, ask you about unclear ones one at a time, and score fit.
2. Candidates (a Sunday scan you review, plus anyone you add from your phone): people whose last touch is older than their tier allows, each with a reason to write now. New connections come from the monthly refresh, and threads that go quiet surface on the pipeline page. Candidates nobody plans expire, and long-quiet threads are archived. Nothing is deleted.
3. Plan (Monday): set the week's effort to full by default and report the facts that might justify lowering it; it never lowers it for you. Rank candidates and follow-ups due. You pick ("plan 1 and 3"); it never plans anyone.
4. Draft (for each person planned): read the live thread first so it never repeats itself, write two versions, have a separate reviewer grade them against what does not work, then a voice pass. Drafts appear in chat only.
5. Log (any day, in any tool): "sent [name]" adds a dated touch line with the channel and whether it asked for something, moves the stage and sets the next follow-up. LinkedIn notes count because you log them, and so do notes to people from an event (see the event scout run). Replies you paste are logged as inbound.
6. Follow up: nudges come due in sequence. A reply, a meeting or a final soft close ends the thread; no answer after the last nudge marks it gone quiet.
7. Check in (Wednesday): count outreach against the week, each marked as found in mail or calendar, from your log, or your word. Name open calendar slots and a few people worth a comment this week (see the comments run), and stage the planned drafts.
8. Campaigns (when you run one): a time-boxed list in one file with a daily send limit. Campaign people get their own section, and when it ends anyone still open returns to normal follow-up.
9. Close (Friday): recount the week, add the week's row from your LinkedIn scoreboard, and ask one question: what went out, and who wrote to you first? A week stays open until you confirm it, and a missed week until you write the one thing you will change.
10. Deliver (after every run): one private pipeline page with the week against its goal, follow-ups due and overdue, threads in flight, who to add next, the recent reply rate, who has gone quiet, and any campaign.
11. Memory: one dated touch line per event in each person's file, the weekly log, and the scored universe.

Check

• Point the tracker at a copy of your files and run only its read commands. Render the page to a scratch file without publishing. Draft for a test person and confirm no email draft or sent message exists.

In my version

• Three Claude scheduled tasks in Cowork (Monday 7am, Wednesday 9am, Friday 2pm), a Sunday reconnect scan in Claude Code, a daily scan that turns phone reminders into candidates, a monthly refresh from my LinkedIn export, and a small Python tracker with one command per step. The page is a private claude.ai artifact.

Ask first

• What decides whether LinkedIn is working for you? (default who saw you and who wrote to you, ahead of reactions)
• Who are you trying to reach? (default the two or three job titles that could hire or refer you)
• When should it run? (default the afternoon before your weekly business development review)
• What makes a post good? (default a score against targets you set)

Needs

• Your LinkedIn analytics, read in your own signed-in browser, read-only.
• A scoreboard file: one row a week and one row per post.
• Your person files, to tag who engaged.
• My score's ingredients, weights and targets stay private; start with three things you want more of and a target for each.
• If your assistant can only chat: paste a screenshot of your analytics each Friday and ask "what changed, and who should I reply to?"

Build

1. Read-only: open the analytics pages, scroll, wait and read. Never like, comment, message, connect or type anywhere, and never open your inbox.
2. Read (the week): profile views, where you appeared (posts, comments, recommendations, search), and the job titles of who saw your posts.
3. Read (each recent post): its numbers, and every reactor and commenter.
4. Tag who engaged from your notes on people: founder, product leader, referrer, peer or other. Someone you already tagged keeps your tag; unknown names are listed, not guessed.
5. Read (your comments): open each comment you logged recently and list who replied under it, tagged the same way. Read the reaction count without clicking it: on LinkedIn that count is also the like button.
6. Score each post against your targets with a script, never by hand.
7. Never invent a number: a value that does not load is written "not read", with the reason.
8. Deliver: write the week's row and the post rows in place, then rebuild the dashboard and republish it to the same private page.
9. Inbound: who wrote to you first comes from your own answer at the weekly close, because the inbox preview shows who wrote last.
10. Hand off: your Friday business development close reads the row and compares it with your first week.

Check

• Run it once by hand: every tab it opened is closed, nothing was clicked beyond reading, and a missing value says "not read".

In my version

• A Claude Code scheduled task on my Mac, reading LinkedIn through Claude in Chrome. A Python script renders the dashboard, a private claude.ai artifact, and my Friday business development close reads the file.

Ask first

• Which sources? (default one event platform's emails and one community's own announcements)
• How many a week? (default a small number you set, so it recommends your best, not every good one)
• What decides? (default the topic, the people you could meet, and what it costs you to get there)
• How far ahead is too far for today? (default a lead time you set; anything further out waits for a weekly ranking)

Needs

• Event emails, found by search rather than filtered away, so confirmations still reach you normally.
• Your calendar.
• A short list of topics and the kinds of people worth meeting. Mine is private; write five lines of your own.
• A ledger of every event it looked at.
• If your assistant can only chat: forward three invitations and ask which one is worth the evening.

Build

1. Read: sort mail by subject before opening any. Invitations get scored, confirmations recorded, reminders ignored. Record confirmations first.
2. Decide: collapse duplicates. Score each against your topics, the people you could meet and what it costs you to get there; surface only clear yeses, stating any doubt. Never surface a past event.
3. Decide (placement): events inside your lead time compete today; later ones are held and ranked once a week. Anything cut by the cap is logged with its rank.
4. Decide (clash): check every calendar for the event's window and name any clash.
5. Deliver: one line per event in the brief's notes: name, day and time, place, host, why, and any clash. It never RSVPs or replies.
6. Memory: one ledger row per state change. A confirmation marks an event acted on; a passed date with none marks it skipped.

Check

• Score last month's invitations by hand into a scratch file: about as many as your cap allows surface, and the ones you went to are among them.

In my version

• Part of my community routine, a Claude scheduled task in Cowork at 4:45am that reads event mail from Luma and three communities in Gmail. Switched on October 18, first run October 19; I check it against my own picks on November 20.

Ask first

• When? (default once a week, in a live chat; never as an unattended run)
• What should it prepare first? (default the Friday sweep, your calendar, open loops, last week's movement)
• How should decisions come? (default one batched list, a recommendation on each)
• A short daily version? (default yes: under two minutes, about five decisions)

Needs

• Your task board and the Friday sweep (from the task system run), your calendar, and the morning notes from your overnight routines (see the morning brief run).
• A log of your standing preferences and past decisions, read every time. Mine stays private; start with five rules you keep repeating.
• If your assistant can only chat: paste your task list and calendar and say "plan my week: one list of decisions, with recommendations".

Build

1. Read (homework, before asking anything): your preferences log, how fresh each morning note is, open loops, the live calendar checked against the overnight flags, the Friday sweep, last week's movement, one idea from your reading, a Find Patterns scan (see the Find Patterns run), and posts you saved.
2. Decide: build one batched list of decisions, each with a recommendation. Short drafts sit inline; long files open beside their item. Calendar changes are limited to travel time and locations you confirm.
3. You answer in one line.
4. Deliver: carry out every decision in one pass, then read each change back from the file or calendar to confirm it landed.
5. Close: a short plan for the week, and new entries in the preferences log.
6. Daily version: re-check the calendar live, check who has gone quiet, read full email threads before suggesting a reply, and stop at about five decisions. New tasks go to quick, next or holding, never to deep work.

Check

• Run it on a copy of your task folder and stop before the execute pass: one list, a recommendation on every item, and nothing changed.

In my version

• A Claude skill in Cowork, run on Friday afternoon, the weekend or Monday morning, with a second skill for the daily sync. Find Patterns and the review of my saved posts run inside it.

Ask first

• When should it run? (default inside your weekly planning, once a few retros have piled up)
• How many repeats make a rule? (default a small number you choose, seen in different sessions)

Needs

• Session retros and a corrections log (see the Retro run).
• Rules kept in files your skills load on every run, so an approved rule takes effect at once. A rule written into a skill's own instructions waits until you reinstall the skill.
• A list of which file owns which kind of rule. My routing table, thresholds and logs stay private; start with one log and one rules file per skill.
• If your assistant can only chat: once a week, paste the week's "what did I correct" answers and ask "which of these repeat, and what rule would stop them?"

Build

1. Open: check that last week's report was closed out. If its proposals were never written, say so first and build on it rather than starting over.
2. Read: retros not yet reviewed and log sections not yet scanned. Mark each one when done, so nothing is counted twice.
3. Decide (rules): send each correction to the file that owns it. Similar corrections are staged as a rule on watch, with the narrowest condition that explains them and what would prove it wrong. A staged rule that keeps repeating across sessions becomes a candidate. Counts are rebuilt from the log every time. A correction that contradicts a rule is shown to you, never absorbed.
4. Decide (automation): requests or workarounds repeated across sessions become candidates for a skill, a scheduled task or a template, each with a draft and an honest time estimate.
5. Decide (checks): when a rule takes many forms, it is proposed as a check the skill runs on its own draft, not as a line of text.
6. Decide (drift): when sessions keep differing from a context file the same way, propose the exact edit. A one-off is only watched.
7. Upkeep, read-only: context files past their date, promises in contact notes gone quiet, facts still marked unconfirmed, meetings prepped and never followed up, skill edits never installed.
8. Deliver: one report. You approve rule by rule, never in a batch. Approved rules are written to the owning file, and the report stays open until they are.

Check

• Run the scan and stop before writing anything: the report lists candidates with their counts, and no file changed.

In my version

• A Claude skill run from weekly planning in Claude Code and Cowork, reading the notes from my Retro run. When a skill keeps making the same mistake, I run a separate check builder on it; those checks live in the skill and work once I reinstall it.

Ask first

• How often? (default monthly, after a busy week of changes, or before anything public)
• Which AI tools do you use? (default run it once in each, then merge)

Needs

• A written map of your system: what each routine and skill does, when it runs, and where its output lands.
• Read access to each tool's schedules and installed skills.
• If your assistant can only chat: paste your list of routines and ask "which have I not seen output from in two cycles?"

Build

1. Read: the map, in full, first.
2. Read: the live sources: schedules, installed skills, rules, and when each routine's output last changed.
3. Decide: the source wins. Each finding cites the file or setting it came from, and anything inferred says so. Two missed cycles means "looks stopped".
4. Decide (sort): correctness (wrong, stale, unsupported, imprecise) and practice (where the system drifted from its own rules), each with a one-line fix. Then three short lists: checked and correct, in the sources but missing from the map, and could not read.
5. Deliver: a dated report with numbered edits, naming what only you can check by hand. No personal data: name the routine, never what it found.
6. Apply: you reply by number, and approved edits go in one write with a dated change line. Silence means skip.

Check

• It is read-only by design: print the report in chat instead of saving it, and confirm nothing changed.

In my version

• A Claude skill run once in Claude Code and once in Cowork. The map is one markdown file. Between audits, a nightly check compares my other scheduled routines with their schedules, and my morning brief shows a line for any that missed a run or is stuck waiting on an approval nobody gave.

Ask first

• What will you keep? (default articles, podcast highlights and book notes)
• Do you have stories of work you ran? (default yes; start with three)
• Where does your idea list live? (default one document)

Needs

- Your own frameworks and positions. Mine stay private; have your assistant interview you about each story and capture it word for word.

- A keep test and a standing test, in your own words. A generic starter, not mine:

Keep: you would quote it to a client this year.

Standing: a named person or study is behind it, and you can open the original.

- If your assistant can only chat: paste a source with your two tests and ask it to apply them.

Build

1. Read (getting in): a source by link, a podcast highlight, your dictation, a talk from your event notes, or posts you saved, reviewed during weekly planning. Check for duplicates first.
2. Decide (keep test): run your keep test. If it fails, no file.
3. Decide (standing test): run your standing test, and write down the signals you check. A fail is kept for the idea only and never cited.
4. Decide (classify): borrowed, your method, or your own claim. Your own claims never count as support for themselves.
5. Deliver (layers): sources stay as they are. Topic pages are compiled from sources one topic at a time, every claim citing its source. Positions are argued from sources and your own records, and change only with your approval. Experience records hold the facts, the spoken version, the steps and the one-line beliefs they earn.
6. Maintain: every addition ends with a list of pages that have taken several inserts since their last rebuild. A weekly task refreshes the diagram of how it all works.
7. Use: "pitch me", or "pitch me on" a topic, reads your idea list (fed by session retros, your experience records and your reading) and, for each idea, the topic pages, your records, your positions and your published posts. It scores the claim, outside support, your own record and whether you said it before, ranks a short list with changed minds first, and writes nothing.
8. Memory: a table classifying every source, and a ledger of your decisions on ideas.

Check

• Add one public article and compile one topic: the page cites it. Add one of your own posts and compile again: no page cites it as support. Run "pitch me": nothing is written.

In my version

• Plain markdown files run by Claude Code with nine commands, Snipd for podcast highlights, and a weekly scheduled task in Claude Code that keeps the diagram of it current.

Ask first

• Where do your meeting notes come from? (default your meeting recorder, then your own notes)
• Which meetings need the full transcript? (default any where something could be agreed)
• Score every meeting? (default yes)
• Who sends the follow-up? (default you; it only drafts)

Needs

• Your recorder's notes or a transcript, and your notes on the person.
• The same scorecard and debrief log the prep uses. Mine stay private; start yours by scoring three past meetings with your assistant.
• A voice guide for the follow-up (see the voice run).
• If your assistant can only chat: paste your notes and say "debrief this".

Build

1. Read: the notes, the brief, the person's notes and past meetings.
2. Decide (what happened): sort each point into said, agreed or only floated. Only agreed items become open loops. Status words like "approved" or "signed off" need the transcript. Record what they said they want for themselves, in their words, or "not discussed" so the next prep knows to ask.
3. Decide (score): score the brief's focus areas first, then the scorecard: landed, partial or missed. Each miss gets the line you could have said, plus one thing to do differently.
4. Decide (next touch): propose a date from the person's status.
5. Draft: a short follow-up in your voice, checked against a list of asks that do not work.
6. Deliver: one message with the debrief, the notes change and the draft, ending "approve all three for write?" Write only on yes. Never send.
7. Memory: the log and the notes. A person's file is created only after a real one-to-one.

Check

• Run it on last week's meeting and stop at the approval question: nothing is written.
• A point that was only floated never shows up as a commitment.

In my version

• A Claude skill in Cowork or Claude Code, reading Granola. Notes in an Obsidian vault, follow-ups through my voice skill, one log across all my meetings.

Ask first

• Who buys from you? (default your ideal customer, in a paragraph)
• Who refers you? (default investors and peers)
• What are you testing? (default a post, a web page, a proposal, an offer or your positioning)

Needs

• Your ideal customer and what you learned from real buyers. My panel stays private; start from your last five buyers: what each one doubted, and what made them say yes.
• If your assistant can only chat: describe three buyers in a paragraph each and ask them to react in turn.

Build

1. Build the panel once: seven buyers across stages and sectors, plus two outside voices, an investor and a peer. Give each a distinct doubt, a way of deciding, and allies and rivals on the panel.
2. Round one: each reacts alone with a first impression, credibility, relevance, the line that landed, what made them skeptical, the exact words to change, and a score from 1 to 10.
3. Round two: a moderated discussion where they really disagree, and the moderator draws out the quiet ones. It always asks "would you forward this?" and "what is not being said?"
4. Synthesis: what most of the panel agrees on, the tensions, fixes ranked high to low, and one open question.
5. Modes: full for pages, offers and proposals; light for posts, about a third the length; outline mode to test the argument before the sentences.
6. Deliver: the report in chat. Tensions come to you; it never resolves them for you.

Check

• Run light mode on something you already published: nine distinct voices, varied scores, at least one real disagreement, and a ranked list.

In my version

• A Claude skill in Cowork and Claude Code, with seven founders, an investor and a peer adviser, each a written profile.

Ask first

• Whose posts do you want to show up on? (default the ten people you most want to notice you)
• What do you have first-hand standing on? (default three topics you have done, not read about)
• How soon can you comment on the same person again? (default your call)
• How many picks a day? (default five)

Needs

• Your notifications and a short watch list, read in your own signed-in browser, by link, read-only.
• Notes on what you can speak to, and a few comments you posted and liked.
• My watch list, lanes and ranking rules stay private; start with ten names and three topics.
• If your assistant can only chat: paste three posts and ask which deserves a comment and why.

Build

1. Read: notifications first, then searches in your own words, then the watch list. The feed only as a last resort.
2. Decide (drop): already seen, too old, too soon for this person, a repost, a promotion, an occasion post, or outside what you know.
3. Decide (rank): five picks, each with a reason and an angle, links checked. Nothing is drafted yet.
4. You choose: "draft 1 and 4".
5. Draft together: it suggests what the comment is for, reads the post and the thread, and writes two different versions in your voice. You edit, usually for a round or two.
6. You post it yourself. It never posts, reacts or types into the site.
7. Deliver: "log it" records the final text and what you changed.
8. Memory: what it showed, what you passed on, and your edits, which shape the next scan and draft.

Check

• Run the scan and stop before picking: nothing is drafted. Draft one comment and do not post it: your activity shows nothing new.

In my version

• A Claude skill in Claude Code and Cowork, reading LinkedIn through my own Chrome, read-only. Comments go through my voice skill, and the log feeds my Friday business development close.

Ask first

• When should it run? (default when you say "retro" or wrap up a session with real work in it; skip quick lookups)
• Where do the notes go? (default one folder, one dated file per session)
• What may it do without asking? (default anything that only records what happened and can be undone in one move)

Needs

• A task folder (see the task system run), a log of your standing preferences, and your context files (see the context layer run).
• One log for corrections to drafts, each tagged with the file that should own the rule. Find Patterns reads it.
• My notes and logs stay private; start with one dated note per session and one corrections log.
• If your assistant can only chat: end each chat with "what did we do, what did I decide, what did I correct, and what did I ask for twice?" and keep the answers in one document.

Build

1. Review: read the session from the start: what finished, what you asked for more than once, which skills needed a workaround, what you edited after it drafted, and anything that contradicted a context file.
2. Split: one test for every action. If you said no, would the file be wrong, or just different? Wrong means bookkeeping, so it does it and reports it. Different means a decision, so it asks.
3. Tasks: match the work to open tasks. Advanced: a dated note, and who has the ball updated. Looks done: one line of evidence and a question. It never marks a task done on its own.
4. Sweep: tasks to add, superseded drafts to archive, preferences to log, and conflicts with a context file. A stale fact it can check now is corrected and reported. A change to what you believe or offer is proposed as an exact edit and written only on your yes. A behavior that differs from a file once is staged for Find Patterns, which waits to see it repeat.
5. Corrections: every edit that changed meaning, tone or structure is logged with the draft, your version and the file that would own the rule. Count every round of edits, not only the last. If the log is busy, write to a side file; never drop an entry.
6. Write: one dated note in a fixed shape, including drafts you used with no edit, so the record is not only failures.
7. Deliver: the automatic work in one block with an offer to undo, then every question in one numbered list. You reply "1 yes, 2 skip"; silence means skip. A deletion always gets a second confirmation.

Check

• Run it on a short test session and stop before writing: the bookkeeping block and the numbered list print, and no file changed.

In my version

• A Claude skill in Claude Code and Cowork. Nothing forces it; I run it when a session did real work. It also checks that the first draft of every email was saved, so I can measure how much I edit before sending, and it logs the session's time for the work per hour run.

Ask first

• Who gets a file? (default anyone you have had a real one-to-one with; people you have only contacted get a lighter outreach file)
• Which fields matter? (default status, warmth, how they could help, first met, last and next touch, next action)
• Which statuses? (default a short list from first contact through client, past client or passed)
• Where should it live? (default plain text files in one folder, opened in a notes app)

Needs

• A folder and a notes app or simple viewer.
• The runs that write to it: meeting and event debriefs, and logging what you send.
• If your assistant can only chat: keep one document per person, paste it before a meeting, and paste the update after.

Build

1. Shape: one file per person. A short header holds the fields every routine filters on, and it is the single source of truth. The body holds open loops, a one-line link to each meeting note and prep brief, touches and themes. Each meeting gets its own note.
2. Create: only after a real one-to-one, proposed by a debrief and created on your yes. People you have contacted but not met live in a lighter outreach file, promoted when you meet.
3. Write (after a meeting): the debrief adds a meeting note, moves the status, records what each side agreed as open loops (agreed items only, never what was floated), records what they said they want for themselves, adds a touch line and proposes the next touch date. You approve first.
4. Write (after outreach): saying "sent [name]" adds one dated touch line and sets the next follow-up.
5. Write (before a meeting): the prep adds a link to its brief.
6. Read: meeting prep starts here, the pipeline counts from here, the quiet check looks for who is overdue, and the event scout matches guest lists against it.
7. Rule: the file is memory, not proof. Before saying anything about the state of a thread, re-read the live thread.
8. Memory: the files themselves, edited in place, never rewritten from scratch.

Check

• Debrief a past meeting and stop at approval: the proposed change touches agreed items only, and the next touch date is set.
• Search for anyone whose next touch is in the past: that is your overdue list.

In my version

• An Obsidian vault of markdown files with a YAML header, written by my meeting and event debrief skills and a small Python tracker.