Snippets and Thoughts of One Oracle Developer

C Claude Code ships a "/insights" command that generates a usage report. It covers which sessions succeeded, where things broke, tool usage patterns, cost distribution. It is a HTML file and extracting anything useful from it is just enough friction to lose the habit. The big issue There's a bigger problem though. By default, "/insights" generates a report from the past 30 days. That's a huge window. I don't want feedback once per month, I want it once per week. At that point most of the recommendations there are for things you may have solved two or three weeks ago. The report feels stale before you even open it. I found a solution by manipulating the source data. Claude Code reads "~/.claude/projects/*/*.jsonl" to compute the report. The skill temporarily moves JSONL files older than 7 days out of that directory before running "/insights", then restores them immediately after regardless of success or failure. This constra...

W When Claude finishes a long task, you get silence. That's fine, but there's a better option. Claude Code supports hooks, which are commands that fire on specific events. So I wired up Mario sounds you might know from my APEX Deployment Tool , and now I get a little coin chime when Claude is done, a warning tone when it's waiting for me, and a dying-mushroom sound right before it compacts the conversation. Here's how to set it up. Install chime The chime Python library does all the work. One install, no system dependencies. pip install chime The script Save this anywhere stable. I keep mine at "~/.claude/scripts/play_sound.py". #!/usr/bin/env python3 import argparse import chime SOUNDS = { 'success' : chime.success, 'error' : chime.error, 'warning' : chime.warning, 'info' : chime.info, } def main(): parser = argparse.ArgumentParser() parser.add_argument('sound'...

S So I just published two Claude Code plsql-formatter and sql-formatter skills. The first one handles packages, procedures, functions, and triggers. The second handles the SQL side: standalone queries, any SQL embedded inside PL/SQL and views. Together they cover everything that lands in a real project. I split them into two skills because that is how Claude routes, by intent. Two skills, two trigger sets, no token waste on rules that don't apply. The Problem SQL Developer's built-in formatter is configurable, but every developer has a slightly different preferences and not everything can be customized there as you want. The result on a shared repo is a diff full of whitespace noise, columns realigned three different ways, WHERE clauses re-indented on every commit. So you spend time in code review fixing formatting instead of logic. Eventually you settle with a style which you don't really like. A skill fixes this differently. Instead of running a tool that rewrit...