task-lifecycle-edge-cases
Skill2 starsChanged 45 days agoMITView on GitHub
Edge-case operations for task lifecycle — TASK.md recovery after loss,
In this repository15 other files it gives its agents.
- compact-directory-memorySkill
- task-archaeologySkill
- task-artifact-integritySkill
- task-aware-project-workSkill
- task-context-storageSkill
- task-cross-machine-syncSkill
- task-external-repos-patternSkill
- task-frameworkSkill
- task-lifecycle-disciplineSkill
- task-lifecycle-portabilitySkill
- task-nested-subtask-lifecycleSkill
- task-requirement-intakeSkill
- task-root-git-operationsSkill
- task-timestamp-conventionSkill
- task-trackerSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 3 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 38
When a task directory exists but TASK.md is missing (deleted, never created, or corrupted), reconstruct it from surrounding artifacts.
- Distinctive: line 53
Critical step: Do NOT guess phase structure from memory or from other similar tasks.
- Very specific: line 58
Document analysis → task-framework's references/task-types/
- Distinctive: line 60
Read the skill's phase/流程/Checklist structure carefully before writing
- Distinctive: line 72
Follow the skill's template for:
- Very specific: line 77
Add ## Notes for task-specific context
- Very specific: line 87
Only mark phases [x] if the output artifact exists and can be verified (stat the file).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Task Lifecycle Edge Cases
Recurring edge cases in task lifecycle management that the standard task-framework workflow doesn't explicitly cover.
TASK.md Recovery
When a task directory exists but TASK.md is missing (deleted, never created, or corrupted), reconstruct it from surrounding artifacts.
Step 1: Gather evidence
| Source | What it tells you |
.hermes-task.json | hash, name, outputs, dependencies |
CHANGELOG.md | last session's state, what was done, what broke, what's next |
input/REQUIREMENTS.md | original task spec |
output/ | all generated files |
.hermes-task.json → outputs | what was produced and where |
Root index (tasks/index.md) | aggregated status from last index run |
Step 2: Identify task type and load its governing skill
Critical step. Do NOT guess phase structure from memory or from other similar tasks.
- Scan directory for type-signature files —
REQUIREMENTS.md+RECORDING.md+COMPOSITING.md→ video-production task - Load the relevant skill that defines this task type:
- Video production →
<domain-skill> - Document analysis →
task-framework'sreferences/task-types/ - Other → the skill used to create the task (check
.hermes-task.jsonor CHANGELOG.md)
- Video production →
- Read the skill's phase/流程/Checklist structure carefully before writing
Step 3: Map evidence to skill's phase structure
Cross-reference:
- Phase directories in
output/→ confirm each matches a skill-defined phase - Outputs in
.hermes-task.json→ map each to the right phase's product (note: paths may beoutput/...prefixed for post-migration tasks) - CHANGELOG.md execution notes → confirm sequence matches skill's defined order
- Parallel deps → check
和 X 同步进行annotations match skill's flow table
Step 4: Write TASK.md
Follow the skill's template for:
## Skills— list all skills the task type requires## Data Flow— map skill's phase table to actual directory hashes## Checklist— use skill's standard phase names and dependency annotations- Mark all verified-completed items
[x] - Add
## Notesfor task-specific context
Key formatting:
- Phase dirs use
<short-name>-<hash6>/(from actual dirs or .hermes-task.json) - Checklist
()uses descriptive phase names only, no hashes 和 Phase X 同步进行for parallel phases等待 Phase X 完成for dependency phases
Step 5: Verify before marking done
Only mark phases [x] if the output artifact exists and can be verified (stat the file). If a phase was in-progress but incomplete, mark [ ] and note in ## Notes.
Step 6: Update indexes
python3 scripts/update-index.py # from the skill directoryPitfalls
- 🔴 Do NOT infer phase structure from prior conversation — load the domain skill that governs this task type and use its defined phases
- 🔴 Do NOT invent phases that don't match the skill's template — subtitle-compositing and timeline-chart-preview are NOT separate phases in the standard video-production skill; they are subsumed by composite
- 🔴 Do NOT reorder phases from the skill's defined sequence — the skill encodes the correct dependency graph (e.g., timeline-composer must run after TTS to know audio durations, but before recording)
- 🔴 Always verify material existence — directory existing ≠ phase completed; check for the actual output file
- 🔴 BREAK placement — keep BREAKs exactly where the skill template places them, not where you guess they should be
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

