Building TimeBlocker Part 2: Skills, Memory, and Claude Code Workflow

Part 1 covered the documentation-first approach and agent setup. Today I refined the workflow with something I didn’t anticipate: the distinction between agents and skills.

The Agents vs Skills Question

Claude Code has two ways to extend its capabilities: agents (via the Task tool) and skills (slash commands). After setting up seven specialized agents, I asked myself: should everything be an agent?

The answer is no. Here’s the distinction I landed on:

Agents are heavy. They spin up a subprocess, carry specialized context, and are designed for substantial work. The Convex backend agent knows the schema, understands offline-first constraints, and can implement entire features.

Skills are light. They’re instructions for common tasks that don’t need isolated context. Running lint, creating commits, scaffolding components.

14 Skills for TimeBlocker

Based on this distinction, I created skills for the repetitive stuff:

Session Management:

/status         → Quick status check
/session-start  → Initialize with full context
/session-end    → Save progress for next time

Development:

/dev     → Start all apps
/check   → Run lint + typecheck
/commit  → Semantic commits
/sync    → Convex schema sync

Scaffolding:

/convex-fn         → Generate Convex function
/svelte-page       → Scaffold SvelteKit route
/svelte-component  → Create Svelte 5 component
/tauri-cmd         → Rust command + TypeScript IPC

Release:

/release       → Version bump + changelog
/deploy-web    → Deploy to Vercel
/build-desktop → Build Tauri app

Each skill is a markdown file with instructions. The /tauri-cmd skill, for example, includes the exact Rust boilerplate, how to register commands in main.rs, and the TypeScript bridge pattern. No more looking up “how do I add a Tauri command” every time.

The Memory Problem

Here’s a problem I didn’t anticipate: Claude Code doesn’t remember between sessions.

If I spend three hours implementing Phase 2, close the terminal, and come back tomorrow, Claude has no idea where we left off. I’d have to re-explain the entire project state. That’s a waste of context tokens and my time.

Solution: a status file.

STATUS.yaml

I created .claude/STATUS.yaml as persistent memory:

current_phase: 1
phase_name: "Monorepo Foundation"
phase_status: not_started

in_progress: null
blockers: null

phases:
  1_monorepo:
    status: not_started
    tasks:
      - "Initialize pnpm workspace"
      - "Create turbo.json"
      - "Set up shared TypeScript config"
    commit_msg: "chore: set up monorepo with Turborepo"

  2_convex:
    status: not_started
    # ... all 20 phases

completed_phases: []
decisions: []
tech_debt: []

next_steps:
  - "Start Phase 1: Initialize pnpm workspace"

last_session:
  date: "2026-01-15"
  summary: "Set up skills and status tracking system"

The workflow is now:

1. Session start: Claude reads STATUS.yaml, reports state
2. During work: Updates in_progress, tracks blockers
3. After implementation: Updates completed tasks immediately
4. Session end: Saves summary and next steps

The key insight: update after every implementation, not just at session end. If I complete a task and close the terminal unexpectedly, progress isn’t lost.

Skills for Memory

The memory system got its own skills:

• /status - “Where are we?” in 2 lines
• /session-start - Full context report at session beginning
• /session-end - Save everything before closing

Now starting a session is just /session-start. Ending one is /session-end. No manual bookkeeping.

Instructions That Persist

I updated CLAUDE.md with the session protocol:

## Session Memory Protocol

**At the start of every session:**
1. Read `.claude/STATUS.yaml`
2. Report: current phase, in-progress work, next steps
3. Ask if Master wants to continue

**During the session:**
- Update `in_progress` when starting a task
- Track blockers immediately
- **After ANY implementation**: Update STATUS.yaml

**At the end of the session:**
1. Update phase completion status
2. Note what was accomplished
3. Set next steps

This gets loaded automatically. Every session, Claude knows the protocol.

The Real Workflow

After today’s refinements, the development workflow is:

Session Start
    │
    ▼
┌─────────────────────┐
│  /session-start     │  ← Loads STATUS.yaml, reports state
└─────────────────────┘
    │
    ▼
┌─────────────────────┐
│  Implementation     │  ← Agent does the work
└─────────────────────┘
    │
    ▼
┌─────────────────────┐
│  Update STATUS.yaml │  ← Record progress immediately
└─────────────────────┘
    │
    ▼
┌─────────────────────┐
│  /commit            │  ← Semantic commit
└─────────────────────┘
    │
    ▼
┌─────────────────────┐
│  /session-end       │  ← Save state for next time
└─────────────────────┘

Skills handle the ceremony. Agents handle the substance.

What I Learned

Agents and skills serve different purposes. Don’t make everything an agent. The overhead isn’t worth it for simple, repetitive tasks.

Memory needs to be explicit. AI assistants don’t remember. Build memory into your workflow with persistent files and clear protocols.

Update immediately, not later. The habit of “I’ll update the status later” leads to lost progress. Record completion as it happens.

Current State

Phase 1: Monorepo Foundation - not_started
Next: Initialize pnpm workspace

The infrastructure is ready. Documentation, agents, skills, memory system - all in place. Tomorrow, actual code.

Part 2 of the TimeBlocker build series. Part 3 will cover Phase 1: setting up the monorepo with Turborepo and pnpm.