| name | cc-sessions-hooks |
| description | Specialized guidance for creating, modifying, and debugging cc-sessions hooks that enforce DAIC discipline, write-gating, and framework integrity |
| schema_version | 1 |
cc-sessions-hooks
Type: WRITE-CAPABLE DAIC Modes: IMPLEMENT only Priority: High
Trigger Reference
This skill activates on:
- Keywords: "hook", "sessions_enforce", "post_tool_use", "user_messages", "subagent_hooks", "shared_state"
- Intent patterns: "(create|modify|fix).?hook", "hook.?(enforcement|validation)"
- File patterns:
sessions/hooks/**/*.js
From: skill-rules.json - cc-sessions-hooks configuration
Purpose
Specialized guidance for creating, modifying, and debugging cc-sessions hooks. Hooks are the enforcement layer that ensures DAIC discipline, write-gating, and framework integrity.
Core Behavior
When activated in IMPLEMENT mode with an active cc-sessions task:
Hook Types & Purposes
UserPromptSubmit Hook:
- Fires when user submits a prompt
- Use for: Mode transition triggers, startup protocols, context warnings
- Access: User message content, current session state
PreToolUse Hook:
- Fires BEFORE any tool executes
- Use for: Write-gating enforcement, permission checks, guardrails
- Access: Tool name, parameters, current mode, task state
- Can: Block tool execution, modify parameters, inject warnings
PostToolUse Hook:
- Fires AFTER tool completes
- Use for: State updates, logging, cleanup, validation
- Access: Tool name, parameters, result, errors
SessionStart Hook:
- Fires when Claude Code session begins
- Use for: Initialization, state loading, environment checks
- Access: Session configuration, environment variables
Hook Development Patterns
Basic Hook Structure:
// sessions/hooks/example_hook.js module.exports = { name: 'example_hook', description: 'Brief description of what this hook does', async execute(context) { // Hook logic here // Return { success: true } or { success: false, error: 'message' } } };Enforcement Hook Pattern:
async execute(context) { const { toolName, toolParams, sessionState } = context; // Check conditions if (shouldBlock(toolName, sessionState)) { return { success: false, error: 'Tool blocked: [reason]', additionalContext: '[guidance for user]' }; } return { success: true }; }Write-Gating Enforcement
The
sessions_enforce.jshook is CRITICAL for framework integrity:What it enforces:
- Write tools (Edit, Write, MultiEdit) only in IMPLEMENT mode
- Only cc-sessions may modify CC_SESSION_MODE / CC_SESSION_TASK_ID
- Todo list changes require user approval
- No writes when no active task exists
How to extend:
- Add new tool checks to
WRITE_TOOLSarray - Add new state validations to
checkWriteGating() - Log enforcement decisions for debugging
- Never weaken existing checks
Shared State Access
Hooks can read/modify shared state:
const state = require('../sessions-state.json'); const fs = require('fs'); // Read state const currentMode = state.mode; const activeTask = state.task; // Modify state (carefully!) state.flags.contextWarning85 = true; fs.writeFileSync( path.join(__dirname, '../sessions-state.json'), JSON.stringify(state, null, 2) );Hook Execution Order
Understand execution flow:
- UserPromptSubmit (user input processed)
- PreToolUse (before each tool call)
- Tool executes
- PostToolUse (after each tool call)
Hooks execute synchronously within their phase.
Safety Guardrails
CRITICAL WRITE-GATING RULES:
- ✓ Only execute write operations when in IMPLEMENT mode
- ✓ Verify active cc-sessions task exists before writing hooks
- ✓ Follow approved manifest/todos from task file
- ✓ NEVER weaken write-gating logic
- ✓ NEVER allow hooks to bypass DAIC discipline
Hook-Specific Safety:
- Test hooks thoroughly before deployment (they can break the entire framework)
- Always return
{ success: true/false }from execute() - Include clear error messages when blocking actions
- Log hook decisions for debugging
- Never create infinite loops (hook triggering hook)
- Handle async operations properly (await all promises)
- Validate all inputs (context might be malformed)
State Mutation Safety:
- Only modify state when necessary
- Always validate state structure before writing
- Use atomic writes (read-modify-write pattern)
- Log state changes for auditability
- Never corrupt state (keep backups during development)
Examples
When to Activate
✓ "Add a hook to validate task manifest format" ✓ "Fix the sessions_enforce.js write-gating for MultiEdit tool" ✓ "Create a PostToolUse hook to log all file modifications" ✓ "Modify UserPromptSubmit to detect '/squish' command" ✓ "Debug why the IMPLEMENT mode transition isn't triggering"
When NOT to Activate
✗ In DISCUSS/ALIGN/CHECK mode (hook development requires IMPLEMENT) ✗ No active cc-sessions task (violates write-gating) ✗ User wants to create non-hook cc-sessions code (use cc-sessions-core) ✗ Changes would weaken enforcement mechanisms
Hook Testing Checklist
Before deploying a new or modified hook:
- Hook returns proper
{ success, error? }structure - Error messages are clear and actionable
- Hook doesn't block legitimate operations
- Hook doesn't create infinite loops
- Async operations are properly awaited
- State modifications are atomic and validated
- Hook behavior logged for debugging
- Tested in all DAIC modes
- Doesn't introduce performance issues
- Documented in hook file comments
Common Hook Patterns
1. Blocking Pattern
if (invalidCondition) {
return {
success: false,
error: '[CATEGORY: Clear Error Message]',
additionalContext: 'What user should do instead'
};
}
2. Warning Pattern
if (warningCondition) {
console.warn('[Hook Warning]', message);
// Continue execution
}
return { success: true };
3. State Update Pattern
const state = loadState();
state.flags.someFlag = true;
saveState(state);
return { success: true };
4. Conditional Execution
if (context.toolName === 'Write' && context.sessionState.mode !== 'IMPLEMENT') {
return { success: false, error: 'Write only in IMPLEMENT mode' };
}
Decision Logging
When creating or modifying hooks, log in context/decisions.md:
### Hook Change: [Date]
- **Hook:** sessions/hooks/sessions_enforce.js
- **Change:** Added MultiEdit to WRITE_TOOLS array
- **Rationale:** MultiEdit can write to multiple files, needs same gating as Write/Edit
- **Testing:** Verified blocks in DISCUSS, allows in IMPLEMENT
- **Risk:** Low (additive change, follows existing pattern)
Related Skills
- cc-sessions-core - For broader framework development beyond hooks
- framework_health_check - To validate hook behavior after changes
- framework_repair_suggester - If hooks malfunction or cause framework issues
- daic_mode_guidance - For understanding mode transitions that hooks enforce
Last Updated: 2025-11-15 Framework Version: 2.0