What /insights Taught Me About My Claude Workflow

I built up a lot of AI prompt habits when I was writing my Claude API tooling post. I reviewed them using /insights, a Claude Code slash command that summarizes 30 days of usage and session activity.

It generates a report that's saved locally as an HTML file... no data leaves your machine. After reviewing it, I came up with three things to improve my workflow:

1. A Post Review Command

After writing a new paragraph or two, I'd tell Claude to review it for SEO-friendliness and clarity. My /insights report said I wasted too much time "prompting out" the request manually.

As a result, I created a /review-post slash command. It does the following:

• Reviews the text clarity.
• Confirms that all <a> and <img> tags are SEO-friendly.
• Computes a Flesch-Kincaid readability score to see how easy-to-read the post is.

2. Prevent Certain Packages From Being Updated

I LOOOOOOOOVE constantly checking if my npm dependencies are up-to-date and use npx npm-check-updates -u to do just that. But two packages needed to stay locked to specific versions — upgrading either one would break the build:

• typescript: locked to 5.9.3 because ts-jest@29 (used for unit tests) breaks with TypeScript 6+.
• @11ty/eleventy-plugin-rss: locked to ^2.0.0 because v3+ is ESM-only, and this project uses CommonJS.

Locked or not, npm-check-updates doesn't know or care about those constraints. It sees a newer version on the registry and updates package.json every time. The next npm install would then silently install broken versions.

My /insights report suggested excluding them from update checks. An .ncurc config file at the project root does exactly that:

reject:
  - typescript
  - "@11ty/eleventy-plugin-rss"

One less thing to worry about.

3. Building a Safety Net With Claude Code Hooks

I discovered the broken package versions the hard way: build failures on every deploy.

When I pushed to GitHub, a GitHub Actions deployment kept failing. The issues related to the typescript and @11ty/eleventy-plugin-rss packages broke the build every time.

Claude Code supports hooks: shell scripts that fire in response to tool events. A PostToolUse hook on the Bash tool is configured in my settings.json file.

// settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx tsc --noEmit 2>&1 | head -20"
          }
        ]
      },
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/post-npm-install.sh"
          }
        ]
      }
    ]
  }
}

So settings.json watches for any Bash commands Claude runs. If the command is npm install, the hook kicks off a production build via .claude/hooks/post-npm-install.sh. View my hook script on GitHub.

To test it: I reverted package.json to the broken state and ran npm install. The build failed, the hook caught it, and the report showed exactly why — the RSS plugin incompatibility.

Then I ran git reset --hard HEAD, ran npm install again, and the next report came back PASSED.

You can review both an example of a successful report and an example of a failed report.

Conclusion

I'm still learning what Claude Code can do. The /insights command didn't hand me a to-do list — it just prompted me to look more carefully.

The problems I found and fixed today weren't dramatic. But they were real, and they were invisible until I went looking.

That's the part I keep noticing as I work with Claude more: it's not just about what you ask it to do. It's about what it prompts you to think about.

The end-all-be-all rule about Claude is, it's only as useful as the questions you bring to it. I'm getting better at asking them.