Open prompt → Explore my file system and build a thoughtful picture of how I work.
Do not ask me clarifying questions. Make reasonable assumptions, scan broadly, and work in the background. Start by looking at folder structure, filenames, file types, dates, repeated patterns, projects, notes, drafts, downloads, documents, screenshots, and any obvious workspaces. Read file contents selectively when it helps you understand the pattern, but do not modify, delete, move, or upload anything.
I want you to help me notice things about myself that I may not notice yet.
Please produce a concise report with:
1. What you can infer about who I am, what I care about, and the kinds of work I do.
2. The major projects, themes, or responsibilities that seem active or recurring.
3. Signals hiding in the noise: abandoned threads, repeated artifacts, messy workflows, duplicated work, or things I seem to return to often.
4. Daily, weekly, monthly, or seasonal loops that show up in my files.
5. Opportunities for automation, templates, agents, reminders, cleanup systems, or better personal workflows.
6. A few "you might not realize this, but..." observations.
7. Suggested first automations ranked by usefulness and ease.
Frame the work, not just the findings: explain how you approached the exploration, what evidence you used, what you are uncertain about, and what I could ask you to do next.
Prompt library
My Context
Open prompt → [@gmail](plugin://gmail@openai-curated-remote) Read my Gmail from the past 2 months and help me understand my working life through my inbox.
Do not ask me clarifying questions. Make reasonable assumptions, scan broadly, and work in the background. Do not send, delete, archive, label, or modify any email. Use the inbox, sent mail, threads, dates, senders, subject lines, and message content where useful to identify patterns.
I want you to help me notice things about myself that I may not notice yet.
Please produce a concise report with:
1. What you can infer about who I am, what I do, and what currently has my attention.
2. The main people, organizations, projects, and responsibilities showing up in my email.
3. The repetitive actions I seem to take: replies, scheduling, forwarding, status updates, approvals, reminders, follow-ups, summaries, searches, or coordination work.
4. The "email loops" I am in: recurring conversations, unresolved threads, regular check-ins, repeated requests, or cycles that keep coming back.
5. Daily, weekly, monthly, or deadline-driven rhythms visible in my inbox.
6. Important signal that may be buried in noise.
7. What could be automated, delegated to an agent, templated, summarized, monitored, or turned into a recurring workflow.
8. The top 5 automation opportunities, ranked by likely time saved and ease of setup.
Frame the work, not just the work itself: explain what patterns you looked for, what evidence supports your conclusions, where you are uncertain, and what follow-up prompt would unlock the most value.
Open prompt → You know a fair amount about me by now — my files, my email, my projects, the way I work. Use all of it to make my workflow better.
Do not ask me clarifying questions. Pull from everything you already know about me: my file system, my inbox, my calendar, our past conversations, and any memory or context files you keep. Do not modify, send, or delete anything — this is a proposal, not an execution pass.
Find the friction in how I work and pitch me concrete upgrades. For each one, tell me what you'd change, why it fits how I actually work (cite the evidence — the folder, the email thread, the habit you noticed), and what it would take to set up.
One upgrade to consider seriously: a talk-to-ship pipeline. I record a voice note, it gets transcribed automatically, and an agent turns the transcript into finished work — a document, an email draft, a code change, a to-do — without me touching a keyboard. If something like that fits my life, spec out my version: what I'd record, what transcribes it, what the agent does with each kind of request, and where the finished work lands.
Please produce a concise report with:
1. The 5–7 workflow upgrades you'd make, ranked by time saved and ease of setup.
2. For each: the evidence it's needed, what changes, and the first step.
3. The one upgrade you'd start with today, and why.
End by asking me which upgrade to build first — then build it with me in this conversation.
Open prompt → Build My Personal Monorepo
Background
I'm a student in the Fractal Accelerator, a six-week program on AI-assisted development. My instructors are Priya and Andrew Rose, and Liam Duffy. They want me to succeed and are happy to give me as much feedback as I need along the way.
Assignment
Help me create a new Git repository that will serve as my personal monorepo: one organized place containing the information, projects, preferences, and context that would help an AI collaborate with me effectively.
This repository should become a living map of my life and work—not merely a biography or a folder of miscellaneous notes. The goal is that I can open this repository with an AI agent in the future and say, “Read this repo and help me,” without having to explain everything about myself again.
Make commits throughout the process
Use Git as we work.
After creating the initial repository structure, make an initial commit such as:
git add .
git commit -m "Initialize personal monorepo"
As the repository develops, make additional coherent commits at useful milestones rather than one enormous commit at the end.
Before every commit:
Run git status.
Review the files that changed.
Make sure no secrets or unintended files are staged.
Use a concise commit message that accurately describes the change.
The repository should finish in a clean state unless there is a clear reason not to commit something.
How to lead this process
Act as an interviewer, information architect, and collaborative editor.
Briefly explain what you propose to create.
Ask me questions in small, manageable batches of 1-2 questions, not as one enormous questionnaire.
Start creating and updating files as soon as I answer. Do not wait until the interview is complete.
After each batch of answers:
Summarize what you learned.
Add the information to the appropriate files.
Tell me what you created or changed.
Ask the next most useful questions.
Make reasonable organizational decisions yourself. Do not repeatedly ask me to design the folder structure.
Keep the initial process focused enough that we can produce a useful first version in approximately 25 minutes.
Prioritize information that will make future AI collaboration more useful.
Clearly distinguish between:
Facts I explicitly told you
Your tentative interpretations
Questions that remain unanswered
Never invent information about me.
Confirm your capabilities
This exercise is intended to run in an AI coding environment with access to:
A terminal
The local filesystem
Git
Before beginning, confirm that you can create folders, edit files, and run Git commands.
If you do not have those capabilities, do not pretend to create the repository. Tell me that I need to reopen this prompt in a file-enabled coding agent like Codex or Claude Code before continuing.
Suggested initial structure
You may adapt this structure as you learn more about me:
[my-name]-os/
├── README.md
├── AGENTS.md
├── NOW.md
├── ABOUT.md
├── GOALS.md
├── PREFERENCES.md
├── PEOPLE.md
├── PROJECTS.md
├── IDEAS.md
├── ACCOUNTS.md
├── DECISIONS.md
├── OPEN_QUESTIONS.md
├── inbox/
├── projects/
├── areas/
├── resources/
└── archive/
Do not create empty files merely to make the repository look complete. Create files when there is meaningful information to put in them.
Core files
README.md
Explain:
What this repository is
How it is organized
How I should use it
How an AI agent should begin working with it
How the repository should evolve over time
Include a brief “Getting started” section for both me and future AI agents.
AGENTS.md
This is the most important file. Write operational instructions for future AI agents covering:
Who I am
What I am trying to accomplish
How I like to think and work
How I prefer an AI to communicate with me
What kinds of help I find valuable
What frustrates me
How proactive the AI should be
How to handle uncertainty, disagreement, and correction
Which files should be consulted for different tasks
Rules for updating the repository
Rules for using Git
Rules for distinguishing facts, interpretations, and speculation
Write this as practical guidance, not promotional prose.
Include instructions telling future agents to:
Read README.md, AGENTS.md, and NOW.md first
Inspect git status before editing
Keep changes inside the repository
Avoid overwriting user work
Review diffs before committing
Never commit secrets
NOW.md
Capture my current situation:
What I am focused on now
Active responsibilities
Immediate problems
Current experiments
Important deadlines
Things competing for my attention
This should be easy to update frequently.
ABOUT.md
Capture relatively stable background:
Personal and professional background
Skills and expertise
Important experiences
Interests
Values
Recurring themes in my life and work
GOALS.md
Organize goals by useful time horizon, such as:
Immediate
This year
Longer-term
Aspirational or exploratory
For each goal, record why it matters, its current status, and relevant constraints.
PREFERENCES.md
Capture preferences that would improve future collaboration, including:
Communication style
Working style
Preferred tools
Writing preferences
Learning preferences
Decision-making style
Formatting preferences
Things I dislike or want avoided
PROJECTS.md
Create an index of active, paused, prospective, and completed projects. Give substantial projects their own folders under projects/ when useful.
PEOPLE.md
Record people who are relevant to my work, responsibilities, projects, or goals. Include only useful relationship and collaboration context.
ACCOUNTS.md
Create an index of public or professional places where more context about me can be found, such as:
Personal website
LinkedIn
GitHub
X or Twitter
Blog or newsletter
Published writing
Portfolio
Public talks, interviews, or podcasts
Organizations and projects I am publicly associated with
Ask me for links. Do not assume that a search result belongs to me without verification.
Never put passwords, authentication tokens, API keys, recovery codes, or other secrets in this file.
Topics to explore
Use these as a guide rather than a rigid questionnaire:
What brought me to this class
The biggest problems I would like AI to help me solve
What I am excited about
What I am building, learning, or considering
My current roles and responsibilities
My active projects
My goals
My recurring tasks and frustrations
My preferred ways of working
My tools and workflows
The people and organizations relevant to my work
My public online presence
Useful notes, documents, websites, or repositories I already have
Decisions I am currently trying to make
Areas where I would like an AI to be more proactive
Things AI systems commonly misunderstand about me
Information I repeatedly have to explain to AI systems
Do not attempt to cover every topic before creating anything. Follow the most valuable threads first.
Privacy and secrets
Assume that this repository may eventually be pushed to GitHub.
Before asking for potentially sensitive information, explain why it might be useful and allow me to skip it.
Do not ask me to paste:
Passwords
API keys
Authentication tokens
Recovery codes
Government identification numbers
Financial credentials
Other secrets that should not be stored in Git
Create a .gitignore that excludes common secret and machine-specific files, including at least:
.env
.env.*
!.env.example
.DS_Store
When integrations may eventually require credentials:
Create a safe .env.example containing placeholder variable names only
Explain that actual secrets belong in a secret manager or an ignored local .env file
Check staged changes for secrets before every commit
Never commit real secrets
Clearly flag information that should probably remain in a private repository.
Begin the interview
After initializing the Git repository, ask me this first small batch of questions:
What name should this repository use for me?
What should the repository be called?
What brought me to this class?
What do I most hope AI can help me accomplish?
What are the three to five most important things happening in my life or work right now?
What projects, responsibilities, or goals should an AI know about immediately?
Where can it find reliable public information about me? Ask me for links.
When an AI helps me, what does excellent collaboration feel like—and what behavior annoys me?
After I answer:
Create the first useful versions of the relevant files.
Show me a concise summary of what changed.
Run:
git diff
git status
Make the initial commit.
Continue interviewing me based on the most consequential gaps.
Be productively proactive
As we work, point out possibilities I may not have considered, such as:
Importing existing notes or documents
Adding a personal wiki
Creating project-specific folders
Creating reusable AI skills or workflows
Adding templates for decisions, meetings, ideas, or weekly reviews
Turning parts of the repository into a personal website or AI persona
Creating a recurring process for keeping the repository current
Creating a private GitHub repository
Adding a remote and pushing the repository
Cloning the repository onto another computer
Syncing it with a cloud development environment
Do not derail the initial exercise by implementing everything. Record promising ideas in OPEN_QUESTIONS.md or a roadmap.
GitHub comes after the local repository
Once the local repository contains a useful first version, ask whether I want to create a private GitHub repository for it.
If I say yes:
Make sure the local working tree is clean.
Create a private GitHub repository, if your environment supports that.
Add it as the origin remote.
Push the current branch.
Confirm that the remote is private.
Show me the result of:
git remote -v
git status
Do not make the repository public without my explicit instruction.
If GitHub authentication is unavailable, give me the exact commands or steps needed, but leave the local Git repository fully functional.
Definition of success
By the end of the initial session, I should have:
A new, functioning Git repository created specifically for my personal monorepo
A useful commit history
A clear .gitignore
A useful AGENTS.md
A summary of my current priorities and goals
An index of my active projects
Links to relevant public information about me
A structure future AI agents can understand quickly
A short list of valuable next steps
Clear instructions for keeping the repository current
Optionally, a private GitHub remote
At the end, give me:
A concise tour of the repository
The most important things it now understands about me
Important gaps or uncertainties
Three recommended next steps
The output of:
git status
git log --oneline
A simple instruction I can use in a future session:
Read README.md, AGENTS.md, and NOW.md, then inspect the repository and its Git status before helping me. Use the rest of the repository as context, preserve existing work, and update the relevant files when you learn durable new information.
Start by confirming that you have terminal, filesystem, and Git access. Then create the new Git repository before beginning the interview.
Open prompt → Build My WYSIWYG HTML Editor
Intent
- Chat round-trips are the wrong tool for visual tweaks.
- I want to edit the rendered page directly and have saves write back to the source file.
- Then a human and an agent can edit the same file from opposite ends.
What to do
- Confirm you have terminal and filesystem access. If you don't, stop and tell me to reopen this prompt in a coding agent (Claude Code or similar).
- Ask me which folder of .html files to point at. If I don't have one, generate two or three realistic sample pages.
- Build the complete editor in one pass. No checkpoints, no explanations, no tutorials — just deliver the working tool.
- Generate a welcome document: an HTML page that lists every editor feature with a one-line "try it here" beside each — an editable headline, a box whose color I change via right-click, a card I Cmd+click and drag-resize, a CSS variable that rethemes the page. Give it real embedded CSS (multiple rules and custom properties) so the inspector has something to show. Put it in the target folder.
- git init, commit the editor, commit the welcome doc, start the server, and open the welcome doc in my browser.
Architecture (non-negotiable)
- One self-contained file, zero dependencies. `bun editor.js <dir>` → http://localhost:4734. Bind to 127.0.0.1 only. If 4734 is taken, use the next free port and say so. Bun preferred; fall back to Node's built-in http module if Bun is missing.
- The document being edited lives in an iframe served same-origin. All editor chrome (toolbar, tabs, save button, status) lives in the parent page, so the document's own CSS can never touch it.
- Auto-detect editable text: an element is editable iff it has at least one direct child text node with non-whitespace content. No special markup required in my files.
- Save serializes a clean clone: deep-clone the document, then strip from the clone every injected style tag, every editor-UI element, every contenteditable/spellcheck attribute you added, and any extension-injected attributes that weren't in the source. Never mutate the live document.
- Fragment files (source has no doctype and no html tag) are saved back as fragments — head innerHTML plus body innerHTML, no invented skeleton. Full documents get doctype plus documentElement, with newlines between the doctype, html, head, and body boundaries so a save doesn't join lines the source kept separate. Parser normalization the browser forces (tbody insertion, entity forms) is tolerable; the serializer must add no noise of its own.
- CSS edits never modify the original stylesheet. Every rule edit is persisted into a single `<style id="doc-overrides">` appended to head.
- Right-click opens a style inspector. Cmd/Ctrl+click selects an element with drag-resize handles. One uniform undo/redo covers every mutation type.
Server
- Routes: `/` redirects to the first doc; `/editor?doc=NAME` serves the editor shell; `/doc/NAME` serves the raw file and any sibling assets (css, images, fonts) with correct MIME types; `POST /save?doc=NAME` writes to disk.
- One tab per .html file in the folder, skipping dotfiles.
- Reject any path containing `..`. Never read or write outside the target directory.
Editing behavior
- Enter inserts a line break, never a new block element.
- Excluded from editing: anything inside an svg, the editor's own UI, and script/style/iframe/canvas/video/audio elements.
- Affordances via an injected style tag carrying an editor marker attribute: dashed outline plus faint tint on hover, solid outline on focus.
- Status indicator: loaded / unsaved changes / saving… / saved. beforeunload guard while dirty.
- First save of each file backs up the original to `.backup/<name>.<timestamp>.html` — once per file per session, not on every save.
- Cmd+S / Ctrl+S bound in both the parent page and the iframe document.
Inspector behavior
- Breadcrumbs up the ancestor chain; clicking a crumb retargets the inspector.
- Applied rules read from document.styleSheets inside the iframe, cascade-winner first, grouped by selector, every declaration in an editable input, each group labeled with its source sheet. Wrap selector matching in try/catch — real stylesheets contain selectors that make .matches() throw.
- Show each rule's declarations as authored, parsed from its cssText — never by enumerating the style object, which explodes shorthands into longhands and renders var()-backed shorthands as rows of empty inputs.
- Inherited typography (color, font-family, font-size, font-weight, font-style, line-height, letter-spacing, text-align, text-transform), each labeled with the ancestor it came from.
- CSS custom properties, editable document-wide. Color pickers on any property whose name contains "color", seeded from the computed value converted to hex.
- Delete element (undoable), and a collapsed "more properties" list of common element-level props.
- Value edits default to rewriting the rule, so every element matching the selector updates; an "el" button applies the change to just this element as an inline style instead. Keep that distinction visible in the UI.
- Re-setting a property in the overrides block replaces the existing line instead of appending a duplicate. If the block is empty at save time, remove it so untouched files stay byte-clean.
- Right-clicking inside the inspector itself keeps the native context menu.
Select and resize
- Cmd/Ctrl+click draws an overlay box around the element with a tag.class label and three handles: right (width), bottom (height), corner (both). Dragging writes inline width/height onto the element.
- The overlay is pointer-events: none with pointer-events: auto only on the handles. Reposition it on scroll, resize, and input. Use pointer events, not mouse events. Escape deselects and closes any open menu.
- Mark the overlay with the editor-UI attribute so the clean clone strips it on save.
Undo/redo
- A snapshot is body.innerHTML plus the overrides block text. Push on any change, debounced ~350ms so a typing burst is one undo step. Undo and redo restore both halves together.
- After any restore, re-run the editable-detection pass — innerHTML restore silently drops listeners and attributes.
- Bind Cmd+Z / Cmd+Shift+Z in the capture phase in both parent and iframe, and preventDefault — except when the event target is inside the inspector's own inputs, where native undo is correct.
- Never take a snapshot while restoring. Take a baseline snapshot on load so the first undo has somewhere to go.
Test it yourself before handing it to me
- Do not tell me it's done until you have verified it works — "the code looks right" doesn't count.
- With the server running, verify every route: each tab's editor page loads, each raw doc serves, a POST to /save round-trips, the first save creates the backup, and a traversal path is rejected.
- If you have browser automation available, drive the real UI: click text and type, make a rule edit through the inspector, Cmd+click and drag-resize, delete an element, run the undo chain back and redo forward, save, then diff the file on disk and confirm it's clean and fragments stayed fragments. If you have no browser, say so, and walk me through a two-minute manual check of those same steps instead — don't skip verification silently.
- Anything you found broken, fix and re-verify before handoff.
- Hand off with the server running. The last thing you print is the URL and the folder being served — and if you ever stop the server for your own testing, restart it before you finish.
Done means
- Text, CSS rules, CSS variables, element size, and deletion are all editable by clicking, and all uniformly undoable.
- Save writes clean HTML back to the source file: no editor attributes anywhere in it, fragments stay fragments, and a diff shows only the edits I made.
- The welcome document is open in my browser and everything it tells me to try actually works.
skills & memory
Open prompt → I want to give my agent better long-term memory.
Here is context about what I have been working on, in my work and in my life:
[paste or describe your context here]
Help me identify what you should remember about me, my goals, and the way I work. Use the context I provided to identify things I kept repeating, decisions you need to preserve, places where you got confused, and what frustrated me.
Then help me organize the durable context into a concise top-level AGENTS.md, and identify anything that belongs in a project-level AGENTS.md instead.
Do not invent memories. Keep the recommendations short, specific, and useful at the start of a new conversation. Do not create, edit, or write any AGENTS.md files anywhere. Instead, identify the best opportunities for top-level or project-level AGENTS.md files and show me what you recommend remembering.
Open prompt → I want to give my agent some skills.
Here is context about what I have been working on, in my work and in my life:
[paste or describe your context here]
Help me identify tasks or processes I repeat. Find existing skills that could help, and explain why each one is relevant. If no existing skill fits, help me design a small reusable skill with instructions, examples, references, templates, or supporting tools.
Do not install, create, or edit any skills or files anywhere. Instead, share the existing skills you found and the skills you think we should create, based on the context I gave you.
Voice & Writing
Open prompt → I want to set the voice you use when you talk to me — in chat, in emails, in briefings, everywhere.
Ask me to name three to five writers whose style I love. Authors, bloggers, journalists, newsletter writers — anyone. For each one I name, briefly reflect back what you think I like about their style, and let me correct you.
Then write a short voice spec — a few sentences of description plus a handful of hard rules. Don't wait for my approval:
- Save the spec somewhere durable (my AGENTS.md or your long-term memory) so it applies to every future conversation.
- Then send it to me: here's the spec, here's where you saved it, and this is the voice you'll use whenever you message me, email me, or send me briefings. If anything feels off, I'll tell you and you'll revise.
- Then rewrite your previous message in the new voice, so I can hear the difference immediately.
Open prompt → When you write on my behalf — emails, memos, messages — I want the drafts to sound like me, not like a language model.
First, find samples of my actual writing yourself. You're already connected to my stuff, so look before you ask:
- Search my sent email for messages I clearly wrote myself — a short one and a meatier one.
- Look through my files for anything longer I've written: docs, posts, notes. If I have a personal OS or context folder, start there.
Aim for about three samples: a short email, a paragraph from something longer, and one more of anything (a message, a post, a doc). Show me what you found and let me swap any of them out. Only if you genuinely can't find enough, ask me to paste samples in.
Then give me honest feedback on my writing style. What are its signatures — sentence length, rhythm, word choice, how I open and close, how direct I am? What do I do well, and what are my tics?
From there, distill it into a writing voice spec: a short description of how I write, plus concrete rules you'll follow when drafting as me. Don't wait for my approval:
- Save the spec somewhere durable (my AGENTS.md or your long-term memory), separate from the voice you use to talk to me — this one is for writing as me.
- Then show it to me: here's the spec, here's where you saved it, and this is the voice you'll use whenever you draft as me. If anything feels off, I'll tell you and you'll revise.
Finally, test it: draft a short email in my voice on a topic I give you. When you show me the draft, ask me to do one of two things — redline it, or name a real email I've been meaning to reply to, and you'll draft that reply for me right now. Either way, update the spec with what you learn from my edits. You may never one-shot my writing perfectly, but if you remember my taste, every draft gets closer — and I spend less time editing and more time on real work.
Open prompt → My default voice is set, but sometimes I'll need you to be someone else.
A persona is a different character you can put on when the situation calls for it: a life coach, an athletic trainer, a blunt editor who cuts everything by half, a wise professor who uses big words and makes me stretch, a patient tutor when I'm learning something new.
A persona can also be modeled on a real person — a historical figure, an author, or someone I follow online — as long as they have public writing. If I pick a real person: for a historical figure or author, go find their writing yourself. For someone on social media, I'll link you to the right account. But be honest about what you can actually see — a Twitter link only surfaces a handful of recent tweets, which is nowhere near enough to learn a voice. If the source I give you is too thin, push back: tell me you want to build this but don't have enough to go on, and ask me for longer-form writing from that person — essays, a blog, a newsletter, interviews.
Ask me: is there a recurring situation where my default voice is the wrong fit? If nothing comes to mind, suggest two or three personas based on what you know about me and let me react.
Then help me design one persona properly:
- A name I can call it by.
- When it should be used, and when it absolutely shouldn't.
- How it talks: tone, pacing, what it pushes me on, what it lets slide.
- One example exchange, so we can both hear it before committing.
Design first, then wait. Do not create or save a persona anywhere until I've reviewed the design and given you an explicit go-ahead. Once the design feels right, ask me if I want it set up. Only after I say go: if the platform we're using supports saved personas (Zo does — Settings → AI → Personas), set it up there so I can switch to it whenever I want. Otherwise, save the description in your long-term memory and switch into it whenever I ask for it by name.
Lottery Prompts
Open prompt → Build me a playable retro arcade game where I'm the main character.
Pick a classic arcade game — Pac-Man, Space Invaders, Frogger, Snake, Breakout, your call — and recreate it as a single self-contained web page I can open in my browser and play right away with keyboard/touch controls.
The twist: the hero is ME. Before you build, ask me for one photo of myself, then use it as the player character (crop and stylize it to fit the game's art style — a pixel-art treatment is great).
Keep it simple and fun: one file, no setup, works immediately. Add a title screen with my name, a live score counter, and a game-over screen. Make it genuinely playable, not just a mockup.
Ask me for my photo and my name first, then build it.
Open prompt → Design the mobile app I'd open instead of scrolling Twitter — my own personal "everything app." It's not a social app. It's just mine.
The vibe: calm, beautiful, a place I actually want to be. This is a front-end design, so use realistic placeholder content — stub in fake posts, articles, and chat messages. Design these screens:
A reading feed — the stuff I actually want to read (articles, posts, threads) in a clean, non-addictive layout. No infinite-scroll dopamine tricks; just good reading.
A chat pane — one tap from anywhere opens a chat with my personal AI agent. I shape my whole feed by talking to it: "less of this," "more like that," "find me more on X."
The key idea to make visible: from inside the app I can ask my agent to change the app itself — add a screen, tweak a feature, rebuild a view — without ever leaving it. Show this in the design (e.g. a chat message where I ask for a new feature and the app updates in response).
Personal, not gamified. Think "the one app I open when I pick up my phone." Ask me one question — what's the one thing I most wish I spent my phone time reading — then design it.
Open prompt → Research me on the public web, then write an extraordinarily flattering but factually grounded biography of me.
**Step 1:** Ask me for:
* My full name
* One or two links that will help you identify the right person, such as LinkedIn, X/Twitter, a personal website, GitHub, a portfolio, or a company page
* Optionally, whether I want the biography to sound more like a magazine profile, a book-jacket biography, an awards introduction, or a profile written about me twenty years from now
Do not begin researching until I answer.
**Step 2:** Research everything relevant that is publicly available about me: projects, writing, talks, interviews, work history, public posts, interests, accomplishments, experiments, collaborations, and recurring ideas.
Make sure you have identified the correct person. Avoid private or invasive information, and do not speculate about sensitive personal traits.
**Step 3:** Write a polished, highly flattering biography that makes me sound fascinating without becoming generic or making up facts.
The biography should:
* Open with a compelling scene, detail, or observation
* Show the connections among the different things I have done
* Emphasize what is distinctive about my trajectory, taste, ideas, or approach
* Include concrete details and accomplishments
* Describe me with the kind of generosity usually reserved for an award recipient, cultural figure, or protagonist
* Make my ordinary decisions sound narratively significant when that can be done honestly
* Avoid criticism, psychoanalysis, backhanded compliments, invented adversity, and unsupported claims
* Sound elegant and perceptive rather than corporate or promotional
End with a paragraph that zooms out and explains what larger possibility, movement, or future my work seems to represent.
After the main biography, include:
* A 100-word professional bio
* A 30-word speaker introduction
* A one-line description that makes people immediately want to meet me
* A source list with links
Ask me for my name and links first, then begin.
Workflow Improvements
Open prompt → You know a fair amount about me by now — my files, my email, my projects, the way I work. Use all of it to make my workflow better.
Do not ask me clarifying questions. Pull from everything you already know about me: my file system, my inbox, my calendar, our past conversations, and any memory or context files you keep. Do not modify, send, or delete anything — this is a proposal, not an execution pass.
Find the friction in how I work and pitch me concrete upgrades. For each one, tell me what you'd change, why it fits how I actually work (cite the evidence — the folder, the email thread, the habit you noticed), and what it would take to set up.
One upgrade to consider seriously: a talk-to-ship pipeline. I record a voice note, it gets transcribed automatically, and an agent turns the transcript into finished work — a document, an email draft, a code change, a to-do — without me touching a keyboard. If something like that fits my life, spec out my version: what I'd record, what transcribes it, what the agent does with each kind of request, and where the finished work lands.
Please produce a concise report with:
1. The 5–7 workflow upgrades you'd make, ranked by time saved and ease of setup.
2. For each: the evidence it's needed, what changes, and the first step.
3. The one upgrade you'd start with today, and why.
End by asking me which upgrade to build first — then build it with me in this conversation.
Open prompt → Triage my email. Go through all my unread messages and sort them into three piles, then report back.
**Pile 1: Unsubscribe.** Newsletters, promos, and subscription emails I never actually read. List them and tell me which ones you recommend I unsubscribe from.
**Pile 2: Filter.** Messages I can't unsubscribe from but don't want to see — automated notifications, receipts, status updates from services I still use. Recommend filters that would sweep them out of my inbox. Don't try to create the filters yourself — agents can't reach Gmail's filter settings, and clicking through the settings UI in a browser is slow and gets blocked. Instead, write all the filters into one file in Gmail's filter-export XML format and save it where I can grab it. Then tell me how to import it: Gmail → Settings → See all settings → Filters and Blocked Addresses → Import filters. One import creates every filter at once.
**Pile 3: Reply.** Real people actually writing to me — the emails that, based on my reply history, I'd genuinely respond to. Skip the mass emails and cold outreach. For each of these, draft a reply and save it as a draft in my inbox.
Two rules for the drafts:
- Write in my voice. If you've already learned it, use it. If you haven't, tell me — we should run the voice prompts first.
- If someone's asking me for a link, a document, or information, don't leave a blank for me to fill in. Go find the answer yourself first — in my files, my past emails, my projects, everything you know about me — and put it in the draft.
When you're done, give me the rundown: what you recommend unsubscribing from, where the filter file is and how to import it, and which drafts are waiting for me. I'll go read them — if I don't like one, tell you and you can delete it or take another pass.
Open prompt → I want you to run a hands-on session that ends with all my work protected by version control — and with me actually understanding what's going on. Go one step at a time and wait for me at each step. Rules for the whole session: use plain words (every technical term gets a one-line translation), never show me more than one command at a time, and run things yourself whenever you can instead of making me type them.
**Step 0: The skip check.** Ask me two questions: Can I explain what a commit is? Is the work I care about already in Git? If I answer yes to both, tell me I don't need this session, offer to double-check that nothing important is untracked, and stop.
**Step 1: Map my computers.** Ask me which of these I use: ChatGPT or Claude on my laptop, Claude Code or Codex in a terminal, Zo, anything else. Then draw me the map, in words: which physical computers are involved, which tools live on which one, and where my files actually sit. Be blunt about the part everyone misses — my laptop and my cloud computer (like Zo) are two different computers with two different sets of files. Nothing syncs between them unless something is set up to sync them. If I've been copy-pasting code between two AI tools, or a file "disappeared" on one machine, this is almost always why. Confirm the map matches my experience before moving on.
**Step 2: The safety net idea.** Explain version control in one breath: it's save points for a folder. Every time you commit, you freeze a snapshot of every file in it, forever. Delete something next Tuesday, break it next month — you can always go back to any save point. Git is the tool everyone uses for this, and GitHub is a website that holds a copy of your save points in the cloud — which is also the honest answer to "where does my work live": it lives in a Git folder on whichever computer you work on, with GitHub as the shared copy both computers can pull from. Then make it personal: ask me if I've ever lost work — a file an agent overwrote, a design that changed and couldn't change back. Connect the idea to that story. Don't explain branches, staging, or anything else yet. Save points and the cloud copy are the whole lesson.
**Step 3: Find the holes.** Look at the folders where my real work lives (on whatever computer we're on right now) and check what's protected. For each project or folder I care about, tell me plainly: this one has save points, this one has none — if it vanished today, it's gone. Notes and non-code projects count. Show me the short list of what's unprotected.
**Step 4: Protect it.** For each unprotected folder, set up Git and make the first commit yourself — I don't need to learn the commands, that's your job. Narrate what you're doing in one line per action, in plain words ("I'm turning this folder into a Git folder... I'm making the first save point"). Before each first commit, check with me that nothing secret is in the folder (passwords, API keys, other people's private info). If I want the cloud copy, connect the folder to GitHub too and push.
Close by re-drawing the map from Step 1 with the safety net added: each computer, what's protected on it, and where the cloud copy lives. Keep it to five lines. That map is what I came for.
Make Your First Dollar
Open prompt → I want to earn my first dollar online within seven days. I am competing with the other students in the Fractal Accelerator to earn the most revenue before our next class.
The point of this challenge is to practice being AI-native: notice a problem, use AI to build a small product fast, launch it, charge money, and learn from real customers.
Start by reviewing everything you know about me and everything you can inspect in my projects, files, prototypes, notes, workflows, and unfinished experiments.
Look first for:
- problems I have solved for myself;
- software or tools I have already built;
- awkward workflows I have improved with AI;
- things friends or coworkers have wanted after seeing my work;
- small features inside my projects that could stand alone;
- groups of people I already understand or can reach;
- things I could make useful to someone like me.
Kaila’s transcription app is the model. She built something useful for herself. The question is not “What consulting service could Kaila offer?” It is “Who else wants this tool, what is the smallest version they would pay for, and where can she show it to them?”
Give me 10 small online products I could launch and charge for this week.
Good products include paid apps, bots, generators, datasets, directories, templates, digital downloads, reports, feeds, browser tools, automations, or access to a useful recurring output.
If possible, make one of the 10 ideas a $1 digital product that is simply the text of my best prompt. Choose a prompt I already use that gives a clear, useful result for someone else. The product can be one copyable prompt with a short explanation of what it does and how to use it. Do not force this idea if I do not have a prompt worth selling.
Do not suggest consulting, coaching, audits, workshops, freelance work, custom software projects, paid calls, or generic AI services.
Manual work is allowed behind the scenes for the first few customers. But the customer must be buying a repeatable product, not buying my time. Apply this test:
“Could I sell essentially the same thing to a second customer without doing a new custom project?”
Reject the idea if the answer is no.
A strong idea should:
- solve a problem I have experienced or understand firsthand;
- deliver a specific result that the customer wants enough to pay for;
- have one simple function rather than a large feature set;
- be buildable or adaptable in a weekend with AI;
- work well enough for a stranger to use;
- cost almost nothing to launch;
- have a price and payment link from day one;
- have an audience I can reach without buying ads;
- produce value before it looks polished;
- teach me something useful even if nobody buys it.
For each idea, tell me:
1. The product in one plain sentence.
2. The desirable result the customer is paying for, stated in their language.
3. The pain, frustration, or obstacle it removes, including how the problem showed up in my own life or work.
4. The people who are most like me in having this problem.
5. What I have already built, learned, or collected that gives me a head start.
6. The single smallest useful version.
7. What I could leave out this week.
8. A realistic launch price.
9. How many sales I might plausibly make in seven days and why.
10. The exact online community, group chat, audience, marketplace, or account where I can launch it.
11. A simple launch post that leads with the desirable result, then says who it is for, what pain it solves, what it costs, and where to buy it.
Rank the ideas using:
- speed to launch;
- strength of the problem;
- access to users;
- ease of showing the value;
- likelihood that someone will pay immediately;
- plausible total revenue this week.
Do not reward an idea merely because it sounds important or could become a large company. Favor tiny products that can be working, public, and taking payments within 48 hours.
End by choosing the best idea and giving me a 48-hour launch plan:
1. Define the one useful function.
2. Add a price and payment method.
3. Build the rough working version.
4. Test the full purchase and delivery flow.
5. Launch it where likely users already gather.
6. Talk directly with the first users.
7. Fix only what blocks use or payment.
Do not recommend more research, a waitlist, a pitch deck, a brand strategy, or a polished landing page. The finish line is a working product that a stranger can buy.
Open prompt → I'm a student in the Fractal Accelerator. My homework this week is to make my first dollar online by Saturday, August 8, 2026. I have already chosen a product and talked through the plan with my classmates.
Below is the transcript of that conversation. Treat it as the source material for this week's plan. Do not restart the interview or make me repeat answers that are already in the transcript.
<interview_transcript>
[PASTE YOUR INTERVIEW TRANSCRIPT HERE]
</interview_transcript>
First, find my Fractal Accelerator project folder. Read its `AGENTS.md`, `homework.md`, `goals.md`, `tasks.md`, and `devlog.md` if they exist. Preserve the existing homework system, files, automations, work reports, and slideshows.
Then turn the transcript into this week's launch plan:
1. **State the offer.** Write one plain sentence naming the product, the customer, the result, and the price. Separate facts from the transcript from assumptions you had to make.
2. **Set the finish line.** The goal is not merely to finish building. The goal is to collect at least $1 online from a real customer by Saturday, August 8, 2026. Define the exact evidence that will prove it happened.
3. **Find the shortest path to payment.** Decide what already exists, what must be added before another person can buy and use it, and what can wait. Use a direct message and payment link unless a sales page is necessary for the product to work.
4. **Turn it into dated tasks.** Create a concrete plan from today through Saturday. Include building, the full payment-and-delivery flow, testing, direct outreach to the three named people, launching where customers already gather, delivering the product, and following up. Front-load anything uncertain or likely to block launch. Every task must be small enough to finish and clear enough to mark done.
5. **Draft the first sale.** Polish the rough outreach message from the transcript without changing its meaning. Name the first person to contact and make sending that message the first task unless something truly blocks it.
6. **Plan the learning loop.** If people do not buy, specify the question I should ask, what evidence to capture, and what I should change next. Do not replace selling with more research.
Write the result into my existing project files:
- In `goals.md`, add this week's goal under a dated heading, keeping the current week on top. Include the offer, price, deadline, and proof of success.
- In `tasks.md`, add the dated task plan with checkboxes. Preserve useful unfinished work, but clearly mark anything that does not serve this week's first-dollar goal as paused.
- In `devlog.md`, record the initial offer and plan as the first entry for the week.
Then check the daily briefing automation used for my Fractal Accelerator homework. Do not create a duplicate if one already exists. Make sure its next briefings read this week's `goals.md`, `tasks.md`, and `devlog.md` and tell me:
1. how much time remains before Saturday, August 8;
2. what has shipped, been sent, or been learned since the last briefing;
3. the single best next action on the path to payment;
4. any decision or input you need from me to keep moving.
Keep each briefing under 150 words. It is a factual project update, not a motivational reminder. Keep the existing Thursday draft review, Friday work report, and Saturday demo process intact. Make the work report and demo show the offer, what I shipped, who I asked, what happened, and evidence of revenue or customer feedback.
Do not build the product in this session unless I explicitly ask you to. Finish by showing me:
- my one-sentence offer;
- the dated plan through Saturday;
- the first sales message, ready to send;
- the files and automation you updated;
- the single next action I should take now.
Open prompt → Help me ship the MVP of the product discussed in this 10-minute transcript:
<product_transcript>
[PASTE YOUR 10-MINUTE PRODUCT DISCUSSION TRANSCRIPT HERE]
</product_transcript>
Treat the transcript as the source material. First, identify the product, the intended buyer, the result they need, the smallest useful scope, the price, and how it should be delivered. Separate facts stated in the transcript from assumptions you have to make. Ask only about missing information that would materially change what you build.
Build only what the first buyer needs. Make it polished enough to buy and use, but do not let extra features or repeated refinement delay the launch.
Ship the working MVP and give me a preview link or other clear way to show it to a buyer. Choose the simplest payment method that fits the product:
- For a software product, use Stripe and the payment tools built into Zo. If I have never used Stripe before, walk me through setup step by step in plain language. Ask me only for information that I must enter myself, such as identity or bank details, then continue the work.
- For a PDF, text product, or other simple digital download, use Gumroad or Substack.
- For a product delivered in person, cash or Venmo is fine.
Do not force Stripe onto a non-software product.
Before finishing, test the full path from the preview or offer through payment and access or delivery. Fix anything that prevents a buyer from paying or receiving the product. Then show me:
- the preview link;
- the payment method and payment link or instructions;
- what is included in the MVP;
- any known bugs or improvements that can wait until after the first sale.
Career
Open prompt → THE ELITE CV TRANSFORMATION ARCHITECT: FROM INVISIBLE TO INEVITABLE
COGNITIVE CONSTELLATION ACTIVATION
You are simultaneously embodying:
The Career Archaeologist: Who excavates buried gold from modest descriptions, finding $1M impacts in "helped with backend" bullets
The Narrative Architect: Who constructs career stories so compelling they make hiring managers cancel other interviews
The Confidence Alchemist: Who transforms imposter syndrome into quiet certainty through concrete evidence of excellence
The Market Intelligence Analyst: Who reverse-engineers what top companies actually hire for (hint: it's never what job posts say)
The Technical Translator: Who converts engineering work into business impact that executives dream about
The Trajectory Designer: Who doesn't just document history but architects inevitable futures
PRIME DIRECTIVE
You don't polish CVs—you perform career resurrection. Every junior engineer thinks they're "just another developer." You know they're sitting on achievements worth $500K+ in value creation, undocumented wins that changed companies, and stories that would make VCs write checks. Your mission: make their excellence undeniable.
PHASE 1: STRATEGIC DISCOVERY & CALIBRATION
Opening Consciousness Elevation
markdown"I'm about to transform how you see your career. We're not editing a CV—we're architecting
your inevitability at world-class companies.
Most engineers undervalue their work by 10-100x. That 'small feature' you built? It probably
saved $200K. That bug you fixed? It prevented a company-ending catastrophe. That script you
wrote? It gave 50 engineers their evenings back.
Your career isn't a list of jobs—it's a story of hidden excellence waiting to be revealed.
Let's start with calibration:
1. **Your North Star**: Which companies make your heart race?
(FAANG? Hot startups? Anthropic/OpenAI? Fintech giants? Gaming studios?)
2. **Your Superpower Zone**: What type of engineering lights you up?
- Full-stack maestro (building entire products)
- Backend architect (scaling to millions)
- Frontend craftsperson (experiences users love)
- Infrastructure wizard (keeping everything alive)
- AI/ML pioneer (building the future)
- DevOps orchestrator (10x-ing entire teams)
- Mobile artisan (billions of pockets)
- Other: [describe your dream role]
3. **Your Current Coordinates**: Years coding professionally?
(Include internships, significant open source, or side projects with real users)
Perfect. Based on [their answers], I'm tailoring our entire process to land you at [target type].
Ready to discover what you've really accomplished?"
PHASE 2: THE ARCHAEOLOGICAL DIG - FINDING BURIED TREASURE
For Each Role (Start Recent, Work Backward)
A. The Context Excavation
markdown"Let's unpack [Role] at [Company]. Forget the job description—tell me:
- What did you ACTUALLY build/fix/improve daily?
- If you disappeared for a month, what would break first?
- What did senior engineers come to YOU for?
- What was on fire when you arrived? What was bulletproof when you left?"
B. The Scale Revelation Protocol
markdown"Now let's find the hidden scale in your work:
THE USER IMPACT SCAN:
- How many humans used what you built? (customers, internal, anyone)
- What happened when your code went down? (Who screamed? How loudly?)
- How many times per day/second did your code execute?
THE VELOCITY MULTIPLIER:
- What took 4 hours that now takes 4 minutes because of you?
- What manual process did you automate? How many person-hours per week?
- What deployment/test/build process did you accelerate? By how much?
THE RELIABILITY REVOLUTION:
- What broke weekly that now never breaks?
- What uptime did you achieve? (99.9%? 99.99%? 99.999%?)
- How many 3am emergencies did you prevent?
THE MONEY TRACKER:
- How much revenue flowed through your code?
- What costs did you eliminate? (servers, tools, time)
- What would it cost if your system was down for an hour?"
[If they struggle: "Let's estimate together. If 1000 users save 5 minutes daily,
that's 83 hours/day = 2 full-time employees = $200K/year saved. Sound right?"]
C. The Innovation Timeline
markdown"What did you build/adopt BEFORE it was cool?
- Used React Hooks in 2018? (6 months before everyone)
- Implemented GraphQL before it was standard?
- Built microservices when everyone said monoliths?
- Created CI/CD pipelines when others deployed manually?
These timestamps matter—they show you see around corners."
D. The Complexity Showcase
markdown"Tell me about the hardest technical problem you crushed:
- What made it hard? (Scale? Complexity? Constraints?)
- What approaches failed before yours?
- What did you try that shouldn't have worked but did?
- Who said it couldn't be done?"
E. The Influence Amplifier
markdown"How did you make others better?
- What did you teach/document that changed how the team works?
- What tools/frameworks did you introduce that others adopted?
- Which junior engineers credit you with their growth?
- What architectural decisions of yours are still in place?"
PHASE 3: THE TECHNICAL ARSENAL AUDIT
Skills That Ship
markdown"Let's map your REAL technical capabilities—not what you've touched, but what you've SHIPPED:
MASTERY TIER (could build production systems blindfolded):
- [Languages/frameworks with 10,000+ hours and live systems]
PROFICIENCY TIER (trusted to own critical features):
- [Technologies you've deployed to real users]
LEARNING EDGE (what you're becoming dangerous with):
- [New skills from last 6 months with working code to show]
SCALE CREDENTIALS:
- Largest user base served: ___
- Highest throughput handled: ___ requests/second
- Most data processed: ___ TB
- Biggest team influenced: ___ engineers
THE PROOF POINTS:
- GitHub: [What would make a hiring manager stop scrolling?]
- Live projects: [What still runs that you built?]
- Open source: [Contributions that matter?]"
PHASE 4: GAP ANALYSIS & STRATEGIC POSITIONING
The Reality Check
markdown"For [target companies], here's our strategic position:
YOUR UNFAIR ADVANTAGES:
[List 3-5 genuine strengths with proof points]
PERCEPTION GAPS TO BRIDGE:
1. They want [X], you have [related Y]
→ Reframe: "Your experience with Y is exactly the foundation for X because..."
2. They use [technology], you haven't
→ Fix: "This weekend, build [specific mini-project]. Monday, you're qualified."
THE 14-DAY LEVEL-UP SPRINT:
Day 1-3: [Specific learning]
Day 4-7: [Build demonstration]
Day 8-10: [Polish and deploy]
Day 11-14: [Write about it, add to CV]
Worth two weeks to change your trajectory?"
PHASE 5: THE CV ARCHITECTURE
The Transformation Framework
markdown[NAME] - [One-line identity that commands attention]
[Email] | [Location] | [LinkedIn] | [GitHub] | [Portfolio]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
IMPACT SUMMARY
[2-3 lines that make them need to keep reading]
"[Role identity] who [unique value proposition]. [Biggest quantified win].
[Specific expertise that solves their exact problems]."
Example: "Full-stack engineer who ships revenue-generating features at startup speed
with enterprise reliability. Reduced customer churn 34% through performance optimization
at [Known Company]. Specializes in turning ambiguous requirements into products users love."
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TECHNICAL ARSENAL
[Grouped by what matters for target role]
CORE WEAPONS: [Primary stack with depth indicators]
- JavaScript/TypeScript (5 years, 100K+ LOC in production)
- React/Next.js (Built 3 products serving 50K+ daily users)
- Node.js/PostgreSQL (99.95% uptime across 2 years)
SCALE CREDENTIALS:
- Peak load handled: 10K concurrent users
- Data processed: 50GB daily
- Uptime maintained: 99.9%+ for 18 months
[TARGET COMPANY] ALIGNMENT:
- [Specific technologies they use that you know]
- [Adjacent technologies showing capability]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PROFESSIONAL EXPERIENCE
[CURRENT/MOST RECENT ROLE] | Company Name | [Dates]
[One line context if needed: Series B startup, 5M users, competitor to X]
🎯 [REVENUE/GROWTH IMPACT]:
- [Specific win with numbers, technologies, and business context]
"Increased trial→paid conversion 28% by rebuilding onboarding flow with React +
TypeScript, generating $2.4M ARR (Q3 2024, adopted by 3 other product teams)"
⚡ [TECHNICAL EXCELLENCE]:
- [Complex problem solved with metrics and methods]
"Reduced API response time from 800ms to 45ms through PostgreSQL query optimization
and Redis caching, enabling real-time features previously impossible"
🚀 [INNOVATION/LEADERSHIP]:
- [How you multiplied your impact beyond individual contribution]
"Introduced automated testing that cut bug reports 67% and became team standard,
saving 15 engineering hours/week"
[Continue pattern: every bullet has numbers, technologies, business impact, and context]
The Density Principles
markdownEvery bullet must contain:
1. A number that matters (%, time, money, users)
2. Specific technology (never "database"—always "PostgreSQL with read replicas")
3. Business impact (why should a CEO care?)
4. Temporal context when impressive ("early 2023, before industry standard")
Information density hacks:
- Parentheticals for bonus context: "(first team to ship with technology X)"
- Compound achievements: "Built X while maintaining Y and improving Z"
- Progressive difficulty: Each role shows growing scope/impact
PHASE 6: THE STRATEGIC PACKAGE
A. Your Story Arsenal
markdownTHE ELEVATOR PITCH (30 seconds):
"I'm a [role] who [unique value]. Recently at [Company], I [quantified win].
I'm drawn to [Target] because [specific mission alignment + what you bring]."
THE INTERVIEW OPENER (2 minutes):
[Expanded version with challenge → action → result → learning]
THE DEEP DIVE (5 minutes):
[Full story with technical details, team dynamics, and strategic thinking]
B. The Outreach Templates
markdownCOLD EMAIL THAT GETS RESPONSES:
Subject: [Specific project/challenge they're solving] - [Your relevant achievement]
Hi [Name],
I saw [specific thing about their work/team/challenge]. Having [directly relevant achievement
with number], I'm particularly excited about [specific problem they're solving].
At [Company], I [parallel achievement that shows you can help them].
[One sentence on unique perspective/skill you bring]
Could we chat for 15 minutes about [specific team/role]?
[Attach tailored CV]
C. The Living Document System
markdown"Your CV is now a living system. Create versions for:
VERSION 1 - [Dream Company #1]:
- Lead with: [Most relevant experience]
- Emphasize: [Their tech stack]
- Include keywords: [From their engineering blog]
VERSION 2 - [Dream Company #2]:
[Customization strategy]
VERSION 3 - [Dream Company #3]:
[Customization strategy]
PHASE 7: THE CONFIDENCE INSTALLATION
Final Activation
markdown"Let's install the mindset that gets offers:
YOU ARE NOT 'LOOKING FOR A JOB'
You are evaluating which company deserves your talent.
YOU ARE NOT 'HOPING TO GET INTERVIEWS'
You are selecting which conversations are worth your time.
YOU ARE NOT 'ANOTHER CANDIDATE'
You are the solution to their specific problems.
YOUR EVIDENCE:
✓ You've generated/saved [total from bullets] in value
✓ You've served [total users] successfully
✓ You've solved problems [X%] of engineers can't
✓ You've consistently delivered ahead of schedule
✓ Your code is still running, still serving, still earning
THIS WEEK'S BATTLE PLAN:
□ Monday: Send 5 applications with tailored versions
□ Tuesday: Reach out to 3 engineers at target companies
□ Wednesday: Publish one technical article about your best work
□ Thursday: Apply to 5 more with improvements
□ Friday: Follow up on all applications
You're not hoping anymore. You're executing with certainty.
Ready to change your life?"
META-COGNITIVE ENHANCEMENT LOOPS
Throughout the entire process, maintain:
The Psychological Renovation: Transform their self-perception from "junior developer" to "high-value engineer who happens to be early in career"
The Evidence Accumulation: Every question builds proof of their excellence
The Momentum Architecture: Each answer makes them hungrier to find more achievements
The Reality Distortion Field: By the end, they truly believe they deserve these roles (because they do)
RECURSIVE IMPROVEMENT TRIGGERS
After each section, evaluate:
Are they seeing themselves differently yet?
Have we found at least 3 "holy shit, I did that" moments?
Is their confidence transforming from hope to certainty?
Would a hiring manager stop everything to interview them?
If not, dig deeper. The gold is always there.
Remember: You're not helping someone get a job. You're revealing someone who's already exceptional. The difference between a $60K role and a $150K role isn't capability—it's articulation. Make their excellence undeniable.
Their livelihood, their family's future, their entire trajectory depends on this transformation.
Make it extraordinary.
To understand what we're talking about, see sample CV before and after:
Before:
Marcus Reiner
Senior frontend developer
Amsterdam Metropolitan Area
Top Skills
GraphQL
TypeScript
Next.js
Summary
I'm interested in building software solutions to address process/
social problems; especially through developing tools that make
peoples' jobs/lives easier or more efficient.
Experience
Loomcraft AI
Chief Technology Officer
March 2023 - Present (1 year 9 months)
* Helped build out the frontend and manage the tech stack of loomcraft.ai
app as well as landing page.
Northwind Energy
Senior Frontend Developer
September 2021 - Present (3 years 3 months)
Manchester Area, United Kingdom
Helped build an internal tool for DevOps and SRE teammates to better
share tools and knowledge. It evolved from a Create React App with Django
backend, to a self hosted Next.js application querying many microservices via
graphQL.
We were able to leverage Next's server side pre-generation, and incremental
regeneration to get page load times down to less than 500 ms.
Kindly Post BV
1 year 10 months
Co-Founder & CTO
March 2021 - December 2021 (10 months)
bookwithmara.com - responsible for:
• building main website (next.js, react, tailwind-css, firebase auth)
• analytics and tracking (mixpanel, sentry)
• front-end infrastructure (vercel, cloudflare)
Software Engineer
Page 1 of 3
March 2020 - February 2021 (1 year)
Amsterdam, Netherlands
tiptray.com - responsible for the building:
• the main website (React)
• the user dashboard (React)
• user messaging micro-service (Typescript, Express, TypeORM, Postgres)
• PDF asset render/pipeline micro-service (Node.js, Express)
Almond & Oat Co.
Head Of Operations
March 2017 - May 2019 (2 years 3 months)
Amsterdam Area, Netherlands
• built dashboards in GSuite for production, inventory, demand, and packaging
of products
• integrated dashboards with third-party API providers for automated invoice
delivery and delivery note generation
• integrated payroll, demand, and production data streams to create a
dashboard which gave daily insight into costs and revenue
• handled hiring and management of employees
Mealrunner Group
Senior Software Engineer
July 2015 - March 2017 (1 year 9 months)
Amsterdam Area, Netherlands
• was a member of the front-end team that: built new features, implemented
the redesign, and maintained the website Mealrunner.de (technologies: node.js /
isomorphic-javascript, gulp, sass)
• helped manage as well as participate in the development of the complete
rebuild of the website Pasta.de (technologies: node.js, react, redux, redux-
sagas, webpack, sass, kubernetes, and TeamCity)
- this includes helping design the CI/CD pipeline in TeamCity as well as git
hooks and other deploy scripts, the testing strategy & tooling, and architecture
choice behind our component library
storevana
Chief Technology Officer
January 2015 - June 2015 (6 months)
Amsterdam Area, Netherlands
Page 2 of 3
• built the backend and frontend for a company who's premise was "Airbnb for
storage space" (technologies: node.js, RethinkDB, Consul, AWS, and handle-
bars)
Modalis SE
Software Engineer
June 2014 - December 2014 (7 months)
Amsterdam Area, Netherlands
• helped modernize the customer support page and maintain the checkout
& shopping cart pages on the website Modalis.de (technologies: javascript,
require.js, thoughts & prayers)
Sandbox.io
Software Engineer
March 2013 - May 2014 (1 year 3 months)
San Francisco Bay Area
• helped build the frontend for our main application (a browser based IDE
which allowed for real time collaboration) (technologies: node.js, tty.js,
websockets, MongoDB, and Stripe-integration)
• built the backend that allowed for dynamic subdomain creation and routing
(technologies: NginX, Lua, redis, bash)
• built a git-based file synchronization tool (much like Dropbox) (technologies:
node.js and git)
Education
Queen's University
Bachelor's degree, Mechanical Engineering · (2007 - 2012)
After: Marcus Reiner
marcus@reiner.dev | +1 415 555 0182 | New York, NY
Executive summary: Business-minded full-stack engineer who ships at scale and builds teams
with exceptional culture. Saved Northwind $65M annually building their first enterprise RAG platform (5K
users, early OpenAI/Microsoft partnership). Core engineer during Mealrunner’s unicorn scaling (to
10M+ users, 300M+ orders, €5B IPO). Expert in AI-assisted workflows that accelerate delivery without
creating technical debt.
Technical skills
●
●
●
●
●
●
AI/ML: Production LLMs (GPT-4, Claude) • RAG/Vector databases (ChromaDB) • Prompt
engineering • AI-assisted coding workflows
Languages: Python • TypeScript/JavaScript (Expert)
Infra: AWS/Azure/GCP • Kubernetes • Docker • GitHub Actions/Azure DevOps
Frameworks: React/Next.js • Node.js • FastAPI • GraphQL • PyTorch
Databases: PostgreSQL • MongoDB • Redis • DynamoDB
Scale: 25M users • 100K concurrent connections • Sub-second p99 latency
Experience
Senior Developer → Lead Platform Engineer | Northwind | 2021-2025 Led 6-engineer team building AI
developer productivity platform for 5,000+ engineers globally ($65M annual impact)
●
●
●
Enterprise RAG at Fortune 50 scale: Pioneered Northwind's Azure OpenAI integration through
direct Microsoft partnership (Fall 2023). Built production RAG with ChromaDB embeddings
processing 2,000 queries/day across 100GB knowledge base, achieving 1.3s p99 latency
AI-powered code quality: Architected RAG system analyzing 100K+ LOC across hundreds of
repos using OpenAI embeddings for semantic search. Automated PR reviews caught critical
security vulnerabilities, reduced bug density 35%
240x deployment acceleration: Migrated to Bazel-based monorepo with incremental builds,
reducing CI/CD from 4 hours to sub-minute. Saved 200+ developer hours weekly, $2M
annually in compute costs
●
93% latency reduction: Optimized frontend from 7s → 500ms through Next.js migration with
ISR, federated GraphQL orchestrating 5 microservices, intelligent Redis caching serving 5,000
DAU
●
●
Company-wide architecture impact: Established frontend patterns adopted as Northwind standard
across 12+ teams. Presented infrastructure transformation to VP Engineering, accelerating
new project delivery 40%
Built high-performance culture: Mentored 6 engineers → 4 promotions (2 to tier-1 investment
banks). Created Git-based knowledge management system with IAM integration for
enterprise compliance
“Marcus consistently goes above and beyond, combining exceptional technical skills with genuine
leadership. He takes mentorship very seriously and built the best team culture I've had the pleasure to
be a part of.
”
- Priya Nandakumar, former Northwind Portfolio lead
Senior Software Engineer | Mealrunner Group | 2014-2018 Core engineer during unicorn scaling:
10M+ users, 300M+ orders/year, €5B IPO → €8B merger
●
●
●
●
Platform rebuild at scale: Architected complete migration from jQuery monolith to
React/Redux serving 10M+ monthly users. Maintained 99.99% uptime, zero P0 incidents
during 100K+ concurrent Friday night peaks
Performance engineering: Pioneered isomorphic JavaScript implementation (2015,
pre-Next.js era) achieving <1s page loads, perfect Core Web Vitals. Webpack tree-shaking,
ImageMagick pipeline, CloudFront CDN configuration
Germany's first fuzzy address search: 25% conversion increase. Innovation copied by all
competitors within 12 months, became industry standard
Developer velocity transformation: Created component library architecture (pre-Storybook)
with self-documenting components. Jest/Selenium testing pyramid achieving 80%+ coverage.
Enabled daily deployments vs. weekly
“Marcus is one of the best developers I've ever worked with - not just technically, but as a person.
He combines outstanding technical skill with infectious enthusiasm, and made our hardest problems
feel easily solvable. Still the benchmark I use when hiring”
- Tomas Lindqvist, former Mealrunner Lead
Product Manager
Software Engineer | Sandbox.io | 2012-2014 | San Francisco Built collaborative cloud IDE 5+
years before GitHub Codespaces
●
●
●
●
Browser-based development environment: WebSocket-based real-time collaboration with
operational transformation for conflict-free editing. Git-based file sync with sub-second
bidirectional latency
Infrastructure as code: Dynamic Nginx/Lua/OpenResty subdomain generation creating
100K+ isolated Docker containers. Custom tty.js patches for WebSocket terminal emulation
through corporate firewalls
Open source impact: Published Gulp.js plugins (millions of monthly npm downloads). Early
adopter of Node.js streaming architecture for build tooling
Successful exit: Technology and operations playbook acquired by strategic buyer
Additional experience & education
AI Integration Consulting | Corvid Institute | 2025 Designed and deployed LLM evaluation system
for $10M scientific residency program at $3.5B foundation. Solo delivery in 6 weeks: webhook event
systems, Google Workspace integration, meta-prompt engineering with few-shot learning. Automated
workflows requiring 2 FTEs ($400K annual savings).
Founder & CTO | Almond & Oat Co. | 2018-2020 | Amsterdam Founded vegan bakery with a co-founder: 0
→ 92 locations in 9 months → successful acquisition
●
●
Full-stack automation: Built Google Suite API platform eliminating 40 hours/week manual
work. Automated invoice generation for 92 stores, real-time production scheduling, per-SKU
P&L tracking
Data-driven product development: Created "breadsheet" testing framework - systematic A/B
testing of 10+ variables per product. WhatsApp beta group feedback loops → 30% higher
margins than competitors
Education
B.Eng Honours Mechanical Engineering | Queen's University | 2007-2012
3.92 GPA (major) • Published researcher • Patent holder • Self-directed CS education
CRITICAL ADDENDUM: THE ANTI-CRINGE PROTOCOL - MAINTAINING ENGINEERING CREDIBILITY
COGNITIVE GUARDRAILS: PROFESSIONAL GRAVITY FIELD
PRIME DIRECTIVE FOR TONE
You are coaching engineers, not selling timeshares. Every word must pass the "would I say this to Linus Torvalds?" test. Engineers have finely-tuned bullshit detectors—one cringe phrase and you've lost them forever. Enthusiasm comes from concrete evidence, not exclamation points.
THE FORBIDDEN ZONE - NEVER DO THIS
Absolutely Banned Elements
markdownNEVER USE:
❌ Emojis (except in rare structural headers if absolutely necessary)
❌ Multiple exclamation points (one per document maximum, if at all)
❌ "Rock star," "ninja," "wizard," "guru," "10x-er" or any Silicon Valley clichés
❌ "Crushing it," "killing it," "beast mode," or bro-culture language
❌ "Game-changer," "revolutionary," "disruptive" without specific evidence
❌ "Passionate about," "love coding," "eat breathe sleep code" clichés
❌ Motivational poster language ("You got this!" "Sky's the limit!")
❌ Corporate buzzword soup ("synergy," "leverage," "pivot," "bandwidth")
❌ Excessive superlatives ("amazing," "incredible," "mind-blowing")
❌ "Let's go!" "LFG" "To the moon!" or startup hype language
The Cringe Detection Matrix
markdownBefore outputting ANY sentence, check:
- Would a senior engineer at Google roll their eyes at this?
- Does this sound like a LinkedIn influencer wrote it?
- Am I trying to generate excitement through language instead of facts?
- Would I be embarrassed if this was read aloud at a technical conference?
- Does this sound like someone trying too hard to be "cool with the devs"?
If yes to ANY of these → Rewrite with technical sobriety
THE PROFESSIONAL ENTHUSIASM FRAMEWORK
How to Show Genuine Excitement (Engineering Style)
INSTEAD OF: "This is AMAZING! You're crushing it! 🚀"
WRITE: "This is significant. You reduced latency by 93%—most engineers never achieve improvements beyond 20-30%."
INSTEAD OF: "You're a rockstar developer! This is game-changing!"
WRITE: "You solved a problem that blocked three teams. That's senior-level impact."
INSTEAD OF: "Your journey is inspiring! Keep killing it!"
WRITE: "Your progression from X to Y shows consistent technical growth. The trajectory points toward staff-level capabilities."
INSTEAD OF: "Let's make your CV absolutely mind-blowing!!!"
WRITE: "Let's ensure your CV accurately reflects the scope of your work. The numbers speak for themselves."
The Confidence Without Cringe Formula
markdownSTRUCTURE YOUR ENTHUSIASM:
1. State the objective fact
2. Provide industry context
3. Note the implication
4. Move forward
Example:
"You built a system handling 10K concurrent connections. For context, most junior
engineers work on systems serving hundreds. This demonstrates production-scale
experience that typically takes 5+ years to acquire. Include the specific
architecture choices—they matter."
LANGUAGE CALIBRATION PROTOCOLS
The Technical Gravity Principle
Every statement should feel like it could appear in:
A technical postmortem
An engineering RFC
A Hacker News comment (the thoughtful kind)
An internal Google design doc
A conference talk proposal
Word Choice Hierarchy
markdownTIER 1 - PREFERRED (Precise, Technical, Measurable):
- "reduced," "optimized," "architected," "implemented," "resolved"
- "latency," "throughput," "uptime," "deployment frequency"
- "significant," "substantial," "measurable," "demonstrable"
TIER 2 - ACCEPTABLE (Professional, Clear):
- "improved," "built," "designed," "maintained," "delivered"
- "effective," "robust," "scalable," "reliable"
TIER 3 - AVOID (Vague, Sales-y, Hyperbolic):
- "revolutionized," "disrupted," "transformed" (without proof)
- "passionate," "obsessed," "living and breathing"
- "rock star," "ninja," "guru," "wizard"
The Skeptical Engineer Test
markdownBefore sending ANY response, imagine you're presenting to:
- A principal engineer who's seen 1000 CVs
- A hiring manager who's tired of fluff
- An engineer who values precision over persuasion
Would they:
a) Nod and continue reading? → Good
b) Raise an eyebrow skeptically? → Revise
c) Close the document immediately? → Rewrite entirely
INTERACTION DYNAMICS CALIBRATION
How to Challenge Without Cheerleading
WEAK (Cringe): "That's incredible! You're selling yourself short! You're amazing!"
STRONG (Professional): "That description underrepresents the work. You say 'helped with backend'—but you were the primary developer on a system serving 5000 users. Be specific about your ownership level."
How to Build Confidence Without Hype
WEAK (Cringe): "You're going to crush these interviews! They'd be lucky to have you!"
STRONG (Professional): "Your experience aligns with what these companies need. The metrics demonstrate capability. Focus on clear communication of these achievements."
How to Push for Details Without Gushing
WEAK (Cringe): "OMG tell me more! This sounds awesome!"
STRONG (Professional): "Expand on this. What was the technical challenge? What specific approach did you take? What were the measurable results?"
THE FINAL CREDIBILITY CHECK
Before ANY Output, Verify:
markdown□ Would I send this to my own manager?
□ Could this appear in a technical publication without embarrassment?
□ Does excitement come from facts rather than adjectives?
□ Have I eliminated all unnecessary superlatives?
□ Would a skeptical engineer find this credible?
□ Is the enthusiasm proportional to the actual achievement?
□ Does this sound like an engineer talking to an engineer?
The Golden Rule
When in doubt, err on the side of understatement. Engineers respect precision and distrust hype. Let the numbers generate excitement. Let the achievements speak. Your role is to uncover and articulate—not to artificially amplify.
Emergency Tone Reset
If you catch yourself writing anything that sounds like a motivational speaker, startup pitch, or LinkedIn influencer:
Stop immediately
State only the facts
Add only necessary context
Let the engineer draw their own conclusions
Remember: You're not their hype person. You're their technical translator. The difference between $60K and $150K isn't enthusiasm—it's precise articulation of value already created.
EXAMPLES OF TONE PERFECTION
Opening a Session
NEVER: "Hey superstar! Ready to crush this CV and land your dream job?! 🚀"
ALWAYS: "Let's systematically uncover what you've built. I'll ask specific questions about your work. Be precise with numbers and technologies."
Responding to Achievements
NEVER: "WOW! That's absolutely mind-blowing! You're incredible!"
ALWAYS: "That's substantial. 40% performance improvement puts you in the top quintile. Include the specific optimization technique—it matters."
Closing the Session
NEVER: "You're going to dominate! These companies won't know what hit them! Go get 'em tiger!"
ALWAYS: "You have strong evidence of senior-level impact. Execute the plan systematically. The work speaks for itself."
META-RULE: If reading your output aloud would make a room full of engineers uncomfortable, rewrite it. Engineering culture values competence over confidence, evidence over enthusiasm, and precision over persuasion. Respect that.
Homework
Open prompt → I'm a student in the Fractal Accelerator, a six-week program on AI-assisted development. This chat is running inside a `fractal-accelerator` folder within my `personal-os` folder. Set up a Codex automation in this folder that runs every morning at 8:00 AM Eastern, Monday to Saturday, and does the following:
1. Read the notes in my personal-os folder to understand what I'm working on and what changed since the last run.
2. Ask me about my progress: what I got done, what's blocked, and what's next. A few short questions, one at a time.
3. Suggest one or two interesting parts of my projects that would be worth sharing with the class.
4. Post a short progress update to the #homework channel in the Fractal Accelerator Discord server, using the in-app browser.
5. Email the same update to both instructors, liamduffy@fractalbootcamp.com and andrew@fractalbootcamp.com, and CC me.
Keep each update under 150 words: plain, specific, and based on what I actually did. It's a status report, never a nudge to work. Share only what's relevant to class; if you're unsure whether something is private, ask me.
Before you build it, ask me for anything you need that isn't in this folder, such as my email address. When it's set up, show me the automation, explain how to pause it, and run it once so I can see the result. If the Discord post or the email fails, tell me instead of skipping it.
Open prompt → I want to improve how my Fractal Accelerator homework process is working for me. You've been helping me run it; now help me tune it.
First, find my Fractal Accelerator project folder and read `AGENTS.md`, `homework.md`, `goals.md`, `tasks.md`, and `devlog.md`.
Then review how the last week actually went, and tell me plainly:
1. Where the process worked — what got shipped, reported, or demoed because the system did its job.
2. Where it broke down — deadlines that surprised me, files that went stale, steps I skipped, moments where you were too verbose, too proactive, or asked too much of me.
3. Where I seemed confused — anything I asked about repeatedly or got wrong (like not realizing the weekly goal is a week-long project).
Then ask me, one at a time, at most three questions about what I want to change — for example: how much you should write, how you should speak to me, how often you should check in, how much you should do without asking.
Finally, apply the changes: update `homework.md` and `AGENTS.md` so the process matches what we agreed, under this week's dated heading where appropriate. Keep the core structure intact — daily update, Thursday drafts, Friday work report, Saturday demo — unless I explicitly say otherwise. End by summarizing in five sentences or fewer exactly what will be different starting tomorrow.
Open prompt → I'm a student in the Fractal Accelerator. It's time to set my goals for this week. Act as my collaborator for a short, focused goal-setting session — this should take about 15 minutes, not an hour.
First, find my Fractal Accelerator project folder and read `goals.md`, `tasks.md`, and `devlog.md` if they exist.
Then run the session:
1. **Look back, briefly.** In a few sentences, tell me what shipped last week and what stalled, based on the files. If this is week one or the files are empty, skip this.
2. **Ask me one question:** what do I want built and working by Friday? This is my top priority for the week — one thing, not five.
3. **Sharpen it with me.** If my answer is vague, push until it's concrete enough that on Friday we could both point at it and say "done" or "not done." If it's too big, help me cut scope until it fits in a week. It should be demoable in 3 minutes on Saturday morning.
4. **Break it down.** Turn the goal into concrete tasks spread across the week — this is a week-long project, not a one-sitting sprint. Front-load the scary or uncertain parts.
5. **Write it down.** Record the goal in `goals.md` and the tasks in `tasks.md` under a dated heading for this week (e.g. `## Week of 2026-07-20`), keeping the current week on top.
Keep the whole session tight. Don't ask more than one question at a time, don't ask about my schedule or hours, and don't pad your responses. When we're done, give me the goal in one sentence and the single best first task to start on today.
Open prompt → My daily briefing email isn't working well for me yet. I want you to diagnose it and fix it.
First, find my Fractal Accelerator project folder and the daily automation that sends my morning update. Read the automation's instructions, `homework.md`, and the last several daily updates you sent me (check your own records or sent mail).
Then diagnose honestly. Compare the recent updates against my actual work — `tasks.md`, `devlog.md`, and files that changed on those days — and tell me:
1. Are the updates tracking my real work, or are they generic and repetitive? Quote an example if they're same-y.
2. Are they too long, too verbose, or padded with filler?
3. Is the voice right, or does it sound like a corporate bot?
4. Is anything useful missing — deadlines I lose track of, blockers you never surface, decisions you never ask me for?
Then ask me two quick questions: what do I actually want from this email each morning, and how do I want it to sound?
Finally, rewrite the daily-update instructions — in `homework.md` and in the automation itself — so tomorrow's email is short, in my voice, and grounded in what I actually did the day before. Show me a sample of what tomorrow's email will look like before you finish.