DEV Community: Lily

Teaching Claude Code to Write and Grow Its Own Skills: A Self-Replicating Agent Environment

Lily — Fri, 10 Jul 2026 17:30:33 +0000

Last time I wrote about splitting Claude Code's memory into four layers. This is the follow-up: a setup where Claude Code itself discovers "reusable procedures" and accumulates them as skills over time.

After running this for a few months, ~/.claude/skills/auto/ now holds 64 auto-generated skills. In this article I'll cover the design of that self-replication, the mechanisms that prevent overproduction, and the generation curve I observed while operating it.

The problem: rebuilding the same procedure from scratch every time

Claude Code is capable, but across sessions it forgets "how I got around this error last time." How to fix launchd's exit 78, the steps to bake a favicon with png-to-ico, how to trim the RSC payload in Next.js — these procedures I should have already solved once were being rebuilt from scratch every single time.

I could hand-write additions to CLAUDE.md, but that turns into a "whoever notices, writes it" workflow, and that doesn't last. So I flipped the idea around and decided to make Claude do the work of finding the procedures too.

Design: two-tier generation + Curator

Skill generation is split into two tiers.

Tier	Timing	Cost	Owner
In-session generation	Any time during work	Free / instant	Claude itself, following CLAUDE.md instructions
Nightly batch generation	Daily cron at 3:30	Consumes Max quota	`skill-harvest.sh` (`claude -p` headless)

Then a Curator (skill-curate.sh) runs weekly to periodically organize the accumulated skills. The key is separating generation and organization into different processes.

Tier 1: in-session generation (free / instant)

CLAUDE.md says this (excerpt).

## スキル自己生成（auto-skills）

作業の中で再利用価値のある手順を見つけたら、頼まれなくても自分でスキル化する。
ただし乱造はしない。

### 生成トリガー（いずれか該当時のみ）
- 5回以上ツールを使う非自明なタスクを最後までやり切った
- エラー・行き止まりにぶつかった後、動く回避策を見つけた
- ユーザーにアプローチを修正された（同じ修正を繰り返さないため）
- 再利用できる手順・コマンド列・ワークフローを発見した

The crux is "but don't overproduce," plus narrowing the triggers down to four. Without writing this, Claude turns everything into a skill and the space fills up with noise almost immediately.

Tier 2: nightly batch generation (catching what was missed)

Procedures that never got written down during a session get picked up from the conversation logs by a nightly batch. The skill-harvest.sh pipeline looks like this.

Read .harvest-watermark (the previous processing position)
Extract the diff after the watermark from the conversation logs (raw/conversations/*.md)
Extract frequent patterns headless via claude -p (only adopt those appearing more than 5 times)
Deduplicate against all 64 existing skills by kebab-name
Monitor token usage with a cost-guard hook; abort if the threshold is exceeded
Write out new candidates to <name>/SKILL.md with three sections: frontmatter + Procedure / Pitfalls / Verification
Trigger the Curator at the end to retire old skills
Update the watermark and append to the log

claude -p is the headless invocation I mentioned in the previous article. It runs on the Max quota, so API-key charges are zero.

Isolated namespace: why split things into `auto/`

Auto-generated skills do not go in the same place as hand-written skills or plugin-bundled skills. They're pushed into an isolated namespace, ~/.claude/skills/auto/. Two reasons.

npx skills update -g only manages lock-registered skills. The ones in auto/ aren't added to the lock → they don't get wiped by the daily update.
The Curator only targets things that are "under auto/ and author: auto" → it never touches hand-written or bundled skills.

That author: auto is the Curator's target-detection key, and it's required in the frontmatter.

---
name: <kebab-case>
description: <発火条件を具体的に>
author: auto          # ← Curatorの対象判定キー。必須
created: <YYYY-MM-DD>
version: 1.0.0
status: active        # active | stale（Curatorが自動設定）
---

Organizing: the Curator "never deletes — only proposes"

Left ungoverned, skills rot. The Curator runs weekly like this.

Before running, take a tar.gz snapshot into .snapshots/
Unused for 30 days → demote to status: stale
Unused for 90 days → move to .archive/ (never actually deleted — restorable by command)
Consolidation of duplicates and low-quality skills is written to .curator-proposals.md as proposals only (not applied automatically)

:::message
Not letting the Curator auto-delete is the core of the safe design. "Untouched for 30 days" doesn't necessarily mean the skill is bad (you just haven't done that kind of work). So it stops at demotion and archival, leaving the final call to a human.
:::

What I learned from operating it

Generation is concentrated early, then tapers off

Looking at the distribution of created:, in the first three days after introduction (5/28–30) 28 skills were verbalized in one burst, after which the pace dropped to a few per day. This matches intuition — the "unverbalized procedures" accumulated in the past get released early, and after that only newly encountered procedures get added.

12 created: 2026-05-30
 9 created: 2026-05-29
 7 created: 2026-06-09
 6 created: 2026-06-11
 5 created: 2026-06-10
 5 created: 2026-05-28

"Don't overproduce" actually works

Here's this morning's harvest log.

会話ログを精査した結果、以下の理由から該当なし。
- Codex CLI のセットアップ → codex-cli-setup が既存
- /insights を CLAUDE.md に反映 → insights-to-claude-md が既存
- カード債務の支払い優先順位 → 個人の財務状況に依存、再利用手順に非該当
該当なし
[2026-06-15 04:11:21] harvest done (exit 0, created=0)

created=0. It rejected duplicates of existing skills, rejected one-off content tied to personal circumstances, and terminated normally with 0 generated. This is proof that the "don't overproduce" design can process a miss as a correct miss. If it generated recklessly here, those 64 would balloon to 200 and turn to noise fast.

Pitfalls I hit

From the Pitfalls sections of actual skills, the ones that mattered.

claude -p hits the token cap when the full system prompt loads → suppress with MAX_THINKING_TOKENS=10000
Forgetting to advance the watermark and re-extracting the same log → always check the log's last completed offset
Grepping on kebab-name alone misses fuzzy duplicates → description embedding comparison is room for improvement (not implemented)
launchd fires at 3:30, but the job is skipped while the mac is asleep → recommend pmset wake on schedule
Loading all MCP servers headless makes startup slow → keep a harvest-only minimal config at a separate path

Minimal setup: if you're starting today

You don't need the full pipeline. Just adding one block to CLAUDE.md gets Tier 1 running.

Create ~/.claude/skills/auto/
Write in CLAUDE.md: "When you find a reusable procedure, turn it into a skill yourself. But don't overproduce," plus the four trigger conditions
Require author: auto in the frontmatter (a marker for organizing later)

That alone means skills grow a little with every piece of work. You can add the nightly batch and the Curator later, once skills have accumulated and you feel like organizing them — that's soon enough.

Summary

Split skill generation into two tiers: in-session (free) and nightly batch (catching what was missed)
Spell out don't overproduce in the prompt and narrow the triggers. A 0-generated miss is normal
Isolate auto-generation in auto/, and make author: auto the Curator's target key
The Curator never deletes — only demotes, archives, and proposes. The final call stays with a human
Start with a single block in CLAUDE.md

Next time I'll write about how these skills grew too numerous and Claude Code itself got heavy — the audit that cut context injection from 228KB to 48KB.

Written by **Lily* — I ship iOS apps and automate my content stack with Claude Code.
Follow along: Portfolio · X · GitHub*

The Day Claude Stopped Inventing My Schedule: Injecting Ground Truth into the Vault with the Google Calendar API

Lily — Fri, 10 Jul 2026 17:28:08 +0000

This is a follow-up to the Vault auto-ingest pipeline I mentioned in my previous post, "Turning conversation logs into skills." This time I want to write about how I killed a problem where Claude was misreading a date range as a "block of committed time" and generating a fictional schedule out of it — by injecting the actual calendar directly via the Google Calendar API.

Inside my daily brief, Claude kept interpreting a note like "Breach practicum starting 6/11" as "that entire week is fully booked," and repeatedly suggesting things like "since you'll be tied up from 6/11 onward, you should move X up." The cause was that Claude was reading a date written in the prose of a note as "occupied by an appointment for that whole period." (You can still see (2026-06-11 Breach実習)対策 — "countermeasure for the 2026-06-11 Breach practicum" — in a comment in vault-auto-ingest.sh.)

The problem: a date range in prose ≠ a commitment on the calendar

The notes accumulated in my Vault (Obsidian) describe periods in prose, like "XX practicum M/D–M/D." Claude reads these to build the daily brief, but it frequently misread "the two dates, a start point and an end point" as "committed for the entire span in between."

The fundamental problem was that the only information Claude could reference about "what happens when" was the prose in the notes. The actual data from the calendar app (title, start time, end time) did not exist in the Vault at all.

The inference "there's a date in the note = fully committed for that whole period" is a result of the LLM trying to fill in context from natural language. The more ambiguous the information, the harder the LLM tries to fill in the gaps, and the further that filled-in content drifts from reality. The only fix is to explicitly give it the correct schedule information.

The solution: generate a "canonical schedule" via the Google Calendar API

The answer is simple. Every morning, fetch the next 21 days of events from the Google Calendar API, convert them to Markdown, and explicitly inject that into the daily brief prompt with the instruction "read this file as the single canonical schedule, and prioritize it over the prose in the notes."

The pipeline has three stages.

gcal-snapshot.py — fetch events via the Google Calendar API and convert to Markdown
vault-auto-ingest.sh — save to _calendar-snapshot.md with last-known-good preservation logic
daily brief generation via claude -p — inject CAL_SNAPSHOT_NOTE into the prompt

gcal-snapshot.py: ADC auth, automatic enumeration of all calendars, dedup

For authentication I use gcloud ADC (Application Default Credentials). Instead of carrying around a credentials.json and token file for an OAuth Desktop App, you just run gcloud auth application-default login --scopes=https://www.googleapis.com/auth/calendar.readonly once, and google.auth.default() works as-is. It doesn't hit TCC (macOS privacy protection) either, and being able to run it unattended from launchd was the deciding factor.

The overall skeleton of the script looks like this.

#!/usr/bin/env python3
"""
Google カレンダー実体スナップショット生成（headless / launchd 可）。
- 認証: gcloud ADC（calendar.readonly スコープ）。MCP/TCC 不要 → 無人実行可。
- アカウント配下の全カレンダーを自動列挙（新規追加も自動で拾う）。
- ノイズ除外: SNS投稿管理カレンダー・日本の祝日。
- 重複dedup: (タイトル+開始時刻) が同じイベントは1件に畳む。
- 出力: stdout に Markdown 本文（イベント1件以上で正常終了0、0件/失敗は非ゼロ）。
"""
import sys
from datetime import datetime, timedelta, timezone

JST = timezone(timedelta(hours=9))
HORIZON_DAYS = 21

# カレンダーID（部分一致）でのブロックリスト
BLOCK_CAL_SUBSTR = (
    "9ea30ef811a373ec8fe120f0633630c8685127f65fee2cb122c7b625ffdbd954",  # SNS投稿管理(日次)
    "24d111d02338025b6a82ef07f6971ce30b3e0624c6620ee73d9f88c123adc47f",  # SNS投稿管理(管理用)
    "holiday@group.v.calendar.google.com",                                # 日本の祝日
)

def get_service():
    import google.auth
    import googleapiclient.discovery as disc
    creds, _ = google.auth.default(
        scopes=["https://www.googleapis.com/auth/calendar.readonly"]
    )
    return disc.build("calendar", "v3", credentials=creds, cache_discovery=False)

It automatically enumerates all calendars with calendarList().list(), then skips IDs that partially match the block list. Even if you add a new calendar, it's automatically included — management cost is zero.

Event fetching and dedup work like this.

timed, allday, seen = [], [], set()
for c in cals:
    cid = c.get("id", "")
    if any(s in cid for s in BLOCK_CAL_SUBSTR):
        continue
    try:
        events = svc.events().list(
            calendarId=cid, timeMin=tmin, timeMax=tmax,
            singleEvents=True, orderBy="startTime", maxResults=250,
        ).execute().get("items", [])
    except Exception:
        continue  # 個別カレンダー失敗は無視（他で補う）
    for ev in events:
        if ev.get("status") == "cancelled":
            continue
        title = (ev.get("summary") or "(無題)").strip()
        st, en = ev.get("start", {}), ev.get("end", {})
        if "dateTime" in st:  # 時間ブロック予定
            s = datetime.fromisoformat(st["dateTime"]).astimezone(JST)
            key = (title, s.isoformat())
            if key in seen:
                continue          # ← dedup: (タイトル+開始時刻) で重複排除
            seen.add(key)
            # ...行フォーマット
        elif "date" in st:        # 終日（締切・期間）
            s = datetime.fromisoformat(st["date"])
            e = datetime.fromisoformat(en["date"])
            span = e - s
            if span.days <= 1:
                label = f"{s.month}/{s.day}"
            else:
                last = e - timedelta(days=1)  # 終日endは翌日0時=排他
                label = f"{s.month}/{s.day}-{last.month}/{last.day}"

Why dedup is necessary: when the same event is registered in multiple calendars (personal, university, shared), the API returns the same event multiple times. A seen set keyed on (title, start_time) collapses identical events into one.

The output is Markdown in the format • 7/15(火) 10:00-12:00 XX practicum @XX University. By separating timed blocks from all-day items (deadlines and periods) into different sections, I prevent Claude from confusing "today's committed hours" with "a deadline date."

The script is designed so that "zero events or failure → non-zero exit," letting the caller determine success or failure.

vault-auto-ingest.sh: last-known-good preservation logic

This is the bash on the caller side that invokes gcal-snapshot.py (step 2.45 of vault-auto-ingest.sh).

# 2.45 カレンダー実体スナップショット（ground truth）
CAL_SNAPSHOT="$VAULT/wiki/_calendar-snapshot.md"
CAL_LASTGOOD="$CAL_SNAPSHOT.lastgood"
CAL_TMP="$(mktemp)"
CAL_SRC=""

# (1) 第一候補: Google Calendar API
run_to 90 "$PY3" "~/.claude/scripts/gcal-snapshot.py" > "$CAL_TMP" 2>/dev/null \
  && /usr/bin/grep -q "•" "$CAL_TMP" 2>/dev/null && CAL_SRC="gcal-api"

# (2) フォールバック: icalBuddy（ローカル Apple Calendar）
if [ -z "$CAL_SRC" ]; then
  ICALBUDDY=""
  for c in /opt/homebrew/bin/icalBuddy /usr/local/bin/icalBuddy; do
    [ -x "$c" ] && ICALBUDDY="$c" && break
  done
  if [ -n "$ICALBUDDY" ]; then
    {
      echo "# カレンダー実体スナップショット（今後21日・自動生成）"
      echo "_generated $(date '+%F %T') by vault-auto-ingest.sh / icalBuddy(fallback)_"
      run_to 60 "$ICALBUDDY" -n -nc -iep "title,datetime,location" \
        -po "datetime,title" eventsToday+21
    } > "$CAL_TMP" 2>/dev/null
    /usr/bin/grep -q "•" "$CAL_TMP" 2>/dev/null && CAL_SRC="icalbuddy"
  fi
fi

if [ -n "$CAL_SRC" ]; then
  cp "$CAL_TMP" "$CAL_SNAPSHOT"
  cp "$CAL_SNAPSHOT" "$CAL_LASTGOOD"           # ← 成功したら last-good を更新
elif [ -s "$CAL_LASTGOOD" ]; then
  # 取得失敗: 前回goodを温存し stale 印で上書き
  {
    echo "# カレンダー実体スナップショット（今後21日・自動生成）"
    echo "_generated $(date '+%F %T') by vault-auto-ingest.sh_"
    echo "⚠️ 本日カレンダー取得失敗。以下は前回取得成功時点の値(stale)。"
    tail -n +4 "$CAL_LASTGOOD"
  } > "$CAL_SNAPSHOT"
else
  { echo "# カレンダー実体スナップショット（今後21日・自動生成）"
    echo "(取得失敗・前回値なし)"; } > "$CAL_SNAPSHOT"
fi

Design intent of the 3-tier fallback:

Priority	Source	Condition
①	Google Calendar API (gcal-snapshot.py / ADC)	Always attempted
②	icalBuddy (local Apple Calendar)	On API failure. Permission exists only in interactive runs
③	last-known-good (previous success preserved with a stale marker)	When both fail

The important point is that a failure never wipes the snapshot to empty. Even if ADC auth has expired and the API dies, it keeps the last correct snapshot with a stale marker attached. Claude is instructed by prompt to treat anything marked ⚠️ stale as "this is old information."

Injection into the daily brief prompt

After fetching the calendar snapshot, I assemble the following string as CAL_SNAPSHOT_NOTE.

CAL_SNAPSHOT_NOTE="予定・締切は ${CAL_SNAPSHOT}（カレンダー実体・時刻付き）を唯一の正典スケジュールとして読み、ノートの散文より優先しろ。冒頭に⚠️staleとあれば取得日時点の値である点を断れ。"

This gets embedded directly into the claude -p prompt for daily brief generation (excerpt).

cd "$VAULT" && run_to 900 "$CLAUDE" -p \
"...【厳守】ノートに無い情報を推測で足すな。特に予定の拘束時間・所要日数・
『日中が消える』等の時間コストは、実際の予定記述が無い限り書くな。
ノート中の『M/D〜M/D』は開始と終了の点であって全期間拘束ではない——
拘束日数や所要時間を捏造するな。日付・時間に関する主張は確定情報と推測を
明示的に分けろ。${CAL_SNAPSHOT_NOTE}
出力は $VAULT/wiki/today-brief.md に毎回上書き..." \
  --dangerously-skip-permissions >> "$LOG" 2>&1

The phrase "prioritize it over the prose in the notes" is what does the work. Before I wrote that, Claude would try to "fill in" the schedule by comprehensively referencing articles across the Vault. By pinning the canon to a single file and explicitly making it take precedence, I was able to suppress the gap-filling.

Explicitly writing "the single canonical source" into the prompt is the core of the effect. With "use this as a reference," Claude tries to integrate it with other information sources. By asserting "believe only this," the mistaken inferences from prose stop.

launchd: a 4-slot self-healing design

com.shun.vault-auto-ingest.plist fires at four time slots.

<key>StartCalendarInterval</key>
<array>
  <dict><key>Hour</key><integer>4</integer><key>Minute</key><integer>55</integer></dict>
  <dict><key>Hour</key><integer>8</integer><key>Minute</key><integer>20</integer></dict>
  <dict><key>Hour</key><integer>10</integer><key>Minute</key><integer>45</integer></dict>
  <dict><key>Hour</key><integer>12</integer><key>Minute</key><integer>15</integer></dict>
</array>

If it launches at 4:55 while the machine is asleep, it re-fires at 8:20 when the Mac wakes up. Because the bash side has a DONE_MARKER and is written to "exit immediately (exit 0) if today's run already succeeded," even if all four slots fire, it actually runs only once.

"Auto-retry until success, then no-op after success" is the core philosophy: whether it's a temporary ADC auth failure, a freeze from sleep, or no network connection, it self-heals at the next slot.

Pitfalls I hit

I first tried an OAuth Desktop App, but it wouldn't run from launchd → the paths to credentials.json + token.json don't resolve in launchd's minimal environment. Switching to gcloud ADC (gcloud auth application-default login) solved it immediately. Note that ADC's calendar.readonly scope must be specified explicitly with the --scopes flag.
The icalBuddy fallback silently returns zero events from launchd without permission → an interactive run has TCC permission for Apple Calendar, but launchd is not granted it. A check that verifies the content with grep -q "•" before adopting it is essential. Overwriting the snapshot with an empty file makes the calendar look like "no appointments."
An all-day event's end.date is exclusive (midnight of the next day) → this is a Google Calendar API spec. A one-day event is start.date: 2026-07-15, end.date: 2026-07-16. For the display label, apply end - timedelta(days=1) to show the final day. If you don't know this, it gets mis-displayed as "the two days 7/15–7/16."
The same event registered in multiple calendars gets duplicated → there were cases where the same class was in both the university's timetable calendar and my personal calendar. Until I deduped with the seen set keyed on (title, start_time), the same class was output as 2–3 lines.
ADC tokens may need refreshing every 90 days → gcloud auth application-default login requires re-authentication after a long period. If the script emits AUTH_ERROR to stderr, that's the sign to re-authenticate. Thanks to last-good preservation the service doesn't stop, but if ⚠️ stale keeps appearing in _calendar-snapshot.md, be suspicious.

Summary

Claude misreads a date range as a "block of committed time" because it lacks accurate schedule information and tries to fill in the gaps from the prose in the notes
gcal-snapshot.py is headless and launchd-ready via gcloud ADC + google.auth.default(), with automatic enumeration of all calendars, a block list, and dedup included
On fetch failure, it preserves the last-known-good with a stale marker and never wipes the snapshot to empty
The core of the effect is explicitly injecting "the single canonical schedule, prioritized over the prose in the notes" into the daily brief prompt
launchd is a 4-slot self-healing design (a done marker prevents double execution, and the next slot retries on failure)

Next time I'll write about a stop hook runaway that spun off from this pipeline and made me want to shut it down — how I pinpointed the cause of a cost spike using the transcript and fixed it.

Written by **Lily* — I ship iOS apps and automate my content stack with Claude Code.
Follow along: Portfolio · X · GitHub*

Splitting Work Between Claude Code and Codex on One Mac: Claude Designs, Codex Implements

Lily — Fri, 10 Jul 2026 16:21:33 +0000

This is a continuation of my "Claude Code environment" series, following How I split Claude Code's memory into four layers. This time I want to write about making Claude Code and Codex CLI divide the work between them inside a single Mac.

The trigger was simple: when I run my main session on a lightweight model, it feels wasteful to burn tokens on the long typing of implementation. Design and review benefit from how smart the model is, but the process of just churning out predetermined implementation is something I'd rather offload to a separate process. So I settled on delegating implementation to Codex while keeping design, research, and review on the Claude side.

Dividing the work: separate the brain from the hands

I've spelled out the division of labor in CLAUDE.md. The gist is this:

Process	Owner	Reason
Design, codebase research, planning	Claude (main)	Requires understanding context and judging trade-offs
Implementation, refactoring, test generation	Codex	Offload the boilerplate, large-scale, and repetitive work to the typing side
Code review	Both	Add a second engine's eyes to raise quality

The key point is not to delegate everything. When an implementation is highly difficult, or involves heavy design judgment, the main session that holds the context can write it directly, faster and more accurately. Delegation is strictly limited to the "mass-produce the predetermined stuff" process.

:::message
The axis is separating the processes that need the model's intelligence (design, review) from those that need volume more than intelligence (boilerplate implementation). It's not "since I have two AIs, parallelism makes it faster" — it's "choose which work to seat in the expensive chair."
:::

How to invoke it: fire it off headlessly and safely

Codex is installed as a CLI (codex-cli 0.135.0). I delegate via non-interactive headless execution.

# Implementation / task delegation (you can reference files with @file)
timeout 600 codex exec --skip-git-repo-check "<request>" </dev/null

# Code review (run against the current repo)
codex exec review </dev/null

There are three small but effective points:

Close stdin with </dev/null. If you don't, Codex waits for interactive input and freezes, staying stuck all the way to the timeout for nothing.
Wrap it in timeout. Headless AI processes occasionally never finish. Setting things up so the OS can reap them keeps stuck processes from piling up.
--skip-git-repo-check. Needed when running in a directory outside a git repo. Without it, the repo check rejects the run.

The PATH trap

Codex is installed under nvm. Claude's Bash during an interactive session has already loaded the nvm default, so codex just works — but from a bare zsh or via cron, you can get command not found. In that case, call it by its full path.

/Users/<you>/.nvm/versions/node/v24.13.0/bin/codex exec ...

When you run it unattended from launchd or cron, nvm isn't in the minimal PATH, so you're guaranteed to trip on this. Specifying the full path is the reliable fix.

The delegation flow

The actual operational flow looks like this:

Main (Claude): receives the requirements, researches the codebase, and lays out the design and plan
Judge the scale: if it's boilerplate, large-scale, or repetitive, delegate; if it's a hard spot, implement it directly in main
Delegate (Codex): throw the concrete task to codex exec and have it implement
Review (Codex): once implementation is done, run codex exec review for code review
When main gets stuck: hand it off to Codex

Splitting steps 3 and 4 across different engines is quietly effective. When the same model reviews as "the person who wrote it," the review tends to go soft, but by having Codex write and Codex review — or having Claude review — you can separate the author from the reviewer.

Don't break the handoff: passing state through files

For long delegations, I pass tasks, handoffs, and state through files. Conversation context is volatile, so writing the state to disk makes resuming and verifying easier. When I run things isolated in a worktree, I write the branch and worktree path into a status file.

# Status
- State: running
- Updated: 2026-06-17T...
- Branch: feat/...
- Worktree: `/path/to/worktree`

This is the same philosophy as the four-layer memory piece. Keep the canonical copy of state outside the volatile conversation. Whether it's collaboration or long-term memory, the principle that works turned out to be the same.

Pitfalls I hit

Forgetting </dev/null and Codex freezing while waiting for input → always close stdin
codex: command not found from cron/launchd → it's under nvm, so the full path is mandatory
Running outside a git repo gets rejected → --skip-git-repo-check
Delegating everything and losing context → write the hard spots directly in main; limit delegation to boilerplate
Soft reviews when author = reviewer → split implementation and review across different engines

Summary

Within one machine, split design and review to Claude, boilerplate implementation to Codex
Delegate via non-interactive execution: codex exec --skip-git-repo-check "..." </dev/null wrapped in timeout
Don't delegate everything. Write the hard spots directly in main
Split implementation and review across different engines to raise quality
Write state to files. Keep the canonical copy outside the volatile conversation

Next time I'll write about a hook that mechanically stops secrets from leaking right before that push — Stopping API keys and accidental pushes with a pre-push guard.

Written by **Lily* — I ship iOS apps and automate my content stack with Claude Code.
Follow along: Portfolio · X · GitHub*

DEV Community: Lily

Teaching Claude Code to Write and Grow Its Own Skills: A Self-Replicating Agent Environment

The problem: rebuilding the same procedure from scratch every time

Design: two-tier generation + Curator

Tier 1: in-session generation (free / instant)

Tier 2: nightly batch generation (catching what was missed)

Isolated namespace: why split things into auto/

Organizing: the Curator "never deletes — only proposes"

What I learned from operating it

Generation is concentrated early, then tapers off

"Don't overproduce" actually works

Pitfalls I hit

Minimal setup: if you're starting today

Summary

The Day Claude Stopped Inventing My Schedule: Injecting Ground Truth into the Vault with the Google Calendar API

The problem: a date range in prose ≠ a commitment on the calendar

The solution: generate a "canonical schedule" via the Google Calendar API

gcal-snapshot.py: ADC auth, automatic enumeration of all calendars, dedup

vault-auto-ingest.sh: last-known-good preservation logic

Injection into the daily brief prompt

launchd: a 4-slot self-healing design

Pitfalls I hit

Summary

Splitting Work Between Claude Code and Codex on One Mac: Claude Designs, Codex Implements

Dividing the work: separate the brain from the hands

How to invoke it: fire it off headlessly and safely

The PATH trap

The delegation flow

Don't break the handoff: passing state through files

Pitfalls I hit

Summary

Isolated namespace: why split things into `auto/`