LinkedIn maxxing with OpenCode: a file-based system and 12 prompts

LinkedIn maxxing with OpenCode means setting up one working folder where plain files (AGENTS.md, opencode.json, a voice guide and your business context) tell the agent who you are, then running 12 prompts that research, draft, review and measure your LinkedIn posts. OpenCode suits this because it is open source, works with whatever model you connect, including a local one, and keeps everything it knows about you in files you can read, edit and version.

Ask an AI for a LinkedIn post on a topic and it will skip the part that makes a post worth reading: understanding the people you sell to, finding an angle, collecting evidence, and knowing what you can credibly claim. The prompts below turn that part into a process you can repeat, from market research and a content calendar through to spotting which posts start real business conversations.

What you end up with:

• A voice guide that reflects how you really write and speak.
• A research routine that finds good ideas before the calendar asks for them.
• A drafting and review loop with clear quality standards.
• A monthly report that points to what you should write next.

Keep this page handy for your next content planning session.

What context does OpenCode need before the first prompt?

Your job title plus "sound human" won't do. OpenCode has to understand who your customers are, what you believe and which claims you can support with evidence.

Start by pasting this:

Use what follows as the permanent context for my LinkedIn writing. Save it as a reference file I can reuse and tell me its path. Business: [company name, website, product or service, typical sales cycle]. Audience: [customer roles, company sizes, industries, locations]. Their biggest problems: [problems]. Objections they raise most: [objections]. Events that send them looking for help: [triggers]. Positioning: we help [audience] reach [outcome] with [approach]. Our clearest differences: [differences]. We are a poor fit for [disqualifiers]. Point of view: I hold these three opinions about my industry: [opinions]. I push back on [common advice] because [reason]. Evidence: draw only on these approved case studies, results, examples and personal experiences: [sources]. Don't make up customers, revenue figures, stories or quotes. Voice: [10-20 posts] and [transcripts or writing samples] that sound like me are attached. Avoid [phrases, tones and formatting habits]. Goals: my main aim on LinkedIn is [qualified conversations / deal support / recruiting / awareness]. My offer is [offer], and I'd like interested readers to [action]. Working rules: use connected sources only where access exists and is authorized. If you can't reach a source, ask me for an export or for pasted text. I handle all LinkedIn publishing, comments, connection requests and messages myself. Write drafts into [review destination], separate evidence from inference, and flag whatever needs my input.

Refresh this context whenever your offer, audience or opinions shift.

Where does OpenCode keep this context?

OpenCode doesn't tuck what it knows about you into an account setting. The context sits in files, and two of them matter for this setup.

File one is AGENTS.md. Make a working folder such as ~/linkedin-content, start opencode inside it and type /init. That writes an AGENTS.md, which OpenCode adds to the model's context in every session. Paste the context prompt and have the Build agent save the answer into that file, or into context/business.md if it gets long. Whatever /init produces, rewrite it for writing work instead of code, roughly like this:

# LinkedIn house rules
- Audience, offer, positioning: context/business.md
- Write like voice-guide.md; the banned phrases live there too
- Every number or customer story must come from context/evidence.md
- Only write files in drafts/, review/, replies/, reports/
- Never publish, comment, connect or send messages for me

File two is opencode.json in the same folder. Its instructions field loads extra files at the start of every session, which is the tidy way to attach the larger material:

{ "$schema": "https://opencode.ai/config.json", "instructions": ["context/business.md", "voice-guide.md"] }

The finished folder looks like this:

linkedin-content/
  AGENTS.md            # house rules, loaded every session
  opencode.json        # instructions list, permissions, MCP
  context/business.md
  voice-guide.md
  .opencode/
    agents/editor.md                 # reviewer without edit rights
    commands/transcript.md           # the /transcript command
    skills/linkedin-draft/SKILL.md

Rules you want in every folder belong in ~/.config/opencode/AGENTS.md. If you're moving over from Claude Code, OpenCode reads an existing CLAUDE.md when a folder has no AGENTS.md. Put the folder under git and you get a history of how your positioning changed over time.

Part 1: research and content production (prompts 1-8)

1. How do you build a voice guide in OpenCode?

A voice guide is useful when it explains the decisions behind your writing: the way you set up an argument, the way you use examples, the way you move between ideas. Calling yourself "conversational and authoritative" tells a writer close to nothing.

Study the posts and transcripts I supplied and write a practical LinkedIn voice guide from them. Describe: how I open a post, explain an idea and wrap up an argument; my typical vocabulary, sentence length, paragraph length and use of lists; how I handle disagreement, uncertainty, humour and confidence; phrases I use naturally, with exact examples and where they came from; and habits from my weaker pieces that shouldn't become rules. Then list phrases and patterns to avoid, including pointless repetition, staged drama, confidence without support and too many one-line paragraphs. Close with three before-and-after rewrites that turn generic copy into my voice and keep the meaning intact. Make it specific enough that a different writer could use it.

In OpenCode: for this prompt the model matters more than the tool, because OpenCode writes only as well as the model behind it. Open /models and choose the strongest writing model you have connected, just for this run. Type @ and fuzzy-pick your sample files from samples/ so they go in complete. Twenty long posts and a few transcripts fill the context window fast; /compact summarises the session so far and frees space before the final write-up. When the Build agent saves voice-guide.md, the file is already in your instructions list, so the next session opens with it loaded.

Why it helps: a good voice guide lets you reuse feedback. You stop fixing the same phrasing every week and fix the instructions behind every draft once.

2. How do you find the customer questions worth answering?

Sales calls and customer conversations bring up questions that never appear in a keyword tool. The best ones usually circle a decision someone is struggling with. OpenCode can read a whole folder of exports, and you decide which model gets to see them.

Read the sales calls, support conversations, customer interviews and closed-lost notes I supplied from [period]. Sort recurring questions into five buckets: problems customers are trying to understand; concerns that slow a decision down; alternatives they compare us with; expectations that end in disappointment; and questions they ask just before deciding. For each theme include an anonymized quote, the source, how many separate conversations contain it, the customer's role and their stage in the decision. Offer two LinkedIn angles per theme: one that helps the reader diagnose the problem, one that helps them assess a solution. Rank the top 10 by how often they recur, their commercial weight and the strength of our evidence. Keep what customers said explicitly separate from your interpretation.

In OpenCode: call recordings and closed-lost notes are the most sensitive material in this whole guide. With a hosted provider, your files travel from your machine straight to that provider. If that's a problem, use /connect to add a local model through Ollama or LM Studio, and the transcripts never leave your computer. Run opencode models to see exactly which provider/model names you can call, and choose the local one for this session only. In both cases, keep one file per conversation in calls/ so the count per theme can be checked, and ask for the output as backlog/customer-questions.md.

Why it helps: your backlog is tied to conversations your business is already having, in language you recognise and with evidence you can verify.

3. How do you track topics moving from X into your market?

An argument gathering attention on X can become a useful LinkedIn post, provided you explain what it means for your customers and add more than a rewrite.

Using web search where it's switched on, the links I give you and public sources you can access, review the last [seven days] of discussion on [topics] and from these accounts: [accounts]. Find up to 10 developments or arguments that matter to [customer]. For each one, give me: 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 consequence for our audience; and a possible angle backed by our experience or evidence. Treat reaction counts as a snapshot, never treat popularity as proof, and check factual claims against the original source when you can. Recommend three ideas to develop and tell me what I would need to add before each becomes a credible LinkedIn post.

In OpenCode: give this to the built-in Scout subagent by starting your message with @scout. Scout is read-only and exists 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 how you've set things up, so the dependable 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 it helps: research gives you somewhere to start, and your judgment gives people a reason to follow you. A good adaptation links the discussion to a decision your readers are facing.

4. How do you analyze posts that beat their author's usual results?

Holding every post up against a celebrity account's biggest hit warps the research. Compare each post with its author's normal results first, then work out what might explain the difference. Because OpenCode can run shell commands, a script can do the arithmetic, so you aren't relying on the model's estimate.

Go through this LinkedIn swipe file and the performance data I have for it: [file]. Where enough comparable data exists, compare each post's reactions and comments with the author's median for a similar format and period. Show your working, and flag small samples, missing metrics and posts that are very recent. For the strongest outliers, set out: the topic and the intended reader; the opening, argument, supporting evidence and close; the format and approximate length; whether the comments suggest real customer relevance; and confounding factors such as a launch, a news event or unusually wide distribution. Produce five reusable structural patterns, then propose one original idea for each, drawn from my own experience. Don't copy distinctive wording and don't present an observed pattern as a rule of the algorithm.

In OpenCode: press Tab to switch to the Build agent, because the medians come from a small script run on swipe-file.csv, and Plan won't run shell commands without asking. Most OpenCode permissions start at allow, so tighten them in opencode.json first; then every command is shown to you before it runs:

{ "permission": { "bash": "ask", "edit": "ask" } }

Have it keep the script as scripts/medians.py so next month's run uses the same maths. To judge a single post quickly, our LinkedIn engagement rate calculator does the same comparison in your browser.

Why it helps: you get sharper hypotheses to test and avoid assuming that a successful post's layout will bring the same results a second time.

5. How do you turn recordings into original posts?

A transcript can bury a strong post inside a story, a passing explanation, or a disagreement that deserved more time than it got in the original conversation. Once the prompt is a saved command, each new recording costs you one line in the terminal.

Go through this interview, podcast, webinar or meeting transcript: [source]. Find eight moments that could support an original LinkedIn post, looking first for decisions, mistakes, surprising observations, practical explanations and opinions rooted in experience. For each moment, give: the exact quote and its timestamp or position; the main idea and who would gain from it; context needed so the speaker isn't misrepresented; supporting facts we already have; and one follow-up question that would strengthen the idea. Pick the three strongest moments and write a post from each using my voice guide. Keep the speaker's level of certainty, take out confidential details, and use placeholders wherever a result or example needs confirming.

In OpenCode: you'll run this after every recording, so make it a custom command. Save the prompt as .opencode/commands/transcript.md, replacing [source] with $ARGUMENTS:

---
description: Pull LinkedIn post ideas out of a transcript
agent: build
---
Go through this interview, podcast, webinar or meeting transcript: $ARGUMENTS
Find eight moments that could support an original LinkedIn post. ...

After that, /transcript transcripts/episode-12.md runs the whole thing. Add subtask: true if you'd like it to run as a separate child session that keeps your main conversation uncluttered.

Why it helps: you publish from knowledge that already exists, and nobody has to produce a brand-new opinion each time the calendar has a gap.

6. How do you build a four-week content calendar?

A calendar has to balance what customers need to understand against what you can back with evidence. Fill every slot with another take on your offer and the feed turns repetitive. With the calendar stored as a file in the same folder, OpenCode can check every slot against your backlog.

Put together a four-week LinkedIn calendar at [three posts per week] from the ideas we approved in research. Include a mix of: practical explanations that help customers fix a problem; opinions supported by experience or evidence; customer examples we're allowed to share; answers to objections and decision questions; and an offer post now and then with a relevant next step. For each post, name the reader, the single goal, the main argument, the source material, a suggested format and the action you want from the reader. Look for repeated topics, overlapping arguments, unsupported claims and too many sales posts. Write complete briefs for week one and shorter outlines for weeks two to four. Leave space for one timely swap each week; the calendar doesn't have to stay fixed.

In OpenCode: point it at backlog/ with @ so the calendar uses approved ideas only, and ask for calendar.md with a table, plus one brief per week-one post in briefs/. For a job with a clear end point, /goal keeps the session going until a reviewer confirms the objective, such as /goal calendar.md has 12 slots, week-one briefs are complete, no topic repeats. Newer versions include an opt-in image_generate tool (experimental.image_generate in opencode.json) for a rough visual for a carousel slot; the slides themselves are faster in our LinkedIn carousel maker. Take the day and hour from the best time to post on LinkedIn tool instead of the model's guess.

Why it helps: a good calendar saves weekly planning time and still leaves space for better ideas, new evidence and shifts in the market.

7. How do you draft posts that have something to say?

Research should fix the argument before OpenCode starts polishing sentences. Skip that, and you can get neat prose that spends several paragraphs on an obvious point.

Draft three LinkedIn posts from these approved briefs: [briefs], following my business context and voice guide. In every draft: make one clear argument for one intended reader; open with a specific observation, tension, result or question the brief supports; explain the reasoning through a concrete example; use bullets where parallel points scan better as a list; vary the length of sentences and paragraphs, with the odd one-line paragraph for emphasis; and finish with a useful implication or a natural next step. Target [180-300 words] unless the idea needs another length. Avoid repeated wrap-ups, invented personal stories, overblown promises and formula contrasts. Provide two alternative openings and say briefly how each changes the emphasis. Flag missing evidence apart from the copy that's ready to publish.

In OpenCode: make this a skill instead of a command, so the agent picks it up by itself whenever you ask for a draft. Create .opencode/skills/linkedin-draft/SKILL.md. The name has to be lowercase-kebab, and the description is what the agent matches against your request:

---
name: linkedin-draft
description: Use when writing LinkedIn posts from approved briefs.
---
(paste the drafting prompt here, unchanged)

OpenCode also looks for skills in .agents/skills/ and .claude/skills/, so the same file works if other agents share the folder. Drafts go to drafts/{week}/{slug}.md. Before review, you can run a finished draft through our LinkedIn post booster to tighten it for reach.

Why it helps: clear limits give you drafts that are easier to judge, so your review is about the argument and not about cutting filler.

8. How do you set up a separate editorial review?

The reviewer needs one defined task: find what's weak in a draft and say how to fix it. A friendly "This is strong" doesn't amount to an editorial process. In OpenCode the cleanest separation is a different agent with different permissions.

Assess these LinkedIn drafts against the brief, the source material, my business context and my voice guide. Give each a score out of 100: customer relevance 25, specificity and supporting evidence 25, strength and clarity of the argument 20, fit with my voice 20, readability and formatting 10. Explain what each score rests on. Check every factual claim, call out generic passages, and mark repetition, abrupt one-line fragments and paragraphs that would work better as lists. Return a revision ready to publish, a short explanation of the changes that matter, and any open questions. Made-up evidence, exposed confidential information or a misrepresented source stops the draft regardless of its score. Keep everything in the review document for a human to approve.

In OpenCode: you can build the reviewer as an agent of its own. Add .opencode/agents/editor.md with mode: subagent, deny it the edit permission, and put the rubric in its instructions:

---
description: Scores LinkedIn drafts with my rubric
mode: subagent
permission:
  edit: deny
---
You are my editor. Score each draft with the rubric from the review prompt...

Call it with @editor. It can't write files, so it can't quietly "fix" a draft without you seeing. It returns scores and a revision; you press Tab to go back to Build and save the approved version into review/. If you don't want to set up an agent yet, the built-in Plan agent is also blocked from editing. Then check the revision on a phone-sized screen in our LinkedIn post preview and confirm its length with the LinkedIn character counter.

Why it helps: a rubric writes your standards down. The score keeps the feedback in order, and the source checks plus the editor's judgment decide whether the post is ready.

What should you do in the first hour after publishing?

You approved the revision from prompt 8 and the post is live. From here, LinkedIn maxxing works the same no matter which agent you use: the first hour counts most, and your job is to gather as many reactions as you can within it.

Start with people you can reach. Colleagues, friends, relatives, clients: people you can contact directly are the best ones to ask for a reaction.

Next, try groups where members support each other's posts. The ones in the next section come from our other guides.

Or use LinkedInLikes, our own community. You paste the post link, choose the action (comments, likes, reposts or saves), set the points per action and how many you want. Other members do it by hand from their own LinkedIn accounts, and they write comments in their own words. If someone confirms an action they didn't do, you can report it within 72 hours and the points are taken back. We never ask for your LinkedIn password. It's free, and new accounts start with 100 starter points.

OpenCode has no way to send the link to LinkedInLikes for you, so paste it in yourself once the post is up. Get first comments on LinkedInLikes.

Which LinkedIn groups can you join for first reactions?

All of these are free. Member counts are the numbers each platform displayed on Oct 21, 2026. Admins run every group their own way, so read the pinned message before posting.

If you'd prefer to skip the group search, add your post to LinkedInLikes and members will see it there.

Part 2: pipeline and performance (prompts 9-12)

9. How do you build content around deals that went quiet?

Some of your most useful posts can answer a concern that several prospects raised in private. The aim is to explain the issue so well that future customers arrive better informed. This is also the prompt where your choice of provider and your sharing settings matter most.

Review the CRM records and call notes I supplied for qualified deals that stopped moving during [period]. Find the objections that keep recurring and separate: objections stated explicitly in conversations; possible explanations nobody has confirmed; and operational delays that content is unlikely to solve. For each repeated objection, record the customer's role, the deal stage, the evidence we have and the question a useful LinkedIn post should answer. Recommend five content briefs. Each should present the concern fairly, show where our approach fits, admit where it doesn't, and identify the proof we'd need. Draft the two strongest posts without naming prospects or disclosing deal details. Separately, suggest approved resources we already have that a salesperson could share in a relevant conversation.

In OpenCode: a CSV export from your CRM in crm/ is the simplest input. A CRM MCP server works too, but every server you switch on adds to the context of each turn, so turn it on for this session and off afterwards. Keep the entry in opencode.json disabled by default and set its "enabled" flag to true only when you run this prompt (the URL is a placeholder for your CRM's server):

{ "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 customer roles in place of names.

Why it helps: marketing starts answering the questions salespeople hear again and again, and you avoid persuasive posts about problems your customers don't think matter.

10. How do you prepare briefs for conversations that start on LinkedIn?

When someone responds to a post, the right next move depends on what they said and whether a business conversation would be welcome. A like or a comment alone doesn't show business interest. Run this prompt in Plan first, because reading and proposing is all it has to do.

Go through these LinkedIn conversations I've supplied: [comments, inbound messages or interactions recorded by hand]. Put them into four groups: questions that deserve a useful public answer; conversations where sharing a resource would help; explicit interest in our offer; and general discussion with no commercial next step. For each relevant conversation, summarise the need the person stated, the business context available and what is still unknown. Write a reply that responds to what they actually said before raising anything else. Where it fits, suggest one follow-up question or a resource we already have. Don't infer business interest from a like, don't invent familiarity, and don't squeeze a meeting request into a conversation that doesn't 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 any file. Switch to Build only to save the drafts to replies/{date}.md. Nothing leaves your machine apart from the model call, and you send every reply yourself. /export saves the whole session as markdown, a handy record of why each reply was drafted the way it was. For quick public replies under your own post, our LinkedIn comment generator is a useful second opinion.

Why it helps: preparation makes your replies more thoughtful without turning every exchange into a sales sequence. Sometimes the best outcome is simply a useful answer.

11. How do you report on business results with honest attribution?

Impressions describe distribution. They can't show whether the right people became interested or whether a post played a part in a deal. OpenCode can run this report headless, without opening the interface.

Merge the LinkedIn analytics, tracked website visits, inbound inquiry records and relevant CRM data I've supplied for [period]. Report on: reach, reactions and comments by post, topic and format; qualified inbound conversations; resource sign-ups and demo requests where tracking exists; opportunities with a documented LinkedIn contact point; and time spent producing and reviewing content. Separate directly tracked conversions, self-reported discovery and possible influence. Don't attribute a whole deal to LinkedIn because one contact reacted to a post. Call out posts that attracted relevant customers, posts that reached a broad but less relevant audience, and posts with too little data to judge. Finish with three findings, three limitations and one recommended experiment. Where possible, compare posts at the same age so new posts aren't judged unfairly against older ones.

In OpenCode: this one doesn't need the TUI. Save the prompt as prompts/monthly-report.md with the 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 particular file, and --format json gives machine-readable output if a spreadsheet needs to pick it up. When some posts have no impression figures, estimate them with our LinkedIn impressions calculator and label them as estimates.

Why it helps: better reporting gives you a reason to repeat or change what you're doing, and it keeps uncertainty in view so patchy tracking doesn't become a confident revenue claim.

12. How do you turn your edits into a better system?

Every draft you edit records something about your standards. Write down the lessons that repeat, and you'll spend less time correcting the same problems.

Compare the original drafts, my edits, the final published versions and the performance data available for [period]. Find: voice corrections I make again and again; claims that needed more evidence; ideas that became clearer after the framing changed; formatting changes that made posts easier to read; and topics that led to useful conversations with customers. Suggest updates to the voice guide, the research briefs and the editorial checklist. For each suggested rule, show an example, explain its purpose and say when an exception would be fine. Keep style preferences apart from performance hypotheses. Don't make a permanent rule out of one post that did well or badly. Return a short change log for my approval and one controlled experiment for next month.

In OpenCode: the comparison only works if your edits are on record, and OpenCode already depends on git: /undo and /redo need it to roll back the agent's own changes. Commit each draft as the agent wrote it, then commit your edited version; the diff between them is the input for this prompt:

git add drafts/ && git commit -m "agent draft: hiring-myths"
# make your edits
git add drafts/ && git commit -m "edited: hiring-myths"
git log -p drafts/ > review/edit-history.txt

Pass review/edit-history.txt to the prompt with @. Approved rules go into voice-guide.md and into the editor agent's rubric, so the writer and the reviewer change together. If a rule turns out to be wrong, /undo reverses the edit OpenCode made.

Why it helps: the workflow gets easier to manage month by month. Your corrections turn into guidance you can reuse, and performance ideas stay open to testing before they harden into superstition.

How should you roll out all 12 prompts?

Build the workflow in stages so you can check the output before you add another recurring job.

For every recurring job, set its inputs, where its output goes, how often it runs and who owns it. Test one run before trusting the schedule, and have OpenCode report missing access or unfinished work. There are two ways to schedule it:

• opencode run plus a scheduler you already use. 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.
• Built-in schedules, if you're comfortable with experimental features. Recent releases add opt-in scheduled prompts through /schedule once experimental.schedules is switched on, and they run under opencode serve. Treat them as a preview and check the first few runs by hand.

# Mondays at 08:00: topic scan (prompt 3)
0 8 * * 1 cd ~/linkedin-content && opencode run "$(cat prompts/x-topics.md)"
# 1st of each month at 09:00: report (prompt 11)
0 9 1 * * cd ~/linkedin-content && opencode run "$(cat prompts/monthly-report.md)"

OpenCode writes the plan; publishing is up to you. You don't need 12 separate agents on day one. Begin with the job that eats the most time and gives you output you can judge with confidence.

What can OpenCode do for you, and what stays your job?

OpenCode can organise research, find useful evidence, prepare drafts and learn from your edits. The quality still depends on the experience and judgment you put into the system, and on the model you pick to run it.

That means holding a real opinion, being ready to explain it, and noticing when a polished draft says something you would never defend face to face.

Next step: run /init, load your context and start with prompt 1, since better inputs improve every step after it. When the first post is live, join LinkedInLikes and use your starter points to get its first comments from members.

More articles

• How to build an AI content system for LinkedIn from one empty folder
• The 2027 LinkedIn marketing playbook
• LinkedIn maxxing with Claude Code