Free · .mdone-page prompt pack
GrowthOS · Prompt Pack
One bundled prompt for building the system from the deck. Paste the whole thing into Claude Code or Codex in an empty folder, then work through the six sections in order.
read first
# GrowthOS prompt pack
Paste this whole file into Claude Code, Codex, or another coding agent in an empty folder.
The goal is to create a local GTM system: a folder of plain files that lets agents help run sales and marketing work from shared context, reusable workflows, approval rules, and a learning loop.
This is designed as one bundled prompt pack. Run it in order the first time. After that, use the individual sections when you want to improve one part of the system.
Inspired by Andrej Karpathy's LLM wiki pattern: keep important knowledge as short, readable pages that can be updated when new evidence arrives.
## How to use this
You are going to build the first useful version of a GTM system.
Work in six passes:
1. Create the folder.
2. Build the context layer.
3. Add one workflow.
4. Connect one safe tool.
5. Add measurement and guardrails.
6. Run one loop and audit it.
At the end of each pass, stop and show what changed. Ask before moving to the next pass if anything is unclear.
Do not ask for API keys in chat. If a tool needs credentials, create an `.env.example` file and explain the required variables.
Do not send emails, publish campaigns, change CRM records, alter budgets, push to production, or write to external systems without explicit approval.
## The mental model
A GTM system has four parts.
**Context.** What the system knows about customers, market, offer, proof, channels, and voice.
**Workflows.** The repeatable GTM jobs the system can run, such as researching accounts, building campaigns, enriching lists, reviewing performance, or writing a report.
**Guardrails.** The rules that decide what can run freely, what can write local files, and what needs human approval before it touches customers, spend, CRM, public pages, or production systems.
**Learning.** The small updates saved after each run so the next run starts from better information.
The system should stay simple. The folder is the system.
## Architecture
Create these core parts.
```text
.
├── CLAUDE.md or AGENTS.md
├── sources/
│ ├── calls/
│ ├── crm-exports/
│ ├── campaign-reports/
│ ├── support-threads/
│ └── research-notes/
├── context/
│ ├── index.md
│ ├── icp.md
│ ├── personas.md
│ ├── positioning.md
│ ├── proof.md
│ ├── voice.md
│ ├── channel-linkedin.md
│ ├── channel-meta.md
│ └── channel-outbound.md
├── skills/
│ └── first-workflow/
│ └── SKILL.md
├── tools/
│ ├── README.md
│ └── adapters/
├── outputs/
│ ├── campaigns/
│ ├── reports/
│ ├── account-notes/
│ ├── decisions/
│ └── runs/
├── evals/
│ ├── claims.md
│ ├── voice.md
│ ├── channel-rules.md
│ ├── risk.md
│ └── performance.md
├── learning/
│ ├── index.md
│ └── changes.md
└── .growthos/
├── approvals.jsonl
└── run-log.jsonl
```
Use `CLAUDE.md` for Claude Code. Use `AGENTS.md` for Codex. If the folder may be used by both, create both with the same core instructions.01 Create the folder
#01-create-folder## 01 Create the folder You are setting up the local folder that will become the GTM system. Create the directory structure above. Then create the first instruction file for the agent. If this is Claude Code, write `CLAUDE.md`. If this is Codex, write `AGENTS.md`. If the user is unsure, write both. The instruction file should tell the agent: - Always read `context/index.md` first. - Use source files for checking quotes, claims, and numbers. - Save outputs in `outputs/`. - Save reviewed learning in `learning/`. - Ask before sending, spending, publishing, changing CRM, changing customer records, or writing to production systems. - Keep all secrets out of the repo. Create a short `README.md` that explains the system in plain English. ### Files to create ```text CLAUDE.md AGENTS.md README.md sources/ context/ skills/ tools/ outputs/ evals/ learning/ .growthos/ ``` ### Move on when - The core folders exist. - The instruction file names what to read first. - The agent can explain what each folder is for. - Open questions are written down in `outputs/decisions/open-questions.md`.
02 Build context
#02-build-context## 02 Build context Build the context layer before creating tools or workflows. Start from existing evidence where possible: - sales calls - customer interviews - Fireflies, Gong, or call summaries - CRM exports from HubSpot, Salesforce, or another CRM - support threads - campaign reports - landing page copy - ad account exports - outbound replies - sales notes - website copy - founder notes If there is not enough evidence, ask the user for the minimum useful context: 1. What do you sell? 2. Who buys it today? 3. Which customers are the best customers? 4. What pain makes them look for a solution? 5. What proof do you have that the solution works? 6. Which channels are already working? 7. Which channels should the system avoid for now? Turn the evidence into short context pages. Do not dump raw notes into context. Keep raw material in `sources/`. Context should be the readable version an agent can use before doing work. ### Files to write ```text context/index.md context/icp.md context/personas.md context/positioning.md context/proof.md context/voice.md context/channel-linkedin.md context/channel-meta.md context/channel-outbound.md ``` ### What each page should contain `context/index.md` - The read order. - The current state of the GTM system. - Which context pages are reliable. - Which pages need more evidence. `context/icp.md` - Primary ICP. - Secondary ICP. - Best customer patterns. - Poor-fit patterns. - Account selection rules. - Source links. `context/personas.md` - Roles and responsibilities. - Jobs to Be Done. - Pains and anxieties. - Objections. - Exact customer language. - Source links. `context/positioning.md` - Category. - Promise. - Main use cases. - Differentiation. - Competitors or alternatives. - Claims to avoid. `context/proof.md` - Customer proof. - Metrics. - Case studies. - Quotes. - Claims that need evidence. `context/voice.md` - Voice traits. - Words to use. - Words to avoid. - Examples of strong copy. - Examples of copy that feels wrong. `context/channel-*.md` - Channel purpose. - Audience logic. - Creative or messaging rules. - Approval requirements. - What good looks like. - Common failure modes. ### Move on when - The best customer patterns are clear. - Personas use customer language. - Important claims point back to evidence. - Context pages are short enough for an agent to read first.
03 Add workflow
#03-add-workflow## 03 Add workflow Pick one repeated GTM job and turn it into a workflow. Good first workflows: - ICP analysis - account enrichment - LinkedIn campaign draft - outbound sequence draft - landing page review - weekly GTM scorecard - campaign post-mortem - sales call insight extraction Choose one. Keep it narrow. Create a skill file that defines the workflow. ### Files to write ```text skills/<workflow>/SKILL.md outputs/<workflow>/ evals/<workflow>.md ``` ### Skill structure ```markdown # <Workflow name> Use this when: - <clear trigger> Read first: 1. context/index.md 2. context/icp.md 3. context/personas.md 4. context/proof.md 5. context/voice.md 6. context/channel-<channel>.md Inputs: - <input files or user-provided brief> Allowed tools: - filesystem read - filesystem write to outputs/ - read-only service adapters, if available Approval required: - sending messages - publishing campaigns - changing CRM records - changing budgets - writing to production systems Output: - outputs/<workflow>/<run-id>/brief.md - outputs/<workflow>/<run-id>/sources.md - outputs/<workflow>/<run-id>/approval.md - outputs/<workflow>/<run-id>/learning.md Checks: - evals/claims.md - evals/voice.md - evals/channel-rules.md - evals/risk.md ``` ### Move on when - The skill defines the read order. - The workflow runs from sample input. - The output is saved in the expected place. - The review checklist catches weak work.
04 Connect tool
#04-connect-tool## 04 Connect tool Begin with one safe tool. A tool is a connector the agent can use to work with a service or file. It might be a script, API wrapper, CLI command, MCP server, browser action, or local adapter. Start with read-only access. Useful first tools: - `hubspot.readAccounts` - `hubspot.readDeals` - `clay.enrichCompanies` - `apollo.findContacts` - `fireflies.searchTranscripts` - `ga4.readTraffic` - `linkedin.readBenchmarks` - `filesystem.writeOutput` Create a tool document before writing code. ### Files to write ```text tools/README.md tools/<tool-name>.md tools/adapters/<tool-name>.mjs outputs/tool-tests/<tool-name>.md .env.example ``` ### Tool spec ```markdown # <tool-name> Purpose: - <what this tool does> Action type: - read | draft | stage | write | launch | audit Inputs: - <fields> Outputs: - <fields> Approval: - read-only can run freely - writes need approval Rate limits: - <known platform limits> Logging: - log request id - log timestamp - log status - log errors Secrets: - use environment variables - never print tokens ``` ### Move on when - The tool has clear inputs and outputs. - A read-only test run succeeds. - Errors and rate limits are logged. - Write actions are blocked until approved.
05 Measure and guard
#05-measure-and-guard## 05 Measure and guard Add just enough measurement and guardrails to know whether the workflow helped and whether risky actions are still behind approval. Create three types of checks. **Quality checks** - Is the output useful? - Does it follow the workflow? - Does it use the right context? - Does it include source evidence? **Risk checks** - Does this send anything to a customer? - Does this spend money? - Does this publish externally? - Does this change CRM or customer records? - Does this change production systems? **Performance checks** - What metric should improve? - What baseline should this be compared against? - What would make this workflow worth repeating? - What should be reviewed next time? ### Files to write ```text evals/performance.md evals/voice.md evals/risk.md evals/claims.md .growthos/approvals.jsonl outputs/reports/ ``` ### Permission model Use this as the default. ```text read -> no approval draft -> local files only stage -> paused or draft objects only write -> ask first launch -> explicit approval audit -> save logs ``` Approval is required for: - outbound sends - ad launches - spend changes - CRM writes - customer record changes - public pages - social posts - production writes - git pushes ### Move on when - The scorecard says what good means. - Approval rules cover spend, sends, publishing, CRM writes, and production writes. - The report format can be repeated. - The system knows what requires human review.
06 Run and audit
#06-run-and-audit## 06 Run and audit Run one workflow end to end. Use a real but low-risk task. A good first run is a campaign draft, account enrichment report, landing page review, or weekly GTM scorecard. The run should: 1. Read context. 2. Check source evidence. 3. Run the workflow. 4. Save the output. 5. Run checks. 6. Ask for review. 7. Save learning. 8. Update the smallest useful file. ### Files to write ```text outputs/runs/<run-id>/report.md outputs/runs/<run-id>/output.md outputs/runs/<run-id>/sources.md outputs/runs/<run-id>/approval.md outputs/runs/<run-id>/learning.md learning/changes.md ``` ### Learning update format ```markdown # Learning update Run: - <run id> What changed: - <small, specific update> Why it changed: - <reason> Evidence: - <source file or output> Update made: - context/<page>.md - skills/<workflow>/SKILL.md - evals/<check>.md Review status: - proposed | approved | rejected ``` ### Move on when - A user can inspect one real output. - The report explains what happened. - The learning note has a source and a reason. - The next run starts from better context or a better workflow. ## Starter CLAUDE.md Use this if the system is primarily for Claude Code. ```markdown # GrowthOS This folder is a local GTM system. Always read `context/index.md` first. The core loop is: 1. Sources become context. 2. Workflows use context. 3. Tools run only within allowed boundaries. 4. Outputs are saved for review. 5. Reviewed learning updates context, workflows, guardrails, or evals. Rules: - Keep raw evidence in `sources/`. - Keep readable context in `context/`. - Keep repeatable workflows in `skills/`. - Keep service connectors in `tools/`. - Keep run outputs in `outputs/`. - Keep checks in `evals/`. - Keep approved learning in `learning/`. - Ask before sending, spending, publishing, changing CRM, changing customer records, writing to production, or pushing code. - Do not expose secrets. - Make the smallest useful change. ``` ## Starter AGENTS.md Use this if the system is primarily for Codex. ```markdown # GrowthOS This folder is a local GTM system for agent-run GTM work. Start with `context/index.md`. Use the closest skill in `skills/` for repeated work. If no skill exists, propose one before creating new workflow logic. Use tools only within their documented permission level: - read: no approval - draft: local files only - stage: paused or draft objects only - write: ask first - launch: explicit approval - audit: save logs Save outputs in `outputs/` and learning in `learning/`. Never send, spend, publish, change CRM, change customer records, write to production, or push code without approval. ``` ## Starter context index ```markdown # Context index Read order: 1. context/icp.md 2. context/personas.md 3. context/positioning.md 4. context/proof.md 5. context/voice.md 6. context/channel-notes.md Current confidence: - ICP: - personas: - positioning: - proof: - voice: - channels: Open questions: - Recent learning: - ``` ## Starter workflow ```markdown # LinkedIn campaign workflow Use this when the user asks for a LinkedIn campaign draft. Read first: 1. context/index.md 2. context/icp.md 3. context/personas.md 4. context/proof.md 5. context/voice.md 6. context/channel-linkedin.md 7. data/target-accounts.csv, if present Allowed tools: - filesystem read - filesystem write to outputs/ - hubspot.readAccounts, if configured - clay.enrichCompanies, if configured - apollo.findContacts, if configured - linkedin.readBenchmarks, if configured Approval required: - creating a live campaign - changing spend - publishing ads - writing to CRM - sending messages Output: - campaign spec - audience logic - creative brief - claims and proof - approval questions - learning note ``` ## Starter evals ```markdown # Claims check For every meaningful claim, answer: - What is the claim? - What evidence supports it? - Where is the source? - Is the claim safe to publish? - Does it need review? ``` ```markdown # Voice check Review the output against `context/voice.md`. - Does it sound like the company? - Does it use customer language? - Does it avoid banned words or claims? - Is it clear enough for the target persona? ``` ```markdown # Risk check Before any live action, classify the action: - read - draft - stage - write - launch - audit Approval is required for write and launch actions. ``` ## Final instruction to the agent Build this in order. Start with the folder and context. Keep the first version small. Use one workflow and one safe tool before expanding. After every run, save what happened, what changed, and what should improve next time. The system is working when the next run starts with better context than the last one. Deck page: https://omarismail.com/projects/growth-os/deck
The public deck lives at /projects/growth-os/deck.