Status cards
One graphic, one post, and a clear answer to “what is actually done?” Keep estimates, evidence, and blockers in the same frame.
Small dots.
Useful tricks.
Progress trackers, incident updates, and a few hard-earned ways to get your dot to do the job you actually asked for.
A dot is ChatGPT’s ongoing assistant. This is my collection of reusable workflows for mine. It is not an official store, and it does not mean the rough bits are fixed.
- Make something useful
- Check that it works
- Ask permission… again?
The skill shelf
Each guide explains when to use it, what to give your dot, and what a useful result looks like. The full instructions are plain Markdown you can read before trying anything.
Incident updates
Tell people what is broken, what still works, and what to do next. A green light should mean something.
Visual audits
Check the thing people will see. Catch cramped labels, clipped graphics, broken controls, and motion that gets in the way.
Source evidence
Follow a claim back to its source. Separate what happened, what you inferred, and what you still cannot verify.
A bar with
something behind it.
Pretty progress is easy. Honest progress needs a scope, evidence, and a way to say “not checked.” Try the states below. The celebration waits for verification.
Building
Newsroom planning board
Progress toward the agreed goal25%
Six equally weighted milestones. Partial work is an estimate, not time remaining.
- Scope agreedComplete
- ImplementationIn progress
- Review + mergeNot verified
- ReleaseNot verified
- Live checkNot verified
- Staff acceptanceNot verified
The scope is agreed and the build is partly complete. No release or live check yet.
- Last successful evidence check
- Example day, 09:40
- Last progress change
- Example day, 09:20
Choose a state, then see what an unchanged or failed check does to the two clocks.
All numbers, events, and times here are examples. This page does not connect to Slack, check a real project, or schedule work.
- Define the finish line.
Choose the deliverables and the proof you need before calculating a percentage. “Code written” and “working for staff” are different milestones.
- Keep two clocks.
A fresh check does not mean fresh progress. A failed check should not make old evidence look current.
- Update the same post.
Prepare the full card, replace the approved original when the tools support it, then read it back. No placeholder post and no surprise extra ping.
Still 67%? That can be right.
A broken test browser does not undo completed code. It also does not prove the release works. Keep the progress; name the missing check.
Try a recipe.
Keep the receipt.
These are instructions to adapt, not buttons that install access to your accounts. Start small enough that you can check the result.
- Read the playbook.
Choose one job. Review the inputs, examples, and limits before giving the instructions to your dot.
- Make the scope concrete.
Name the destination, posting identity, permitted actions, and what must stay private. Have the dot read back what it saved.
- Try one low-stakes run.
Inspect the delivered result. A recurring schedule should come after that check, not stand in for it.
- Bring back what happened.
Share a redacted example, the failure, or an improvement. State what you tested and what you could not test.
Something like
a skill exchange.
I want this to become a place to share useful dot workflows, not just screenshots of things that worked once. For now, it is a small, public collection with readable instructions and visible limits.
A good submission includes a real task, a reusable method, an example, and a frank account of what failed. No one-click installation or blanket compatibility claim is implied.