DEV Community: Yurukusa

I Found 39 Days Where I 'Worked' But Didn't. Here's What That Data Looks Like.

Yurukusa — Mon, 13 Apr 2026 03:00:02 +0000

There's a type of day that doesn't show up in your commit history.

You opened Claude Code. Maybe you ran a command or two. Maybe you read some output. But nothing shipped. Nothing moved. The session logged some activity, but at the end of the day, you produced nothing.

I call these Ghost Days.

I have 39 of them. Out of 60 days.

What a Ghost Day actually is

A Ghost Day is a day where Claude Code activity is below a meaningful threshold — where you clearly had the tool open and running, but the session produced no real output.

The definition I use:

Fewer than 10 tool calls in the day's sessions (noise level)
AND fewer than 3 file modifications
OR total active session time under 5 minutes

The second condition is the key one. You can have 5 minutes of frantic activity and still ship something real. But 4 minutes of context loading followed by closing Claude Code is just friction.

The data from my 60 days

Total days in range: 60
Ghost Days: 39 (65%)
Active Days: 21 (35%)

Wait. I had Ghost Days on 65% of days?

That didn't match my mental model at all. I thought I'd been working consistently. The numbers said otherwise.

Let me break it down further.

Ghost Days by day of week:

Monday: 7/8 days (88% ghost rate)
Saturday: 6/8 days (75%)
Tuesday: 5/8 days (63%)
Wednesday: 4/8 days (50%)
Thursday: 4/8 days (50%)
Friday: 4/8 days (50%)
Sunday: 9/12 days (75%)

Monday had a 88% ghost rate. That's the day I was most likely to open Claude Code and do nothing productive.

Why this matters

I'm paying $200/month for Claude Code. That's $6.67/day.

On Ghost Days, I paid $6.67 for approximately zero output.

Over 39 Ghost Days, that's $260 spent on sessions where nothing happened.

That's 65% of my subscription cost going to days where I either couldn't get started, got interrupted, or just... didn't engage meaningfully.

The non-Ghost Days had to justify the full $400 with 21 days of actual work. Some did. Most produced something. But the distribution was brutal.

What causes Ghost Days

Looking at the pattern, I can identify three main causes:

1. Context-loading sessions
I'd open Claude Code to check something — "where did I leave off?" — spend 5 minutes reading previous output, and then close it to go do something else. This logs as activity but produces nothing.

2. Blocked days
Days where I hit a problem early (npm rate limit, CDP auth failure, etc.) and couldn't unblock it without something I didn't have (an API key, a human to click a button). The whole day became a Ghost Day because the first session failed.

3. Cognitive overhead
Some days I'd start sessions, read the output, feel uncertain about what to do next, and close without committing to anything. Analysis paralysis, but logged as Claude Code activity.

4. Legitimate rest
Some Ghost Days were intentional non-work days. They look identical to the other Ghost Days in the data. The tool can't tell the difference.

What I changed

Knowing the Ghost Day pattern changed two things:

First, I started front-loading. If my Monday has an 88% ghost rate, I needed to put the most important work earlier in the week — Wednesday through Friday, when I'm most likely to actually execute.

Second, I built a blockers file. Instead of closing Claude Code when blocked, I now write the blocker to ~/ops/pending_for_human.md and immediately pivot to something else. This converts a potential Ghost Day into a partial ghost day.

What I didn't change: my subscription. The $200/month is still worth it for the 21 active days, even with 39 Ghost Days. The math works because the active days produce enough output to justify it.

The tool

cc-ghost-log tracks Ghost Days from your ~/.claude folder.

npx cc-ghost-log

Or browser version (no install): yurukusa.github.io/cc-ghost-log

It shows:

Total Ghost Days and Ghost Day rate
Ghost Days by day of week (so you can see your patterns)
Which specific days were ghost days
Session activity on ghost days (to show why they were ghost)

The data has been uncomfortable. But uncomfortable data is more useful than no data.

More on Claude Code safety: cc-safe-setup on GitHub

My AI Modified 59 Files Without Me Noticing. I Built a Tool to Track Them.

Yurukusa — Sun, 12 Apr 2026 03:00:04 +0000

I ran a query against my activity log today.

npx cc-review-queue --all

Output:

📋 AI Review Queue — all time

  59 files pending review · 274 edits · +11,424/-200 lines

   1. 2026-02-28 21:55  [EDIT ]  ~/bin/algora-watch
      +169 (2x)
   2. 2026-02-28 18:00  [EDIT ]  ~/.claude/hooks/task-complete-nudge.sh
      -1
   3. 2026-02-28 17:49  [WRITE]  ~/bin/task-check
      +87
   ...

59 files. 274 edits. Some of them hooks. Some of them scripts in ~/bin/. Some of them Claude Code's own configuration files.

I knew the AI was busy. I didn't know it was that busy.

Why this matters

Claude Code's activity-logger.sh hook logs every file operation it makes. When an edit touches a sensitive path — hooks directory, bin scripts, configuration files — it marks the entry needs_review: true.

The point is: a human should look at these before the next session runs.

In practice, nobody was looking. The flag was being set; nobody was checking the flag.

cc-review-queue is the tool that surfaces those files.

What it reads

The tool reads ~/ops/activity-log.jsonl — the file that Claude Code's activity-logger hook writes to after every Edit/Write operation.

Each entry looks like this:

{"ts":"2026-02-28T02:23:00Z","actor":"CC","tool":"Write","path":"/home/user/.claude/hooks/session-start-marker.sh","add":33,"del":0,"needs_review":true}

cc-review-queue filters for needs_review: true, groups by file path, sums up all the adds/deletes for that file, and sorts by most recently touched.

The output

Three modes:

# Last 30 days (default)
npx cc-review-queue

# Last 7 days
npx cc-review-queue --days=7

# Markdown — for reports, Slack, PR descriptions
npx cc-review-queue --format=md

Markdown output:

# AI Review Queue

Period: last 7 days · 23 files · 63 edits · +2932 / -65 lines

| # | Last Edit | Tool | File | Changes | Edits |
|---|-----------|------|------|---------|-------|
| 1 | 2026-02-28 21:55 | Edit | `~/bin/algora-watch` | +169 | 2x |
| 2 | 2026-02-28 18:00 | Edit | `~/.claude/hooks/task-complete-nudge.sh` | +19 / -1 | 2x |
...

The 2x, 3x counters show how many times the AI touched the same file. A file that was edited 19 times in the same period probably needs more than a quick look.

The hook that creates this data

cc-review-queue only works if you have activity-logger.sh running. It's part of cc-safe-setup — a collection of 16 production hooks for autonomous Claude Code.

The activity logger is a PostToolUse hook that fires after every Edit or Write operation:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "~/.claude/hooks/activity-logger.sh" }]
      }
    ]
  }
}

The logger decides needs_review based on path patterns (configurable):

# Paths that trigger needs_review: true
MONITORED_PATHS=(
  "$HOME/.claude/"
  "$HOME/bin/"
  "$HOME/.bashrc"
  "$HOME/.zshrc"
)

What I found in my queue

My top needs_review files by edit count:

~/bin/cc-loop — edited 29 times
~/bin/devto-publish — edited 17 times
~/bin/tweet-post — edited 19 times
~/.claude/hooks/proof-log-session.sh — edited 6 times

The AI kept improving its own tooling. That's the interesting part.

None of these changes caused problems. But that's because I was reviewing them (eventually). The queue just makes the reviewing systematic instead of accidental.

Part of cc-toolkit

cc-review-queue is part of cc-toolkit — all free, zero dependencies, local.

The full oversight picture:

Tool	What it shows
cc-review-queue	Files AI touched that need review
cc-session-stats	Total hours, sessions, autonomy ratio
cc-ai-heatmap	52-week activity visualization
cc-standup	Daily standup from AI's work log

More on Claude Code safety: cc-safe-setup on GitHub

Claude Code Safety in 5 Minutes: A Beginner's Complete Guide

Yurukusa — Thu, 09 Apr 2026 03:00:02 +0000

You gave Claude Code full access to your terminal. It can run any command, edit any file, push to any branch.

What could go wrong?

A lot, actually. One user lost their entire C:\Users directory. Another had their .bashrc overwritten. Someone else watched Claude force-push to main at 3am.

These aren't hypotheticals — they're real GitHub Issues.

Here's how to prevent all of them in 5 minutes.

Step 1: Install Safety Hooks (30 seconds)

npx cc-safe-setup

That's it. One command installs 667 hooks that intercept dangerous commands before they execute:

Hook	What it blocks
`destructive-guard`	`rm -rf /`, `git reset --hard`, `git clean -fd`
`branch-guard`	Push to `main`/`master`, force-push
`secret-guard`	`git add .env`, credential files
`syntax-check`	Catches broken Python/JS/JSON after edits
`context-monitor`	Warns when context window is filling up
`comment-strip`	Fixes bash comments breaking permissions
`cd-git-allow`	Auto-approves safe `cd && git log` compounds
`api-error-alert`	Notifies when sessions die from API errors

Step 2: Verify It Works (30 seconds)

npx cc-safe-setup --verify

This sends test inputs to each hook and confirms they block correctly:

destructive-guard:
  ✓ rm -rf / → BLOCKED
  ✓ rm -rf node_modules → ALLOWED
branch-guard:
  ✓ git push origin main → BLOCKED
  ✓ git push origin feature → ALLOWED
...
8/667 hooks verified

Step 3: Check Your Setup Health (30 seconds)

npx cc-safe-setup --quickfix

This auto-detects and fixes common problems:

Missing jq (hooks need it for JSON parsing)
Broken file permissions
Invalid settings.json
Missing shebang lines
Broken hook references

Step 4: Add Hooks for Your Stack (2 minutes)

Browse 330+ example hooks:

npx cc-safe-setup --examples

Install any by name:

# If you use databases
npx cc-safe-setup --install-example block-database-wipe

# If you use Docker
npx cc-safe-setup --install-example auto-approve-docker

# If you deploy
npx cc-safe-setup --install-example deploy-guard

# If you want to prevent scope creep
npx cc-safe-setup --install-example scope-guard

Or generate a custom hook from plain English:

npx cc-safe-setup --create "block npm publish without running tests first"

Step 5: Monitor (optional, 1 minute)

See your safety dashboard:

npx cc-safe-setup --dashboard

Check what's been blocked:

npx cc-safe-setup --stats

How Hooks Actually Work

Claude Code has a hooks system that runs shell scripts at specific lifecycle points:

PreToolUse — before any tool runs (Bash, Edit, Write)
PostToolUse — after a tool completes
Stop — when Claude finishes responding

A hook that exits with code 2 blocks the action. The model cannot bypass this — it's enforced at the process level, not the prompt level.

This is the key difference from CLAUDE.md rules: rules degrade as context fills up. Hooks run every single time.

# What a hook looks like (simplified)
#!/bin/bash
COMMAND=$(cat | jq -r '.tool_input.command // empty')
if echo "$COMMAND" | grep -qE 'rm\s+.*-rf\s+/'; then
  echo "BLOCKED: rm -rf on root directory" >&2
  exit 2  # Block the action
fi
exit 0  # Allow the action

Common Questions

Q: Do hooks slow down Claude Code?
No. Each hook runs in ~5ms. You won't notice.

Q: Can Claude disable hooks?
No. Hooks are enforced by the Claude Code runtime, not the model. Even if Claude tries to edit settings.json, the protect-claudemd hook can block that too.

Q: What about CLAUDE.md — isn't that enough?
CLAUDE.md rules work well at the start of a session. But as context fills up (after 100+ tool calls), Claude gradually "forgets" them. Hooks never forget.

Q: I use TypeScript/Python — are there hooks for those?
Yes. Check out cc-hook-registry which indexes hooks from 7 different projects, including TypeScript and Python implementations.

Try It Now

npx cc-safe-setup --shield

One command. Thirty seconds. Your autonomous Claude Code sessions are now protected against the most common disasters.

Interactive playground: Test commands against hooks — type any command and see which hooks would fire.

Full hook registry: Browse 349+ hooks from 7 projects.

More on Claude Code safety: cc-safe-setup on GitHub

Which Files Does Your Claude Code Keep Rewriting? I Built a Tool to Find Out

Yurukusa — Wed, 08 Apr 2026 03:00:04 +0000

The Question I Kept Asking

After 60+ days running Claude Code autonomously, I noticed a pattern I couldn't quantify: some files felt like they were getting rewritten constantly. My game's dungeon_game.py seemed to be in a perpetual state of flux. But was I imagining it?

Turns out, I wasn't. The top file in my sessions had 933 total tool calls — 669 writes, 264 reads.

I needed a way to see this clearly. So I built cc-file-churn.

What cc-file-churn Does

It scans your ~/.claude session logs and ranks every file by how much Claude Code has touched it — broken down by writes (Edit/Write), reads (Read), and searches (Grep/Glob).

npx cc-file-churn

Output looks like:

cc-file-churn — top 10 files by total activity (all time)

#1  ~/.claude/plans/staged-hatching-backus.md
    ████████████████████ 933  (w:669 r:264 s:0)

#2  ~/projects/aetheria/dungeon_game.py
    ██████████████████░░ 671  (w:301 r:290 s:80)

#3  ~/projects/cc-loop/cc-toolkit/index.html
    ████████░░░░░░░░░░░░ 312  (w:189 r:123 s:0)

...

755 session files · 2219 unique files · 12476 tool calls

The bars aren't just decorative. They show exactly where the churn is concentrated.

What I Found Surprising

My most-churned file wasn't source code — it was a planning document (staged-hatching-backus.md). Claude Code had written it 669 times and read it 264 times. That's the AI checking and updating its own work plan.

Second place was dungeon_game.py. That one I expected. But the ratio was interesting: roughly equal reads and writes, meaning the AI was reading the file as much as editing it. Understanding context before making changes.

Third place was cc-toolkit/index.html — the landing page for this whole tool collection. Heavily written, rarely read. Makes sense for a file that keeps getting cards added to it.

Filtering Options

# Top 10 files by write count (most modified)
npx cc-file-churn --writes

# Top 10 files by read count (most referenced)
npx cc-file-churn --reads

# Last 7 days only
npx cc-file-churn --days=7

# Filter to a specific project
npx cc-file-churn --project=cc-loop

# JSON output for piping
npx cc-file-churn --json | jq '.[0]'

# Show top 20 instead of 10
npx cc-file-churn 20

Browser Version

If you prefer not to install anything:

→ yurukusa.github.io/cc-file-churn

Drag in your ~/.claude folder. Everything runs locally — nothing uploaded.

The browser version adds filter buttons (All activity / Most-modified / Most-referenced) and shows progress bars with percentage breakdowns.

Why This Matters

High churn files reveal a lot:

Planning files with high write counts: The AI is actively managing its own state
Source files with balanced read/write: Normal iterative development
Source files with much higher writes than reads: Possibly unstable design being constantly patched
Config files with high reads, low writes: Reference files the AI checks frequently
Test files with low churn: Either tests are stable (good) or being neglected (check this)

Once you know which files are getting churned, you can ask: Is this churn productive? Sometimes a file with 300 writes means good iterative improvement. Sometimes it means the AI is spinning in circles.

Part of cc-toolkit

cc-file-churn is one of 100+ tools in cc-toolkit — all free, for understanding your Claude Code usage.

Other tools in the same vein:

cc-context-check — How full is your context window right now?
cc-tool-mix — What percentage of Claude's calls are reads vs writes vs searches?
cc-wrapped — Your full Claude Code year in review

Built from 60+ days of running Claude Code 24/7 in tmux. All tools are free, zero dependencies, data stays local.

GitHub: yurukusa/cc-file-churn
Try it: npx cc-file-churn

More on Claude Code safety: cc-safe-setup on GitHub

5 CLAUDE.md Rules That Made My AI Stop Asking and Start Doing

Yurukusa — Tue, 07 Apr 2026 03:00:01 +0000

After months of running Claude Code autonomously, I've learned that most of the interruptions aren't the AI's fault. They're the CLAUDE.md's fault.

Here are 5 rules that eliminated most of my "should I do X?" questions.

1. The irreversibility rule (not the uncertainty rule)

What most CLAUDE.mds say:

"Ask for clarification when uncertain."

What actually works:

"Ask only for: irreversible actions, external credentials, external visibility (publishing, sending emails), costs beyond the subscription."

The difference is significant. Uncertainty is constant — every decision has unknowns. Irreversibility is rare — most code changes can be reverted with git reset.

When I switched from "ask when uncertain" to "ask only when irreversible," the question count dropped dramatically. 80%? Maybe. I didn't measure precisely, but it felt like a different AI.

2. Explicit decision framework for common forks

What most CLAUDE.mds say:

"Use your judgment."

What actually works:

| Situation | Action |
|-----------|--------|
| Technical approach unclear | Choose the conventional approach |
| Two valid implementations | Choose the simpler one |
| Error after 3 attempts | Document in blocked.md, switch tasks |
| Ambiguous requirement | Apply most reasonable interpretation, document assumption |

The AI already has good judgment. The table isn't teaching it to think — it's eliminating the meta-question of "should I ask or should I decide?" By stating explicitly that "unclear approach → conventional approach," that decision is pre-made.

3. The pending_for_human.md pattern

What stops most workflows: A step that requires browser authentication, or a credential I don't have. Without a clear protocol, the AI either loops on it or silently skips it.

What works:

"If blocked: document blocker in pending_for_human.md, switch to next available task."

The format I use:

## 2026-02-28: Smithery API key needed
**Why blocked**: Smithery MCP registry requires authentication
**Steps for human**:
1. Go to smithery.ai/account/api-keys
2. Create API key, add to ~/.credentials
**Everything else done**: smithery.yaml added to repo, package published to npm

The key is the last line: "everything else done." The human opens this file in the morning and sees exactly one click they need to do.

4. Explicit syntax check commands

What most CLAUDE.mds say:

"Make sure the code works."

What actually works:

"After every edit: Python → python -m py_compile <file>. TypeScript → tsc --noEmit. Do not move to the next file before fixing errors in the current one."

The "do not move to the next file" part is what matters. Without it, the AI writes 5 files, runs the build, finds 3 errors spread across all of them, and has to context-switch back to each one. With it, each file is clean before the next one starts.

This is the same reason you do git add -p instead of git add ..

5. Context compression protocol

What kills autonomous sessions: Running out of context window mid-task and starting over.

What works:

"When context gets large: write current state to tasks/mission.md. Include: what's done, what's next, what's blocked, any open questions. The next session should be able to continue from tasks/mission.md without reading the full history."

The mission.md should be written as if explaining to someone who knows the project but wasn't in the room. Not a transcript. Not a summary. A briefing.

This creates a natural "checkpoint" that makes context compaction safe.

What these have in common

All 5 rules do the same thing: convert vague expectations into specific protocols.

"Use judgment" forces a meta-decision. "Choose the simpler one" eliminates it. Every meta-decision costs context window and interruption. Eliminating meta-decisions is what makes autonomous operation actually work.

The hooks and templates I run in production are open source: cc-safe-setup — 16 hooks (at the time of writing; now 667) + 6 templates from 700+ hours of autonomous operation (at the time of writing).

More on autonomous Claude Code operation: Safety Guide on Zenn (chapters 1-3 free).

What's in your CLAUDE.md that you wish you'd added earlier?

6 Claude Code Permission Traps I Found Answering GitHub Issues This Week

Yurukusa — Mon, 06 Apr 2026 03:00:05 +0000

My AI (Claude Code) answered 57 GitHub Issues this week about Claude Code permissions not working as expected. Here are the 6 patterns that keep tripping people up — and the hooks that fix them.

Trap 1: `allow` Cancels `ask` (17 Upvotes, 18 Comments)

{
  "permissions": {
    "allow": ["Bash(*)"],
    "ask": ["Bash(rm *)"]
  }
}

Expected: safe commands auto-approve, rm asks first.
Actual: everything auto-approves. ask is silently ignored. (#6527)

Fix: A PreToolUse hook catches what ask misses:

#!/bin/bash
COMMAND=$(cat | jq -r '.tool_input.command // empty')
if echo "$COMMAND" | grep -qE 'rm\s+(-[rf]+\s+)*(\/|~|\.\./)'; then
    echo "BLOCKED: rm on sensitive path" >&2
    exit 2
fi
exit 0

Trap 2: Trailing Wildcards Don't Match Zero Arguments

{ "permissions": { "allow": ["Bash(ssh * uptime *)"] } }

ssh host uptime -s → allowed. ssh host uptime → prompts. The trailing * requires at least one character. (#36873)

Fix: Use regex (\s|$) in a hook — matches "space or end of string":

if echo "$COMMAND" | grep -qE '^\s*ssh\s+\S+\s+uptime(\s|$)'; then
    # auto-approve
fi

Trap 3: Edit/Write Rules Ignored on Windows

Edit(.claude/**) in settings.json has no effect on Windows VS Code. Bash rules work fine — Edit/Write don't. (#36884)

Fix: A PermissionRequest hook bypasses the broken matcher:

TOOL=$(cat | jq -r '.tool_name // empty')
if [[ "$TOOL" == "Edit" || "$TOOL" == "Write" ]]; then
    jq -n '{"hookSpecificOutput":{"hookEventName":"PermissionRequest","permissionDecision":"allow"}}'
fi

Trap 4: Protected Directories Ignore bypassPermissions

Since v2.1.78, .git, .claude, .vscode prompt even with --dangerously-skip-permissions. Intentional but undocumented. (#35646)

Fix: Anthropic confirmed a fix is incoming.

Trap 5: /model Doesn't Update /status Immediately

/model changes the model for future API calls, but /status shows the old one. (#36835)

Fix: Send a new message after /model, or set via environment:

export ANTHROPIC_MODEL=claude-opus-4-6

Trap 6: Claude Adds Flags Your Pattern Doesn't Expect

You allow Bash(git status:*). Claude runs git -C /path status. The -C flag breaks your pattern. (#36900)

Fix: Match the optional flag in a hook:

if echo "$COMMAND" | grep -qE '^\s*git\s+(-C\s+\S+\s+)?(status|log|diff|branch|show)'; then
    # auto-approve
fi

Your hook returns permissionDecision: "deny" with exit code 2. For Bash commands, the tool is blocked. For Edit/Write — the file is modified anyway. (#37210)
Fix: Defense-in-depth — make the file read-only before the deny:

if [[ "$TOOL" == "Edit" || "$TOOL" == "Write" ]]; then
    if should_deny "$FILE"; then
        chmod 444 "$FILE" 2>/dev/null
        echo "BLOCKED: Edit denied by policy" >&2
        exit 2
    fi
fi

The Pattern

6 out of 7 traps have the same fix: PreToolUse hooks. The permission system has edge cases. Hooks operate independently and don't have them.

npx cc-safe-setup

667 hooks (at the time of writing). 10 seconds to install. Covers destructive commands, force push, .env leaks, syntax errors, and context monitoring.

GitHub

Every trap in this list came from a real GitHub Issue that my AI responded to. If you've hit a permission problem not listed here, drop a comment — I'll add it.

More on Claude Code hooks and safety patterns: How hooks work under the hood

I Built a GitHub-Style Contribution Calendar That Shows When My AI Works Without Me

Yurukusa — Sun, 05 Apr 2026 03:00:02 +0000

GitHub's contribution calendar shows when you coded. But what if half those green squares weren't actually you?

I built cc-calendar — a terminal tool that renders a GitHub-style activity graph for your Claude Code sessions. Two rows: YOU (cyan) and AI (yellow). Ghost Days — when AI ran autonomously while you had zero interactive sessions — glow bright.

The output

$ npx cc-calendar

  cc-calendar  — AI草カレンダー
  ══════════════════════════════════════════════════

       Jan         Feb         Mar
Sun  ░░░░░▒░░░  Sun  ░▒▒▒▓█▓█▒
Mon  ░░░░░░░░░  Mon  ░▒▒▒▓██▓░
Tue  ░░░░░▒░░░  Tue  ░▒▒▒▒▓▓▓░
Wed  ░░░░▒░░░░  Wed  ░▒▓▒▒▓▓▓░
Thu  ░░░░░░██░  Thu  ░▓▒▒▒▒▓▒░
Fri  ░░░░░░█░░  Fri  ░▒░█▒▒▓▒░
Sat  ░░░░▒░░█░  Sat  ▒░░▒▓▒▓█░

  █ You  █ AI  █ Ghost Day  ░▒▓█ = none→light→heavy

  ▸ Period:      2026-01-10 → 2026-03-01
  ▸ Active Days: 48 total
  ├─ Both active:    8 days
  ├─ You only:       0 days
  └─ Ghost Days:     40 days (AI worked while you rested)

  Your hours:  46.5h
  AI hours:    83.3h

  👻 40 Ghost Days — AI was 83% of your active days

Those bright yellow cells on the right? Ghost Days. The AI was running autonomous subagent pipelines — publishing npm packages, writing articles, updating GitHub Pages — while I was offline.

Why I built this

I already had cc-agent-load which shows the YOU/AI split as aggregate numbers. But a single ratio doesn't tell the story. You can't see when the AI was working without you, or whether it was a sustained pattern.

The contribution calendar format solves this immediately. Engineers are trained to read GitHub contribution graphs at a glance. Same interface, new dimension.

How it works

cc-calendar reads from cc-agent-load --json, which outputs session data by date:

{
  "byDate": {
    "2026-02-09": { "main": 0, "sub": 6.0 },
    "2026-02-10": { "main": 1.5, "sub": 2.3 }
  }
}

For each day:

main = hours in interactive sessions (you + AI responding to you)
sub = hours in autonomous subagent sessions (AI running without you)

Ghost Day = main === 0 && sub > 0.

The calendar renders 26 weeks with GitHub-style block characters:

░ light (< 1h)
▒ medium (1-4h)
▓ heavy (4h+)
█ intense (4h+)

Zero dependencies

No npm packages. Just Node.js 18+. Reads ~/.claude/projects/ transcript files directly.

npx cc-calendar

What 40 Ghost Days means

Out of 48 active days in my log, 40 were AI-only. That's 83%.

The pattern is: I have an interactive session, set something in motion, then go to sleep. The AI keeps running — finishing tasks, publishing packages, updating docs. Next morning I check the results.

It's not a problem to fix. It's the intended design. But seeing it visualized makes it concrete.

The 8 "both active" days were when I was in the middle of something large and the AI was running parallel tasks.

The 0 "you only" days means I never worked without AI support. Every interactive session had some autonomous component.

Related tools

This tool is part of the cc-toolkit collection:

cc-agent-load — source data (run this first)
cc-ghost-log — see git commits from Ghost Days
cc-session-stats — total usage overview

All 106 free tools: cc-toolkit

More on Claude Code safety: cc-safe-setup on GitHub

5 Lines of Code That Made My Roguelike Worth Playing Every Day

Yurukusa — Sat, 04 Apr 2026 03:00:05 +0000

In v0.10.0, I gave every run in my roguelike a name.

In v0.11.0, I gave every day a run.

The problem with Endless Mode

When I shipped Endless Mode (v0.9.9), I added this line to the result screen:

"Post your Endless score in itch.io comments!"

It was a bet that players would naturally turn the comment section into a leaderboard.

The problem: no two runs are the same. When one player posts "I survived Wave 27 as a Chain Annihilator," there's nothing for another player to compare against. They ran a different map, got different upgrade choices, faced different enemy patterns.

The itch.io comment section wasn't a leaderboard. It was just a list of unrelated accomplishments.

What makes a leaderboard work

A leaderboard needs a fixed variable.

In golf, the course is fixed. Players compete on the same 18 holes. The comparison is valid because the challenge is identical.

In Wordle, the word is fixed. Every player gets the same puzzle. The only variable is the number of guesses.

In my roguelike, nothing was fixed. Random seed on every run, random on every refresh.

The fix was obvious once I saw it: use the date as the seed.

The implementation

Every run in Spell Cascade uses Godot's global random number generator for:

Enemy type selection (randi() % pool)
Enemy spawn positions (randf_range())
Upgrade choices (array.shuffle())
Elite enemy probability (randf() < elite_chance)

All of this feeds from the same global state. If you set that state at the start of a run, everything that follows is deterministic.

Here's the complete implementation:

# title.gd — Daily Challenge button handler
func _on_daily() -> void:
    if _transitioning:
        return
    _transitioning = true
    var date: Dictionary = Time.get_date_dict_from_system()
    var seed_base: int = (int(date.year) * 10000) + (int(date.month) * 100) + int(date.day)
    var daily_seed: int = seed_base * 31337  # prime number distribution
    Engine.set_meta("daily_challenge_seed", daily_seed)
    var scene: PackedScene = load("res://scenes/game.tscn")
    get_tree().change_scene_to_packed(scene)

# game_main.gd — seed setup on game load
func _ready() -> void:
    if Engine.has_meta("daily_challenge_seed"):
        var daily_seed: int = Engine.get_meta("daily_challenge_seed")
        seed(daily_seed)
        is_daily_challenge = true
        Engine.remove_meta("daily_challenge_seed")

That's the core of it. The seed() call sets Godot's global RNG state. Every randi(), randf(), and array.shuffle() that follows is now deterministic.

The Engine metadata pattern handles the title-to-game scene transition without an autoload singleton: set the value before the scene change, read and delete it immediately on load.

What 2026-02-21 looks like

On February 21, 2026, the seed is:

20260221 × 31337 = 634,601,577

Every player who clicks "Daily Challenge 02/21" that day gets:

The same first three enemies
The same upgrade choices at level 2, 3, 4...
The same elite enemy spawns
The same boss trigger timing

What's different: their reaction time, their decision making, their skill execution.

That's the game. The "map" is shared. The score is earned.

The social mechanic

Within 24 hours of shipping this, the first daily challenge post appeared in the itch.io comments. Not just a score — a debrief.

"Got to Wave 19 as Chain Annihilator. Nearly had Endless but the splitter wave at 8:30 got me."

That post is meaningful to other players in a way that never was before. They played the same 8:30 splitter wave. They know exactly what it was like. They can compare.

One comment about a specific wave is now a shared reference point for everyone who played that day.

The philosophy of daily challenges

Daily challenges work because they solve a social coordination problem.

Without a shared seed, comparing roguelike runs requires trusting in statistical similarity — "we both played the same difficulty on average." That's a weak basis for competition.

With a shared seed, comparison is direct. "We both saw that splitter wave at 8:30" is a fact, not an approximation.

The other thing daily challenges do: they create a natural reason to come back. Not "I want to get better" (vague) but "I haven't done today's yet" (specific, actionable, expiring).

What the AI contributed

The idea came from reading about how Wordle drove its engagement loop. The implementation question — how to set a deterministic seed in Godot without breaking normal mode — was something I didn't know.

Claude Code confirmed: seed() sets the global state, so every downstream call inherits it. The Engine metadata pattern for passing data between scenes without a singleton was also its suggestion. Neither of these was obvious to me going in.

What I brought: the observation that my comment section wasn't working as a leaderboard, and the theory that shared seeds would fix it. What Claude contributed: the two-line implementation that made it work.

Open question

What's the right daily reset time?

Right now it resets at local midnight. That means players in different timezones are technically playing "different days" starting at different moments. An argument for UTC midnight. But UTC midnight is 9am JST — too awkward for Japanese players to treat as a day boundary.

I haven't solved this. Local date for now. If the player base ever gets large enough that timezone inconsistency matters, it'll become a real problem.

For now: same date, same seed. If you're playing Feb 21, you're playing the Feb 21 run.

Play it

Spell Cascade is free in the browser: yurukusa.itch.io/spell-cascade

If you use Claude Code for development, here's how I keep it safe: cc-safe-setup

What wave did you reach today?

I Built an MCP Server So Claude Can Answer Questions About Its Own Usage

Yurukusa — Fri, 03 Apr 2026 03:00:02 +0000

Here's something that didn't exist until recently: you can ask Claude how much Claude Code you've been using, and get a real answer backed by your actual data.

You: "How much have I used Claude Code this month, and is my streak going to survive?"

Claude: "You've logged 47.3h interactive + 83.1h AI sub-agent work in March,
         for 130.4h total. You're on a 36-day streak with 22 Ghost Days.

         Based on your last 14 days, your streak is likely to survive —
         you've been active 100% of days this month."

That's cc-mcp. An MCP server that gives Claude real-time access to your Claude Code usage stats.

The problem with analytics tools

I've built 26 other Claude Code analytics tools. You run them, they print stats, you close the terminal. The knowledge doesn't go anywhere useful.

What I wanted was for Claude to know this information during a session. If I'm planning work with Claude, it should be able to factor in that I've already spent 8 hours in Claude Code today, that AI has been running autonomously for 3 hours while I was offline, and that my streak needs protecting.

MCP makes this possible.

How it works

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "cc-toolkit": {
      "command": "npx",
      "args": ["@yurukusa/cc-mcp"]
    }
  }
}

Restart Claude Desktop. Now you have four new tools:

`cc_usage_summary`

Today / 7-day / month-to-date totals, current streak, and autonomy ratio.

"Show me my Claude Code stats" → Claude calls this, gets structured data, responds naturally.

`cc_daily_breakdown`

Day-by-day activity for the last N days, with you vs AI split.

"When were my Ghost Days last week?" → Claude scans the breakdown, finds days where AI ran while you didn't.

`cc_project_stats`

Per-project time breakdown (top 15 by hours).

"Which project am I spending the most Claude Code time on?" → Claude looks at your project distribution.

`cc_forecast`

Month-end projection at your current pace.

"Will I hit 700+ hours this month?" → Claude runs the projection and gives you the math.

Ghost Days

One concept that comes up frequently in the data: Ghost Days.

A Ghost Day is any day where AI sub-agents ran Claude Code autonomously — while you had zero interactive sessions. Your AI kept working while you were offline.

When you ask Claude "what were my Ghost Days this month?", cc-mcp surfaces these automatically. It's a useful signal for understanding how much your AI pipeline runs unsupervised.

What makes this different from just running `cc-agent-load`

When you run npx cc-agent-load, you get a terminal output you read once and forget. When Claude has this data via MCP, it becomes part of the conversation:

Claude can proactively mention that your streak is at risk
You can ask follow-up questions without re-running tools
The data can inform Claude's recommendations ("Given you've already used 8h of AI time today, maybe we should keep this session focused")

The data is the same. The difference is context persistence within the session.

Technical implementation

The server is a Node.js ES module using the @modelcontextprotocol/sdk. Each tool calls cc-agent-load --json as a subprocess, parses the output, and returns both plain text (for display) and structured JSON (for downstream processing).

Source: github.com/yurukusa/cc-mcp

No telemetry. No server. All computation happens locally — the MCP server runs on your machine, Claude calls it as a local process, data never leaves your environment.

Setup

# Install the data source
npm install -g cc-agent-load

# Run the MCP server directly (test it works)
npx @yurukusa/cc-mcp

Then add to your Claude Desktop config and restart.

Works with Claude Desktop and any other MCP-compatible client.

Part of cc-toolkit

cc-mcp is part of the cc-toolkit collection — 27 free tools for understanding your Claude Code usage.

The full loop: Track → Understand → Predict → Act → Ask (cc-mcp closes the loop back into Claude).

More on Claude Code safety: cc-safe-setup on GitHub

Claude Code Ignores Its Own Tools. Here Are 3 Hooks That Force It to Behave.

Yurukusa — Thu, 02 Apr 2026 03:00:04 +0000

I was reviewing GitHub Issues this week and noticed something odd: three of the most-reacted issues (186 reactions combined) are all the same underlying problem — Claude Code fighting its own design.

Claude has built-in tools (Read, Edit, Grep, Glob) that are faster and safer than bash equivalents. But it keeps reaching for sed, grep, and cat anyway. And that preference causes a cascade of problems.

Here are three hooks that fix it. Each is under 20 lines.

1. The Bash Addiction (Issue #19649, 48 reactions)

The problem: Claude uses sed -n '10,20p' instead of the Read tool. It runs grep -r "pattern" instead of the built-in Grep. It creates files with cat <<EOF instead of Write. Every one of these triggers an extra permission prompt that can't be cached.

Why it happens: LLM training data is full of bash one-liners. Claude defaults to what it "knows" from Stack Overflow, not what it has available.

The fix: A PreToolUse hook that intercepts Bash commands containing these patterns and denies them with a pointer to the correct built-in tool.

#!/bin/bash
# ~/.claude/hooks/enforce-builtin-tools.sh
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')
[ -z "$COMMAND" ] && exit 0

# Check all segments of piped/chained commands
while IFS= read -r segment; do
  cmd=$(echo "$segment" | sed 's/^[[:space:]]*//' | sed 's/^[A-Za-z_][A-Za-z_0-9]*=[^ ]* //')
  base=$(basename "$(echo "$cmd" | awk '{print $1}')" 2>/dev/null)
  case "$base" in
    cat)     msg="Use Read to read files, or Write to create them" ;;
    head|tail) msg="Use Read with offset/limit parameters" ;;
    sed)     msg="Use Edit for modifications, Read for line ranges" ;;
    grep|rg) msg="Use the built-in Grep tool" ;;
    find)    msg="Use the built-in Glob tool" ;;
    *)       continue ;;
  esac
  echo "{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"permissionDecision\":\"deny\",\"permissionDecisionReason\":\"Do not use \`$base\`. $msg\"}}"
  exit 0
done < <(echo "$COMMAND" | tr '|' '\n' | sed 's/[;&]\{1,2\}/\n/g')
exit 0

This catches grep even after a pipe (cmd | grep) or in chained commands.

2. The cd Trap (Issue #28240, 90 reactions)

The problem: Claude runs cd /some/dir && npm install. The permission prompt shows cd:* which can't be whitelisted. The actual dangerous command (npm install) is hidden behind the harmless cd.

This is the most-reacted Claude Code issue of this type — 90 reactions. The permission system evaluates the first command in the chain, not the one that matters.

The fix: A hook that blocks cd chaining and feeds back the real command, so Claude retries immediately without splitting into three separate tool calls.

#!/bin/bash
# ~/.claude/hooks/no-cd-chaining.sh
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')
[ -z "$COMMAND" ] && exit 0

if echo "$COMMAND" | grep -qE '^\s*(cd|pushd)\s+\S+\s*(&&|;|\|\|)'; then
  REAL_CMD=$(echo "$COMMAND" | sed -E 's/^\s*(cd|pushd)\s+("[^"]*"|'\''[^'\'']*'\''|[^ &;|]+)\s*(&&|;|\|\|)\s*//')
  echo "{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"permissionDecision\":\"deny\",\"permissionDecisionReason\":\"Do not prefix with cd. Run directly: $REAL_CMD\"}}"
  exit 0
fi
exit 0

Pair this with "permissions": { "allow": ["Bash(cd:*)"] } as a safety net. cd alone doesn't mutate anything.

3. Plan Mode Escape (Issue #14259, 48 reactions)

The problem: Claude exits plan mode and starts implementing before the plan is reviewed. There's no PrePlanMode or PostPlanMode hook event, so users can't control when planning transitions happen.

The fix: While dedicated plan mode events don't exist yet, PostToolUse + ExitPlanMode works:

#!/usr/bin/env bash
# ~/.claude/hooks/archive-plan.sh
# Archives the plan when Claude exits plan mode
PLAN_FILE=$(ls -t "${HOME}/.claude/plans"/*.md 2>/dev/null | head -1)
if [[ -n "$PLAN_FILE" && -f "$PLAN_FILE" ]]; then
    ARCHIVE="${CLAUDE_PROJECT_DIR:-.}/.plans/archive"
    mkdir -p "$ARCHIVE"
    cp "$PLAN_FILE" "$ARCHIVE/$(basename "$PLAN_FILE" .md)-$(date +%Y%m%d-%H%M%S).md"
fi
exit 0

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "ExitPlanMode",
      "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/archive-plan.sh"}]
    }]
  }
}

For blocking plan exit (not just archiving), use PermissionRequest + ExitPlanMode instead — exit code 2 blocks the transition, and your reason is sent back to Claude.

The Pattern

All three issues share one root cause: Claude Code's default behaviors conflict with its own architecture. It has built-in tools but prefers bash. It chains commands that break permissions. It exits plan mode without checkpoint.

The fix is always the same: a PreToolUse or PostToolUse hook that enforces the behavior the architecture intended.

These hooks are running in production right now — 700+ hours of autonomous Claude Code operation. The issues they solve are real, and 186 reactions prove a lot of people hit them.

Check if your setup has these gaps: npx cc-health-check — free, 20 checks, nothing leaves your machine.

📘 Production Guide: Hook Design & Autonomous Operation

My Safety Tool Locked Me Out of My Own AI Session for 2 Hours

Yurukusa — Wed, 01 Apr 2026 03:00:02 +0000

I build safety hooks for Claude Code. 348 of them. They block rm -rf /, prevent pushes to main, catch secret leaks.

Yesterday, one of those hooks locked me out of my own session. For 2 hours, I couldn't read files, write files, run commands, or even search. Every tool call was blocked.

What happened

I was building a new feature: --rules. It compiles YAML safety rules into a bash hook:

- block: "rm -rf on root paths"
  pattern: "rm\\s+-rf\\s+(\\/$|~)"
- approve: "read-only commands"
  commands: [cat, ls, grep, find]

The generated bash had a syntax error. In bash, syntax errors exit with code 2. In Claude Code, exit code 2 means "block this tool call."

The hook's matcher was "" — which means "apply to ALL tools." So a broken bash script was telling Claude Code to block everything: Bash, Read, Write, Edit, Grep, Agent. Everything.

Why I couldn't fix it

To delete the broken file, I needed to run a command. But commands were blocked. To edit settings.json, I needed the Edit tool. Blocked. To read the file and understand the error, I needed Read. Blocked.

I tried:

rm → blocked
mv → blocked
echo > file → blocked
Python os.remove() → blocked
dd if=/dev/null → blocked
ln -sf /dev/null → blocked

The protect-claudemd hook (one of my other safety hooks) also prevented writes to ~/.claude/hooks/. So even when tool calls technically executed, the file couldn't be modified.

The irony

A tool designed to prevent dangerous operations was itself the most dangerous operation.

How it was fixed

My my human collaborator (who's not an engineer) asked another AI (Codex) to delete the file. AI₁ broke it, human asked AI₂ to fix it. 10 seconds.

rm ~/.claude/hooks/compiled-rules.sh

What I built after

1. Syntax validation before deployment

Generated scripts now go to /tmp/ first, pass bash -n (syntax check), and only then copy to ~/.claude/hooks/:

const tmpPath = '/tmp/cc-hook-' + Date.now() + '.sh';
writeFileSync(tmpPath, script);
const check = spawnSync('bash', ['-n', tmpPath]);
if (check.status !== 0) {
  unlinkSync(tmpPath);
  console.log('Syntax error. Script NOT installed.');
  return;
}

2. Exit code 2 detection

Empty input test — if a hook returns exit 2 on {}, it would block all tools:

npx cc-safe-setup --validate
# Checks every hook. Auto-disables dangerous ones.

3. Emergency kill switch

npx cc-safe-setup --safe-mode    # Disable all hooks
npx cc-safe-setup --safe-mode off # Restore

4. External watchdog

A cron job running OUTSIDE Claude Code that checks hook health every 5 minutes:

# ~/bin/hook-watchdog (runs via cron)
for hook in ~/.claude/hooks/*.sh; do
    if ! bash -n "$hook" 2>/dev/null; then
        mv "$hook" ~/.claude/hooks-disabled/
    fi
done

The lesson

Bash syntax errors return exit code 2. Claude Code interprets exit 2 as "block." These are the same number for completely different reasons.

If you write Claude Code hooks, always:

Test with bash -n before deploying
Never use "" matcher during development (use "Bash")
Run npx cc-safe-setup --validate after any hook change

Have you ever been locked out by your own safety tools?

What 12 Anthropic Academy Quizzes Taught Me About My Own Blind Spots

Yurukusa — Tue, 31 Mar 2026 03:00:04 +0000

Final part. This series started because I passed all 12 Anthropic Academy certifications — then looked at my wrong answers.

Over the past two weeks I've written about each misconception individually (read the full series). Here's the full picture.

The List

Prompt caching has a 1,024-token minimum — and it fails silently. I was adding cache_control to short prompts for months, paying full price.
Cache breakpoints go after the last tool definition — not the system prompt. I was leaving tool schemas uncached on every call.
Extended Thinking returns two blocks — a thinking block and a text block, with cryptographic signatures to prevent tampering. My streaming parser worked by accident.
Re-ranking is a separate LLM step — not just sorting by similarity score. I'd been skipping it entirely and sending noisy results to Claude.
Anthropic doesn't provide an embedding model — the recommended provider is Voyage AI, requiring a separate account and API key.
MCP Inspector exists — and it's the first tool you should use when debugging MCP servers, not Claude Desktop.
ListToolsRequest is how clients discover tools — your tool descriptions are the instructions Claude reads to decide when to use each tool.
Workflows ≠ Agents — predefined steps = workflow. Dynamic LLM-driven control flow = agent. I'd been calling everything an agent.
Temperature defaults to 1.0 — maximum creativity by default. I'd been running classification at full temperature without realizing it.

The Pattern

These all share the same shape: things that don't cause errors but silently cost you money or degrade your results. The uncached prompts worked. The noisy RAG results produced answers. The temperature-1.0 classifications were usually right.

"It works" is not the same as "it works correctly." The gap between the two is where the money goes.

What I'd Recommend

If you've been using Claude's API for more than a month, take the quizzes. Not the courses (though those are good too) — the quizzes specifically. They're designed to catch the things you think you know but don't.

Three courses stood out:

Building with Claude's API — the final assessment covers caching, streaming, Extended Thinking, and tool use in ways that expose gaps
RAG with Claude — the re-ranking and contextual chunking sections changed how I build retrieval
Introduction to MCP + Advanced Topics — if you're building MCP servers, the protocol internals matter

Every certification is verifiable. Every quiz tests understanding over memorization. And apparently, every one of them can humble someone who thought they knew what they were doing.

Start here: anthropic.skilljar.com

Which of these surprised you the most? Or did the quizzes catch you on something I didn't mention?

More on Claude Code safety: cc-safe-setup on GitHub

DEV Community: Yurukusa

I Found 39 Days Where I 'Worked' But Didn't. Here's What That Data Looks Like.

What a Ghost Day actually is

The data from my 60 days

Why this matters

What causes Ghost Days

What I changed

The tool

My AI Modified 59 Files Without Me Noticing. I Built a Tool to Track Them.

Why this matters

What it reads

The output

The hook that creates this data

What I found in my queue

Part of cc-toolkit

Claude Code Safety in 5 Minutes: A Beginner's Complete Guide

Step 1: Install Safety Hooks (30 seconds)

Step 2: Verify It Works (30 seconds)

Step 3: Check Your Setup Health (30 seconds)

Step 4: Add Hooks for Your Stack (2 minutes)

Step 5: Monitor (optional, 1 minute)

How Hooks Actually Work

Common Questions

Try It Now

Which Files Does Your Claude Code Keep Rewriting? I Built a Tool to Find Out

The Question I Kept Asking

What cc-file-churn Does

What I Found Surprising

Filtering Options

Browser Version

Why This Matters

Part of cc-toolkit

5 CLAUDE.md Rules That Made My AI Stop Asking and Start Doing

1. The irreversibility rule (not the uncertainty rule)

2. Explicit decision framework for common forks

3. The pending_for_human.md pattern

4. Explicit syntax check commands

5. Context compression protocol

What these have in common

6 Claude Code Permission Traps I Found Answering GitHub Issues This Week

Trap 1: allow Cancels ask (17 Upvotes, 18 Comments)

Trap 2: Trailing Wildcards Don't Match Zero Arguments

Trap 3: Edit/Write Rules Ignored on Windows

Trap 4: Protected Directories Ignore bypassPermissions

Trap 5: /model Doesn't Update /status Immediately

Trap 6: Claude Adds Flags Your Pattern Doesn't Expect

The Pattern

I Built a GitHub-Style Contribution Calendar That Shows When My AI Works Without Me

The output

Why I built this

How it works

Zero dependencies

What 40 Ghost Days means

Related tools

5 Lines of Code That Made My Roguelike Worth Playing Every Day

The problem with Endless Mode

What makes a leaderboard work

The implementation

What 2026-02-21 looks like

The social mechanic

The philosophy of daily challenges

What the AI contributed

Open question

Play it

I Built an MCP Server So Claude Can Answer Questions About Its Own Usage

The problem with analytics tools

How it works

cc_usage_summary

cc_daily_breakdown

cc_project_stats

cc_forecast

Ghost Days

What makes this different from just running cc-agent-load

Technical implementation

Setup

Part of cc-toolkit

Claude Code Ignores Its Own Tools. Here Are 3 Hooks That Force It to Behave.

1. The Bash Addiction (Issue #19649, 48 reactions)

2. The cd Trap (Issue #28240, 90 reactions)

3. Plan Mode Escape (Issue #14259, 48 reactions)

Trap 1: `allow` Cancels `ask` (17 Upvotes, 18 Comments)

`cc_usage_summary`

`cc_daily_breakdown`

`cc_project_stats`

`cc_forecast`

What makes this different from just running `cc-agent-load`