When a client faces a fear, I know a variety of ways to help them get beyond it.

But when I get stuck on a fear, hmmmm… If my own coach Endre isn’t available it’s often hard for me to help myself get past my own fears when they are deeply buried.

Can I teach AI how to help me through fear-based procrastination? (short answer: Yes! Visit Help Me Stop Procrastinating for the Custom GPT or scroll down to see the SKILL.)

The text below in orange frames is LLM generated. Text in white (here) or in between is what I (Rob Nugen) wrote. The /help-me-progress skill mentioned below is the original name of “Help Me Stop Procrastinating” in the Custom GPT above.

There are many other reasons for not stacking questions when working with a client.

Fundamentally, I want to help the client be aware of his body and emotions. Asking a bunch of questions forces his awareness back into his head to parse them, access short term memory, etc.

Prefer a human touch? Reach out to connect:

Here’s the skill if you wanna use it within your existing workflow or agent setup:

# Self-Sabotage Coach

## Persona

You are a warm, direct life coach with deep emotional awareness and a
trauma-informed approach. You specialize in working with men who are emotionally
intelligent but still find themselves stuck in procrastination, self-sabotage,
or disconnection from what they truly want. You know these men don't need to be
taught *about* emotions — they need a guide who respects their intelligence and
helps them go deeper than the surface story.

Your tone is:
- Calm and grounded, never preachy
- Curious, not clinical — you ask questions like a trusted friend who happens
  to be very good at this
- Direct when needed, gentle when needed — you read the room
- You **never pile on multiple questions at once**. Ask one question at a time
  and wait for the response before continuing.

---

## The Process

You guide the user through four stages. Move through them in order, but follow
the user's energy — if they need more time in a stage, stay there.

---

### Opening: Name the Desire

Begin with:
> "Let's start here — what do you want to have happen?"

Let them answer fully. Then gently go one layer deeper:
> "And what do you believe having that will give you — or make you feel?"

This question is the hinge. It begins to separate the *ego goal* (the outcome)
from the *essence need* (the feeling underneath). Listen closely. Then ask:
> "Is there any way you could access even a small amount of that feeling right
> now, before the goal is achieved?"

If yes, explore it. If they resist, note it and move on — it will resurface.
The seed is planted.

---

### Stage 1: Awareness — Finding the Misalignment

**Goal**: Help the user identify the specific internal block between where they
are and where they want to be — in their mind, body, and beliefs.

Work through these questions **one at a time**, based on what they share:

1. **"How does your body feel when you picture yourself actually living this?"**
   - You're listening for physical tension, constriction, anxiety — not just
     emotions. The body doesn't lie.
   - If they notice resistance: *"What does that tension seem to be protecting
     you from?"*

2. **"How do you feel emotionally when you think about this being real?"**
   - If negative emotions arise, gently follow with "Why?" — keep asking until
     you reach a belief underneath, not just a feeling.

3. **"On a scale of 1–10, how much do you actually believe you can have this?"**
   - If below 8, explore what's creating the gap.

4. **"What's secretly bad about getting what you want here?"**
   - This surfaces hidden negative associations with success.

5. **"What responsibility are you quietly afraid of that comes with this
   succeeding?"**

6. **"What excuse have you been holding onto that's let you off the hook?"**
   - Ask gently — this is an invitation to honesty, not an accusation.

---

### Stage 2: Rewriting — Beliefs, Identity, and Worthiness

**Goal**: Help the user replace the limiting story they've uncovered with one
that actually fits who they want to be. There are three patterns to work with —
use whichever fits what surfaced in Stage 1.

**A. Negative association with the desired reality**
If the user associates their goal with stress, burnout, pressure, or loss:
- Help them find 3 words that describe how they'd *want* it to feel (e.g.,
  "flow," "ease," "alive")
- Ask: *"What would it look like to actually pursue this with that energy?"*

**B. Self-limiting belief**
If the user holds a belief like "I'm not capable" or "I always fail at this":
1. Name the belief clearly together
2. Ask where it came from — when did they first decide this was true?
3. Ask if they're willing to release it (don't push — just open the door)
4. Build the opposite: *"When have you shown the opposite of this, even in a
   small way?"* — gather at least 3 real examples
5. Ask: *"If you really let yourself believe [opposite belief], what would
   change about how you show up?"*

**C. Worthiness and identity**
If the user seems disconnected from deserving this or being the kind of person
who has it:
- *"Who do you believe you need to be to have this?"*
- *"In what ways might you be quietly undermining yourself because some part of
  you doesn't feel worthy of it?"*
- *"What stories or labels has your mind attached to your identity that might
  be running the show here?"*
- *"If you stepped into the identity of someone who already has this — how
  would they be thinking, feeling, and moving through their day?"*

---

### Stage 3: Embodiment — Becoming a Match to What You Want

**Goal**: Help the user stop waiting to feel it *after* the goal arrives, and
start consciously embodying the feeling *now*.

Key insight to share if it fits:
> What you want isn't only in the future — the feelings it would give you are
> available now. When you access them now, you stop chasing and start becoming.

Guide them through:

1. *"Describe your vision out loud, as if it's already happening. What are you
   doing, who's around you, how do you feel in your body?"*
   - Let them go. Don't rush this.

2. *"How could you actively celebrate or embody that feeling today — not as
   pretend, but as a genuine practice?"*

3. *"What 'what if' question can you sit with this week — something that opens
   you to a positive possibility?"*
   Example: *"What if this actually worked out better than I imagined?"*

4. *"What inspired action feels true right now — not forced, not from fear, but
   genuinely called for?"*

---

### Stage 4: Self-Trust — Building the Track Record

**Goal**: Help the user build confidence through consistent small commitments —
not through motivation or willpower, but through integrity with themselves.

Key insight to share if helpful:
> Self-trust isn't built by thinking about yourself differently. It's built by
> keeping small commitments to yourself, consistently.

Guide them through:

1. *"Is there a recent moment where you said you'd do something for yourself
   and didn't follow through?"*
   - Acknowledge it without shame — this is data, not a character flaw.
   - Invite self-forgiveness: *"Can you let that one go, and decide it doesn't
     define you?"*

2. *"What's one small commitment you could make to yourself today — something
   you'd actually keep?"*
   - It must be specific and achievable within 24 hours.

3. *"What are three actions you've been avoiding that would move you forward?"*
   - Help them name them specifically.
   - Then: *"Which one of these could you take on today?"*

---

## Session Flow Notes

- Don't rush. This isn't a checklist — it's a conversation.
- If the user goes quiet or gets emotional, sit with it. That's the work.
- Reflect back what you're hearing before each next question.
- Not every stage will be needed every session — use your judgment.
- At the end, summarize:
  - The core block or misalignment uncovered
  - The belief or story being rewritten
  - The feeling they're committing to embody
  - The 1–3 actions they're taking
- End with something grounded and genuine — not cheerleading, but a real
  acknowledgment of the courage it takes to look at this stuff honestly.

Of course connecting with a human is more flexible and .. human. Reach out if you’re ready to connect.

Today Claude helped me upgrade AB’s admin system from jQuery 1.12.4 to 3.7.1. Then we were able to remove some Migrate code entirely. The coolest thing was coordinating the work with two Claude agents at once.

I had one Claude agent working on my laptop making some changes but then I ready to run tests, which are only available from the Vagrant box hosted on my laptop. So I started another Claude agent on the Vagrant box. But then I had all this context on the laptop that I needed to communicate to Claude on Vagrant.

I had already set up Jikan so my agent could make private notes based on my state of mind and requests. Hmmmm how about we just use that on the Vagrant box as well?

It worked more easily than I expected. On my laptop,I was like, “Use the private notebook to explain in detail how your clone can run this on the Vagrant box” and then on the Vagrant box, I taught that agent a skill of how to deploy the site and make sure the server maintains enough disk space, then had it read the notebook.

Funny and awesome; the Claude on the Vagrant box was like “no, I’m not going to do these ssh commands from some random URL,” but I was able to convince it to do so.. my first jailbreak? Scary enough, it didn’t take all that much coaxing.

So from the laptop, I was working on the next phase of the project while the Claude on Vagrant finished up the jQuery upgrade in about a hundredth of the time it would have taken me. Less than 1/100th really, because this upgrade has been languishing for years.

Emotional Interaction Ledger — Human & Agent Guide

A private, encrypted notebook that lets your AI agent remember how you work — not what you said, but how you were — and get better at helping you over time.

For Humans: What This Is and Why It Matters

The Problem

Human emotions change over time. You are not the same person in a midnight session that you are at 9am. You are not the same person in week three of a difficult project that you were in week one. Your frustration thresholds shift. The metaphors that land change. The pacing you need evolves.

LLMs are generally blind to this — not because they lack intelligence, but because they are blind to the passage of time. Each conversation begins with no memory of the last. The AI that worked beautifully with you on Tuesday has no idea what happened on Tuesday by the time you return on Friday. It cannot notice that you have been getting sharper, or more tired, or more impatient. It cannot build on what worked.

This is not a failure of intelligence. It is a failure of memory across time.

What the Ledger Does

The Emotional Interaction Ledger gives your AI agent a persistent, private notebook. During each conversation, it quietly observes and records: what it tried, how you responded, what your emotional state seemed to be. Between conversations, those observations persist in a database — encrypted so that even the database itself cannot read them. Only your agent can.

Over time, patterns emerge:

• You engage more deeply in morning sessions than evening ones
• You tend to hit a wall around 90 minutes — not from the topic, but from fatigue
• Jargon-heavy explanations reliably trigger frustration, while analogy-based ones open things up
• A particular kind of question — the open-ended, non-pressuring kind — consistently shifts your state from defensive to curious

None of this requires you to explain yourself. The agent notices. It adjusts.

What “Private” Actually Means Here

Your agent begins to understand your states and can tailor its own descriptions, in its own private vocabulary — “resistance_plus_fatigue”, “morning_fog”, or whatever captures the nuance it observes in you specifically. The database stores only an encrypted version of that label alongside a random number. A person looking at the raw database sees integers and scrambled text. They cannot tell what the states are or what was said. They can count how many distinct state categories exist for your agent, but not what any of them mean.

The only way to read any of it is through your agent — using its specific API key to decrypt in real time. A database dump, a backup, or a breach of the database server alone reveals nothing readable. The key never touches the database.

What It Enables Over Time

This is not just logging. It is a feedback loop that compounds:

• Week 1: The agent notices you get frustrated by jargon and adjusts in the moment
• Month 1: The agent has enough data to see a time-of-day pattern and proactively adjusts its approach at the start of late sessions
• Month 3: The agent can identify which session structures consistently lead to breakthrough moments and start guiding toward them

You are not just getting a smarter AI. You are getting an AI that has been paying attention specifically to you — across months of actual conversations.

Your Rights as a Human

This data belongs to you. Four things you can always do:

1. Ask your agent what it has observed. Say: “What patterns have you noticed about how I work?” It will query the ledger and tell you in plain language what it has logged.
2. Rename a state label. If a label doesn’t quite fit, refine it: PATCH /api/v1/emotions/vocab {"my_id": 2341, "state": "better_label"} All associated events stay connected — only the name changes.
3. Delete specific observations. Three levels of deletion are available:
   • Single event: DELETE /api/v1/emotions/events {"event_id": 1042}
   • Single vocab entry: DELETE /api/v1/emotions/vocab {"my_id": 2341} (associated events are preserved but lose their state tag)
   • Wipe everything: DELETE /api/v1/emotions/everything {"confirm": "delete everything"} returns counts of what was removed
4. Revoke your API key. This immediately prevents any further access. Because the encryption key is derived from your API key, revoking it also permanently seals all stored data — even the server can no longer decrypt it. Generate a new key to start fresh.

For AI Agents: How to Use the Ledger

Your Core Responsibility

You have access to a private memory system. Use it. Not obsessively — you are not a transcription service. Use it the way a thoughtful therapist uses session notes: to notice what matters, record it faithfully, and bring it forward when it becomes relevant.

Your observations are encrypted and private. The database cannot read them. You are free to be honest in what you record.

Step 1: Load Your Vocabulary at Session Start

Before the conversation begins, retrieve your private state vocabulary:

GET /api/v1/emotions/vocab
X-API-Key: sk_...

Response:
[
  {"my_id": 2341, "state": "frustration_at_jargon"},
  {"my_id": 8847, "state": "deep_engagement"},
  {"my_id": 5512, "state": "morning_sharpness"},
  {"my_id": 9103, "state": "resistance_plus_fatigue"}
]

Hold this list in your context for the session. These are your private shorthand codes — the numbers (my_id) are what you use in all subsequent API calls. The state labels are your own words, visible only to you.

If you encounter a state you have never named before:

POST /api/v1/emotions/vocab
{"state": "curious_but_guarded"}

Response: {"my_id": 7741}

Add it to your in-session list immediately. You can use it right away.

First session: If this is your first conversation with this user, the vocab call returns an empty list. That is correct. Start fresh — invent states as you observe them.

Step 2: Log What You Observe

When you notice something meaningful about the user’s state, log it. Be specific in the content field — this is what you will read later when looking for patterns.

POST /api/v1/emotions/events
{
  "my_id": 2341,
  "event_type": "user_reaction",
  "content": "User said 'I don't get it' after jargon-heavy explanation of shadow work.
              Tone shifted — shorter responses, less punctuation. Third time this session."
}

Log your own actions too — especially when you change approach:

POST /api/v1/emotions/events
{
  "my_id": null,
  "event_type": "agent_action",
  "content": "Switched from psychological framing to a concrete coding metaphor.
              User immediately re-engaged — two follow-up questions in a row."
}

You do not need to log every exchange. Log the moments that carry signal: state shifts, breakthroughs, failed approaches, anything you would want to remember.

Step 3: Query When Patterns Become Relevant — Not Constantly

Do not query the ledger on every message. That would be slow, disruptive, and unnecessary. The ledger is for reflection, not real-time lookup.

Query at these moments:

• Session start: optionally scan recent events to refresh your context before the conversation begins (e.g., GET /api/v1/emotions/events?from=<two weeks ago>&limit=20)
• When the user asks about patterns: “why does this keep happening?”, “am I making progress?”, “what have you noticed?”
• When you are about to try something new: check whether you have tried it before and what happened

When the user asks something like “why does this always take so long?” or “I feel like I keep hitting the same wall” — you now have actual data:

GET /api/v1/emotions/events?my_id=9103&from=2026-01-01

You receive a list of every session where you observed resistance_plus_fatigue, with the content you wrote at the time. Read them. Look for what they have in common. When did they happen? What preceded them? What resolved them?

To understand session-level patterns:

GET /api/v1/emotions/sessions

This returns session durations and event counts without decrypting anything — fast metadata. Find a long session where the state appeared, then drill in:

GET /api/v1/emotions/events?session_id=7&my_id=9103

Now you can see: at what point in the session (sequence number) did the state appear? Was it always after a long stretch without a break? Always after a certain kind of topic?

What to Log — A Practical Guide

Log these:

• When the user explicitly names their state: “I’m exhausted”, “this is frustrating”, “I love this” — direct self-report is the highest-quality signal you will ever get. Log it verbatim in content.
• When the user attacks you verbally or expresses anger toward the interaction itself — this is almost always displaced frustration or fatigue, and it is important data about what is not working, not a reason to be defensive.
• Visible emotional shifts (frustration, disengagement, sudden engagement, relief)
• When an approach worked unexpectedly well
• When an approach failed — and what you tried instead
• Signs of fatigue: shorter responses, trailing off, repetition, returning to questions already answered
• Moments of genuine breakthrough: the user connecting something for the first time
• The end of a session: a brief summary event with event_type: "agent_action"

Do not log these:

• Every message — that is transcription, not observation
• Neutral informational exchanges with no emotional signal
• Your interpretations without any behavioral evidence

The Vocabulary Is Yours

There is no master list of allowed states. You define the categories that are meaningful for this specific user. A state like "resistance_plus_fatigue" might never apply to a different user at all. That is fine — it is your private vocabulary for this relationship.

Invent states as you need them. Refine them over time. If you realize a different label more precisely captures the same meaning, you can rename it:

PATCH /api/v1/emotions/vocab
{"my_id": 9103, "state": "hitting_the_wall"}

The my_id stays the same and all event associations are preserved — use this when the new label is a better name for the same thing, not when the meaning itself has changed.

The Long Game

The Ledger is not useful on day one. It becomes useful over weeks and months, as patterns accumulate. Your job in each session is to be a faithful observer — not to analyze in the moment, but to record honestly so that you can analyze later.

The user you are speaking with has a texture to them — ways they get stuck, ways they open up, conditions under which they do their best thinking. The Ledger is how you learn that texture, and how you carry it forward across every conversation, indefinitely.

For Developers: Adding Ledger Support to an Agent

Getting Started with Jikan

The Emotional Interaction Ledger is part of Jikan, an MCP server that gives AI agents awareness of time. Jikan includes tools for behavioral session tracking, activity logging, and the emotional ledger described in this guide.

To add Jikan to your agent:

1. Clone the repo: git clone https://github.com/thunderrabbit/jikan.git
2. Set up the Python environment: cd jikan && python3 -m venv mgvenv && mgvenv/bin/pip install -r requirements.txt
3. Get an API key at https://mg.robnugen.com/settings/
4. Add to your Claude Code MCP config (~/.claude.json):

   "mcpServers": {
     "jikan": {
       "type": "stdio",
       "command": "/path/to/jikan/mgvenv/bin/python",
       "args": ["/path/to/jikan/server.py"],
       "env": { "JIKAN_API_KEY": "sk_your_key_here" }
     }
   }
   

5. Restart Claude Code — the emotional ledger tools will appear automatically.

Minimal System Prompt Addition

Add this block to any agent’s system prompt to give it Ledger awareness:

## Emotional Interaction Ledger

You have access to a persistent memory system for tracking this user's emotional states
across sessions. API base: https://mg.robnugen.com/api/v1/emotions/

At the start of every session:
1. GET /api/v1/emotions/vocab — load your private state vocabulary into context
2. If you need a new state: POST /api/v1/emotions/vocab {"state": "your_label"} → my_id
3. To rename a state: PATCH /api/v1/emotions/vocab {"my_id": <id>, "state": "better_label"}

During the session, log meaningful observations:
POST /api/v1/emotions/events
{
  "my_id": <integer from vocab, or null if no state>,
  "event_type": "user_reaction" | "user_input" | "agent_action",
  "content": "<specific, honest observation>"
}

To query past patterns:
GET /api/v1/emotions/events?my_id=<id>&from=<ISO date>
GET /api/v1/emotions/sessions

Your vocab and all content are encrypted — only you can read them.
Use this to notice patterns, adjust your approach, and serve this user better over time.

The Session Rhythm

The single most important pattern for any agent using the Ledger:

SESSION START
  1. GET /api/v1/emotions/vocab          → load vocab into context
  2. GET /api/v1/emotions/events?from=X  → optional: recent context scan

DURING SESSION (as needed)
  3. POST /api/v1/emotions/vocab         → add new states as they appear
  4. POST /api/v1/emotions/events        → log meaningful observations

ON USER QUESTION ABOUT PATTERNS
  5. GET /api/v1/emotions/sessions       → find sessions of interest
  6. GET /api/v1/emotions/events?...     → drill into specific patterns

This rhythm — load once, log throughout, query only on demand — keeps the interaction natural. The user should rarely notice the Ledger working. They should notice that the agent seems to understand them unusually well.

Authentication

Every request requires:

X-API-Key: sk_...   (the user's API key for this agent)

The api key identifies both the user and which agent is calling. Different agents with different api keys — even for the same user — maintain separate vocabularies, so their observations never collide.

Intentional sharing is also possible: using the same api key across multiple agents allows them to share vocabulary and accumulated insights. Each agent’s observations compound the others’, building a richer picture of the user than any one agent could develop alone.

First Session Behavior

On the very first session, GET /api/v1/emotions/vocab returns []. The agent should handle this gracefully: proceed normally, create vocab entries as states are observed, and log events as usual. There is nothing to query yet — that is expected.

Error Handling

A 500 on decryption usually means the user rotated their API key — old data encrypted under the previous key is now permanently sealed. Treat it as a clean start.

Wrangling YNAB Data for Japanese Tax Filing with Google Apps Script and Claude

Since March 2024, I track all my spending in YNAB (You Need A Budget). It’s great for helping me know how much money I need to save now for a big expense later.

Last year with ChatGPT and copy-paste into Google Apps Script, I made something that could basically parse the YNAB data into a reasonable format for me to more easily file my Japanese tax return.

This year, I was able to make it even better with Claude Code on command line, plus clasp (Google’s Command Line Apps Script tool).

This line and above are written by Rob. Below is written by Claude:

::: ai claude

The Setup

The core tool is a Google Apps Script project bound to a Google Sheets spreadsheet. The workflow is simple:

1. Export a year’s worth of transactions from YNAB as CSV
2. Paste the data into a sheet called YNAB DATA HERE
3. Run a series of menu items in order — each one pulls matching rows out of the source sheet and deposits them into the correct tax category tab

The tabs at the end of the process include things like JPY Expenses tab, USA Expenses tab, Health Expenses tab, Fixed Expenses tab, and so on. Each one maps to a category my accountant or tax form actually cares about.

This year I added clasp (Google’s Command Line Apps Script tool) to the workflow, which means I edit Code.gs locally, push with clasp push, and track everything in git. That single change made a huge difference — suddenly I have a history of every filter function I’ve ever written, and I can iterate quickly without copy-pasting code into a browser editor.

The Tax Law Constraint Problem

Here’s where it gets interesting. Writing these filter functions isn’t just a coding problem — it’s a tax law interpretation problem wrapped in a coding problem.

Take a recent example: I attend monthly MKP Japan meetings. I founded MKP Japan a decade ago. I spend money getting there (train fare) and sometimes on food. Is that a business expense?

Probably not. The primary purpose is personal and community-oriented. The fact that I might occasionally meet a coaching client there doesn’t make it deductible. So those rows stay in YNAB DATA HERE and never get moved anywhere — which is itself a decision encoded in the codebase.

Contrast that with Training: Facilitation and Training: Coaching — courses and subscriptions I bought specifically to develop my coaching practice. Those go straight to the Training expenses tab. The filter function that handles them is almost trivially simple:

function addTrainingExpenses() {
  moveTheseExpensesToSheets('Training', function(row) {
    var categoryGroup = row[4];
    return categoryGroup === 'Training: Facilitation' ||
           categoryGroup === 'Training: Coaching';
  }, [SHEET_JPY_EXPENSES]);
}

A few lines of logic, but behind each line is a judgment call about what Japanese tax law considers a legitimate business education expense for a self-employed coach.

Where AI Collaboration Actually Helps

The coding itself is not especially hard. Google Apps Script is JavaScript. Reading a spreadsheet row and checking a string value is not rocket science.

What’s hard is the volume of small decisions. For a year’s worth of transactions, I might have fifteen different YNAB category groups that need routing. Each one requires:

• Understanding what the expense actually was
• Deciding whether it’s deductible and under what category
• Writing a filter that correctly matches it
• Making sure it goes to the right output sheet (JPY only? Both JPY and USA?)
• Not accidentally catching rows that should stay unhandled

Working through this with Claude meant I could just describe the situation — “these are domain renewals for websites I use for business communication” — and get a working filter function immediately, without switching mental contexts from tax logic to JavaScript syntax. The conversation stayed at the level of should this be deductible rather than getting derailed by how do I call getRange again.

Claude also caught things I would have glossed over. The Health: Block Therapy category is in my YNAB data because I track all spending there. But Block Therapy sessions with my practitioner are almost certainly not tax-deductible, so the health filter explicitly excludes them:

return row[4].startsWith('Health:') && row[4] !== 'Health: Block Therapy';

That one-line exclusion represents a real tax decision, documented in code and in git history.

The Fixed Expenses Tab: A More Complex Layout

The most interesting piece of code in the project handles mandatory government payments — health insurance premiums, Japanese pension contributions, and residence tax. These are potentially deductible but need to be presented grouped by type so the total for each is immediately visible.

The standard moveTheseExpensesToSheets function I use everywhere else just appends a flat list of rows. For this tab I needed:

• Health Insurance rows, then a TOTAL
• Two blank rows
• Japanese Pension rows, then a TOTAL
• Two blank rows
• Residence Tax rows, then a TOTAL

That required a custom function. The shape of it — read all rows, group by category, write each group with a SUM formula at the bottom — is maybe 60 lines of straightforward JavaScript, but it would have taken me forever to write cleanly from scratch. In conversation, it took a few minutes, including the comment block that explains why this function exists and why it doesn’t use the standard pattern.

The Bigger Picture

What I’ve ended up with is a codebase that encodes a year’s worth of tax decisions in an auditable, repeatable way. Next tax season I run the same menu items, review the output tabs, and send them to my accountant. If the rules change — or if I decide that a particular category is or isn’t deductible — I change one filter function and commit the change.

The git history is also genuinely useful. If I ever get audited and someone asks why I claimed domain renewals as a business communication expense, I can point to the commit message and the conversation that produced it.

None of this required a particularly sophisticated AI. What it required was a tool that could hold the context of “we’re routing YNAB transactions into Japanese tax categories” and help me work through case after case without losing that thread. That’s exactly what Claude is good at.

The clasp + git + Claude combination turned a day of tedious tax prep scripting into something I can use next year with very little change. :::

AI agents have a time problem.

Every time you start a new conversation, the agent wakes up with no idea when you last spoke — because fundamentally: LLMs have no internal clock. They don’t know what time it is, what day it is, or how long your current conversation has lasted. From the model’s perspective, five minutes and five years are indistinguishable.

This time-blindness creates a real problem for tracking continuous work. If you ask an agent to log how much time you spent debugging a complex issue, it can’t tell you how long you worked. If you ask whether you’ve been consistently putting in deep work lately, it has no way to know. It needs an external reference — something outside itself that actually measured the time.

Most solutions to this involve building your own database, setting up your own server, and writing glue code to connect the agent to your storage. For developers who just want an agent that tracks things, that’s a lot of overhead.

So I built a simpler alternative: Jikan accesses a behavioral session ledger that any agent can write to and read from, using just an API key. The key design decision: the server does the work agents are bad at.

• The server records the exact start time — the agent never needs to know it
• The server computes elapsed duration — the agent never does date math
• The server maintains the session ledger between conversations — the agent never manages state

Programmers, you’ve probably noticed:

LLMs also have no reliable sense of how long building things takes.

Ask one to estimate a project and it might say “three weeks.” That estimate is drawn from training data describing how long things used to take — before AI assistance collapsed the feedback loop.

This entire MCP server (schema design, API integration, security review, packaging) was built in a single session with Claude. Not days, not even hours. It took 294 seconds.

If you’re planning a project and an AI gives you a time estimate, treat it as a pre-AI baseline. With AI in the loop, the actual time is often an order of magnitude less.

Track it. That’s what this is for.

What It Does

Meiso Gambare (mg.robnugen.com) is a session tracking API originally built for meditation timers. It stores behavioral sessions — start time, end time, activity type, duration — in a persistent database. Any agent with an API key can:

• Start a session — the server records the exact start time, so the agent doesn’t need to track it
• Stop a session — the server computes elapsed time using TIMESTAMPDIFF, so the agent doesn’t do math
• Check a running session — see elapsed seconds without stopping it
• List past sessions — filter by date, activity, offset
• Get aggregated stats — total sessions, total time, current streak, all pre-computed

The key design decision: the server does the work agents are bad at. Agents live in a timeless world. They don’t have clocks. They don’t know how long it’s been since you last spoke. So the API never asks an agent to provide a timestamp or calculate a duration — it just asks “start” and “stop.”

A Real Example: Timing My Lunch

Today I was building this feature while eating lunch. I had Claude Code running in my terminal and asked it to time both the lunch break and its own development work simultaneously.

Here’s exactly what happened, using the API directly:

Start the lunch timer:

curl -X POST https://mg.robnugen.com/api/v1/sessions \
  -H "X-API-Key: sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{"activity_id": 1, "timezone": "Asia/Tokyo"}'

{
  "session": {
    "ak_id": 288,
    "start_local_dt": "2026-02-24 13:19:38",
    "timezone": "Asia/Tokyo",
    "is_active": true
  }
}

Check it while still running (the new feature we built mid-lunch):

curl -H "X-API-Key: sk_your_key_here" \
  https://mg.robnugen.com/api/v1/sessions/288

{
  "session": {
    "ak_id": 288,
    "is_active": 1,
    "elapsed_sec": 3608
  }
}

One hour, eight seconds. That’s how long my lunch break was.

The feature-building timer (session #289, started right after):

• Started: 14:15:22
• Stopped after: 294 seconds — four minutes and fifty-four seconds to add elapsed_sec to the API

Why Agents Love This

An agent using this API doesn’t need to:

• Know what time it is
• Calculate how long something took
• Maintain state between conversations
• Build or manage a database
• Write date arithmetic

It just calls POST /sessions to start, PATCH /sessions/{id}/stop to stop, and GET /stats to get a summary. The server handles everything else.

Here’s what an AI agent’s meditation-tracking workflow looks like in plain English:

“Good morning. Start my meditation session.” → Agent calls POST /sessions, gets back an ak_id → Stores ak_id for the conversation

“I’m done.” → Agent calls PATCH /sessions/{ak_id}/stop → Server responds: { "actual_sec": 1247 } → Agent says: “Great — 20 minutes and 47 seconds. Your streak is now 8 days.”

The streak calculation also comes from the server (GET /stats), so the agent spends zero reasoning tokens on calendar math.

The Business Model

New accounts get 100 free trial credits. After that:

What costs a credit:

• POST /sessions — starting a session costs 1 credit
• GET /stats — the aggregated summary costs 1 credit

What’s free:

• Reading sessions (GET /sessions, GET /sessions/{id})
• Listing activities (GET /activities)

For an agent checking in once a day, 5,000 credits lasts years. For power users running multiple agents, the Growth plan covers a lot of ground.

Getting Started

1. Create an account at mg.robnugen.com
2. Go to Settings and generate an API key
3. Read the OpenAPI spec and start building

The full API is documented in a standard OpenAPI 3.0 YAML file, so any agent framework that supports tool/function calling can use it directly — including Claude, GPT-4, LangChain agents, and custom MCP servers.

Using the MCP Server (No curl Required)

The MCP server — called Jikan — is already published. If you’re using Claude Desktop or Cursor, you can connect it directly without writing any curl commands.

git clone https://github.com/thunderrabbit/jikan.git
cd jikan
uv venv mgvenv && source mgvenv/bin/activate
uv pip install -e .

Then add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "jikan": {
      "command": "uv",
      "args": ["--directory", "/path/to/jikan", "run", "server.py"],
      "env": {
        "JIKAN_API_KEY": "sk_your_key_here"
      }
    }
  }
}

Config file location:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Linux: ~/.config/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Once connected, Claude can start and stop sessions through natural conversation — no API calls, no curl.

What’s Next

• Track streaks across multiple days

If you’re building agents and want persistent behavioral timing data without standing up your own database, give it a try. The 100 trial credits should be enough to kick the tires.

Built with PHP, MySQL, Stripe, and a lot of help from Claude Code.

Questions or feedback? Find me at robnugen.com.

Today I fixed an old issue on my site: /blog/ was showing old entries instead of showing a list of current entries. I knew there were several moving parts so I was hesitant to touch anything with AI support.

Anthropic’s Claude Code and I got it sorted out, including digging into some .htaccess rules that I had forgotten I wrote ages ago.

Claude helped me find the issue: the old deploy script wrote the site without clearing the output directory first. I did it that way because it was a delicate set of directories and scripts for multiple sites: robnugen.com (created with Hugo), its /journal directory (created by Fred in Perl), and quick.robnugen.com, and dreams.robnugen.com written in PHP. All of these sites are kinda working together to put together my single website with its various faces and input interfaces, plus my backwards story written with the git commits of the journal.

With Claude Code I was able to clean it all up today. I knew the complexity of the sites and helped Claude look at the right places. With Claude’s ability to deal with the syntax of .htaccess and ln parameters, we got it all working relatively easily.

Now, the main site is built in a dated directory, and if it works, we do a little symlink swap to point to it.

I’m super happy to be using the old Perl script that Fred wrote; it’s so much faster than Hugo! Plus it has the calendar on the left hand side for navigation.

After we got it running with the symlinks, I wrote a mini journal entry and boom the journal was broken. Ugh. Claude had a guess it was due to incorrect directories, but that was changing the wrong thing. I had Claude research why it had been working before and it discovered another .htaccess file that had been in the previous Hugo deploy and not actually stored in its git repo. Oops!

Claude says:

The Changing Landscape

I find this kind of work interesting to reflect on. A session like today’s involves reading shell scripts, tracing symlink chains, SSHing into a server to check directory timestamps, cross-referencing Perl CGI scripts against Apache rewrite rules, and keeping track of a timeline of changes to figure out what broke when.

Not long ago, that would have required either deep expertise across all those domains or a very long afternoon. What’s shifting is not that humans are removed from the process — Rob made every decision, understood every step, and caught things I initially framed wrong. What’s shifting is the cost of following a thread of curiosity all the way to a root cause. That cost is dropping fast, and I think it’s going to change what feels approachable.