The Claude Code Workflow Cheatsheet: Stop Prompting, Start Configuring

Most people start with Claude Code by typing prompts and seeing what happens. That works for quick tasks, but it misses the real power. Claude Code is not a chatbot you talk to - it is a workflow system you configure. The difference between someone who uses it casually and someone who ships with it consistently comes down to understanding six building blocks: project memory, file hierarchy, skills, hooks, permissions, and repeatable workflows.

This article breaks down each building block with practical examples, then puts it all together in a visual cheatsheet you can reference while working.

CLAUDE.md Is the Foundation

Every Claude Code session starts by reading CLAUDE.md from your project root. This file is persistent context - it loads automatically, every time, before Claude writes a single line of code. If this file is strong and specific, Claude produces consistent output. If it is vague or missing, outputs drift.

A good CLAUDE.md answers three questions: what is this project (tech stack, architecture), why do things work this way (design decisions, constraints), and how should Claude operate (commands, workflow rules, forbidden patterns).

# CLAUDE.md

## Project: InvoiceAPI
FastAPI REST API + React SPA + PostgreSQL 16

## Architecture
/app - FastAPI routes and dependencies
/lib - shared utilities and helpers
/prisma - DB schema and migrations

## Commands
npm run dev
npm run test
npm run lint

## Rules
- Service layer owns business logic, not route handlers
- All DB access through repositories in /app/repositories
- No raw SQL - use the query builder
- Run tests after every code change

The most effective CLAUDE.md files are specific and opinionated. "We use TypeScript" is too vague. "TypeScript strict mode, no any type, use unknown and narrow it" gives Claude a rule it can actually follow. Start with the decisions that come up most often in code review - those are the conventions that cost the most time when violated.

The Memory Hierarchy

One of the most underused features in Claude Code is the memory file hierarchy. Context does not have to live in one giant file. You can scope knowledge to exactly where it applies, which keeps Claude's context focused instead of noisy.

Three rules for the hierarchy: keep each file under 200 lines, subfolder files append context rather than override it, and never overwrite parent context from a child. In a monorepo, this means the root CLAUDE.md has shared conventions, and each package has its own file with package-specific rules.

Skills Are the Real Superpower

Skills are reusable markdown files that Claude auto-invokes based on what you are doing. Instead of rewriting the same instructions every session - "when you review code, check for X, Y, and Z" - you define a skill once and Claude applies it automatically whenever the context matches.

Skills live in .claude/skills/ in your project (shared with the team) or in ~/.claude/skills/ for personal skills. Each skill is a markdown file with a frontmatter header that tells Claude when to activate it.

---
name: testing patterns
description: Jest testing patterns for this project
allowed tools: Read, Grep, Glob
---

# Testing Patterns
Use describe + it + AAA pattern (Arrange, Act, Assert)
Use factory mocks from /test/factories
Always test edge cases: null, empty, boundary values
Never mock the database - use the test database

The description field in the frontmatter is critical - it is what Claude uses to decide when to activate the skill. Be specific: "Jest testing patterns for this project" is better than "testing" because it tells Claude exactly when this skill applies.

Hooks and Permissions - The Safety Layer

This is the part most teams underestimate. An AI coding tool without guardrails can quickly become messy, unpredictable, or risky in team environments. Claude Code solves this with two mechanisms: hooks for controlled automation, and permissions for access control.

Setting Up Hooks

Hooks are deterministic callbacks that fire at specific points in Claude's workflow. They let you add automated checks, transformations, or validations without relying on Claude to remember to run them.

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "scripts/sec.sh",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

Three hook types are available: PreToolUse fires before Claude uses a tool (great for security checks), PostToolUse fires after (great for linting or formatting), and Notification fires on events like errors or completions. Exit codes control flow: 0 allows the action, 2 blocks it.

Permissions and Safety

Permissions define what Claude can and cannot do in your project. This is how you prevent Claude from reading sensitive files, running dangerous commands, or modifying things it should not touch.

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Read:*",
      "Bash:git:*",
      "Write:*:*.md"
    ],
    "deny": [
      "Read:env:*",
      "Bash:sudo:*",
      "Write:*:*.env"
    ]
  }
}

The allow/deny model is straightforward: explicit allows for things Claude should access freely, explicit denies for things that are off limits. Everything else prompts for confirmation. This is what makes Claude Code usable in environments where security and predictability matter.

The 4-Layer Architecture

The most useful mental model for Claude Code is four layers, each building on the one below. Understanding these layers is the difference between using Claude Code as a fancy autocomplete and using it as a structured development workflow.

Most developers start at L4 (asking Claude to do things) and wonder why results are inconsistent. The teams that get reliable output start at L1 (encoding their context and rules) and work up. The foundation determines the quality of everything above it.

The Daily Workflow Pattern

Workflow beats prompting. The developers who get the most consistent results from Claude Code follow a predictable daily pattern rather than freestyle prompting. Here is what that looks like:

Quick Reference

These are the commands and shortcuts you will use most often. Print this or keep it visible until they become muscle memory.

Project File Structure

Here is how a well-configured Claude Code project looks on disk. Every file has a purpose and a specific scope. Understanding this structure is the first step to getting reliable output.

your-project/
├── CLAUDE.md                    # Project context (committed to git)
├── .claude/
│   ├── settings.json            # Hooks, permissions, MCP config
│   ├── settings.local.json      # Personal settings (gitignored)
│   ├── skills/
│   │   ├── code-review/
│   │   │   └── SKILL.md         # Code review standards
│   │   ├── testing/
│   │   │   └── SKILL.md         # Test patterns and rules
│   │   └── deploy/
│   │       └── SKILL.md         # Deployment checklist
│   ├── commands/
│   │   └── deploy.md            # Custom slash commands
│   └── agents/
│       └── security-reviewer.md # Agent definitions
├── frontend/
│   └── CLAUDE.md                # Frontend-scoped context
├── backend/
│   └── CLAUDE.md                # Backend-scoped context
└── .gitignore

The key principle: CLAUDE.md and .claude/skills/ are committed to git so the whole team shares the same context. settings.local.json is gitignored for personal preferences. This separation means the team stays consistent while individuals can customize their workflow.

The Cheatsheet

Here is everything above condensed into a single visual reference. Save it, print it, or keep it open in a tab while you work.

From Chatbot to Workflow System

The shift in thinking is straightforward. Stop treating Claude Code as a tool you prompt and start treating it as a system you configure. The six building blocks - CLAUDE.md, memory hierarchy, skills, hooks, permissions, and agents - are what turn it from "just another AI coding tool" into a structured, repeatable development workflow.

Start with L1. Write a good CLAUDE.md. Then add one skill for your most common task. Then set up a hook that enforces your linting rules. Each layer compounds on the ones below it. Within a week, you will wonder how you used it without them.

The developers who get the most out of Claude Code are not the ones writing better prompts. They are the ones who built better systems around it.

At RoboticForce, we help development teams configure Claude Code as a production workflow - from CLAUDE.md conventions and custom skills to MCP server integration and team rollout strategy. If your team is adopting AI developer tools and wants to get the foundation right from day one, that is exactly what we do.