Real-World GSD: Practical Playbooks for Code, Writing, and Proposals

The previous five articles covered GSD's problem, mindset, tools, and traps. This article has one job: turn all of that into an operating manual you can use today.

Different task types get stuck in different places, and the launch approach differs too. Below are complete GSD rhythms for three of the most common task types — you don't need to use all of them, just find the one that matches your work today.

Scenario 1: Code Development

Most Common Sticking Points

Vague requirements — unclear where "done" ends
AI changed something, unclear whether it touched things it shouldn't have
Fixed a bug but created another one, on an endless loop
"Build it first, add tests later" — and tests never get added

GSD Playbook

Start (3 minutes)

Tell AI these four things clearly:

What to complete this session (one feature/fix — limit to one thing)
What's out of scope (state it explicitly — AI not touching something is more reliable than it guessing)
Completion standard (what behavior/output counts as done)
What known constraints or dependencies are in play

Task: Implement JWT refresh logic for user login
Out of scope: Login/logout flow, user schema — don't touch
Completion standard: refresh token can exchange for a new access token, old refresh token auto-expires
Constraints: use existing auth.service.ts, no new dependencies

Execute (focused block)

Have AI list what it's planning to do, confirm it, then start
After each small step (e.g., one function), run it locally to verify, confirm it's correct before continuing
If AI's output is something you can't understand, that's a signal — understand it first, then continue. Don't run blind.

Close (5 minutes)

Run through the main flow manually, confirm the happy path passes
Write a commit message that says clearly what changed
If there are tests or edge cases not yet handled, open a to-do item, record it — don't leave it in your head

Common trap to watch for
When AI is fixing bugs, it very easily "incidentally" improves things you didn't ask it to. In the diff, look carefully at changes you didn't request — not because they're necessarily bad, but because you need to know what changed. Otherwise you can't say "I understand what this feature does."

Scenario 2: Article Writing

Most Common Sticking Points

Don't know where to begin, endlessly "in the mood"
AI-generated draft reads like it was written by AI — revising it is harder than rewriting
Got halfway through and realized the structure is wrong, back to square one
Feel like it's not ready to publish yet, in perpetual "polishing" mode

GSD Playbook

Start (5 minutes)

Before writing a word, use AI to clarify these two things:

Who's reading, and what will they know after reading
Not "this article is for developers" — but "after reading this article, the person should be able to explain what X is, and know what their next step is."
The article skeleton (H2 list)
Summarize in one sentence what each H2 argues — not the title itself, but "what this section is saying." Confirm the skeleton is right, then start writing.

With the right skeleton, AI's draft can head in the right direction. Start writing without confirming it, and you'll likely realize mid-way that the structure went sideways, then fall into the costly "restructuring the article" mode.

Execute (complete section by section)

Recommended rhythm: ask AI to write one H2 section at a time, not the entire article at once.

One section at a time has several benefits:

You can verify tone and perspective match what you want at each section's completion
Your own cost to intervene and revise is much lower — editing one section is far easier than editing an entire article
Each completed section gives you a small sense of progress — psychologically easier to handle than seeing one "almost perfect" full draft all at once

When prompting AI to draft, include: "Be more direct, less preamble, avoid openers like 'It's worth noting that'" — this at least filters out the most common AI-sounding patterns that are painful to edit out.

Close (10 minutes)

Quickly scan the whole piece, confirm each H2's argument is clear and the article has proper flow
Change any sentences that don't sound like how you talk (two or three, not the whole thing)
Set a publish time — today or tomorrow, commit to it, then honor it

Common trap to watch for
The feeling of "this isn't ready yet" is, 99% of the time, not real — it's you being a little anxious about being seen. Ask yourself one question: "If this article just needs to give one person something valuable, does it do that now?" If yes, publish.

Scenario 3: Proposal Preparation

Most Common Sticking Points

Unclear what the other party actually cares about — did a lot but missed the core
Too much information crammed in, people can't find the point
AI-generated proposals feel too "template-like," not persuasive
Multiple versions revised back and forth, but no direction between versions

GSD Playbook

Start (5 minutes)

The most important step in launching a proposal is first clarifying "the other party's problem" — not what you're proposing, but "what is the other party's current situation, what outcome do they want, what constraints matter most to them."

Use AI to build an "other party perspective summary":

Audience: [who they are, what role]
Their current situation: [problem or challenge they're facing]
Their desired outcome: [in their language]
Their top constraints: [time, budget, risk, internal politics...]
Please help me, from the perspective of "what matters most to the other party," summarize the core questions this proposal needs to answer.

Once this step is done, you have a framework that's hard to drift from.

Execute (structure first, details later)

The right order for writing a proposal: first confirm "the one-sentence core argument," then expand the structure, then fill in the details last.

The cost of doing it in reverse: you spend a lot of time filling in details, then realize the core argument isn't clear, and the whole proposal needs a major rewrite.

Suggested order using AI:

Ask AI to generate a one-sentence argument for the proposal (three versions, you pick one)
Expand into 3-4 supporting points based on the core argument
What data or examples does each supporting point need (list first, then go find them)
Layout design and visual polish only at the very end

Close (10 minutes)

Quickly read through from the "other party's perspective": does this proposal answer "why is this solution best for them"?
Confirm there's a clear "next step" — what should the other party do after reading, how do you want them to respond
Name the version clearly, save the "version to be sent" as a file — don't let versions keep drifting

Common trap to watch for
AI-generated proposal language tends to be too "formal" — full of "to achieve the objective" and "through effective methods"-style filler sentences. These sentences have words but say nothing. Before sending, replace this kind of language with "we did X, therefore you get Y" — concrete, specific language.

The Universal Closure Ritual

Regardless of task type, do these three things before finishing — so your brain can genuinely say "this thing is done":

Confirm completion conditions are met (not "feels about right" — DoD checklist is checked)
Record unresolved issues in the right place (not left in the chat — into the to-do list or notes)
Let the output leave draft status (commit, publish, send — let it truly "go out")

Turning GSD into a Habit

This series has gone from "diagnosing the problem" to "real-world scenario playbooks." Everything together ultimately wants you to take away just this one daily rhythm:

Morning: what are the three things today (task-level list)
Before each thing: are boundary and completion condition confirmed
After each thing: can I check this box, is the unresolved stuff recorded
End of day: did anything actually get completed

These four questions require no special tools — but they'll make your AI usage efficiency one order of magnitude higher than most people's. Not because you're using a more powerful model or longer prompts, but because you know what you're doing, where "done" is, and how to close when you get there.

That's Get Shit Done.

Back to Series Overview

This is the final stop in the GSD series, covering practical playbooks for code, writing, and proposal tasks. For the full reading path and other article topics, return to the GSD Beginner Course.