I’ll admit it. The first time I opened Claude Code, I treated it like a chat window with a dark background. I typed one line, hit enter and crossed my fingers. So when I found this post from an AI professional who made the same mistake, I felt seen.
The author’s point is simple. Claude Code isn’t a chatbot with a terminal attached. It’s an agentic coding tool. That means it reads your codebase, edits files, runs commands, writes tests and works with Git. Most people type one vague line, hope for the best and then blame the tool when it misses.
The creator shared their own week-one prompt, and it was two words long: “fix authentication.” They called it a founder habit: “Delegate fast, specify never.” The lesson came straight from hiring. Vague briefs get vague work. Specific briefs get shipped.
What I love about this post is that it maps the whole process on one page. The author’s main lesson is that the tool is only as good as the process around it. So here it is as a step-by-step guide you can follow today.
Get set up and learn the five launch commands
Installation takes one curl line on macOS, Linux or WSL. Then you cd into your project folder and run “claude”. From there, the expert points out five launch patterns worth knowing by heart:
- claude: opens an interactive session inside your project
- claude plus a task: starts the session with an instruction already loaded
- claude -p: runs it non-interactively, which is handy for scripts and automation
- claude -c: continues your latest session
- claude -r: resumes an older one
Why bother with these? Because “-c” and “-r” mean you don’t have to re-explain everything after you close the terminal. That alone saves a lot of repeated typing and a lot of lost context.
Follow the six-stage workflow
This is the heart of the post. The original poster lays out a workflow “that holds up,” and each stage has a clear reason behind it.
- Explore: have Claude understand the relevant code first. It can’t fix what it hasn’t read.
- Plan: use Plan Mode for complex changes. You review the approach before a single file changes.
- Implement: make focused changes that keep existing patterns. Small, consistent diffs are much easier to trust.
- Verify: run tests, type checks, linting and builds. This is where “looks done” turns into “is done.”
- Review: check for bugs, security issues and regressions before anything ships.
- Commit: only after verification passes.
The order is the whole point. Most bad results come from jumping straight to implementation and skipping the understanding and checking around it.
Rewrite your prompts like a real brief
According to the author, a strong prompt carries six things: the goal, relevant files, error messages, constraints, expected behavior and verification criteria. Think of it as the brief you’d hand a new senior hire on their first day.
The before-and-after example in the post makes this click. The vague version was “fix authentication.” The better version reads like this:
“Find the session expiry root cause, add a failing test, apply the smallest fix, run tests, review the diff.”
See what changed? It names the actual problem. It asks for proof first with a failing test. It keeps the scope small, and it builds verification right into the request. You can reuse this pattern for almost anything. For example: “Find why the checkout total is off by one cent, add a failing test that reproduces it, apply the smallest fix, run the full test suite and show me the diff.”
Layer on the power features
Once the basics feel natural, this contributor recommends stacking these on top:
- Slash commands: /help, /clear, /compact, /context, /init, /permissions, /hooks, /rewind, /resume, /doctor
- CLAUDE.md: a project file that holds conventions, architecture rules, preferred libraries and test commands
- Skills: for repeatable jobs like reviewing PRs, creating API endpoints or fixing GitHub issues
- Subagents: helpers with separate contexts, such as a debugger, security reviewer, test engineer or docs writer
- MCP: connects Claude to Notion, GitHub, Figma, databases and issue trackers
- Hooks: automatically run tests and ESLint, format files and enforce rules
- Permissions: Plan Mode first, minimum access, sandbox, and human approval for sensitive actions
If that list feels like a lot, start small. Run “/init” once to create a starter CLAUDE.md, so Claude learns your project’s rules without you repeating them every session. Then add one hook that runs your tests. Instructions can get forgotten, but a hook runs every single time.
Avoid the most common mistakes
The author wraps up with the mistakes they see most often. I’d honestly print this list and stick it next to the monitor:
- ✘ Vague prompts
- ✘ Coding before understanding the repo
- ✘ Accepting “done” without verification
- ✘ One huge conversation (use /clear and /compact)
- ✘ Skipping tests
- ✘ Fixing symptoms instead of root causes
The “one huge conversation” trap is the sneaky one for me. Long sessions fill up the context, and the quality quietly drops. A quick “/clear” between unrelated tasks, or “/compact” when you want to keep the thread going, keeps Claude sharp.
Your next move
If you’ve been typing one-line prompts, pick one real task this week and run it through all six stages. Explore, plan, implement, verify, review, then commit. I think you’ll notice the difference on the very first try.
The post’s author also asks readers which habit changed their results the most, and the comments are worth a read. Check out the full LinkedIn post for the one-page guide, and send it to the dev on your team who’s still typing one-liners.