Good vs. Bad Instructions

The key principles

Writing good instructions for Autohand Code comes down to four habits. Once you internalize these, everything else follows naturally.

Be specific, not vague. Tell Autohand Code exactly what you need instead of leaving it to guess. The more precise you are, the less back-and-forth you need.
Include context about intent, not just the change. Explain why you want something done. This helps Autohand Code make better decisions when it runs into edge cases.
Reference files and locations when you know them. If you already know where the problem is or where the code should go, say so. It saves time and avoids changes in the wrong place.
Describe the outcome you want. Instead of dictating every step, describe what done looks like. Autohand Code can often find a better path to the result than you would prescribe.

Rule of thumb: If another developer on your team could not act on your instruction without asking follow-up questions, Autohand Code will struggle with it too.

Bug fixing examples

Bug reports need symptoms, location, and expected behavior. Vague reports lead to guesswork.

Bad:

fix the bug

Too vague. Which bug? Where? What is it doing wrong?

Good:

The login form shows a blank screen after submitting valid credentials.
Fix the redirect logic in src/auth/login.ts

Specific symptom, file location, and a clear pointer to where the problem likely lives.

Bad:

it's broken

No context at all. Autohand Code has nothing to work with.

Good:

The API returns 500 on POST /api/orders when the items array is empty.
Add validation to return 400 with a helpful error message

Error code, endpoint, trigger condition, and expected fix all in two lines.

Feature building examples

Feature requests need scope, technology choices, and references to existing patterns in your codebase.

Bad:

add authentication

Authentication is a huge topic. OAuth? JWT? Session-based? What endpoints?

Good:

Add JWT-based login to the Express API. Use bcrypt for password hashing,
store tokens in httpOnly cookies, and add a /me endpoint that returns
the current user

Specific technology choices, clear scope, and a concrete deliverable.

Bad:

make a dashboard

What kind? What data? Where does it live?

Good:

Create a sales dashboard page at /dashboard with three cards showing
total revenue, active orders, and new customers this month. Use the
existing Card component from src/components/ui

Route, data points, and a reference to existing components so Autohand Code stays consistent with your codebase.

Refactoring examples

Refactoring instructions should name the pattern you want, the target, and any constraints on behavior.

Bad:

clean up the code

What does "clean" mean? Different developers have different opinions.

Good:

Refactor the UserService class to use dependency injection instead of
direct database calls. Extract the DB queries into a UserRepository

Clear pattern (DI), specific target (UserService), and a concrete extraction step.

Bad:

make it better

Better how? Faster? More readable? More testable?

Good:

Split the 400-line handleRequest function in api/router.ts into separate
handler functions, one per HTTP method. Keep the same behavior

Measurable change, specific file, and a safety constraint that existing behavior should not change.

Testing examples

Test instructions should specify the function, the type of test, and the edge cases you care about.

Bad:

write tests

For what? What kind of tests? What should they cover?

Good:

Write unit tests for the calculateDiscount function in src/pricing.ts.
Cover edge cases: zero quantity, negative prices, expired coupons, and
percentage discounts over 100%

Function name, test type, file location, and four specific edge cases. Autohand Code knows exactly what to produce.

Git and review examples

Git workflows benefit from explicit steps and safety checks. Autohand Code respects careful, staged approaches.

Bad:

commit this

No context about what changed or what the commit message should say.

Good:

Review my staged changes, then create a commit with a conventional
commit message

Clear two-step workflow: review first, then commit with a standard format.

Bad:

push to prod

Dangerous without any review step. Autohand Code will push, but you might regret it.

Good:

Review the diff between this branch and main. Flag any security concerns
or breaking changes before I merge

Safety-first approach. Get a review before taking action.

Pipe mode examples

Pipe mode lets you send data directly to Autohand Code from other commands. Pair the piped context with a clear instruction.

Bad:

echo "fix" | autohand

No context, no data, no direction.

Good:

git diff --staged | autohand "Review these changes for potential issues and suggest improvements"

The staged diff provides context, and the instruction tells Autohand Code what to do with it.

Good:

cat error.log | autohand -p "Analyze this error log and identify the root cause"

Log analysis with pipe mode. Autohand Code receives the full log and a focused task.

Quick reference

A summary of the patterns covered in this guide.

Pattern	Bad	Good
Scope	"fix it"	"Fix the null pointer in auth/session.ts line 42"
Context	"add a form"	"Add a contact form to the /about page using the existing Form component"
Outcome	"make it faster"	"Optimize the product list query to use pagination instead of loading all 10k records"
Safety	"change the database"	"Add a migration to rename the users.name column to users.full_name"

Next steps

Autohand Code in your SDLC - Learn how Autohand Code fits into your development lifecycle
Instructing Autohand Code - Dive deeper into writing effective prompts
Plan mode - Use plan mode for large, multi-step tasks