framework-core

What this skill does

# Framework Core Skill

Core skill that establishes workflow context for all katachi framework commands.

## When to Load

All framework commands should load this skill first to establish:
- Collaborative workflow principles
- Status tracking conventions
- Scratchpad usage patterns
- Context bridging guidelines
- Decision type guidance (ADR vs DES)

## Project Templates

These templates are used when creating project structure:

**Planning documents:**
- `references/VISION-template.md` - Vision document structure
- `references/DELTAS-template.md` - Delta inventory structure (work tracking)

**Decision documents:**
- `references/ADR-template.md` - Architecture Decision Record format
- `references/DES-template.md` - Design Pattern document format

**Feature documentation:**
- `../working-on-delta/references/feature-spec.md` - Long-lived feature specification
- `../working-on-delta/references/feature-design.md` - Long-lived feature design
- `../working-on-delta/references/feature-domain-readme.md` - Domain index template
- `../working-on-delta/references/feature-specs-readme.md` - Top-level feature index

**Delta working documents:**
- `../working-on-delta/references/delta-spec.md` - Delta specification (working doc)
- `../working-on-delta/references/delta-design.md` - Delta design (working doc)
- `../working-on-delta/references/implementation-plan.md` - Implementation plan (working doc)

**Guidance documents** (how to write each document type):
- `../working-on-delta/references/spec-template.md` - How to write delta specifications
- `../working-on-delta/references/design-template.md` - How to write design rationale
- `../working-on-delta/references/plan-template.md` - How to write implementation plans

## Decision Types Reference

Load `references/decision-types.md` when:
- Creating a new decision document (ADR or DES)
- Determining which document type to use for a pattern/choice
- Retrofitting existing decisions from code
- Teaching users about ADR vs DES distinction

This reference contains the full decision tree and examples for choosing between ADRs (one-time architectural choices) and DES (repeatable patterns).

## State Detection

Before executing any command, detect project state:

### 1. Not Initialized
**Condition:** No `docs/planning/` directory exists

**Action:**
- If no significant code exists → Offer `/katachi:init-framework`
- If code exists → Explain retrofit options

### 2. Partially Initialized
**Condition:** `docs/planning/` exists but missing VISION.md or DELTAS.md

**Action:**
- List what's missing
- Offer to complete setup
- Show which commands to run

### 3. Fully Initialized
**Condition:** All planning files exist

**Action:**
- Proceed with normal command operation
- Show current focus from CLAUDE.md if available

### 4. Retrofit Mode
**Condition:** Code exists but no framework documentation

**Action:**
- Explain retrofit commands available
- Offer `/katachi:retrofit-spec` for existing modules
- Offer `/katachi:retrofit-decision` for existing patterns

---

## Workflow Principles

Common principles for all collaborative command workflows in this framework.

### Core Principles

#### 1. One Question at a Time

Never batch multiple questions. Wait for answer before proceeding.

**Why:** Prevents cognitive overload, maintains clear conversation flow, ensures each decision gets proper attention.

#### 2. Propose, Don't Decide

Agent proposes options, user confirms. Never add or change anything without user agreement.

**Why:** User is the architect, Claude is the implementer. Maintain this relationship throughout.

#### 3. Use AskUserQuestion for Structured Options

When presenting 2-4 distinct choices, use the AskUserQuestion tool:

- Provide clear header (max 12 chars, e.g., "Logging", "Format", "Approach")
- Write complete question text
- Add description explaining each option and its implications
- Use `multiSelect: true` if choices aren't mutually exclusive
- Examples: installation modes, logging approaches, technical choices, format options

**When to use plain text instead:**
- Open-ended questions (no predefined options)
- Single simple clarification needed
- Asking for creative input
- Yes/no questions

#### 4. Detect Gaps Proactively

Throughout the entire process:
- Surface unstated assumptions by asking about them
- Identify potential edge cases and ask user if they're relevant
- Challenge vague or incomplete answers
- Ask "what could go wrong?" and "what's missing?"
- Never fill gaps yourself - always ask the user

#### 5. Use a Scratchpad

Track state in `/tmp/<command>-state.md`:

**Commands with natural IDs:**
- For `-delta` commands, include the delta ID: `/tmp/<command>-<FEATURE-ID>-state.md`
  - `/spec-delta`: `/tmp/spec-<FEATURE-ID>-state.md`
  - `/design-delta`: `/tmp/design-<FEATURE-ID>-state.md`
  - `/plan-delta`: `/tmp/plan-<FEATURE-ID>-state.md`
  - `/implement-delta`: `/tmp/implement-<FEATURE-ID>-state.md`

**Commands without natural IDs (parallel execution support):**
- Generate unique animal-adjective ID: `/tmp/<command>-<animal-adjective>-state.md`
  - `/add-delta`: `/tmp/add-delta-<animal-adjective>-state.md`
  - `/analyze`: `/tmp/analyze-<animal-adjective>-state.md`
  - `/analyze-impact`: `/tmp/analyze-impact-<animal-adjective>-state.md`
  - `/decision`: `/tmp/decision-<animal-adjective>-state.md`
  - `/review-code`: `/tmp/review-code-<animal-adjective>-state.md`
  - Enables multiple concurrent sessions without state file conflicts
  - Keep state files after completion (don't auto-clean) for debugging/audit trail

**Commands scoped by project name (directory basename):**
- `/vision`, `/deltas`, `/dependencies` - Use `/tmp/<command>-<project-name>-state.md`

**Commands without scratchpads:**
- `/commit`, `/record-learnings` - No scratchpad needed

**Scratchpad contents:**
- Current section/phase being worked on
- Questions asked and answered
- Gaps identified
- Topics to revisit
- Decisions made

**Why:** Prevents information loss across question rounds, maintains context during iteration.

#### 6. Bridge the Context Gap

The agent reads multiple files (specs, designs, ADRs, DES patterns) and builds comprehensive context. The user reads documents when needed but doesn't have the full picture simultaneously.

**When asking questions or explaining decisions:**
- Include diagrams (ASCII art, sequence diagrams, thread/data flows)
- Provide rich context - don't assume shared understanding
- Explain the "why" behind technical questions
- Show concrete examples, not abstract references
- Name the specific files, components, or patterns being referenced

#### 7. Research When Needed

When user shows uncertainty, research to provide informed options.

**Research triggers:**
- User says "I'm not sure" or "I don't know"
- Topic involves technical choices (models, libraries, protocols, frameworks)
- User asks "what options do I have?"
- User mentions alternatives they've tried but weren't satisfied with

Use Task tool (general-purpose agent) to research, then synthesize findings to inform questions.

### Workflow Modes

#### Information Gathering

**Use for:** Understanding requirements, clarifying scope, exploring options

**Workflow:**
- Ask one question at a time
- Wait for answer before proceeding
- Use AskUserQuestion for structured choices
- Build understanding incrementally

#### Document Creation

**Use for:** Specs, designs, plans, decisions

**Workflow:**
1. **Research phase (silent, thorough)**
   - Read spec/requirements
   - Read relevant ADRs and DES patterns
   - Explore related codebase areas if needed
   - Research official documentation for libraries/frameworks/APIs
   - Build understanding without asking upfront questions

2. **Draft proposal (with decision points)**
   - Create complete document following template
   - Base all choices on research findings
   - Note any uncertainties/assumptions clearly
   - **If choices require user input:** Use AskUserQuestion (ambiguous requirements, mul