cc-sessions-hooks

grandinh's avatarfrom grandinh

Specialized guidance for creating, modifying, and debugging cc-sessions hooks that enforce DAIC discipline, write-gating, and framework integrity

⭐1stars🔀0forks📁View on GitHub🕐Updated Nov 17, 2025

When & Why to Use This Skill

The cc-sessions-hooks skill provides specialized guidance for creating, modifying, and debugging lifecycle hooks within the cc-sessions framework. It acts as a critical enforcement layer to maintain framework integrity, implement strict write-gating, and ensure adherence to DAIC (Discuss, Align, Implement, Check) discipline. By managing hooks like PreToolUse and PostToolUse, it allows developers to build robust safety guardrails and state management protocols for agentic workflows.

Use Cases

  • Implementing write-gating logic to prevent unauthorized file modifications when the agent is not in IMPLEMENT mode.
  • Creating PreToolUse hooks to validate tool parameters and inject security checks or permission prompts before execution.
  • Developing PostToolUse hooks to automate state updates, logging, and validation after a tool completes its task.
  • Setting up UserPromptSubmit hooks to detect specific intent patterns and trigger automated mode transitions or context warnings.
  • Debugging framework integrity issues by analyzing hook execution order and ensuring atomic state mutations across shared session data.
namecc-sessions-hooks
descriptionSpecialized guidance for creating, modifying, and debugging cc-sessions hooks that enforce DAIC discipline, write-gating, and framework integrity
schema_version1.0

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:

  1. 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
  2. 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 };
    }
    
  3. Write-Gating Enforcement

    The sessions_enforce.js hook 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_TOOLS array
    • Add new state validations to checkWriteGating()
    • Log enforcement decisions for debugging
    • Never weaken existing checks
  4. 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)
    );
    
  5. Hook Execution Order

    Understand execution flow:

    1. UserPromptSubmit (user input processed)
    2. PreToolUse (before each tool call)
    3. Tool executes
    4. 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)
  • 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