From arcforge
Captures structured session reflections as diary entries for a learning cycle (diary → reflect → instincts). Useful for recording decisions, challenges, preferences, and discoveries after significant work sessions.
How this skill is triggered — by the user, by Claude, or both
Slash command
/arcforge:arc-journalingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Capture session reflections as structured diary entries for the **learning cycle** (diary → reflect → instincts). This is for deliberate reflection and pattern extraction — NOT for session continuity. For saving/resuming work across sessions, use `/arc-managing-sessions save` and `/arc-managing-sessions resume` instead.
Capture session reflections as structured diary entries for the learning cycle (diary → reflect → instincts). This is for deliberate reflection and pattern extraction — NOT for session continuity. For saving/resuming work across sessions, use /arc-managing-sessions save and /arc-managing-sessions resume instead.
| Task | Command |
|---|---|
| Get diary path | node "${SKILL_ROOT}/scripts/diary.js" path --project {p} --date {d} --session {s} |
| Save diary | node "${SKILL_ROOT}/scripts/diary.js" save --project {p} --date {d} --session {s} --content "{content}" |
| Key principle | Reflect from memory, NOT by reading files |
| Permission | NEVER auto-save - always ask first |
| Template location | See "Template" section below |
Node.js utilities handle file paths and directory creation. Optional but recommended.
Set SKILL_ROOT from skill loader header (# SKILL_ROOT: ...):
: "${SKILL_ROOT:=${ARCFORGE_ROOT:-}/skills/arc-journaling}"
if [ ! -d "$SKILL_ROOT" ]; then
echo "ERROR: SKILL_ROOT=$SKILL_ROOT does not exist. Set ARCFORGE_ROOT or SKILL_ROOT manually." >&2
exit 1
fi
Save diary to correct location:
node "${SKILL_ROOT}/scripts/diary.js" save \
--project {project} \
--date {YYYY-MM-DD} \
--session {sessionId} \
--content "{diary_content}"
Verify path (for debugging):
node "${SKILL_ROOT}/scripts/diary.js" path \
--project {project} \
--date {YYYY-MM-DD} \
--session {sessionId}
Core distinction:
arcforge learn dashboard — combines related instincts into a successor candidate)Storage: ~/.arcforge/diaries/{project}/{YYYY-MM-DD}/diary-{sessionId}.md
Before creating a diary entry, verify at least ONE of these criteria is met:
Auto-skip these sessions (no diary needed):
This is a soft gate: Claude judges based on conversation memory. User can always override by invoking arc-journaling explicitly.
/arcforge:arc-journalingReview the conversation from memory. DO NOT read files to gather context.
Ask yourself:
Use this diary template:
# Session Diary: {project}
**Date:** {YYYY-MM-DD}
**Session ID:** {sessionId}
## Decisions Made
- [Decision]: [Rationale]
## User Preferences Observed
- [Preference observed]
## What Worked Well
- [Technique or approach that succeeded]
## Challenges & Solutions
- **Challenge**: [What went wrong]
- **Solution**: [How resolved]
- **Generalizable?**: [Yes/No - pre-flags for arc-reflecting]
## PR/Review Feedback (if any)
- [Feedback]: [Action taken]
## Context for Next Session
- [Key context to remember]
---
_Captured at {timestamp}_
~/.arcforge/diaries/{project}/{date}/diary-{sessionId}.mdAfter saving, briefly mention:
"Diary saved. If you noticed reusable patterns, run
/arcforge:arc-reflectingto extract them."
Record what happened, not rules. Patterns that should become rules belong in arc-reflecting.
Focus on WHY decisions were made, not just WHAT was done.
Keep entries focused. Don't over-document routine work.
Wrong: Reading project files to "understand" what to write Right: Reflect on conversation memory only
Wrong: "Changed line 42 of app.js to use const" Right: "Decided to prefer const over let for immutability"
Wrong: Diary for "fixed a typo" session Right: Skip diary, or note "No significant reflections this session"
Wrong: Same pattern in both diary and instinct Right: Diary captures context; learn extracts reusable pattern
Wrong: Auto-saving without confirmation Right: Present draft, ask "Should I save this diary entry?"
Wrong: Leaving Generalizable? empty or omitting it Right: Always mark solutions as Yes/No - helps arc-reflecting identify patterns
| Variable | Source |
|---|---|
{project} | CLAUDE_PROJECT_DIR or path.basename(process.cwd()) |
{YYYY-MM-DD} | Current date |
{sessionId} | CLAUDE_SESSION_ID or generated |
{timestamp} | ISO timestamp |
~/.arcforge/diaries/{project}/{YYYY-MM-DD}/
└── diary-{sessionId}.md # Diary entry (from arc-journaling)
~/.arcforge/sessions/{project}/{YYYY-MM-DD}/
└── {sessionId}.json # Session data (auto-generated)
Diary files live under ~/.arcforge/diaries/ (not ~/.claude/sessions/)
because Claude Code v2.1.78+ blocks subprocess writes to ~/.claude/.
The Stop-hook background enricher needs to be able to write there.
# Session Diary: my-api-project
**Date:** 2025-01-24
**Session ID:** abc123-def456
## Decisions Made
- Chose PostgreSQL over MySQL: JSON column support needed for flexible schema
- Connection pooling with PgBouncer: scalability requirement for multi-tenant
## User Preferences Observed
- Prefers explicit error handling over try-catch blocks
- Likes detailed commit messages with context
## What Worked Well
- TDD approach helped catch edge case early
- Breaking large migration into smaller steps
## Challenges & Solutions
- **Challenge**: Docker networking issues blocked local development
- **Solution**: Used host network mode instead of bridge
- **Generalizable?**: Yes - applies to any Docker-based local dev
- **Challenge**: Prisma limitation with composite keys
- **Solution**: Workaround using @@id directive with custom naming
- **Generalizable?**: No - specific to this Prisma version
## PR/Review Feedback (if any)
- "Add rollback logic to migration": Added down() method to all migration files
## Context for Next Session
- Migration is half-complete; start with users table
- Test database needs to be reset before next run
---
_Captured at 2025-01-24T15:30:00Z_
npx claudepluginhub gregoryho/arcforge --plugin arcforgeGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.