← Back to all topics
Getting Started

5 Things to Try First

Five projects that — based on real experience — give you the biggest unlock for the least effort. Each produces something real you'll keep using. The order is roughly fastest-to-most-transformative — but pick whichever sounds most useful first.

Work in progress — the structure is solid but each section will continue to be refined with screenshots and worked examples.
Why this page exists: Reading guides is one thing. Doing something real is what makes it click. These five aren't random "AI demos" — they're the things that, in hindsight, made the biggest difference once they were in place.

1. Turn a long document — or a whole project's worth of material — into something usable

This was the first moment OpenCode genuinely changed how I worked. Pick a long, dense document — a Confluence page, a PDF playbook, a strategy deck, a technical spec — something you've been meaning to read but haven't. Drop it into your OpenCode working folder and turn it into something you'll actually use: a 1-page summary, an FAQ for your team, a training brief, a checklist, whatever fits.

The bigger unlock: don't stop at one document. The real power shows up when you give OpenCode everything on a topic at once. Take a whole project's worth of literature — decks, meeting transcripts, Confluence exports, Word docs, PDFs, email threads, prior status updates, anything you can find — and dump it all into a single folder. Then ask for the outputs you actually need. The more context you give it, the sharper and more grounded the output. This is where OpenCode pulls ahead of a normal LLM chat: it can hold and cross-reference a project's entire body of material in one go.

How to do it

  1. Create a folder for the topic or project (e.g. ~/Desktop/OpenCode/Project-Atlas-Context).
  2. Save everything relevant into it — PDFs, Word docs, decks, exported Confluence pages, meeting transcripts, screenshots, prior summaries. PDF, Word, Markdown, plain text, images all work. Don't filter too hard — more context is almost always better.
  3. Open OpenCode in that folder.
  4. Paste in a prompt like the one below.
Read everything in this folder — all the documents, decks, and transcripts —
and produce:
- A 1-page plain-English summary of what this project is and where it stands
- The 5 most important takeaways across all the material
- An FAQ covering the questions a new team member would ask
- Any contradictions, gaps, or things that are unclear across the documents
- A list of open questions or decisions that still need to be made

Save the output as a new markdown file in this folder called project-summary.md.

Then ask follow-ups: "rewrite the summary for an exec audience," "draft a stakeholder update based on this," "what would you tell someone joining the project tomorrow?", "are there any risks the documents hint at but don't call out directly?" Each one takes seconds and uses the same context.

Why it's impactful: almost every team has long documents nobody actually reads. This turns them into something people will. Multiply across every playbook, spec, and SOP your team owns.

What you'll learn: how files become context, how to ask for structured output, how to iterate on the result rather than start over.

Time: 15 minutes

2. Connect your chat tool as a live data source (MCP)

This is the moment OpenCode shifts from "smart chatbot" to "live assistant working alongside you." Instead of you exporting transcripts or copy-pasting messages, OpenCode can read your team chat tool directly — current messages, threads, channels, all of it. Works with Slack, Microsoft Teams, Webex, Discord, and most other chat platforms that have an API.

How to do it

  1. Ask OpenCode to set up an MCP connection to your chat tool of choice. It will tell you what kind of token or API key it needs.
  2. Generate the token from your chat tool's developer or integrations settings (OpenCode can walk you through where to find this).
  3. Paste the token back in — OpenCode will add it to your global config. It's a one-time setup.
  4. Restart OpenCode so it picks up the new MCP.
  5. Ask OpenCode to list your channels/spaces to confirm it's connected.
  6. Then try a prompt like the one below.
Set up an MCP connection to [Slack / Teams / Webex / etc.] so you can
read messages from my team channels. Tell me what you need from me.

Then once it's connected:

Pull the last 30 messages from the [team name] channel and tell me
what's been going on this week — key topics, any blockers, anything I
should respond to.

Or:

Summarise everything that's been discussed in [project] channel since
last Friday and draft me a stakeholder update.

Once you have one MCP set up, others (your wiki, ticket system, etc.) follow the same pattern and feel much easier.

Why it's impactful: removes the friction of moving data into OpenCode. Cuts out the manual export step that kills momentum. Makes "give me a quick summary of what's been happening" a 10-second ask.

What you'll learn: how MCPs work, what live context unlocks, why the small upfront setup pays back many times over.

Time: 30 minutes

3. Publish your first GitHub Page

Ask OpenCode to build you a single-page site — documenting a process, your team, a project, anything — and publish it to GitHub Pages so it has a real URL you can share. Within an hour, you'll have a live, professional-looking page you can send to colleagues. The psychological shift is significant: you go from "AI helps me write things" to "I built that."

How to do it

  1. Make sure you have a GitHub account and can sign in at github.com in your browser.
  2. In OpenCode, open a fresh folder where you want this project to live.
  3. Paste in a prompt like the one below.
  4. OpenCode will create the files, walk you through any GitHub auth prompts, push to a new repo, and enable Pages.
  5. Give it 1–2 minutes after the push for the URL to go live.
Build me a one-page site that explains [process / team / project],
with a clean dark theme. Push it to a new repo on my GitHub account
called [repo-name] and enable GitHub Pages so it has a real URL I can
share. Walk me through anything you need me to confirm.

Real examples: this site you're reading right now was built this way — and a published team overview, several process pages, and personal portfolio sites have all been built the same way by people without a coding background.

Why it's impactful: outputs become real, shareable artefacts with URLs — not just chat history that disappears. Massive credibility unlock with stakeholders. Once you can publish pages, you can document anything in a way that lasts.

What you'll learn: how outputs can become real published artefacts, how GitHub Pages works, how OpenCode handles the technical bits so you don't have to. See Collaborating on GitHub Pages.

Time: 30–60 minutes

4. Set up Backlog.md as your task tracker

Backlog.md is a simple way to track tasks that lives inside your folder structure — and OpenCode can read, update, and create tasks in it directly. Once it's set up, you can stop scattering todos across notes apps, sticky notes, and your head.

How to do it

  1. Pick or create a folder where you want your backlog to live (a dedicated "Assistant" folder or your main working folder both work).
  2. Open OpenCode in that folder.
  3. Ask OpenCode to set it up using the prompt below — it will install Backlog.md and initialise the structure.
  4. Once it's set up, ask OpenCode to add it to your global config so every session knows where the backlog lives.
Set up Backlog.md in this folder so I can track tasks. Once it's
working, update my global AGENTS.md so every future OpenCode session
knows to use this folder as the backlog.

Then start using it:

Add a task to my backlog for [thing], with [acceptance criteria],
priority high.
Show me everything currently in my backlog and suggest what I should
focus on next based on priority and what's already in progress.

This becomes the system of record OpenCode uses across all your sessions. New project? OpenCode checks the backlog first. Want a status update for stakeholders? OpenCode reads it from the backlog.

Why it's impactful: moves your task management from scattered/private to structured/shared with OpenCode. Means OpenCode always knows what you're working on without you having to re-explain. Long projects become genuinely manageable.

What you'll learn: how to use OpenCode as a project manager, not just an output generator. How a single source of truth changes everything downstream.

Time: 20 minutes

5. Write a session summary at the end of each big project session

This sounds small. It's actually the single most underrated practice in this whole guide. It's what turns OpenCode from "great in a single session" into "great across weeks and months."

How to do it

  1. At the end of any meaningful working session, open the project folder in OpenCode (if you're not already there).
  2. Paste in the prompt below.
  3. OpenCode will write a session-summary.md file in that folder.
  4. Next time you open the folder, OpenCode will pick it up automatically (because of the rule in your global config — see Initial Setup).
Write me a session-summary.md in this folder that captures:
- The goal of this project
- What we've done so far
- What's in progress
- What's blocked or pending decisions
- Key context anyone (or you, next time) would need to continue
- Critical IDs, URLs, file paths, credentials I shouldn't have to re-supply

Next time you (or anyone) opens that folder, OpenCode reads the summary first and picks up exactly where you left off. No re-explaining, no lost context, no "what was I doing again?"

This is what makes long-running projects (like this site) actually possible — without it, every new session starts from cold. With it, every session compounds on the last.

Why it's impactful: turns OpenCode from "great in a single session" into "great across weeks and months." This is what unlocks ambitious projects that span many sessions.

What you'll learn: the discipline of capturing state. The compounding power of session continuity. Why the best AI workflows are 80% setup and 20% prompting.

Time: 5 minutes per session — pays back many times over.

What next?

Once you've done two or three of these, the rest of this guide will make a lot more sense — you'll have hands-on context for what's being described. Browse the topic cards on the home page and follow whatever you're most curious about.

And if any of these spark ideas for things you want to try yourself — that's the goal. The five above are starting points, not a finishing list.