Claude Code Tips & Workflows

This post documents the stable workflows, prompting strategies, and plugin usage patterns I’ve settled on while working with Claude Code. The goal isn’t to list every feature — it’s to capture the practices that actually improve delivery speed.

What Claude Code Is Good At

From the perspective of game development, toolchain work, and content engineering, Claude Code is best suited for:

• Understanding existing project structure
• Batch refactoring scripts or tooling code
• Adding tests, documentation, or scaffolding
• Integrating third-party SDKs, service APIs, or CLI tools
• Mid-complexity multi-file changes

Its strengths aren’t about “just throwing everything at it and hoping for the best.” It’s more about:

• Reliable long-context comprehension
• Strong performance on code explanation, refactoring, and summarization
• Workflows that follow an analyze-first, then execute pattern

If your tasks are very granular and real-time — like line-level autocomplete while you type — an in-IDE completion tool is still more direct.

Claude Configuration File Locations

My Stable Workflow

Ask It to Map the Impact First

Before touching shared modules, base libraries, or build scripts, I’ll ask:

1
2

If I change this function signature, which callers will be affected?
Please list them by file and flag the high-risk points.

This step is genuinely valuable for avoiding unintended breakage.

Ask for Verification Steps Along the Way

Beyond just the code changes, I’ll also request:

1
2
3
4

After completing the changes, please add:
1. How to verify the result
2. Recommended commands to run
3. Edge cases that might fail

This brings the final output much closer to a deliverable state.

Be Explicit About What Not to Do

For example:

• Don’t change public APIs
• Don’t introduce new dependencies
• Don’t touch UI styles
• Don’t modify the database schema

Negative constraints like these are critical, especially in existing projects.

• Side note: Claude Sonnet tends to suffer from fairly serious context anxiety. It’s best used for short, quick tasks that can be completed in a single shot.

Plugins

The real value of plugins and external tool integrations isn’t “more features” — it’s turning Claude Code from something that only talks into something that can look things up, run things, and verify things.

My usual criteria come down to three questions:

1. Does it reduce manual context switching?
2. Does it ground the analysis in the actual codebase?
3. Does it form a stable workflow, not just a one-off demo?

ralph-loop (Loop Plugin)

I think of ralph-loop as a “loop execution framework” or a “task closure enhancer” rather than a simple plugin.

It works well for:

• Tasks that require multiple rounds of analysis, execution, and checking
• Situations where you want AI to iterate at a fixed cadence
• Breaking large tasks into observable, reviewable rounds

Auto-Approving Confirmations

If your goal is simply “let it edit files in the current workspace without asking every time,” reach for Claude Code’s built-in permission modes first, rather than expecting the plugin to bypass confirmations.

I think about this in two tiers:

Option 1: Auto-approve file edits only

This is the safer approach.

Claude Code has an acceptEdits mode whose core effect is:

• File edits within the workspace can be batch-accepted
• Commands, network requests, and other side-effectful operations will still prompt you

If your main frustration is the “can I edit this file?” prompt, this is the tier to use.

You can check the current mode via /config or /permissions, or explicitly set it in a settings file:

1
2
3
4
5
6

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Common placement options:

• Global effect: ~/.claude/settings.json
• Current repo only (local): .claude/settings.local.json
• Team-shared config: .claude/settings.json

If you only want to open this up on your own machine for the current project, .claude/settings.local.json is the best fit — it won’t be committed to the repo and won’t affect other projects.

Option 2: Skip command confirmations too

If you want Claude Code to skip confirmations for command execution and tool calls as well, you can pass a startup flag:

1

claude --dangerously-skip-permissions

This mode skips all permission prompts outright. It’s appropriate when you fully trust the current repo and explicitly accept that it may automatically edit files, run commands, and call tools.

The risk level here is noticeably higher — I wouldn’t leave it on by default. Better suited for:

• Your own personal repos
• Well-isolated test environments
• Short-term high-frequency iteration tasks

I’d avoid using it for:

• Repos of unknown origin
• Projects with sensitive configs mixed in
• Projects that can trigger deployments, publishing, or database operations

Practical Recommendation

If your concern is “I don’t want ralph-loop to keep asking me during multi-round execution,” the priority order should be:

1. Switch the default permission mode to acceptEdits first
2. Apply it only to the current repo via .claude/settings.local.json
3. Only switch to --dangerously-skip-permissions if even command confirmations are breaking your flow

In short:

• Just want to skip file edit confirmations → use acceptEdits
• Want to skip basically all confirmations → use --dangerously-skip-permissions

The first is for daily use; the second is for when you’ve consciously accepted the risks.

The bottom line: ralph-loop doesn’t make Claude Code “smarter” — it makes your task orchestration more stable.

Oh My Claude Code (OMC — Claude Agent Suite)

A zero-learning-curve tool for getting into Claude workflows. Provides a pre-configured collection of agents.

Installation

I use npm. Run in your terminal:
npm i -g oh-my-claude-sisyphus@latest
Then omc setup to complete the setup.
Project site

Five Available Modes

🔸 Autopilot (fully autonomous) — end-to-end automation from planning through implementation to testing
🔸 Ultra Pilot (parallel acceleration) — up to 5 parallel workers running simultaneously, ~5x throughput
🔸 Swarm (collaborative team) — multiple agents collaborate like a dev team, pulling from a shared task pool
🔸 Pipeline (sequential) — agents chained in a fixed order, ideal for workflows that must proceed step by step
🔸 EcoCode (economy mode) — maximizes token savings while maintaining efficiency

Status Bar in the New Claude CLI

[OMC#4.11.2] | session:33m | ctx:32% | T:17 A:1
● This is the OMC status bar. Here’s what each field means:

• [OMC#4.11.2] — OMC plugin version
• session:33m — current session has been running for 33 minutes
• ctx:32% — 32% of the context window has been used
• T:17 — Tool calls: 17 tool invocations in this session
• A:1 — Agents: 1 active sub-agent currently running

Common Commands

There’s a subtle distinction worth noting: claude --resume is a startup flag you run in the terminal, while /xxx commands are typed directly inside a Claude Code session.

• claude --resume: Resume the most recent or a specific session. Great when the terminal closes unexpectedly or you want to pick up where you left off.
• /rewind: Roll the current session back to an earlier point. Very handy when a few rounds of thinking went sideways and you want to undo a stretch of work.
• /resume / /continue: Resume an existing session from within a session, or open the session picker to continue a previous task.
• /remote-control / /rc: Expose the current local session for remote control, so you can continue the task from claude.ai/code or a mobile device. Perfect for stepping away from your desk without losing context.
• claude --dangerously-skip-permissions: Skip all permission confirmations at startup — no more per-action approval prompts. Use this when you fully trust the repo and want Claude Code to autonomously edit files, run commands, and call tools. Highest risk mode; best kept for personal projects or isolated environments.
• /compact: Compress the current context into a summary and continue the same session. A lifesaver when the context is nearly full but you don’t want to re-explain the whole project. (Not supported by OMC.)
• /doctor: Check Claude Code’s installation, permissions, and configuration. When a command stops working, a plugin misbehaves, or the environment looks off, running this first usually saves a lot of debugging time.

Errors & Debugging

PowerShell Garbled Output on Chinese Windows

Example error:

1
2
3
4
5
6
7
8

● Bash(powershell.exe -NoProfile -Command "...")
  ⎿  Error: Exit code 1
     ����λ�� ��:1 �ַ��: 169
     + ... ref])|Out-Null;if(.Count -eq 0){'OK: no syntax errors'}else{|%{extglo ...
     +                                                                 ~
     ������ʹ�ÿչ��Ԫ��
         + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
         + FullyQualifiedErrorId : EmptyPipeElement

Root cause:

Simplified Chinese Windows defaults to code page 936 (GBK/GB2312), but Claude Code processes strings as UTF-8 internally. When PowerShell outputs Chinese error messages encoded in GBK, Claude Code interprets them as UTF-8 → mojibake.

This is a very common issue affecting virtually all CJK (Chinese/Japanese/Korean) Windows users. English Windows is unaffected because code page 437 is ASCII-compatible with UTF-8.

Fix: Set the environment variable in Claude Code settings

Add to your project-level .claude/settings.local.json:

1
2
3
4
5

{
  "env": {
    "CHCP": "65001"
  }
}

Or for global effect, add it to ~/.claude/settings.json.

Why not change the system locale:

Windows offers a “Beta: Use Unicode UTF-8 for worldwide language support” toggle that changes the system code page from 936 to 65001. It’s the most thorough fix, but it’s a global irreversible change that can break older Chinese software with hardcoded GBK encoding (legacy installers, older archive tools, etc.). The env CHCP=65001 approach only affects Claude Code’s shell process — the rest of the system remains untouched.

You’ll need to restart your Claude Code session for the change to take effect.

References

Learning video by a Bilibili creator