Single tool 'ccl' has a lengthy description (280+ chars) but lacks critical structure. Input schema is minimal (only optional 'input' string, no type constraints, enums, or validation guidance). No output schema documented. Description mentions state tracking and verbatim output requirements but does not explain WHEN to call the tool, what it returns, or error recovery paths. Tool name 'ccl' is an acronym, not a verb_noun pattern, does not signal action to LLM. No parameter descriptions beyond the bare 'input' field. No error handling guidance. Composition is monolithic: tool bundles scaffolding, state machine, and LLM interaction into one opaque call, forcing the agent to reason about internal state rather than composing discrete operations.

• Rename tool from 'ccl' to 'scaffold_claude_project' or 'create_project_scaffold' to signal action and intent to LLM.
• Add explicit parameter description for 'input': 'User's reply to the current scaffolding prompt. Pass the exact text the user provided; CCL will update conversation state and return the next prompt or completion status.'
• Document output schema: specify whether response is plain text, JSON object with fields like {status, prompt, state_file_path}, or markdown. Include example output.
• Add error handling guidance: 'If state file is corrupted, CCL will return an error with recovery instructions. If LLM API fails, retry with the same input. If user input is invalid, CCL will re-prompt.'
• Consider splitting into separate tools: 'init_project_scaffold' (one-time setup), 'continue_scaffold_conversation' (stateful turns), 'get_scaffold_status' (query state). Enables agent to compose and retry individual steps.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry