--- title: "Before you open the terminal: how to think about AI tooling" description: "Before you open the terminal, there's a more useful question to answer. Here's the AI coding tool workflow mental model that holds up across Claude Code, Codex, and beyond." canonical_url: "https://nomadigital.dev/ai-coding-tool-workflow/" last_updated: "2026-05-15T16:35:55+00:00" --- # Before you open the terminal: how to think about AI tooling There’s a lot of writing out there about how to configure AI coding tools. How to wire up hooks in Claude Code, when to reach for a sub-agent, what goes in CLAUDE.md. That stuff matters — but it’s the second conversation. The first one is simpler: what kind of task is this, and what’s the right layer of your AI coding tool workflow for it? Get that wrong and it doesn’t matter how well-configured your tooling is. This post is about that first conversation. The mental model here applies whether you’re working in Claude Code, OpenAI Codex, Gemini CLI, or anything else in this space — I’ve been splitting my time between Claude Code and Codex lately, and these three layers hold up across both. If you want the implementation details specific to Claude Code — how Skills, sub-agents, hooks, and CLAUDE.md actually work — I covered that over here. This one is the step before that. Let’s dig right in. The Three Layers of Any AI Coding Tool Workflow The way I see it, there are three layers of AI interaction, and picking the wrong one for the job is where most of the confusion — and cost — comes from. These aren’t Claude Code concepts or Codex concepts specifically. They’re categories of thinking that apply across any terminal-based AI coding tool you’re likely to reach for right now. Start Simple: Plain Prompts A plain prompt is just a message. One-off, stateless, no structure. If the task is exploratory or you’re never going to repeat it, this is all you need. The token cost is as low as it gets: your message, the response, done. The mistake I kept making early on was reaching for something fancier when a plain prompt would’ve handled it. So before you spin up a Skill or kick off an agent, ask yourself: will I ever do this again? If not, just prompt. Build Once, Reuse Often: Skills A Skill is a reusable instruction set written in markdown — a SKILL.md file. It tells the model how to approach a category of task. Nothing magic happens under the hood: the model reads the file and follows the instructions, the same way it would follow any other context. The value is that you write it once and get consistent, high-quality results every time you invoke it. Both Claude Code and Codex support Skills. Claude Code looks for them in ~/.claude/skills/ or your project’s .claude/skills/ folder. Codex (which added Skills support in December 2025) looks in ~/.agents/skills/. Same idea, same file format — the location just differs by provider. Skills carry low token cost because the content is static and often cached. You invoke them explicitly, or they can auto-load when the task description matches. I’ve been using them for code review checklists, writing style guidelines, and job application workflows. Be mindful that a Skill is only as good as what you put in it. If you write vague instructions, you get vague results. Treat it like writing documentation for another developer — which, in a sense, you are. Go Autonomous: Agents An agent is an autonomous execution loop. You give it a goal; it plans steps, calls tools, reads files, runs commands, and loops until the job is done — without you steering every turn. That’s powerful. It’s also expensive. Agents run multiple turns, each with accumulated context. Token costs add up fast. So the rule I keep coming back to is: if a Skill and a plain prompt can get the job done, use them. Reach for an agent when the task genuinely has multiple steps, requires tool use (file reads, web searches, code execution), or would take you ten-plus manual steps to handle yourself. A handy way to think about it: power versus cost. Agents are the most capable option. They’re also the most expensive. Don’t use a sledgehammer to hang a picture frame. Pick the Right Tool: A Decision Tree I keep a version of this in my notes and I find myself coming back to it constantly: One-off question or task? → plain prompt Repeatable pattern you want consistent results from? → write a Skill, invoke it Multiple steps, tool use, or autonomous decision-making required? → use an Agent Could a Skill + plain prompt accomplish what the Agent would do? → use the Skill (cheaper, simpler, easier to audit) What I’m Using Right Now: Superpowers For the past several months I’ve had Superpowers installed alongside Claude Code, and honestly it’s been worth it. Superpowers is a curated library of Skills plus a convention system for when to invoke them — think of it as a pre-written collection of best-practice workflows for things like TDD, debugging, code review, and planning. It’s not a platform or a product; it’s a GitHub repo of markdown files maintained by Jesse Vincent. What I’ve found most useful: the Skills that ship with it are well-written and battle-tested, the sub-agent triaging is solid for complex tasks, and it enforces the right discipline — invoke the Skill before you act, not after. For planning and scoping work especially, it’s saved me from a lot of wandering. That said, I’m not sure I’ll be using it forever. There’s an argument that leaning on someone else’s Skill library abstracts away learning opportunities. If you don’t write your own Skills, you don’t develop the instinct for what makes a good one. I might end up forking out the pieces I actually use and maintaining my own collection. But right now, for the productivity boost alone, it’s earned its place in my workflow. Seems reasonable to me. The Always-On Context File: Different Name, Same Idea Every major AI coding tool has a version of the same concept: a markdown file that loads automatically at the start of every session and gives the model persistent context about your project. In Claude Code it’s CLAUDE.md. In Codex it’s AGENTS.md (global at ~/.codex/AGENTS.md, or project-level at the repo root). In Gemini CLI it’s GEMINI.md. Worth knowing: AGENTS.md has become something of an open standard — it’s now stewarded by the Agentic AI Foundation under the Linux Foundation and is supported across Codex, Cursor, Amp, and others. If you’re working across multiple tools, AGENTS.md is likely to travel further. Regardless of the filename, the distinction that matters is always-on versus on-demand. Use the always-on file for context that applies to every session: project conventions, architecture notes, things you never want the model to forget. Use Skills for workflows you invoke deliberately. I went deeper on how this plays out specifically in Claude Code in my Claude Code customization post. Think About Provider Portability Here’s something I wish I’d thought about earlier: because every provider uses a different filename and a different folder for Skills, it’s easy to end up with duplicated or scattered instruction sets as you move between tools. The better move is to centralize your Skills in a provider-agnostic folder and use symlinks to pull them into each provider’s expected location. It takes a little setup up front, but it’s the right long-term architecture — and it’s something I’m actively working through right now as I explore tools like Ollama for running models locally. I’m still evolving how I work with all of this — and which tools I’m reaching for is shifting week to week. But the Skills vs. Agents vs. plain prompts mental model has been the most clarifying thing I’ve landed on so far, and it’s held up regardless of which tool I’m in. If you’re also thinking about AI coding tool workflow from a developer perspective, I’d love to hear how you’re approaching it. Let me know: @noma_digital. ## Sitemap See the full [sitemap](/sitemap.md) for all pages.