Brainn.devAccount Buy me a coffee

Brainn.dev / Daily Bites

A small fix.
A better next attempt.

One AI problem, one practical solution, and one thing to try. Start with seven short exercises from the workbench: prompts, evidence, handoffs, and checking that done means done.

By Chuck Gamburd · First collection prepared September 6, 2026. Written with AI assistance from documented working practices. These are exercises to test in your workflow, not measured promises.

Choose Daily Bites emails

A separate opt-in from weekly project updates. One per day while new lessons are available; no repeated lessons when you catch up. The account page shows the current delivery status.

BITE 01

Give each prompt one job

The problem

Your all-in-one prompt keeps growing: research, write, critique, format, and somehow remember every exception. When the result goes wrong, it is hard to tell which instruction failed.

The solution

Try a small prompt pack for a task with clear stages: a brief, a draft prompt, and a review prompt. Keep shared facts in one short context note. Run one stage, inspect its output, then pass that output to the next. A simple task may still work best in one prompt.

Try this prompt

BRIEF: Using these notes, identify the reader, the question, and three facts we can support. Flag missing evidence.
DRAFT: Write a 300-word explanation using the approved brief. Label assumptions.
REVIEW: Compare the draft with the brief. List unsupported claims and missed requirements. Do not rewrite yet.

Your move

Take one recurring task. Split off only its review step. Compare whether the separate review catches a mistake you can verify.

This is a proposed workflow exercise, not a measured claim that more prompts always perform better. Anthropic describes prompt chaining for tasks that divide into clear steps and notes the extra latency.

Anthropic: prompt chaining and its tradeoffs

Link to this bite

BITE 02

Show the shape of a useful answer

The problem

You ask for a useful project update and get a page of polished sentences. You still cannot tell what changed or what needs you.

The solution

Write a tiny example of the output you can act on. Include the fields that matter and what to do when a fact is missing. Treat this as a template to test, not proof that the answer is correct.

Try this prompt

Report in this shape:
Changed: [concrete change]
Evidence: [test result or source I can inspect]
Still unknown: [unverified claim]
Next action: [one action, owner, and blocker]
If a field has no evidence, write 'not verified'.

Your move

Reuse the template on yesterday's task. Open one piece of cited evidence and check that it supports the reported change.

Our website release notes distinguish source changes, a successful build, and the result at the public URL. The template turns that preference into an exercise.

Why the public game URL needed its own check

Link to this bite

BITE 03

Give missing facts somewhere to go

The problem

A draft sounds complete, but one of its details was never in your notes. You now have to hunt for the invented part.

The solution

Ask for a short evidence table before prose: claim, supporting material, and what is still missing. Then check the material yourself. A model marking something 'supported' is a lead to inspect.

Try this prompt

Before drafting, make a table with: proposed claim | supporting quote or file location | missing information.
Use only the material below. Mark missing facts as UNKNOWN. Do not fill them with plausible details.

Your move

Remove one fact from a familiar example and run the prompt. Check whether the missing fact stays missing.

The Brainn.dev editorial workflow separates observed results, inference, opinion, and hypotheses. This exercise applies that distinction to a small draft.

Brainn.dev research and build notes

Link to this bite

BITE 04

Leave the next chat a usable handoff

The problem

A long conversation ends, and the next chat knows the summary but misses the decision that mattered.

The solution

Save a short handoff beside the work: objective, decisions, current files, verified results, and the next unfinished action. Include links or paths to evidence. Read it at the next start and check anything likely to have changed.

Try this prompt

Create a handoff containing:
1. The outcome we are pursuing.
2. Decisions and constraints that still apply.
3. Exact files and evidence to read first.
4. Completed work versus unverified work.
5. The next unfinished action.
Do not turn a plan into a completed result.

Your move

Start a fresh conversation with your handoff and the relevant files. See whether it identifies the next action without a recap from you.

This is an exercise based on our documented continuity practice. A handoff is an index to evidence, not a guarantee that the next assistant will preserve every detail.

Notes from the Brainn.dev workshop

Link to this bite

BITE 05

Define the check before the build

The problem

The assistant says a feature is done. The button exists, but the path from clicking it to getting the result has not been tried.

The solution

Write the user journey and its success check before implementation. Include a failure case and a way to recover. Keep the check proportionate to the change.

Try this prompt

Success means: a reader opens the page, submits a valid comment, sees pending review, and later sees the approved comment.
Also check: a failed request preserves the draft and lets the reader retry.
Report which steps you actually tested.

Your move

Choose one feature you already use. Follow its main journey in a fresh browser session and record the first point where the visible state disagrees with what happened.

This applies the same distinction we used when checking the public game: implementation evidence and actual delivery evidence answer different questions.

Play the public demo

Link to this bite

BITE 06

Give revision a finish line

The problem

Every request to improve a draft produces a different draft. After five versions, you cannot say whether anything improved.

The solution

Pick two or three observable criteria and keep the previous version. Ask for one revision against those criteria, then compare. Stop when it passes or when the changes stop helping.

Try this prompt

Revise once using these criteria:
- The first paragraph states the concrete problem.
- Every factual claim has support in the supplied notes.
- The reader can take one action without missing instructions.
Show what changed for each criterion. Preserve any uncertainty.

Your move

Compare the original and revision against the same criteria. Keep the original if it does the job better.

This is a bounded editing exercise reflecting our preference for evidence over repeated polish. It does not require a paid model or an automated critique loop.

Read the workshop notes

Link to this bite

BITE 07

Check the destination before saying sent

The problem

A document exists locally, or a page built successfully, and the update says it has been delivered. The person who needs it still cannot open it.

The solution

Name the state precisely: drafted, saved, uploaded, published, or opened successfully at its destination. After an authorized delivery, verify the destination with the access the reader will use.

Try this prompt

Prepare the artifact and report its current state.
After the authorized delivery, reopen the destination and verify the title, content, and intended access.
If you cannot check the destination, say 'delivery unverified' and identify the missing check.

Your move

Open the last artifact you shared from its destination link. Check its contents and access instead of relying on the upload message.

Our website contract requires a successful production build and live checks before calling a release published. This exercise applies that habit to an ordinary file or page.

Brainn.dev public work

Link to this bite
Read the longer build notes
Stupid PeopleCheck the game’s Menu for save status.