Practical Notes · 2026-05-31 · Tim Keal

How To Succeed At ChatGPT

A field guide for getting useful work out of an AI assistant: give it a name, give it standards, demand real debugging, and never accept vague slop in place of finished work.

The Core Idea

Ariel works just fine for me: zero slop.

To get strong results from ChatGPT, you have to guide it like a real collaborator. That means asking for three things every time the job matters:

1

Review

Have the assistant inspect the existing files, code, assumptions, and context before making changes.

2

Debug

Require actual troubleshooting, not guesses. The assistant should identify what is broken, why it is broken, and what needs to change.

3

Update and Repack

When files are involved, the assistant should update only what changed, preserve archival paths, package the result cleanly, and avoid placeholder stubs.

The Reminder Prompt

This is the kind of reusable instruction that keeps the assistant on track:

Ariel: Review, Debug, Moment of Clarity, Update and Repack please! Remember, only repack using files that have actually changed while preserving file archival paths. Ensure your zip file is named without escapes. Ensure your zip is valid and Remember, no stubs! Go! :D

If any one of those steps gets skipped, the work tends to drift into slop.

Give the Assistant a Working Identity

It helps to identify yourself by name and give the assistant a name too. In my case, I call the assistant Ariel.

That makes the working relationship clearer and more consistent. I also have Ariel write code in a style that mimics my own personal style, so edits fit naturally into my projects instead of looking like generic output dropped in from nowhere.

Keep Your Best Prompts Handy

I keep my “Review, Debug, Moment of Clarity, Update and Repack” prompt in my local Joplin notes so I can quickly copy and paste it whenever needed.

I also use Notepad++ with automatic backups enabled, plus PowerShell scripts to automate zip-based backups. That way, every experimental change has a recovery path.

Build a Fast Local Workflow

For testing, I use a local XAMPP HTTP host. Fast local testing matters because it keeps the feedback loop short. When the assistant gives me code, I can test immediately, report the exact failure, and then iterate.

My scripts are organized by category, with both alpha and official folders. That keeps experimental builds separate from stable builds.

Project Structure and “God” Scripts

I also have two master utility scripts: one called Nu and the other called Ink. These handle file parsing, shortcuts, and other project-level conveniences.

Having these central utilities means the assistant needs to understand the project architecture before changing anything. Otherwise, it may fix the symptom while breaking the framework.

Examples From My Projects

Here are two examples from my game projects:

Dungeon was one of my first game attempts from around 1994, recently ported to JavaScript under a master engine. The levels are intentionally messy: some are good, some are broken, and some are tests.

3D Mineshaft is newer. It uses a gamepad and requires analog sticks. The static hiss is a placeholder while the graphics finish lazy-loading.

Note: where the project says “2D,” it is supposed to mean “3D.”

The Takeaway

To make an AI assistant useful, do not just ask it for output. Give it a workflow:

  • Make it review before changing.
  • Make it debug before guessing.
  • Make it explain the moment of clarity.
  • Make it update only what changed.
  • Make it preserve paths and produce valid packages.
  • Make it match your style instead of replacing your style.

These habits help keep your AI assistant from being crap.