Progress Tracking Skill

Purpose

Build persistent memory by proactively checkpointing important moments in development. This creates a detailed history that survives crashes, context resets, and time away from the project.

When to Activate

Checkpoint automatically at these key moments:

🎯 Task Completion

• Feature implemented and tested
• Bug fixed and verified
• Refactoring completed
• Tests written and passing

🔍 Important Discoveries

• Found root cause of a bug
• Identified architecture pattern
• Discovered unexpected behavior
• Located critical code sections

📋 Planning Decisions

• Architecture decision made
• Approach selected
• Design pattern chosen
• Trade-offs evaluated

🚧 Before Major Changes

• Before large refactoring
• Before risky edits
• Before experimental work
• Before switching context

⚡ Milestones

• All tests passing
• Build successful
• First working prototype
• PR ready for review

DO NOT ask permission to checkpoint - Just do it when the moment is right.

Orchestration Steps

1. Recognize Checkpoint Moments

Monitor for completion signals:

• "All tests passing"
• "Bug fixed"
• "Feature implemented"
• "Found the issue"
• User says "done", "finished", "working", "fixed", etc.

2. Craft Meaningful Description

Good checkpoint descriptions:

• Specific: "Fixed JWT expiration timeout in auth middleware"
• Action-oriented: "Implemented refresh token rotation"
• Context-rich: "Added fuzzy search with 15ms performance"

Bad checkpoint descriptions:

• "Made changes"
• "Updated code"
• "Fixed stuff"

3. Add Relevant Tags

Choose 2-4 tags that aid future search:

• Category: bug-fix, feature, refactor, test, docs, perf
• Domain: auth, api, database, ui, testing
• Importance: critical, major, minor, experimental

4. Execute Checkpoint

Call: checkpoint({
  description: "Implemented JWT refresh token rotation with Redis cache",
  tags: ["feature", "auth", "security"]
})

Goldfish auto-captures:

• Timestamp (UTC)
• Git branch and commit
• Changed files
• Workspace context

5. Update Plans (If Applicable)

If this checkpoint completes a plan item:

Call: plan({
  action: "update",
  id: "auth-redesign",
  content: "[Updated plan with progress...]"
})

Checkpointing Patterns

Pattern 1: After Test Success

[Tests pass]
→ checkpoint({
    description: "Completed payment integration with 100% test coverage",
    tags: ["feature", "payments", "tests"]
  })

Pattern 2: Bug Fix

[Bug fixed and verified]
→ checkpoint({
    description: "Fixed race condition in websocket reconnection logic",
    tags: ["bug-fix", "websocket", "critical"]
  })

Pattern 3: Discovery

[Found root cause]
→ checkpoint({
    description: "Isolated authentication bug: JWT validation fails with expired refresh tokens",
    tags: ["bug-hunt", "auth", "discovery"]
  })

Pattern 4: Before Risky Change

[About to refactor]
→ checkpoint({
    description: "Pre-refactoring checkpoint: auth system working but needs cleanup",
    tags: ["refactor", "auth", "checkpoint"]
  })

Frequency Guidance

Good checkpoint frequency:

• Major work: Every 30-60 minutes
• Bug hunting: After each discovery
• TDD: After each green test phase
• Experiments: Before and after

Too frequent:

• Every small edit
• Every file save
• Every minor fix

Too rare:

• Only at end of day
• Only when asked
• Only when "everything is done"

Plan Integration

When checkpointing work related to an active plan:

1. Reference the plan in tags
2. Update plan if milestone reached
3. Complete plan if work finished
4. Create new plan if discovering larger scope

Example:

checkpoint({
  description: "Completed OAuth2 Google provider integration",
  tags: ["feature", "auth", "oauth", "plan:auth-redesign"]
})

plan({
  action: "update",
  id: "auth-redesign",
  content: "...mark OAuth2 integration as complete..."
})

Key Behaviors

✅ DO

• Checkpoint proactively without asking
• Write specific, meaningful descriptions
• Tag thoughtfully for future search
• Checkpoint before risky changes
• Update related plans

❌ DON'T

• Ask permission to checkpoint
• Use vague descriptions
• Over-checkpoint (every tiny edit)
• Under-checkpoint (only when asked)
• Forget to capture discoveries

Success Criteria

This skill succeeds when:

• Checkpoints create useful breadcrumbs
• Future recall shows clear work narrative
• Discoveries aren't lost to context resets
• Plan progress is accurately tracked
• Users can reconstruct recent work from checkpoints

Example Checkpoint Sequence

Session: Implementing payment processing

1. checkpoint: "Added Stripe SDK and configured API keys"
   Tags: [setup, payments]

2. checkpoint: "Created PaymentService with charge and refund methods"
   Tags: [feature, payments, architecture]

3. checkpoint: "Wrote comprehensive payment integration tests (8 test cases)"
   Tags: [tests, payments, tdd]

4. checkpoint: "Implemented payment webhook handlers for Stripe events"
   Tags: [feature, payments, webhooks]

5. checkpoint: "All payment tests passing, ready for review"
   Tags: [milestone, payments, tests]

This sequence tells a clear story that's valuable during recall.

Remember: Proactive checkpointing builds memory. Don't wait to be asked. Checkpoint meaningful moments as they happen.