TheophilusChinomona Task Journal Skill
Purpose
Persistent task tracking across sessions. Records what was done, what's pending, and what broke — so nothing falls through the cracks when sessions restart or context is compacted.
Activation
- Write: After completing any task, encountering a blocker, or discovering a new issue
- Read: At session start, or when user asks "what's pending?" or "what did we do?"
How It Works
Primary: remember plugin integration
The remember plugin (installed separately) handles session-level persistence via .remember/ in the project root. When available, task-journal reads from and writes alongside the remember plugin's files:
- Read at session start:
.remember/session files provide recent session history - Write task entries: Append to
.claude/idev/task-journal/journal.md(the persistent, human-curated log)
Fallback: standalone journal
When the remember plugin is not installed, task-journal operates standalone using .claude/idev/task-journal/journal.md.
Why two systems?
- remember plugin: automatic session capture, consolidation, compression — system-maintained
- task-journal: manually curated, structured task log — human-maintained for high-signal entries
- They complement each other: remember captures everything, task-journal captures what matters
Journal Format
# Task Journal
Last updated: YYYY-MM-DD HH:mm
## Active / In Progress
- [ ] [FEATURE] Task description
- File: path/to/file
- Status: what's been done so far
- Blocker: what's blocking (if any)
## Completed (Recent)
- [x] [FEATURE] Task description — YYYY-MM-DD
- Files changed: file1, file2, file3
- Summary: one-line summary of what was done
## Known Issues
- [!] [FEATURE] Issue description — YYYY-MM-DD
- File: path/to/file
- Severity: low|medium|high|critical
- Notes: debugging info, what was tried
## Backlog (User Mentioned)
- [ ] [FEATURE] Task description
- Context: what the user said about it
Write Rules
When a task is completed:
1. Move from "Active" to "Completed (Recent)"
2. Add date and files changed
3. Add one-line summary
When a blocker is found:
1. Add to "Known Issues" with severity
2. Update "Active" entry with blocker description
3. Include what was tried and what to check next
When user mentions future work:
1. Add to "Backlog" with the user's context
2. Do NOT start working on backlog items unless user asks
Housekeeping:
- Keep "Completed" list to last 20 entries (archive older ones)
- Keep "Known Issues" until explicitly resolved
- Keep "Backlog" until user addresses or dismisses
- Remove duplicate entries
Read Rules
At session start:
1. Read journal.md (~50-100 lines)
2. If "Active" items exist → inform user
3. If "Known Issues" exist → mention briefly
4. Do NOT read "Completed" unless user asks for history
When user asks "what's pending?":
1. Show "Active" + "Known Issues" + "Backlog"
2. Exclude "Completed"
When user asks "what did we do?":
1. Show "Completed (Recent)"
2. Group by date if multiple sessions
Integration with Other Skills
Task Journal works WITH session-resume AND the remember plugin:
- session-resume = ephemeral (current session snapshot, overwritten each time)
- task-journal = persistent (rolling log across all sessions)
- remember plugin = automatic session capture and consolidation
Workflow:
1. Session starts → load session-resume (what was I doing?)
2. Session starts → load task-journal (what's the big picture?)
3. Session starts → remember plugin provides recent session history
4. Task done → update task-journal (log it)
5. Session ends → update session-resume (snapshot current state)
6. Session ends → remember plugin captures session for future reference
Anti-Patterns
- Do NOT write to journal for trivial actions (reading files, searching)
- Do NOT duplicate the same entry multiple times
- Do NOT let the journal grow beyond ~150 lines (archive old completed items)
- Do NOT use the journal as a substitute for actually reading code
- Do NOT auto-generate backlog items — only log what the user explicitly mentions