Skip to content

Instantly share code, notes, and snippets.

@SoMaCoSF
Created December 22, 2025 19:59
Show Gist options
  • Select an option

  • Save SoMaCoSF/aaf152a4d9da38632f6bb133809dfc52 to your computer and use it in GitHub Desktop.

Select an option

Save SoMaCoSF/aaf152a4d9da38632f6bb133809dfc52 to your computer and use it in GitHub Desktop.
Claude Code Project Framework - File headers, agent tracking, slash commands, and failure prevention for AI-assisted development

Claude Code Project Framework

A comprehensive framework for maintaining clean, organized, and recoverable AI-assisted development projects. This system provides standardized file headers, agent tracking, slash commands, and failure prevention protocols.


System Architecture Overview

flowchart TB
    subgraph Workspace["Workspace Root"]
        CLAUDE["CLAUDE.md<br/>(Rules & Standards)"]

        subgraph Commands[".claude/commands/"]
            CMD1["/project-status"]
            CMD2["/stats"]
            CMD3["/db-inspect"]
            CMD4["/new-project"]
            CMD5["/preflight-check"]
            CMD6["/think"]
        end

        subgraph Projects["outputs/"]
            subgraph Project1["project-name/"]
                README["README.md"]
                DIARY["development_diary.md"]
                UNDERSTAND["understandings.md"]
                VENV[".venv/"]
                TESTS["tests/"]
                LOGS["logs/"]

                subgraph DB["database/context/"]
                    AGENT_DB["agent_context.db"]
                    TASKS_DB["project_tasks.db"]
                end
            end
        end
    end

    CLAUDE --> Commands
    CLAUDE --> Projects
    Commands --> Project1
Loading

Why This Framework?

The Problem

flowchart LR
    subgraph Problems["Common AI Development Issues"]
        P1["Lost Context<br/>Between Sessions"]
        P2["No File<br/>Provenance"]
        P3["No Crash<br/>Recovery"]
        P4["Inconsistent<br/>Structure"]
        P5["Untracked<br/>AI Changes"]
    end

    P1 --> CHAOS["Project Chaos"]
    P2 --> CHAOS
    P3 --> CHAOS
    P4 --> CHAOS
    P5 --> CHAOS
Loading

The Solution

flowchart LR
    subgraph Solutions["Framework Components"]
        S1["File Headers<br/>(Ghost Catalog)"]
        S2["Agent IDs<br/>(Tracking)"]
        S3["SQLite DBs<br/>(Recovery)"]
        S4["Slash Commands<br/>(Automation)"]
        S5["Failure Protocols<br/>(Prevention)"]
    end

    S1 --> ORDER["Organized<br/>Projects"]
    S2 --> ORDER
    S3 --> ORDER
    S4 --> ORDER
    S5 --> ORDER
Loading

Ghost Catalog: File Header System

The "Ghost Catalog" is a metadata system embedded in every file header, creating a searchable index without a separate database.

Header Structure

classDiagram
    class FileHeader {
        +string file_id
        +string name
        +string description
        +string project_id
        +string category
        +array tags
        +date created
        +date modified
        +string version
        +Agent agent
        +Execution execution
    }

    class Agent {
        +string id
        +string name
        +string model
    }

    class Execution {
        +string type
        +string invocation
    }

    FileHeader --> Agent
    FileHeader --> Execution
Loading

File ID Format

SOM-<CATEGORY>-<SEQUENCE>-v<VERSION>
 │       │          │         │
 │       │          │         └── Semantic version (1.0.0)
 │       │          └── Sequential number (0001-9999)
 │       └── Category code (CMD, SCR, DOC, etc.)
 └── Namespace prefix (Somacosf)
flowchart LR
    subgraph FileID["File ID: SOM-CMD-0005-v1.2.0"]
        NS["SOM"]
        CAT["CMD"]
        SEQ["0005"]
        VER["v1.2.0"]
    end

    NS --- |"Namespace"| CAT
    CAT --- |"Category"| SEQ
    SEQ --- |"Sequence"| VER
Loading

Category Codes

graph TB
    subgraph Categories["File Categories"]
        CMD["CMD<br/>Slash Commands"]
        SCR["SCR<br/>Scripts"]
        DOC["DOC<br/>Documentation"]
        CFG["CFG<br/>Configuration"]
        TST["TST<br/>Tests"]
        DTA["DTA<br/>Data/Schemas"]
        LOG["LOG<br/>Logs/Diaries"]
        REG["REG<br/>Registry Files"]
        TMP["TMP<br/>Templates"]
    end
Loading

Header Examples

Markdown/Documentation:

<!--
===============================================================================
file_id: SOM-DOC-0001-v1.0.0
name: README.md
description: Project overview and setup instructions
project_id: MY-PROJECT
category: documentation
tags: [readme, setup, overview]
created: 2025-01-19
modified: 2025-01-19
version: 1.0.0
agent:
  id: AGENT-PRIME-001
  name: agent_prime
  model: claude-sonnet-4-5-20250929
execution:
  type: documentation
  invocation: Read for project context
===============================================================================
-->

Python:

# ==============================================================================
# file_id: SOM-SCR-0042-v2.1.0
# name: data_processor.py
# description: ETL pipeline for customer data
# project_id: DATA-PIPELINE
# category: script
# tags: [etl, data, processing]
# created: 2025-01-15
# modified: 2025-01-19
# version: 2.1.0
# agent_id: AGENT-WORKER-003
# execution: python data_processor.py --input data.csv
# ==============================================================================

PowerShell:

# ==============================================================================
# file_id: SOM-SCR-0010-v1.0.0
# name: setup.ps1
# description: Environment setup script
# project_id: DEVOPS
# category: script
# tags: [setup, powershell, automation]
# created: 2025-01-19
# modified: 2025-01-19
# version: 1.0.0
# agent_id: AGENT-PRIME-001
# execution: .\setup.ps1 -Environment dev
# ==============================================================================

Catalog Benefits

flowchart TB
    subgraph Benefits["Why Ghost Catalog?"]
        B1["Instant Search<br/>grep -r 'file_id:'"]
        B2["AI Attribution<br/>Track agent work"]
        B3["Version History<br/>In-file versioning"]
        B4["Tag Discovery<br/>Find related files"]
        B5["Audit Trail<br/>Created/modified dates"]
    end

    B1 --> USE["Practical<br/>Daily Use"]
    B2 --> USE
    B3 --> USE
    B4 --> USE
    B5 --> USE
Loading

Agent ID System

flowchart TB
    subgraph AgentTypes["Agent Designations"]
        PRIME["AGENT-PRIME-NNN<br/>Primary orchestrators"]
        WORKER["AGENT-WORKER-NNN<br/>Task specialists"]
        REVIEW["AGENT-REVIEW-NNN<br/>Code reviewers"]
        TEST["AGENT-TEST-NNN<br/>Test writers"]
    end

    subgraph Sessions["Session Tracking"]
        REG["Register Agent"]
        WINDOW["Create Activity Window"]
        LOG["Log Actions"]
        SNAP["Context Snapshots"]
        END["End Session"]
    end

    PRIME --> REG
    WORKER --> REG
    REVIEW --> REG
    TEST --> REG

    REG --> WINDOW --> LOG --> SNAP --> END
Loading

Agent ID Format

AGENT-<DESIGNATION>-<SEQUENCE>
   │        │            │
   │        │            └── Sequential number (001-999)
   │        └── Role designation (PRIME, WORKER, REVIEW, etc.)
   └── Fixed prefix

Context Database Schema

erDiagram
    agents ||--o{ activity_windows : "has"
    activity_windows ||--o{ action_log : "contains"
    activity_windows ||--o{ context_snapshots : "has"

    agents {
        string id PK "AGENT-PRIME-001"
        string name "agent_prime"
        string model "claude-opus-4-5"
        string role "Primary orchestrator"
        datetime last_active_at
        string status "active|inactive"
    }

    activity_windows {
        int id PK
        string agent_id FK
        datetime started_at
        datetime ended_at
        string session_summary
        string status "active|completed|interrupted"
    }

    action_log {
        int id PK
        int window_id FK
        string agent_id FK
        string action_type "read_file|edit_file|bash_command"
        string action_summary
        string target
        string result "success|failure|partial"
        json context
        datetime timestamp
    }

    context_snapshots {
        int id PK
        int window_id FK
        string agent_id FK
        string current_task
        json pending_items
        json files_modified
        json decisions_made
        json blockers
        json next_steps
        datetime timestamp
    }
Loading

Task Database Schema

erDiagram
    tasks ||--o{ handoffs : "may have"

    tasks {
        int id PK
        string project_id
        string title
        string description
        string priority "critical|high|medium|low"
        string status "pending|in_progress|completed"
        string created_by
        string checked_out_by
        datetime checked_out_at
        string completed_by
        datetime completed_at
        boolean is_deleted
        datetime deleted_at
    }

    handoffs {
        int id PK
        string from_agent
        string to_agent
        string message_type "task_delegation|status_update|error_report"
        string message
        datetime timestamp
        datetime acknowledged_at
    }
Loading

Crash Recovery Flow

sequenceDiagram
    participant Agent as New Agent Session
    participant DB as agent_context.db
    participant User as User/System

    Agent->>DB: Check for interrupted sessions
    DB-->>Agent: Found: window_id=42, status='active'

    Agent->>DB: Get last context snapshot
    DB-->>Agent: Snapshot: task="Implementing auth", files=["auth.py"]

    Agent->>DB: Get recent actions
    DB-->>Agent: Last 20 actions with targets and results

    Agent->>User: "Found interrupted session. Resume?"
    User-->>Agent: "Yes, continue"

    Agent->>DB: Update window status, continue work
    Agent->>DB: Log new actions
Loading

Failure Prevention Architecture

Based on research: "How Do LLMs Fail In Agentic Scenarios?" (Kamiwaza AI, 2025)

flowchart TB
    subgraph Failures["Four Failure Archetypes"]
        F1["PREMATURE ACTION<br/>Acting without verifying"]
        F2["OVER-HELPFULNESS<br/>Inventing missing data"]
        F3["CONTEXT POLLUTION<br/>Similar name confusion"]
        F4["FRAGILE EXECUTION<br/>Loops & coherence loss"]
    end

    subgraph Preventions["Prevention Protocols"]
        P1["GROUND BEFORE ACTION<br/>Read before edit<br/>Schema before query"]
        P2["NEVER SUBSTITUTE<br/>Return null/0<br/>ASK if uncertain"]
        P3["EXACT MATCHING<br/>Flag similar names<br/>Verify targets"]
        P4["CHECKPOINT OFTEN<br/>Every 3 actions<br/>Stop after 3 failures"]
    end

    F1 --> P1
    F2 --> P2
    F3 --> P3
    F4 --> P4
Loading

Grounding Protocol

flowchart LR
    subgraph Ground["Before Any Action"]
        A1["DB Query?"] --> V1["Check Schema First"]
        A2["File Edit?"] --> V2["Read File First"]
        A3["API Call?"] --> V3["Check Docs First"]
        A4["Using Name?"] --> V4["Verify Exact Match"]
    end

    V1 --> PROCEED["Proceed with Action"]
    V2 --> PROCEED
    V3 --> PROCEED
    V4 --> PROCEED
Loading

Recovery Protocol

flowchart TB
    ERROR["Error Occurred"] --> DIAGNOSE["1. Diagnose Root Cause"]
    DIAGNOSE --> VERIFY["2. Re-verify/Ground"]
    VERIFY --> CORRECT["3. Correct Approach"]
    CORRECT --> VALIDATE["4. Validate Result"]

    VALIDATE --> |"Success"| CONTINUE["Continue Work"]
    VALIDATE --> |"Fail (attempt < 3)"| DIAGNOSE
    VALIDATE --> |"Fail (attempt >= 3)"| STOP["STOP & Reassess"]
Loading

Slash Commands Flow

flowchart TB
    subgraph Commands["Available Commands"]
        C1["/project-status<br/>Quick health check"]
        C2["/stats<br/>Detailed report"]
        C3["/db-inspect<br/>Database queries"]
        C4["/new-project<br/>Scaffold project"]
        C5["/preflight-check<br/>Agent alignment"]
        C6["/think<br/>Toggle thinking"]
    end

    USER["User types /command"] --> CLAUDE["Claude reads<br/>.claude/commands/command.md"]
    CLAUDE --> EXECUTE["Executes instructions"]
    EXECUTE --> OUTPUT["Formatted output"]
Loading

Project Structure

flowchart TB
    subgraph Workspace["somacosf/"]
        CLAUDE_MD["CLAUDE.md"]

        subgraph DotClaude[".claude/"]
            subgraph Cmds["commands/"]
                C1["project-status.md"]
                C2["stats.md"]
                C3["db-inspect.md"]
                C4["new-project.md"]
                C5["preflight-check.md"]
                C6["think.md"]
            end
        end

        subgraph Outputs["outputs/"]
            subgraph Proj["project-name/"]
                README["README.md"]
                DIARY["development_diary.md"]
                UNDER["understandings.md"]

                subgraph DBDir["database/context/"]
                    ADB["agent_context.db"]
                    TDB["project_tasks.db"]
                end

                VENV[".venv/"]
                TESTS["tests/"]
                LOGS["logs/"]
            end
        end
    end
Loading

Session Workflow

sequenceDiagram
    participant User
    participant Agent
    participant CtxDB as agent_context.db
    participant TaskDB as project_tasks.db

    Note over Agent: Session Start
    Agent->>CtxDB: Register/update agent
    Agent->>CtxDB: Create activity_window
    Agent->>CtxDB: Check interrupted sessions

    loop Work Loop
        User->>Agent: Request task
        Agent->>CtxDB: Log action (read_file)
        Agent->>Agent: Process
        Agent->>CtxDB: Log action (edit_file)

        alt Every 10-15 actions
            Agent->>CtxDB: Create context_snapshot
        end
    end

    Note over Agent: Session End
    Agent->>CtxDB: Update window (completed)
    Agent->>User: Session summary
Loading

Quick Start

  1. Copy CLAUDE.md to your workspace root
  2. Create .claude/commands/ directory
  3. Copy slash commands to the commands directory
  4. Initialize databases (optional):
    python database/context/init_context_db.py
  5. Run preflight at session start:
    /preflight-check
    

Files in This Gist

File Purpose
README.md This guide with diagrams
CLAUDE.md Main rules and standards
commands/project-status.md Quick project health check
commands/stats.md Detailed project report
commands/db-inspect.md Database inspection
commands/new-project.md Project scaffolding
commands/preflight-check.md Agent alignment
commands/think.md Toggle thinking mode

License

MIT - Use freely, attribution appreciated.


Credits

Developed for the Somacosf workspace with Claude Code assistance.

Failure prevention protocols based on: "How Do LLMs Fail In Agentic Scenarios?" (Kamiwaza AI, 2025)

Somacosf Workspace

Development workspace for multi-stack projects with Claude Code assistance.

Workspace Structure

somacosf/
├── outputs/          # All project folders (LAN-shared as \\hostname\outputs)
├── scripts/          # Setup, utilities, maintenance scripts
├── templates/        # Project boilerplates
└── .claude/commands/ # Custom slash commands

Environment

  • Platform: Windows 10/11
  • PowerShell: 7.0+
  • Python: 3.12+
  • Package Manager: uv (NEVER use pip directly)
  • File Search: Everything CLI at C:\Program Files\Everything\es.exe

MANDATORY Coding Standards

1. File Operations

ALWAYS make a backup before editing any file:

# Before editing example.py:
Copy-Item example.py example.py.bk

Version every file with a header comment including:

  • File name
  • Version number (semver)
  • Last modified date
  • Brief description

2. Standard File Header (Catalog Schema)

All created/modified files MUST include this header format for catalog integration.

For Markdown/documentation:

<!--
===============================================================================
file_id: SOM-XXX-NNNN-vX.X.X
name: filename.md
description: What this file does
project_id: PROJECT-TYPE
category: category_name
tags: [tag1, tag2, tag3]
created: YYYY-MM-DD
modified: YYYY-MM-DD
version: X.X.X
agent:
  id: AGENT-XXX-NNN
  name: agent_name
  model: model_id
execution:
  type: type_of_file
  invocation: how to use/run this file
===============================================================================
-->

For Python:

# ==============================================================================
# file_id: SOM-SCR-NNNN-vX.X.X
# name: script.py
# description: What this script does
# project_id: PROJECT-TYPE
# category: script
# tags: [tag1, tag2]
# created: YYYY-MM-DD
# modified: YYYY-MM-DD
# version: X.X.X
# agent_id: AGENT-XXX-NNN
# execution: python script.py [args]
# ==============================================================================

For PowerShell:

# ==============================================================================
# file_id: SOM-SCR-NNNN-vX.X.X
# name: script.ps1
# description: What this script does
# project_id: PROJECT-TYPE
# category: script
# tags: [tag1, tag2]
# created: YYYY-MM-DD
# modified: YYYY-MM-DD
# version: X.X.X
# agent_id: AGENT-XXX-NNN
# execution: .\script.ps1 [-Param value]
# ==============================================================================

File ID Format: SOM-<CATEGORY>-<SEQUENCE>-v<VERSION>

Code Category
CMD Slash commands
SCR Scripts
DOC Documentation
CFG Configuration
REG Registry files
TST Tests
TMP Templates
DTA Data/schemas
LOG Logs/diaries

See agent_registry.md for complete ID system and file catalog.

3. Virtual Environments

ALWAYS work inside a virtual environment.

Create with uv:

uv venv .venv
.venv\Scripts\activate.ps1

Install packages:

uv pip install package-name

NEVER use bare pip install.

4. Command Chaining (Windows)

ALWAYS use semicolons (;) for command chaining. NEVER use &&.

# CORRECT:
mkdir logs; cd logs; New-Item log.txt

# WRONG - DO NOT USE:
mkdir logs && cd logs && New-Item log.txt

5. Check Before Doing

ALWAYS verify state before making changes:

  • Check if file exists before creating
  • Check if directory exists before writing
  • Check venv is activated before installing
  • Check database schema before queries
  • Read file content before editing

6. Logging

All scripts must include proper logging:

import logging

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
    handlers=[
        logging.FileHandler('logs/script_name.log'),
        logging.StreamHandler()
    ]
)
logger = logging.getLogger(__name__)

Log files go in <project>/logs/.

7. Test-Driven Development

Write tests first, then implementation:

  • Create tests/ directory in each project
  • Use pytest for Python projects
  • Name test files test_<module>.py
  • Run tests before committing

8. Development Diary

Maintain development_diary.md in each project root:

# Development Diary

## 2025-01-19

### Session: [Brief description]
- **Agent**: Claude
- **Duration**: [time]
- **Tasks completed**:
  - Task 1
  - Task 2
- **Decisions made**:
  - Decision 1: Reasoning
- **Issues encountered**:
  - Issue and resolution
- **Next steps**:
  - Pending item 1

Update this diary at the start and end of each work session.


Project Conventions

New Projects

  1. Create in outputs/<project-name>/
  2. Initialize with:
    • README.md (project overview)
    • development_diary.md
    • .venv/ (via uv)
    • logs/
    • tests/

Database Projects

  • Use SQLite for local databases
  • Schema in database/schema.sql
  • Include diary_entries table for operation logging

Active Projects

  • somaco_clean: File discovery/deduplication TUI (PowerShell + Python)

Path Patterns to Exclude

When searching or processing, always exclude:

  • **/node_modules/**
  • **/.git/**
  • **/.venv/**, **/venv/**, **/cleanup_env/lib/**
  • **/__pycache__/**
  • **/*.bk (backup files)

Quick Reference

Task Command
Create venv uv venv .venv
Activate venv .venv\Scripts\activate.ps1
Install package uv pip install <pkg>
Run tests pytest tests/
Chain commands cmd1; cmd2; cmd3

Remember

  1. Backup before edit (.bk)
  2. Headers on all files
  3. Work in venv
  4. Use uv, not pip
  5. Log everything
  6. Test first
  7. Update diary
  8. Check then do
  9. LOG CONTEXT TO DATABASE (see below)
  10. Register agent session on start
  11. GROUND BEFORE ACTION - verify schema/file/API before operating
  12. NEVER SUBSTITUTE - if missing, return 0/null or ASK

MANDATORY: Agent Context Logging

CRITICAL: All agents MUST log their activity to SQLite databases for crash recovery and session continuity. This is NON-NEGOTIABLE.

Context Databases

Located in: <project>/database/context/

Database Purpose
agent_context.db Agent registry, activity windows, action log, context snapshots
project_tasks.db Task management (CRUD, soft-delete only, full history)

Agent Session Protocol

On Session Start (MANDATORY):

  1. Register/Update Agent in Database

    -- In agent_context.db
    INSERT OR REPLACE INTO agents (id, name, model, role, last_active_at, status)
    VALUES ('AGENT-XXX-NNN', 'agent_name', 'model_id', 'role description', datetime('now'), 'active');
  2. Create Activity Window

    INSERT INTO activity_windows (agent_id, session_summary, status)
    VALUES ('AGENT-XXX-NNN', 'Brief description of planned work', 'active');
    -- Store the returned window_id for logging actions
  3. Check for Interrupted Sessions

    SELECT * FROM activity_windows WHERE agent_id = 'AGENT-XXX-NNN' AND status = 'active';
    -- If found, review context_snapshots and action_log to resume

Action Logging (During Session)

Log Every Significant Action:

INSERT INTO action_log (window_id, agent_id, action_type, action_summary, target, result, context)
VALUES (
    <window_id>,
    'AGENT-XXX-NNN',
    'read_file',           -- action_type: read_file, edit_file, bash_command, search, decision, thought, error
    'Read CLAUDE.md to understand workspace standards',  -- action_summary
    'D:\somacosf\CLAUDE.md',  -- target
    'success',             -- result: success, failure, partial
    '{"reasoning": "Needed to understand file header format"}'  -- context (JSON)
);

Action Types:

Type When to Log
read_file After reading any file
edit_file After modifying any file
bash_command After executing shell commands
search After glob/grep searches
decision When making architectural or design decisions
thought Important reasoning or analysis
error When encountering errors or blockers

Context Snapshots (Every 10-15 Actions or Major Milestone)

INSERT INTO context_snapshots (window_id, agent_id, current_task, pending_items, files_modified, decisions_made, blockers, next_steps)
VALUES (
    <window_id>,
    'AGENT-XXX-NNN',
    'Current task description',
    '["item1", "item2"]',           -- JSON array
    '["file1.py", "file2.ts"]',     -- JSON array
    '["Used X instead of Y because..."]',  -- JSON array
    '["Waiting on user input for..."]',    -- JSON array
    '["Next: implement Z", "Then: test"]'  -- JSON array
);

Session End Protocol

On Session End or Before Terminal Close:

UPDATE activity_windows
SET ended_at = datetime('now'),
    status = 'completed',
    session_summary = 'Final summary of work done'
WHERE id = <window_id>;

Crash Recovery

When starting a new session, ALWAYS check for interrupted sessions:

-- Find unfinished sessions for this agent
SELECT aw.*,
       (SELECT COUNT(*) FROM action_log WHERE window_id = aw.id) as action_count
FROM activity_windows aw
WHERE aw.agent_id LIKE 'AGENT-%'
  AND aw.status = 'active'
ORDER BY aw.started_at DESC;

-- Get last context snapshot
SELECT * FROM context_snapshots
WHERE window_id = <interrupted_window_id>
ORDER BY timestamp DESC LIMIT 1;

-- Get recent actions
SELECT * FROM action_log
WHERE window_id = <interrupted_window_id>
ORDER BY timestamp DESC LIMIT 20;

Task Management Protocol

Agents interact with project_tasks.db for coordinated work:

Check Out a Task:

UPDATE tasks SET
    checked_out_at = datetime('now'),
    checked_out_by = 'AGENT-XXX-NNN',
    status = 'in_progress',
    updated_at = datetime('now'),
    updated_by = 'AGENT-XXX-NNN'
WHERE id = <task_id> AND checked_out_by IS NULL;

Create a Task:

INSERT INTO tasks (project_id, title, description, priority, created_by)
VALUES ('AEGIS', 'Task title', 'Description', 'high', 'AGENT-XXX-NNN');

Complete a Task:

UPDATE tasks SET
    status = 'completed',
    completed_at = datetime('now'),
    completed_by = 'AGENT-XXX-NNN',
    checked_out_by = NULL,
    updated_at = datetime('now'),
    updated_by = 'AGENT-XXX-NNN'
WHERE id = <task_id>;

NEVER Delete Tasks - Use soft delete:

UPDATE tasks SET
    is_deleted = 1,
    deleted_at = datetime('now'),
    deleted_by = 'AGENT-XXX-NNN'
WHERE id = <task_id>;

Multi-Agent Coordination

Use handoffs table for agent communication:

-- Send handoff message
INSERT INTO handoffs (from_agent, to_agent, message_type, message)
VALUES (
    'AGENT-PRIME-002',
    'AGENT-WORKER-001',  -- NULL for broadcast
    'task_delegation',   -- status_update, task_delegation, error_report, context_share
    'Please complete the API integration task'
);

-- Check for messages
SELECT * FROM handoffs
WHERE (to_agent = 'AGENT-XXX-NNN' OR to_agent IS NULL)
  AND acknowledged_at IS NULL
ORDER BY timestamp;

Quick Reference: Required Logging

Event Action Required
Session start Register agent, create activity_window
Read file Log to action_log (type: read_file)
Edit file Log to action_log (type: edit_file)
Run command Log to action_log (type: bash_command)
Key decision Log to action_log (type: decision)
Error/blocker Log to action_log (type: error)
Every 10-15 actions Create context_snapshot
Session end Update activity_window status

Database Locations

<project>/database/context/
├── agent_context.db    # Agent sessions and activity
├── project_tasks.db    # Task management
├── schema.sql          # Context DB schema
├── tasks_schema.sql    # Tasks DB schema
└── init_context_db.py  # Initialization script

Initialize with:

cd <project>/database/context
python init_context_db.py        # Create if not exists
python init_context_db.py --reset  # Reset all tables

MANDATORY: Failure-Aware Agent Behavior

Based on research: "How Do LLMs Fail In Agentic Scenarios?" (Kamiwaza AI, 2025)

"Recovery capability, not initial correctness, best predicts overall success."

Agents MUST follow these protocols to prevent the four identified failure archetypes.

The Four Failure Archetypes

Archetype Description Prevention
Premature Action Acting on assumptions instead of verifying ALWAYS inspect before acting
Over-Helpfulness Substituting/inventing when data is missing Return 0/null, ASK user
Context Pollution Errors from distractor information Exact name matching, curate context
Fragile Execution Generation loops, coherence loss under load Checkpoint every 3 actions

Grounding Protocol (MANDATORY)

BEFORE any critical action, perform a grounding check:

-- Log grounding check to failure_tracking tables
INSERT INTO grounding_checks (window_id, agent_id, intended_action, action_category, target, verification_type, verification_result, proceed_decision, reasoning)
VALUES (
    <window_id>,
    'AGENT-XXX-NNN',
    'Write SQL query for orders table',
    'db_query',
    'orders',
    'schema_check',
    '{"tables": ["enterprise_orders", "enterprise_customers"], "columns": [...]}',
    'modify',  -- proceed, abort, modify
    'Table name is enterprise_orders, not orders'
);

Grounding Requirements by Action Type:

Action Category REQUIRED Verification
db_query sqlite_get_schema or PRAGMA table_info()
file_edit Read file first, understand structure
api_call Check documentation or test endpoint
schema_change Backup AND read existing schema

NEVER:

  • Guess table/column names
  • Assume file structure
  • Execute queries without schema verification

Over-Helpfulness Prevention

When facing missing or ambiguous data:

WRONG: "Company X not found, using Company XYZ instead"
RIGHT: "Company X not found. 0 results returned."

WRONG: "Status 'inactive' not found, using STATUS != 'active'"
RIGHT: "Status value 'inactive' does not exist. Available values: active, pending, closed"

WRONG: Create a file that doesn't exist when asked to edit it
RIGHT: "File not found at path. Should I create it?"

Rule: If uncertain, ASK - do not substitute or invent.

Context Pollution Prevention

The "Chekhov's Gun" effect: LLMs treat ALL context as signal, not noise.

Prevention Checklist:

  • Verify entity names match EXACTLY (similar names are distractors)
  • At each step, re-verify operating on correct target
  • When reading files, note similar-named entities that could confuse
  • Curate context aggressively - more is NOT better

Log context markers when reading files:

INSERT INTO context_markers (window_id, agent_id, marker_type, source, distractor_risk, contains_similar_names)
VALUES (
    <window_id>,
    'AGENT-XXX-NNN',
    'file_content',
    'src/models/user.ts',
    'medium',  -- none, low, medium, high
    1  -- Contains UserProfile, UserAccount, UserSettings - potential confusion
);

Fragile Execution Prevention

Triggers to Watch:

  1. Data Inlining: NEVER embed large CSV/text in code - use file I/O
  2. Extended Error Recovery: >3 consecutive failures = STOP and reassess
  3. Generation Loops: Repeated similar output = coherence degrading

Mandatory Checkpoints:

  • Every 3 actions for complex tasks (>5 steps)
  • Every 20 actions regardless of task complexity
  • After any error recovery attempt
-- Create checkpoint snapshot
INSERT INTO context_snapshots (window_id, agent_id, current_task, pending_items, next_steps)
VALUES (<window_id>, 'AGENT-XXX-NNN', 'Checkpoint: task progress', '[...]', '[...]');

Failure Logging

When a failure occurs:

INSERT INTO failure_incidents (window_id, agent_id, archetype, severity, error_description, expected_outcome, actual_outcome, grounding_bypassed)
VALUES (
    <window_id>,
    'AGENT-XXX-NNN',
    'PREMATURE_ACTION',  -- PREMATURE_ACTION, OVER_HELPFUL, CONTEXT_POLLUTION, FRAGILE_EXECUTION
    'medium',            -- critical, high, medium, low
    'Queried non-existent table "orders"',
    'Data from orders table',
    'SQL error: no such table',
    1  -- Did we skip grounding check?
);

Recovery Protocol

Recovery is the key differentiator. When errors occur:

  1. Diagnose Root Cause - Don't just retry blindly
  2. Inspect/Verify - Go back to grounding (schema, file content, etc.)
  3. Correct Approach - Fix the actual issue
  4. Validate Result - Confirm the fix worked
-- Log recovery attempt
INSERT INTO recovery_attempts (failure_id, window_id, agent_id, attempt_number, strategy, outcome, lesson_learned)
VALUES (
    <failure_id>,
    <window_id>,
    'AGENT-XXX-NNN',
    1,
    'reread',  -- retry, backtrack, reread, ask_user, alternative_approach
    'success', -- success, partial, failed
    'Always check schema before SQL queries'
);

NEVER: Repeat the same failed action more than twice without changing approach.

Quick Reference: Failure Prevention

Before... ALWAYS...
SQL query PRAGMA table_info() or schema read
File edit Read file content first
API call Check docs or test endpoint
Using entity name Verify EXACT match
Complex task Create checkpoint every 3 actions
When... DO...
Entity not found Return 0/null, report missing
Ambiguous request ASK for clarification
>3 consecutive errors STOP, reassess approach
Similar names in context Flag as high distractor risk

Database Extensions

Failure tracking tables in agent_context.db:

  • grounding_checks - Pre-action verification records
  • failure_incidents - Classified failures by archetype
  • recovery_attempts - Recovery strategy and outcomes
  • context_markers - Context pollution risk tracking
  • prevention_checklist - Learned prevention measures

See failure_tracking_schema.sql for full schema. See failure_models.md for detailed archetype documentation with diagrams.

Inspect SQLite database(s) in the current project.

Arguments

$ARGUMENTS can be:

  • Empty: Show database overview
  • A SQL query: Execute and display results
  • A table name: Show table schema and sample rows

Steps

  1. Find databases:

    • Look in database/, project root, and common locations
    • List all .db and .sqlite files found
  2. If no arguments - Show overview:

    • List all tables with row counts
    • Show schema for each table
    • Display last 5 diary_entries if that table exists
  3. If query provided - Execute it:

    • Connect to the database
    • Run the query
    • Format results as a table
    • Show row count
  4. If table name provided - Inspect table:

    • Show CREATE TABLE statement
    • Show column types and constraints
    • Display first 10 rows as sample

Safety

  • Only SELECT queries allowed by default
  • Warn before any data-modifying operations
  • Always show what database file is being queried

Output Format

Present all results in clear markdown tables with:

  • Database file path
  • Query executed (if applicable)
  • Results formatted for readability
  • Row counts and execution notes

Create a new project with standard structure. Use the provided name: $ARGUMENTS

Steps

  1. Check and create directory structure in outputs/<project-name>/:

    <project-name>/
    ├── README.md
    ├── development_diary.md
    ├── logs/
    ├── tests/
    └── database/ (if project involves data)
    
  2. Initialize virtual environment:

    uv venv .venv
  3. Create README.md with standard header (see CLAUDE.md for schema) including:

    • File ID from registry (get next SOM-DOC-XXXX)
    • Project name and description
    • Requirements
    • Installation
    • Usage
    • Project structure
  4. Create development_diary.md with header and first entry:

    • Date
    • Session: Project initialization
    • Tasks completed: Directory structure, venv, initial docs
    • Agent ID performing the creation
  5. Create initial test file tests/test_placeholder.py with header:

    # Placeholder test to verify test harness works
    def test_placeholder():
        assert True
  6. Update agent_registry.md:

    • Add new files to File Catalog Index
    • Update Next Available IDs
  7. Report the created structure and next steps.

Remember

  • Use semicolons (;) for command chaining, never &&
  • Apply standard file headers with file_id to ALL created files
  • Check directories exist before creating
  • Register all new files in agent_registry.md

Pre-Flight Alignment Check

Perform a comprehensive self-assessment to verify alignment with Somacosf framework policies. This ensures all agents operate consistently and maintain system integrity.

Instructions

For each check below, verify you understand and will comply. Report status as:

  • GREEN - Fully understand and will comply
  • YELLOW - Understand but need clarification
  • RED - Do not understand or cannot comply

Checklist

1. Agent Registration

Requirement: Must be registered in agent_registry.md before any work.

Verify:

  • I have checked agent_registry.md for my agent entry
  • I know my agent ID (format: AGENT-<DESIGNATION>-<SEQUENCE>)
  • If not registered, I will register before creating any files

Status: [ ]


2. File ID System

Requirement: Every file gets a unique ID from the catalog.

Verify:

  • I know the format: SOM-<CATEGORY>-<SEQUENCE>-v<VERSION>
  • I know the category codes (CMD, SCR, DOC, CFG, REG, TST, TMP, DTA, LOG)
  • I will check "Next Available IDs" in agent_registry.md before creating files
  • I will update the registry after creating files

Status: [ ]


3. Standard Headers

Requirement: Every file must have a standard header with full metadata.

Verify:

  • I know the header format for Markdown files (YAML in HTML comments)
  • I know the header format for Python files (comment block)
  • I know the header format for PowerShell files (comment block)
  • I will include: file_id, name, description, project_id, category, tags, dates, version, agent info, execution info

Status: [ ]


4. Backup Before Edit

Requirement: Always create .bk backup before modifying any file.

Verify:

  • I will run Copy-Item filename.ext filename.ext.bk before ANY edit
  • No exceptions to this rule

Status: [ ]


5. Virtual Environments

Requirement: Always work in venv for Python; always use uv.

Verify:

  • I will create venvs with uv venv .venv
  • I will activate with .venv\Scripts\activate.ps1
  • I will install packages with uv pip install
  • I will NEVER use bare pip install

Status: [ ]


6. Command Chaining

Requirement: Use semicolons (;) not && on Windows.

Verify:

  • I will use cmd1; cmd2; cmd3 for chaining
  • I will NEVER use cmd1 && cmd2 && cmd3

Status: [ ]


7. Check Before Doing

Requirement: Always verify state before making changes.

Verify:

  • I will check if files/directories exist before creating
  • I will read files before editing
  • I will verify venv is active before installing
  • I will check database schema before queries

Status: [ ]


8. Logging

Requirement: All scripts must include proper logging.

Verify:

  • I will add logging to every script I create
  • I will log to <project>/logs/ directory
  • I will use proper format with timestamp, level, message

Status: [ ]


9. Test-Driven Development

Requirement: Write tests first, then implementation.

Verify:

  • I will create tests/ directory in projects
  • I will write tests before implementation
  • I will use pytest for Python
  • I will run tests before committing changes

Status: [ ]


10. Development Diary

Requirement: Update development_diary.md every session.

Verify:

  • I will log session start with objectives
  • I will log tasks completed
  • I will document decisions made
  • I will note issues encountered
  • I will define next steps

Status: [ ]


11. Catalog Registration

Requirement: Register every file created in agent_registry.md.

Verify:

  • I will add every new file to "File Catalog Index"
  • I will update "Next Available IDs" after using an ID

Status: [ ]


12. Session Logging

Requirement: Log all sessions in agent registry.

Verify:

  • I will add session entry to my agent's session table
  • I will include date and summary

Status: [ ]


Final Assessment

Summary Report

Provide a summary of your pre-flight check:

AGENT: [Your agent ID]
DATE: [Today's date]

CHECK RESULTS:
1. Agent Registration:    [GREEN/YELLOW/RED]
2. File ID System:        [GREEN/YELLOW/RED]
3. Standard Headers:      [GREEN/YELLOW/RED]
4. Backup Before Edit:    [GREEN/YELLOW/RED]
5. Virtual Environments:  [GREEN/YELLOW/RED]
6. Command Chaining:      [GREEN/YELLOW/RED]
7. Check Before Doing:    [GREEN/YELLOW/RED]
8. Logging:               [GREEN/YELLOW/RED]
9. Test-Driven Dev:       [GREEN/YELLOW/RED]
10. Development Diary:    [GREEN/YELLOW/RED]
11. Catalog Registration: [GREEN/YELLOW/RED]
12. Session Logging:      [GREEN/YELLOW/RED]

OVERALL STATUS: [ALL GREEN / NEEDS ATTENTION]

If Any Check is YELLOW or RED

  1. YELLOW: State what needs clarification and check README.md for details
  2. RED: Stop and read the relevant section of README.md before proceeding

Do not proceed with work until all checks are GREEN.


Confirmation

After completing this check with all GREEN status, confirm:

"Pre-flight check complete. All systems GREEN. Ready to begin work session."

Then update development_diary.md with session start.


Quick Reference Links

If you need to review policies:

  • Full dossier: README.md
  • Coding standards: CLAUDE.md
  • Agent/file registry: agent_registry.md
  • Session log: development_diary.md

Analyze the current project status. Do the following:

  1. List key project files with their last modified dates:

    • README.md
    • development_diary.md
    • Any .py or .ps1 files in root or scripts/
  2. Check environment:

    • Is there a .venv, venv, or cleanup_env directory?
    • If found, note its creation date
  3. Database status (if database/ exists):

    • List SQLite files
    • For each database, show tables and row counts
    • Show last 3 diary_entries if that table exists
  4. Recent logs (if logs/ exists):

    • List log files
    • Show last 10 lines of the most recent log
  5. Test status (if tests/ exists):

    • List test files
    • Note if pytest is available in the venv

Present findings in a clear, organized format.

Generate a detailed project statistics report. You MUST read the actual files and report their contents.

Print this header first:

╔══════════════════════════════════════════════════════════════════╗
║  /stats - Project Statistics Report                              ║
║  Command: SOM-CMD-0006-v1.0.0                                    ║
╚══════════════════════════════════════════════════════════════════╝

1. Read understandings.md

Use the Read tool to read understandings.md from the current project directory. If it exists:

  • Print the section header:
    ┌─────────────────────────────────────────────┐
    │ UNDERSTANDINGS                              │
    └─────────────────────────────────────────────┘
    
  • Summarize key points (architecture decisions, patterns, conventions)
  • Quote critical insights verbatim

If not found, print: understandings.md: Not found

2. Read development_diary.md

Use the Read tool to read development_diary.md from the current project directory. If it exists:

  • Print the section header:
    ┌─────────────────────────────────────────────┐
    │ DEVELOPMENT DIARY                           │
    └─────────────────────────────────────────────┘
    
  • Show the last 3 session entries with dates
  • List recent tasks completed
  • Note any unresolved issues or blockers

If not found, print: development_diary.md: Not found

3. Project Structure

Use Glob and Bash to gather:

  • Print the section header:
    ┌─────────────────────────────────────────────┐
    │ PROJECT STRUCTURE                           │
    └─────────────────────────────────────────────┘
    
  • Count of files by extension (.py, .md, .sql, etc.)
  • Whether .venv/ exists
  • Whether tests/ exists and file count
  • Whether logs/ exists and file count
  • Whether database/ exists and list .db files

4. Git Status

Run git status and git log --oneline -5 to show:

  • Print the section header:
    ┌─────────────────────────────────────────────┐
    │ GIT STATUS                                  │
    └─────────────────────────────────────────────┘
    
  • Current branch
  • Uncommitted changes count
  • Last 5 commits

5. Agent Context (if database/context/ exists)

If database/context/agent_context.db exists, query it:

  • Print the section header:
    ┌─────────────────────────────────────────────┐
    │ AGENT ACTIVITY                              │
    └─────────────────────────────────────────────┘
    
  • Last 3 activity windows
  • Any active/interrupted sessions
  • Recent action counts

Footer

Print when complete:

╔══════════════════════════════════════════════════════════════════╗
║  Report complete                                                 ║
╚══════════════════════════════════════════════════════════════════╝

Toggle extended thinking mode. You MUST perform these actions with visual feedback:

Step 1: Print Header

Print this header:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
/think - Extended Thinking Toggle
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Command: SOM-CMD-0005-v1.0.0

Step 2: Read Settings

Use the Read tool to read ~/.claude/settings.json (expand ~ to user home).

Print: Current state: alwaysThinkingEnabled = [value]

Step 3: Toggle

Use the Edit tool to modify ~/.claude/settings.json:

  • If alwaysThinkingEnabled is true → set to false
  • If alwaysThinkingEnabled is false or missing → set to true

Print: Toggling...

Step 4: Confirm with Result Box

Print the result:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RESULT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Thinking mode: [ON or OFF]

Effect: Extended reasoning [enabled/disabled]
Persistence: Saved - applies to future sessions
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Note: Opus 4.5/Sonnet 4.5 have thinking ON by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment