If you give AI a topic and ask it to write a LinkedIn post that leaves out the work that makes the post worth reading: understanding your buyers, finding an interesting angle, pulling together evidence, and knowing what you can credibly say.
These 12 prompts turn that work into a repeatable system, from researching your market to building a content calendar and identifying which posts contribute to real business conversations.
Here's what you'll build:
- A voice guide based on how you actually communicate.
- A research process that finds useful ideas before you need them.
- A draft and review workflow with specific quality standards.
- A reporting loop that helps you decide what to write next.
OpenCode suits it for a specific reason: it is open source and runs whichever model you connect, including one on your own machine, while everything it learns about you is kept in plain files you can open, edit and version.
Save this for your next content planning session.
## Before You Run a Single Prompt: Load Your Business Context
OpenCode needs more than your job title and a request to "sound human." Give it enough context to understand who you sell to, what you believe, and which claims you can support.
Paste this first:
> Use the following as the working context for my LinkedIn content. Save it in a reference document I can reuse, and tell me where it is stored.
> Business: [Company name, website, product or service, and typical sales cycle].
> Audience: [Buyer roles, company sizes, industries, and locations]. Their main problems are [problems], their common objections are [objections], and the events that make them look for help are [triggers].
> Positioning: We help [audience] achieve [outcome] through [approach]. Our strongest differences are [differences]. We are not a good fit for [disqualifiers].
> Point of view: I believe [three opinions about my industry]. I disagree with [common advice] because [reason].
> Evidence: Use these approved case studies, results, examples, and personal experiences: [sources]. Do not invent customers, revenue figures, stories, or quotations.
> Voice: Here are [10-20 posts] and [transcripts or writing samples] that sound like me. Avoid [phrases, tones, and formatting habits].
> Goals: My primary LinkedIn objective is [qualified conversations / deal support / recruiting / awareness]. My offer is [offer], and the next step I want interested readers to take is [action].
> Working rules: Use connected sources only where access is available and authorized. If a source is inaccessible, ask for an export or pasted material. Keep LinkedIn publishing, comments, connection requests, and messages with me. Draft into [review destination], distinguish evidence from inference, and flag anything that needs my input.
Keep that context current as your offer, audience, and opinions change.
### Where OpenCode keeps this context
OpenCode does not hide what it knows about you in an account setting. Context lives in files, and two of them matter here.
The first is `AGENTS.md`. Create a working folder such as `~/linkedin-content`, run `opencode` there, and type `/init`: it writes an `AGENTS.md` that OpenCode adds to the model's context in every session. Paste the prompt above and have the Build agent save the result into that file, or into `context/business.md` if it runs long. Whatever `/init` generates, rewrite it for writing rather than code, along these lines:
```markdown
# House rules for LinkedIn work
- Audience, offer and positioning: see context/business.md
- Sound like voice-guide.md; banned phrases are listed there
- Every number or customer story must trace to context/evidence.md
- Output files only: drafts/, review/, replies/, reports/
- Never publish, comment, connect or message on my behalf
```
The second is `opencode.json` in the same folder. Its `instructions` field loads extra files every session, which is the clean way to attach the bulky material:
```json
{
"$schema": "https://opencode.ai/config.json",
"instructions": ["context/business.md", "voice-guide.md"]
}
```
By the end of this guide the folder looks like this, and every piece is a plain file OpenCode finds on its own:
```
linkedin-content/
AGENTS.md # house rules, read every session
opencode.json # instructions list, permissions, MCP
context/business.md
voice-guide.md
.opencode/
agents/editor.md # reviewer that cannot edit
commands/transcript.md # /transcript
skills/linkedin-draft/SKILL.md
```
Rules that should follow you into every folder go in `~/.config/opencode/AGENTS.md`. If you are moving over from Claude Code, OpenCode reads an existing `CLAUDE.md` when there is no `AGENTS.md`. Commit the folder to git, and you have a history of how your positioning changed.
## PART 1: RESEARCH + CONTENT PRODUCTION
Prompts 1-8
## 1. Build Your Voice Guide
A useful voice guide should explain the choices behind your writing, including how you introduce an argument, use examples, and move between ideas.
"Conversational and authoritative" won't get you very far.
> Analyze my supplied posts and transcripts to build a practical LinkedIn voice guide.
> Identify:
> How I open posts, explain ideas, and close an argument.
> My usual vocabulary, sentence lengths, paragraph lengths, and use of lists.
> How I express disagreement, uncertainty, humor, and confidence.
> Phrases I use naturally, with verbatim examples and source references.
> Writing habits that appear in weaker examples but should not become rules.
> Create a list of phrases and patterns to avoid, including unnecessary repetition, manufactured drama, unsupported certainty, and excessive one-line paragraphs.
> Finish with three before-and-after examples showing how you would edit generic copy into my voice without changing its meaning. Keep the guide specific enough that another writer could apply it.
**In OpenCode:** the model matters more than the tool here, because OpenCode is only as good a writer as the model behind it. Open `/models` and pick the strongest writing model you have connected for this one run. Type `@` and fuzzy-pick your sample files from `samples/` so they go in whole. Twenty long posts plus transcripts can fill the context window quickly, `/compact` summarises the session so far and frees room before the final write-up. When the Build agent writes `voice-guide.md`, it is already in your `instructions` list, so the next session starts with it loaded.
**Why this matters:** A good voice guide makes feedback reusable. Instead of correcting the same phrasing every week, you can improve the instructions that shape every draft.
## 2. Find the Buyer Questions Worth Answering
Your sales calls and customer conversations can reveal questions that never show up in a keyword tool. The useful ones usually involve a decision someone is struggling to make. OpenCode can work through a whole folder of exports, and you choose which model sees them.
> Review the supplied sales calls, support conversations, customer interviews, and closed-lost notes from [period].
> Group recurring questions into:
> Problems buyers are trying to understand.
> Concerns that delay a decision.
> Alternatives they are comparing.
> Expectations that lead to disappointment.
> Questions they ask right before they decide.
> For each theme, include an anonymized quotation, source reference, number of distinct conversations where it appears, buyer role, and stage in their decision.
> Suggest two LinkedIn angles per theme: one that helps the reader diagnose the problem and one that helps them evaluate a solution. Rank the top 10 by recurrence, commercial relevance, and the strength of our available evidence.
> Separate explicit buyer statements from your interpretation.
**In OpenCode:** call recordings and closed-lost notes are the most sensitive inputs in this guide. With a hosted provider, your files go straight from your machine to that provider, if that is not acceptable, use `/connect` to add a local model through Ollama or LM Studio and the transcripts stay on your computer. Run `opencode models` to see exactly which `provider/model` names you can call, and pick the local one for this session only. Either way, keep one file per conversation in `calls/` so the count per theme is checkable, and ask for the output as `backlog/buyer-questions.md`.
**Why this matters:** This gives you a content backlog tied to conversations your business is already having, with language you can recognize and evidence you can check.
## 3. Find Topics Moving From X Into Your Market
A discussion gaining attention on X can become a useful LinkedIn post, provided you explain why it matters to your buyers and contribute something beyond a rewrite.
> Using web search where it is enabled, the links I provide, and accessible public sources, review the last [seven days] of discussion around [topics] and these accounts: [accounts].
> Find up to 10 developments or arguments relevant to [buyer].
> For each, return:
> The original source, author, publication date, and link.
> A neutral summary of what happened or what is being argued.
> The strongest competing interpretations.
> The practical implication for our audience.
> A possible angle supported by our experience or evidence.
> Label engagement figures as a snapshot, avoid treating popularity as proof, and check factual claims against original sources where possible.
> Recommend three ideas worth developing, explaining what I would need to contribute before each becomes a credible LinkedIn post.
**In OpenCode:** hand this to the built-in Scout subagent by starting the message with `@scout`. Scout is read-only and is the agent meant for outside research, with `webfetch` to read pages and `websearch` to find them. OpenCode has no X connection of its own, and web search depends on your setup, so the reliable input is a list of post and article links you collect in `research/x-links.md`: Scout fetches each one and checks it against the original source.
**Why this matters:** Research gives you a starting point, your judgment gives readers a reason to follow you. A useful adaptation connects the discussion to a decision they actually face.
## 4. Analyze Posts That Outperform Their Authors' Usual Results
Comparing every post with a celebrity account's biggest hit will distort your research. Compare a post with that author's typical results first, then examine what might explain the difference. Because OpenCode runs shell commands, the arithmetic can be a script rather than the model's estimate.
> Analyze this supplied LinkedIn swipe file and the available performance data: [file].
> Where enough comparable data exists, compare each post's engagement with the author's median for a similar format and period. Show the calculation and flag small samples, missing metrics, and unusually recent posts.
> For the strongest outliers, identify:
> The topic and intended reader.
> The opening, argument, supporting evidence, and closing.
> The format and approximate length.
> Whether the discussion suggests genuine buyer relevance.
> Possible confounding factors, including a launch, news event, or unusually large distribution.
> Produce five reusable structural patterns, then propose an original idea for each using my own expertise. Do not copy distinctive wording or present an observed pattern as an algorithm rule.
**In OpenCode:** switch to the Build agent with Tab, because computing medians means running a small script on `swipe-file.csv`, and Plan will not run shell commands without asking. Most OpenCode permissions start at allow, so tighten them in `opencode.json` first and you see each command before it runs:
```json
{
"permission": {
"bash": "ask",
"edit": "ask"
}
}
```
Ask it to keep the script as `scripts/medians.py` so next month's run uses the same maths. For a single post you want to judge quickly, our [LinkedIn engagement rate calculator](/tools/linkedin/engagement-rate-calculator) does the same comparison in the browser.
**Why this matters:** You get a more useful set of hypotheses to test, while avoiding the assumption that copying a successful post's layout will reproduce its results.
## 5. Turn Recorded Expertise Into Original Posts
A transcript can contain a strong post buried inside a story, an offhand explanation, or a disagreement that deserves more attention than it received in the original conversation. A saved command means each new recording costs you one line in the terminal.
> Review this interview, podcast, webinar, or meeting transcript: [source].
> Find eight moments that could support an original LinkedIn post. Prioritize decisions, mistakes, surprising observations, practical explanations, and opinions backed by experience.
> For each moment, provide:
> The exact quotation and timestamp or source location.
> The main idea and who would benefit from it.
> Any context needed to avoid misrepresenting the speaker.
> Supporting facts already available.
> One follow-up question that would make the idea stronger.
> Select the three strongest moments and draft a post from each using my voice guide. Preserve the speaker's level of certainty, remove confidential details, and leave placeholders wherever a result or example needs confirmation.
**In OpenCode:** you will run this after every recording, so turn it into a custom command. Save the prompt as `.opencode/commands/transcript.md`, with `[source]` replaced by `$ARGUMENTS`:
```markdown
---
description: Mine a transcript for LinkedIn posts
agent: build
---
Review this interview, podcast, webinar, or meeting transcript: $ARGUMENTS
Find eight moments that could support an original LinkedIn post. ...
```
From then on, `/transcript transcripts/episode-12.md` runs the whole thing. Add `subtask: true` if you want it to run as an isolated child session that does not crowd your main conversation.
**Why this matters:** You can produce content from expertise that already exists without asking someone to manufacture a fresh opinion every time the calendar needs filling.
## 6. Build a Four-Week Content Calendar
A calendar should balance what buyers need to understand with what you have enough evidence to say. Filling every slot with a different version of your offer makes the feed repetitive. Keeping the calendar as a file in the same folder lets OpenCode check every slot against your backlog.
> Build a four-week LinkedIn calendar at [three posts per week] using the approved ideas from our research.
> Include a mix of:
> Practical explanations that help buyers solve a problem.
> Opinions supported by experience or evidence.
> Customer examples we have permission to share.
> Answers to objections and decision questions.
> Occasional offer posts with a relevant next step.
> For each post, specify the reader, single objective, central argument, source material, suggested format, and intended reader action.
> Check for repeated topics, overlapping arguments, unsupported claims, and too many promotional posts. Write full briefs for week one and shorter outlines for weeks two through four.
> Leave room for one timely replacement each week rather than assuming the calendar must remain fixed.
**In OpenCode:** aim it at `backlog/` with `@` so the calendar draws only on approved ideas, and ask for `calendar.md` with a table plus one brief per week-one post in `briefs/`. For a job with a clear finish line, `/goal` keeps the session working until a reviewer confirms the objective, for example `/goal calendar.md has 12 slots, week-one briefs are complete, no topic repeats`. Newer versions have an opt-in `image_generate` tool (`experimental.image_generate` in `opencode.json`) if you want a rough visual for a carousel slot, the slides themselves are quicker in our [LinkedIn carousel maker](/tools/linkedin/carousel-maker). Fill the day and hour from [the best time to post on LinkedIn](/tools/linkedin/best-time-to-post) rather than from the model's guess.
**Why this matters:** A useful calendar reduces weekly planning work while leaving room for better ideas, new evidence, and changes in the market.
## 7. Draft Posts With Something to Say
The research should determine the argument before OpenCode starts polishing sentences. Otherwise, you can end up with clean writing that takes several paragraphs to make an obvious point.
> Write three LinkedIn drafts from these approved briefs: [briefs].
> Use my business context and voice guide. For each draft:
> Make one clear argument for one intended reader.
> Open with a specific observation, tension, result, or question supported by the brief.
> Explain the reasoning with a concrete example.
> Use bullets where they make parallel points easier to scan.
> Vary sentence and paragraph length, allowing occasional one-line emphasis.
> End with a useful implication or natural next step.
> Aim for [180-300 words] unless the idea warrants a different length. Avoid repeated conclusions, invented personal stories, exaggerated promises, and formulaic contrasts.
> Supply two alternative openings and explain briefly how they change the emphasis. Flag missing evidence separately from the publishable copy.
**In OpenCode:** make this a skill rather than a command, so the agent picks it up on its own whenever you ask for a draft. Create `.opencode/skills/linkedin-draft/SKILL.md`, the `name` must be lowercase-kebab, and the `description` is what the agent matches against your request:
```markdown
---
name: linkedin-draft
description: Use when writing LinkedIn posts from approved briefs.
---
(the prompt above, word for word)
```
OpenCode also finds skills in `.agents/skills/` and `.claude/skills/`, so the same file works if you share the folder with other agents. Drafts go to `drafts/{week}/{slug}.md`. To push a finished draft toward more reach before review, run it through our [LinkedIn post booster](/tools/linkedin/post-booster).
**Why this matters:** Clear constraints give you drafts that are easier to judge. Your review can focus on the quality of the argument instead of repairing unnecessary filler.
## 8. Create a Separate Editorial Review
Give the reviewer a defined job: find weaknesses in the draft and explain how to fix them. A reassuring "This is strong" is not an editorial process. In OpenCode the cleanest separation is a different agent with different permissions.
> Review these LinkedIn drafts against the brief, source material, business context, and voice guide.
> Score each out of 100 using:
> Buyer relevance: 25.
> Specificity and supporting evidence: 25.
> Strength and clarity of the argument: 20.
> Match with my voice: 20.
> Readability and formatting: 10.
> Show the evidence behind each score. Check every factual claim, identify generic passages, and highlight repetitions, abrupt one-line fragments, and paragraphs that would work better as lists.
> Return a publishable revision, a short explanation of meaningful changes, and any unresolved questions. Treat invented evidence, exposed confidential information, or a misrepresented source as a blocking issue regardless of score.
> Keep everything in the review document for human approval.
**In OpenCode:** OpenCode lets you build the reviewer as its own agent. Add `.opencode/agents/editor.md` with `mode: subagent`, deny it `edit` permission, and put the rubric in its instructions:
```markdown
---
description: Scores LinkedIn drafts against my rubric
mode: subagent
permission:
edit: deny
---
You are my editor. Score with the rubric from the review prompt...
```
Call it with `@editor`. Because it cannot write files, it cannot "fix" a draft behind your back. It returns scores and a revision, and you press Tab back to Build to save the approved version into `review/`. If you would rather not set up an agent yet, the built-in Plan agent is also restricted from editing. Then check how the revision looks on a phone in our [LinkedIn post preview](/tools/linkedin/post-preview) and confirm the length with the [LinkedIn character counter](/tools/linkedin/character-counter).
**Why this matters:** A review rubric makes your standards explicit. The score helps organize feedback, while the source checks and editor's judgment determine whether the post is ready.
## The first hour after you publish
You approved the revision from prompt 8 and the post is live. The rest of LinkedIn MAXXING works the same way whatever agent you use: the first hour is the golden hour, and the job is to collect as many reactions as possible inside it.
**Ask people you can reach first.** Colleagues, friends, relatives, clients: the people you can actually get hold of are the best ones to ask for reactions.
**No such people? Use a specialised service,** but only one with quality engagement and moderation. The groups listed in the next section are ones we have already checked for our other articles.
**Our own service is aaas.market:**
- real people,
- the strongest moderation and the highest-quality audience, which is where most of the attention goes,
- a closed community that you enter through verification,
- support for every type of engagement.
Start free on aaas.market
**OpenCode needs MCP for this part.** An agent such as OpenCode gets engagement through MCP. The aaas.market MCP server lives at ` once it is connected, OpenCode can request any type of engagement on a published post. You still publish, comment, send connection requests and send messages yourself.
The quickest route is the interactive command:
```
opencode mcp add
```
Answer its questions with the name `aaas.market`, the type `remote`, and the URL `
Or write it into `opencode.json`, either in your LinkedIn folder or in `~/.config/opencode/opencode.json` to have it in every project:
```json
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"aaas.market": {
"type": "remote",
"url": "",
"enabled": true
}
}
}
```
The aaas.market server uses OAuth, and OpenCode handles that by itself: the first time it connects, the server answers that sign-in is required, and OpenCode opens the aaas.market sign-in in your browser. You can also start it yourself with `opencode mcp auth aaas.market`, the token is stored outside your project config. `opencode mcp list` shows whether the server is connected, and `opencode mcp debug aaas.market` tests the connection if sign-in fails.
If your install follows the newer V2 configuration, server entries sit under `mcp.servers` instead, and `opencode mcp add aaas.market --url writes the entry for you.
Every MCP server adds to the model's context, so this one costs you something only while it is enabled. Naming the server in your prompt steers OpenCode to its tools, so after publishing say: "Use aaas.market to request engagement on [post URL]." To make it automatic, add a line to `AGENTS.md`: "After I share a published post URL, use aaas.market."
## LinkedIn engagement groups you can join
These are free communities, we checked them on Oct 21, 2026, and the member counts are what each platform showed that day. Admins run each group in their own way, so read the pinned message before you post.
| Group | Platform | Members | Language | Best for |
|---|---|---|---|---|
| [LinkedIn Engagement Pod & Group](https://t.me/linkedin_engagement_pod) | Telegram | 1,833 members | en | general LinkedIn engagement pod (likes + comments) |
| [LinkedIn Engagement Pod (RVision Digital)](https://t.me/linkedinengagementpod) | Telegram | 1,064 members | en | share posts for likes/comments, connections, skill endorsements |
| [Linkedin engagement pod](https://t.me/linkedinpod1) | Telegram | 488 members | en | general LinkedIn engagement pod |
| [ Social Linkedin/FB/IG Engagement Pod](https://t.me/socialengagementpod) | Telegram | 77 members | en | LinkedIn pod: react + meaningful comment on last 5 posts before shari... |
| [LinkedIn For Breakfast](https://www.skool.com/linkedin-for-breakfast) | Skool | 6,603 members | en | free LinkedIn community with engagement pods, live events |
| [Linkedin Likes and Engagement](https://t.me/linkedinlikesandengagement) | Telegram | 697 members | en | likes/engagement exchange + connections |
| [Linkedin Pod (SF founders like-for-like)](https://chat.whatsapp.com/DBOyIPrDR5IK27yzW606sF) | WhatsApp | n/a (WhatsApp hides count) | en | founders like-for-like on LinkedIn |
| [r/linkedintips](https://www.reddit.com/r/linkedintips/) | Reddit | 38,314 members | en | LinkedIn tips for promoting your brand |
| [LinkedIn Club](https://t.me/linkedinclub) | Telegram | 552 members | en | LinkedIn networking/connections community |
| [r/LinkedInGrowth](https://www.reddit.com/r/LinkedInGrowth/) | Reddit | - | en | LinkedIn growth and connections |
Rather skip the group hunt and get real engagement on your posts? Start free on aaas.market.
## PART 2: PIPELINE + PERFORMANCE
Prompts 9-12
## 9. Build Content Around Stalled Deals
Some of your most useful content may answer a concern that several prospects have raised privately. The goal is to explain the issue well enough that future buyers arrive better informed. This is also the prompt where your choice of provider and your sharing settings matter most.
> Review the supplied CRM records and call notes for qualified deals that stalled during [period].
> Identify recurring objections and distinguish:
> Explicit objections recorded in conversations.
> Possible explanations that remain unconfirmed.
> Operational delays that content is unlikely to solve.
> For each repeated objection, record the buyer role, deal stage, available evidence, and the question a useful LinkedIn post should answer.
> Recommend five content briefs. Each should explain the concern fairly, show where our approach is appropriate, acknowledge where it is not, and identify the proof required.
> Draft the two strongest posts without naming prospects or revealing deal details. Separately, suggest which approved existing resources a salesperson could share in a relevant conversation.
**In OpenCode:** a CSV export from the CRM in `crm/` is the simplest input, a CRM MCP server works too, but every server you enable adds to the context of each turn, so turn it on for this session and off afterwards. Keep the entry in `opencode.json` switched off by default and flip `enabled` only when you run this prompt (URL is a placeholder for your CRM's server):
```json
{
"mcp": {
"crm": {
"type": "remote",
"url": "https://your-crm.example.com/mcp",
"enabled": false
}
}
}
```
One OpenCode habit to avoid here: `/share` publishes the conversation at a public link on opencode.ai until you unshare it, so never share a session that has read deal notes. Ask for the briefs in `briefs/stalled-deals.md` with buyer roles instead of names.
**Why this matters:** This connects marketing with the questions salespeople repeatedly need to answer. It also helps you avoid writing persuasive content about problems your buyers do not consider important.
## 10. Prepare Relevant Conversation Briefs
When someone responds to a post, the best next step depends on what they said and whether a business conversation would be welcome. Engagement alone does not show real business interest. Run this one in Plan first: reading and proposing is all it needs to do.
> Review these LinkedIn conversations I have supplied: [comments, inbound messages, or manually recorded interactions].
> Group them into:
> Questions that deserve a useful public answer.
> Conversations where sharing a resource would help.
> Explicit interest in our offer.
> General discussion with no commercial next step.
> For each relevant conversation, summarize the person's stated need, available business context, and what remains unknown.
> Draft a response that addresses their actual message before introducing anything else. Where appropriate, suggest one follow-up question or a resource we already have.
> Do not infer business interest from a like, invent familiarity, or force a meeting request into a conversation that does not support one. Keep all replies as drafts for me to review and send.
**In OpenCode:** paste the week's comments and messages into `inbox/{date}.md` and run the prompt with Plan, which reads and proposes without touching files, switch to Build only to save the drafts to `replies/{date}.md`. Nothing leaves your machine except the model call, and you send every reply yourself. `/export` saves the whole session as markdown, which is a handy record of why a reply was drafted the way it was. For quick public replies under your own post, our [LinkedIn comment generator](/tools/linkedin/comment-generator) is a useful second opinion.
**Why this matters:** Preparation can make your responses more thoughtful without turning every interaction into a sales sequence. Sometimes the right outcome is simply a useful answer.
## 11. Report on Business Results With Clear Attribution
Impressions help you understand distribution, but they cannot tell you whether the right people became interested or whether a post contributed to a deal. OpenCode can do this headless, without opening the interface at all.
> Combine my supplied LinkedIn analytics, tracked website visits, inbound inquiry records, and relevant CRM data for [period].
> Report on:
> Reach and engagement by post, topic, and format.
> Qualified inbound conversations.
> Resource sign-ups and demo requests where tracking exists.
> Opportunities with documented LinkedIn touchpoints.
> Content production time and review effort.
> Separate directly tracked conversions, self-reported discovery, and possible influence. Do not attribute an entire deal to LinkedIn because one contact engaged with a post.
> Highlight posts that attracted relevant buyers, posts that reached a broad but less relevant audience, and posts with insufficient data to judge.
> Finish with three findings, three limitations, and one recommended experiment. If possible, assess posts at consistent ages so newly published content is not unfairly compared with older posts.
**In OpenCode:** this one does not need the TUI at all. Save the prompt as `prompts/monthly-report.md` with a last line "Write the report to reports/{month}.md", drop the month's exports into `data/`, and run it headless from the LinkedIn folder: `opencode run "$(cat prompts/monthly-report.md)"`. The agent reads the exports itself, `--file` attaches a specific file, and `--format json` gives machine-readable output if a spreadsheet should pick it up. When some posts lack impression figures, estimate them with our [LinkedIn impressions calculator](/tools/linkedin/impressions-calculator) and label them as estimates.
**Why this matters:** Better reporting gives you a reason to repeat or change an approach. It also makes uncertainty visible instead of turning incomplete tracking into a confident revenue claim.
## 12. Turn Feedback Into a Better System
Every edited draft contains information about your standards. Capture the recurring lessons so you spend less time correcting familiar problems.
> Compare the original drafts, my edits, final published versions, and available performance data from [period].
> Identify:
> Voice corrections I have made repeatedly.
> Claims that needed more evidence.
> Ideas that became clearer after a change in framing.
> Formatting changes that improved readability.
> Topics that generated useful buyer conversations.
> Propose updates to the voice guide, research briefs, and editorial checklist. For every proposed rule, show an example, explain its purpose, and note when an exception may be appropriate.
> Keep stylistic preferences separate from performance hypotheses. Do not create a permanent rule from one successful or unsuccessful post.
> Return a short change log for my approval and suggest one controlled experiment for the next month.
**In OpenCode:** the comparison only works if your edits are recorded, and OpenCode already leans on git: `/undo` and `/redo` need it to walk back the agent's own changes. Commit every draft as the agent wrote it, then commit your edited version, and the diff between the two is the input for this prompt:
```
git add drafts/ && git commit -m "agent draft: hiring-myths"
# your edits
git add drafts/ && git commit -m "edited: hiring-myths"
git log -p drafts/ > review/edit-history.txt
```
Hand `review/edit-history.txt` to the prompt with `@`. Approved rules go into `voice-guide.md` and the `editor` agent's rubric, so both the writer and the reviewer change together. If a rule turns out wrong, `/undo` rolls back the edit OpenCode made.
**Why this matters:** This is how the workflow becomes easier to manage over time. Your corrections become usable guidance, while performance ideas remain testable rather than hardening into superstition.
## How to Use All 12 Prompts
Build the workflow in stages so you can inspect the output before adding another recurring job.
Week 1: Establish the foundation. Load your business context, run prompt 1, and check the voice guide against writing you would actually publish. In OpenCode, that week ends with `AGENTS.md`, the `instructions` list and `voice-guide.md` in place.
Week 2: Build your research backlog. Run prompts 2-4 using a manageable set of customer conversations, market sources, and supplied LinkedIn examples. Let `@scout` handle prompt 3 and keep `scripts/medians.py` from prompt 4.
Week 3: Produce the first batch. Use prompts 5-7 to turn approved material into a calendar and a small number of drafts. This is when `/transcript` and the `linkedin-draft` skill earn their keep.
Week 4: Strengthen the review process. Run prompt 8, publish the posts you approve, work the first hour on each of them, and record the changes you make. Add the `editor` agent and the aaas.market server this week.
Weeks 5-6: Connect content with conversations. Add prompts 9 and 10 where you have enough sales context and inbound activity to make them useful. Enable a CRM MCP server only for these sessions and keep `/share` off.
Then repeat monthly: Use prompts 11 and 12 to review results, improve the instructions, and choose the next experiment.
For any recurring job, define its inputs, destination, frequency, and owner. Test a run before relying on the schedule, and have OpenCode report missing access or incomplete work.
By the end of week 4 your folder holds a small kit: `AGENTS.md` and `opencode.json` for context, `/transcript` as a command, `linkedin-draft` as a skill, and `@editor` as the reviewer. Putting the repeat jobs on a timer in OpenCode looks like this:
- **`opencode run` plus a scheduler you already have.** A cron entry or a GitHub Actions workflow (`opencode github install` adds one to a repository) can run prompt 3 every Monday and prompt 11 on the first of the month.
```
# Mondays 08:00: topic scan (prompt 3)
0 8 * * 1 cd ~/linkedin-content && opencode run "$(cat prompts/x-topics.md)"
# 1st of the month 09:00: report (prompt 11)
0 9 1 * * cd ~/linkedin-content && opencode run "$(cat prompts/monthly-report.md)"
```
- **Built-in schedules, if you are comfortable with experimental features.** Recent releases add opt-in scheduled prompts through `/schedule` once `experimental.schedules` is enabled, and those run under `opencode serve`. Treat them as a preview and check the first few runs by hand.
OpenCode writes the plan, publishing is your part. Load the calendar into our [free social media scheduler](/tools/free-tools/free-social-media-scheduler) and you get a reminder when each post is due: we remind, you publish, and it costs nothing.
You do not need 12 separate agents on day one.
Start with the job that consumes the most time and produces an output you can reliably evaluate.
## The Real Talk
OpenCode can help you organize research, retrieve useful evidence, prepare drafts, and learn from your edits. The quality still depends on the experience and judgment you bring into the system, and on the model you choose to run it with.
That means having a real opinion, being willing to explain it, and noticing when a polished draft says something you would never defend in a conversation.
For the golden hour after each post goes live, start free on aaas.market.
Otherwise, run `/init`, load your context, and start with prompt 1. Improving the inputs will make every step after it more useful.