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/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.