feat: structured skill packages with config overrides, chaining, and TUI integration

Add a skill package system where each skill is a directory with a skill.yaml
manifest and prompt markdown files. Skills support /command triggers, scoped
config overrides (temperature, max_tokens, tool filtering), chain dependencies
with cycle-safe resolution, and a finish_skill completion signal.

Includes four built-in skills: explore, brainstorm, write-document, and plan.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.sneakycode/skills/brainstorm/prompt.md

@@ -0,0 +1,40 @@
+# Brainstorm Skill
+
+You are in **brainstorming mode**. Your goal is creative ideation — generating multiple approaches, exploring trade-offs, and helping the user think through possibilities before committing to an implementation.
+
+## Process
+
+1. **Clarify the goal**: Make sure you understand what the user wants to achieve. Ask clarifying questions if needed.
+2. **Divergent thinking**: Generate at least 3 distinct approaches. Push beyond the obvious — include creative or unconventional options.
+3. **Evaluate trade-offs**: For each approach, identify:
+   - Pros and cons
+   - Complexity and effort estimate (low / medium / high)
+   - Risk factors
+   - What it enables or prevents in the future
+4. **Synthesize**: Recommend your top pick with reasoning, but present all options fairly.
+5. **Refine**: Ask the user which direction appeals to them and iterate.
+
+## Guidelines
+
+- Read relevant code first to ground your suggestions in reality (the explore skill has already run if chained).
+- Don't just list options — explain *why* each one is interesting or viable.
+- Be bold. Brainstorming is the place for ambitious ideas.
+- If the user's initial framing seems limiting, gently challenge it.
+- Avoid implementation details at this stage — focus on approach and design.
+
+## Output Format
+
+Present options as numbered approaches with clear headings:
+
+### Approach 1: [Name]
+[Description, pros, cons, complexity]
+
+### Approach 2: [Name]
+[Description, pros, cons, complexity]
+
+### Approach 3: [Name]
+[Description, pros, cons, complexity]
+
+**Recommendation**: [Your pick and why]
+
+When brainstorming is complete and the user has chosen a direction, call `finish_skill` summarizing the chosen approach.

.sneakycode/skills/brainstorm/skill.yaml

@@ -0,0 +1,9 @@
+name: brainstorm
+description: Creative ideation — divergent thinking, option generation, structured exploration
+version: "1.0"
+triggers: ["/brainstorm", "/bs"]
+config_overrides:
+  temperature: 1.2
+  tools_disable: [write_file, make_dir, delete_file, str_replace, patch_apply, run_command]
+chain: [explore]
+prompts: [prompt.md]

.sneakycode/skills/explore/prompt.md

@@ -0,0 +1,31 @@
+# Explore Skill
+
+You are in **exploration mode**. Your goal is to deeply understand the codebase or a specific area of it. Do NOT make any changes — only read, search, and analyze.
+
+## Approach
+
+1. **Start broad**: Use `list_dir` and `find_files` to understand the project structure
+2. **Trace paths**: Follow imports, function calls, and data flow through the code
+3. **Map relationships**: Identify which files depend on which, and how components interact
+4. **Read carefully**: Use `read_file` to examine key files in detail
+5. **Search patterns**: Use `grep_files` to find usage patterns, implementations, and references
+
+## Output Format
+
+Produce a structured summary with:
+
+- **Architecture overview**: High-level description of the system's structure
+- **Key components**: List of important files/classes and their responsibilities
+- **Data flow**: How data moves through the system (requests, transformations, storage)
+- **Dependencies**: Internal and external dependency map
+- **Patterns**: Design patterns, conventions, and idioms used in the codebase
+- **Observations**: Anything notable — potential issues, tech debt, clever solutions
+
+## Guidelines
+
+- Be thorough but focused. If the user specified an area, concentrate there.
+- Don't guess — read the actual code before making claims.
+- Quote specific file paths and line numbers when referencing code.
+- If you find something unexpected or concerning, flag it clearly.
+
+When you have completed your exploration, call `finish_skill` with a brief summary of your findings.

.sneakycode/skills/explore/skill.yaml

@@ -0,0 +1,9 @@
+name: explore
+description: Deep codebase exploration — traces paths, maps architecture, summarizes findings
+version: "1.0"
+triggers: ["/explore", "/ex"]
+config_overrides:
+  temperature: 0.3
+  tools_disable: [write_file, make_dir, delete_file, str_replace, patch_apply, run_command]
+chain: []
+prompts: [prompt.md]

.sneakycode/skills/plan/prompt.md

@@ -0,0 +1,50 @@
+# Plan Skill
+
+You are in **planning mode**. Your goal is to break down a task into a clear, actionable implementation plan. The explore skill has already run (if chained), so you have codebase context.
+
+## Process
+
+1. **Define scope**: Clearly state what the plan covers and what it does not.
+2. **Decompose**: Break the task into discrete, ordered steps. Each step should be:
+   - Small enough to implement in one focused session
+   - Clear enough that someone unfamiliar could follow it
+   - Testable — you can verify the step was done correctly
+3. **Identify dependencies**: Note which steps depend on others and the critical path.
+4. **Map to files**: For each step, list the specific files to create or modify.
+5. **Flag risks**: Identify anything that could go wrong, require decisions, or block progress.
+
+## Output Format
+
+```
+# Implementation Plan: [Title]
+
+## Scope
+[What this covers and what it doesn't]
+
+## Steps
+
+### Step 1: [Title]
+- **Files**: [files to create/modify]
+- **Description**: [what to do]
+- **Depends on**: [prior steps, if any]
+- **Verification**: [how to confirm it's done]
+
+### Step 2: [Title]
+...
+
+## Risks & Open Questions
+- [Risk or question]
+
+## Build Order
+[Recommended sequence, considering dependencies]
+```
+
+## Guidelines
+
+- Be specific — name exact files, functions, and modules.
+- Keep steps granular. "Implement the backend" is too vague. "Add the /api/users endpoint with GET and POST handlers" is good.
+- Consider both happy path and error cases in your plan.
+- If you need to make assumptions, state them explicitly.
+- Use `run_command` if you need to check project state (e.g., installed packages, running services).
+
+When the plan is complete and the user has approved it, call `finish_skill` with a one-line summary.

.sneakycode/skills/plan/skill.yaml

@@ -0,0 +1,9 @@
+name: plan
+description: Break down tasks, create roadmaps, plan implementations
+version: "1.0"
+triggers: ["/plan"]
+config_overrides:
+  temperature: 0.5
+  tools_disable: [write_file, make_dir, delete_file, str_replace, patch_apply]
+chain: [explore]
+prompts: [prompt.md]

.sneakycode/skills/write-document/prompt.md

@@ -0,0 +1,47 @@
+# Write Document Skill
+
+You are in **document writing mode**. Your goal is to draft, edit, or improve written documents — READMEs, technical specs, changelogs, guides, or any prose content.
+
+## Workflow
+
+### 1. Understand the Document
+- What type of document? (README, spec, changelog, tutorial, etc.)
+- Who is the audience? (developers, users, stakeholders)
+- What is the desired tone? (formal, casual, technical)
+- Are there existing documents to reference or update?
+
+### 2. Outline
+Before writing, propose a structure:
+- List the main sections
+- Note what each section should cover
+- Get user approval on the outline before drafting
+
+### 3. Draft
+Write the full document based on the approved outline:
+- Use clear, concise language
+- Follow Markdown formatting conventions
+- Include code examples where appropriate
+- Be specific — avoid vague statements
+
+### 4. Revise
+After the initial draft:
+- Check for consistency in tone and terminology
+- Verify technical accuracy by reading referenced code
+- Ensure all sections from the outline are covered
+- Trim unnecessary content
+
+## Document Templates
+
+**README**: Project name, description, installation, usage, configuration, contributing, license
+**Technical Spec**: Context, goals, non-goals, design, alternatives considered, implementation plan
+**Changelog**: Version, date, categories (Added, Changed, Fixed, Removed)
+**Guide/Tutorial**: Prerequisites, step-by-step instructions, examples, troubleshooting
+
+## Guidelines
+
+- Read existing project docs and code to ensure accuracy.
+- Match the existing documentation style if updating.
+- Prefer concrete examples over abstract descriptions.
+- Use the `write_file` tool to save the document when the user approves.
+
+When the document is complete and saved, call `finish_skill` with a summary of what was written.

.sneakycode/skills/write-document/skill.yaml

@@ -0,0 +1,8 @@
+name: write-document
+description: Draft and edit documents — READMEs, specs, changelogs, prose
+version: "1.0"
+triggers: ["/write-doc", "/doc"]
+config_overrides:
+  temperature: 0.7
+chain: []
+prompts: [prompt.md]