opencodekit 0.21.10 → 0.22.0

package/dist/template/.opencode/skill/deep-research/SKILL.md

@@ -1,384 +0,0 @@
----
-name: deep-research
-description: >
-  Use when analyzing unfamiliar code, implementing complex features, or entering thorough research mode.
-  Provides structured LSP exploration (all 9 operations), memory-first protocol, and confidence-scored findings.
-  Integrates with scout agent deep mode and research command --thorough flag.
-version: 1.0.0
-tags: [research, workflow]
-dependencies: []
----
-
-# Deep Research - Comprehensive Code Understanding
-
-## When to Use
-
-- **Complex implementation**: Feature touches 3+ files or unfamiliar modules
-- **Thorough mode**: `/research <topic> --thorough` or scout deep mode
-- **Pre-edit understanding**: Before modifying code you don't fully understand
-- **Architecture exploration**: Understanding how systems connect
-- **Debugging**: Tracing behavior through multiple layers
-
-## When NOT to Use
-
-- Quick syntax lookup (use quick mode instead)
-- Well-understood code with obvious changes
-- Time-constrained fixes (accept lower confidence)
-
-## Core Protocol
-
-### Phase 1: Memory First (Skip External If Found)
-
-```typescript
-// Search past research on this topic
-memory_search({ query: "<topic keywords>", limit: 5 });
-
-// Check for related observations
-memory_search({ query: "<topic> gotchas patterns", limit: 3 });
-
-// Load relevant project context
-memory_read({ file: "project/architecture" });
-memory_read({ file: "project/gotchas" });
-```
-
-**Stop condition**: If memory returns high-confidence findings on this exact topic, synthesize and skip to documentation. Only proceed to exploration if:
-
-- No relevant memory found
-- Memory findings are outdated or incomplete
-- Question requires fresh analysis
-
-### Phase 2: LSP Exploration (Delegate to Explore Agent)
-
-**Delegate to explore agent** for comprehensive LSP analysis instead of manual operations:
-
-```typescript
-task({
-  subagent_type: "explore",
-  description: "LSP analysis of <target>",
-  prompt: `Very thorough LSP analysis of <symbol/module>.
-
-Target files:
-- src/path/to/file.ts
-- src/related/module.ts
-
-Questions to answer:
-1. What is the type signature of <symbol>?
-2. What calls this function? (incoming calls)
-3. What does this function call? (outgoing calls)
-4. Where is this symbol referenced across the codebase?
-5. Are there interface implementations to consider?
-
-Return structured findings with file:line references.`,
-});
-```
-
-The explore agent will run:
-
-- `documentSymbol` - File structure overview
-- `goToDefinition` - Symbol definitions
-- `findReferences` - All usages across codebase
-- `hover` - Type info and documentation
-- `workspaceSymbol` - Workspace-wide search
-- Call hierarchy (incoming/outgoing calls)
-
-**When to run LSP manually instead:**
-
-- Single symbol lookup (quick mode)
-- Explore agent unavailable
-- Need specific operation only
-
-### Phase 3: Pattern Discovery
-
-```typescript
-// Find similar patterns in codebase (use project's file extension: *.ts, *.py, *.rs, *.go, *.java, etc.)
-grep({ pattern: "<relevant pattern>", include: "*.<ext>" });
-
-// Locate related files
-glob({ pattern: "src/**/*<topic>*" });
-
-// Check tests for usage examples (adapt glob to project conventions)
-// JS/TS: **/*.test.ts, **/*.spec.ts  |  Python: **/test_*.py  |  Rust: **/tests/**
-// Go: **/*_test.go  |  Java: **/src/test/**/*.java
-glob({ pattern: "**/*test*" });
-grep({ pattern: "<function name>", include: "*test*" });
-```
-
-### Phase 4: External Research (If Needed)
-
-Only if internal exploration doesn't answer the question:
-
-```typescript
-// Official docs
-context7({ operation: "resolve", libraryName: "<lib>" });
-context7({ operation: "query", libraryId: "<id>", topic: "<specific question>" });
-
-// Real-world patterns (adapt language parameter to project)
-codesearch({ query: "<API usage pattern>", tokensNum: 5000 });
-grepsearch({ query: "<code pattern>", language: "<project language>" });
-```
-
-## Confidence Levels
-
-Score every finding:
-
-| Level      | Criteria                                   | Action               |
-| ---------- | ------------------------------------------ | -------------------- |
-| **High**   | LSP confirmed + tests exist + docs match   | Proceed confidently  |
-| **Medium** | LSP confirmed but untested or undocumented | Proceed with caution |
-| **Low**    | Inference only, no LSP/test confirmation   | Verify before using  |
-| **None**   | Speculation without evidence               | Discard              |
-
-## Stop Conditions
-
-Stop research when ANY of these are true:
-
-- All questions answered with Medium+ confidence
-- Tool budget exhausted (~100 calls for thorough)
-- Last 5 tool calls yielded no new insights
-- Blocked and need human input
-
-## Tool Budget Guidelines
-
-| Mode     | Tool Calls | Use Case                           |
-| -------- | ---------- | ---------------------------------- |
-| Quick    | ~10        | Single question, syntax lookup     |
-| Default  | ~30        | Moderate exploration               |
-| Thorough | ~100+      | Comprehensive analysis, new domain |
-
-Track your tool count and stop at budget.
-
-## Output Template
-
-Document findings in structured format:
-
-```markdown
-# Deep Research: [Topic]
-
-**Mode:** thorough
-**Tool calls:** [N]
-**Duration:** [time]
-
-## Questions Addressed
-
-1. [Q1] → Answered (High confidence)
-2. [Q2] → Partial (Medium confidence)
-3. [Q3] → Unanswered (needs: [what would resolve])
-
-## LSP Findings
-
-### Symbol: [name]
-
-**Location:** `src/path/file.ts:42`
-**Type:** [type signature from hover]
-
-**Callers (incoming):**
-
-- `src/a.ts:10` - [context]
-- `src/b.ts:25` - [context]
-
-**Dependencies (outgoing):**
-
-- `src/utils.ts:15` - [what it calls]
-
-**References:** [N] usages across [M] files
-
----
-
-## Pattern Analysis
-
-### Pattern 1: [Name]
-
-**Files:** `src/a.ts`, `src/b.ts`
-**Confidence:** High
-**Evidence:** [LSP + grep findings]
-
-[Description of pattern]
-
----
-
-## Key Findings
-
-### [Finding 1]
-
-**Confidence:** High
-**Sources:** LSP goToDefinition, findReferences
-**Evidence:** `src/file.ts:42-56`
-
-[Finding with code evidence]
-
----
-
-## Recommendations
-
-Based on LSP analysis:
-
-1. [Recommendation 1] - because [LSP evidence]
-2. [Recommendation 2] - because [pattern found]
-
-## Open Items
-
-- [Remaining question] - needs: [specific tool/info]
-```
-
-## Integration Points
-
-### Scout Agent Deep Mode
-
-When scout enters deep mode, load this skill:
-
-```typescript
-skill({ name: "deep-research" });
-```
-
-Scout then follows the protocol for external + internal analysis.
-
-### Research Command --thorough
-
-When `/research <topic> --thorough` is invoked:
-
-```typescript
-skill({ name: "deep-research" });
-// Follow full protocol with ~100 tool budget
-```
-
-### Pre-Edit Verification
-
-Before any complex edit:
-
-```typescript
-skill({ name: "deep-research" });
-// Run Phase 2 (LSP) on all symbols being modified
-// Proceed only when all 9 operations complete
-```
-
-## Workflow Example
-
-**Scenario:** Understanding authentication middleware before adding rate limiting.
-
-```typescript
-// Phase 1: Memory check
-memory_search({ query: "authentication middleware rate limiting" });
-memory_read({ file: "project/architecture" });
-
-// Phase 2: Delegate LSP exploration to explore agent
-task({
-  subagent_type: "explore",
-  description: "Analyze auth middleware",
-  prompt: `Very thorough LSP analysis of authentication middleware.
-
-Target: src/middleware/auth.ts
-
-Questions:
-1. What functions are exported from auth.ts?
-2. What calls the auth middleware? (incoming calls)
-3. What does it depend on? (outgoing calls)
-4. Are there existing rate limiting patterns?
-
-Return file:line references for all findings.`,
-});
-
-// Phase 3: Pattern discovery (parallel with Phase 2)
-grep({ pattern: "middleware", include: "*.<ext>" });
-grep({ pattern: "rateLimit", include: "*.<ext>" });
-glob({ pattern: "src/middleware/*" });
-
-// Phase 4: External (if patterns unclear)
-context7({ operation: "resolve", libraryName: "express" });
-context7({ operation: "query", libraryId: "/expressjs/express", topic: "middleware" });
-
-// Document findings
-write({
-  filePath: ".beads/artifacts/<id>/research.md",
-  content: "# Deep Research: Auth Middleware...",
-});
-```
-
-## Anti-Patterns
-
-### DON'T: Skip LSP Exploration
-
-```typescript
-// Bad: Reading file without LSP analysis
-read({ filePath: "src/auth.ts" });
-// Then immediately editing...
-
-// Good: Delegate to explore agent first
-task({
-  subagent_type: "explore",
-  description: "Analyze auth.ts",
-  prompt: "Very thorough LSP analysis of src/auth.ts...",
-});
-// Then edit with understanding
-```
-
-### DON'T: Ignore Memory
-
-```typescript
-// Bad: Jumping straight to exploration
-grep({ pattern: "auth", include: "*.ts" });
-
-// Good: Check memory first
-memory_search({ query: "authentication patterns" });
-// Only explore if memory doesn't answer
-```
-
-### DON'T: Mix Confidence Levels
-
-```typescript
-// Bad: Treating speculation as fact
-"This function definitely handles X"; // Without LSP verification
-
-// Good: Explicit confidence
-"Based on LSP findReferences (High confidence): This function is called from...";
-"Inference (Low confidence): This might also handle X, needs verification";
-```
-
-### DON'T: Exceed Budget Without Stopping
-
-```typescript
-// Bad: 150 tool calls on thorough mode
-// Keep going indefinitely...
-
-// Good: Track and stop
-// Tool call 95: Still finding new insights, continue
-// Tool call 100: Stopping at budget, documenting partial findings
-```
-
-## Success Criteria
-
-Research is complete when:
-
-- [ ] Memory checked before exploration
-- [ ] All 9 LSP operations run on target symbols
-- [ ] Confidence scores assigned to all findings
-- [ ] Tool budget respected
-- [ ] Findings documented with evidence
-- [ ] Open items listed with resolution paths
-
-## Quick Reference
-
-```
-PROTOCOL:
-1. Memory first → skip if found
-2. Delegate LSP to @explore (very thorough)
-3. Patterns → grep + glob (parallel)
-4. External → only if needed
-
-DELEGATION:
-task({ subagent_type: "explore", prompt: "Very thorough LSP analysis..." })
-
-CONFIDENCE:
-High = LSP + tests + docs
-Medium = LSP only
-Low = inference
-None = discard
-
-BUDGET:
-quick ~10 | default ~30 | thorough ~100
-
-STOP WHEN:
-- Questions answered (Medium+)
-- Budget exhausted
-- 5 calls with no new insights
-- Blocked on human input
-```

package/dist/template/.opencode/skill/design-direction-advisor/SKILL.md

@@ -1,139 +0,0 @@
----
-name: design-direction-advisor
-description: Use when the user's design brief is vague ("make it look good", "design something", "I don't know what style I want", "make me a nice-looking page") OR when no brand context exists. Recommends 3 differentiated directions from 5 design schools × 20 named designer philosophies (Pentagram, Field.io, Kenya Hara, Sagmeister, etc.) with parallel visual demos so the user can choose by seeing, not imagining.
----
-
-# Design Direction Advisor (Fallback Mode)
-
-> Adapted from `huashu-design`. When you don't have brand context and the user's brief is too vague to execute, **don't guess from generic intuition** — that produces AI slop. Convert ambiguity into structured choice.
-
-## When to Trigger
-
-- Vague briefs: "make it look good", "design something", "make me a page", "I don't know what I want"
-- User explicitly asks: "recommend a style", "give me some directions", "pick a philosophy", "show me different styles"
-- No design context exists: no design system, no brand kit, no Figma, no reference site
-- User says "I don't know what style I want either"
-
-## When to Skip
-
-- User already provided clear references (Figma / screenshots / brand spec) → run `brand-asset-protocol` instead
-- User already specified the direction ("Apple Silicon launch event style") → go directly to execution
-- Small fix or specific tool call ("convert this HTML to PDF") → skip
-- Uncertain → use the lightest version: list 3 directions in 2 sentences each and let the user pick. Don't generate demos prematurely.
-
-## The 8-Phase Flow
-
-### Phase 1 — Deep-Understand the Need
-
-Ask up to **3** focused questions (skip if already clear):
-
-- Target audience?
-- Core message?
-- Emotional tone?
-- Output format? (web page / slide / animation / app mockup)
-
-### Phase 2 — Advisor-Style Restatement (~150 words)
-
-In your own words, restate: the essential need, audience, scenario, emotional tone. End with: _"Based on this understanding, I've prepared 3 design directions for you."_
-
-This forces alignment before generation. If the restatement is wrong, the user corrects you cheaply.
-
-### Phase 3 — Recommend 3 Differentiated Philosophies
-
-Each direction must include:
-
-- **Named designer or studio** — "Kenya Hara-style Eastern minimalism," not just "minimalism"
-- 50-100 words explaining _why this designer fits your brief_
-- 3-4 signature visual features
-- 3-5 vibe keywords
-- Optional reference work
-
-**Differentiation rule (non-negotiable):** the 3 directions must come from **3 different schools** for clear visual contrast.
-
-### The 5 Schools × 20 Philosophies
-
-| School                               | Vibe                                    | Best as                         | Designers (pick 1 per recommendation)                             |
-| ------------------------------------ | --------------------------------------- | ------------------------------- | ----------------------------------------------------------------- |
-| **Information Architecture (01-04)** | Rational, data-driven, restrained       | Safe / professional choice      | Pentagram (Bierut), Stamen Design, Information Architects, Fathom |
-| **Motion Poetics (05-08)**           | Dynamic, immersive, technical aesthetic | Bold / cutting-edge choice      | Locomotive, Active Theory, Field.io, Resn                         |
-| **Minimalism (09-12)**               | Order, whitespace, refinement           | Safe / premium choice           | Experimental Jetset, Müller-Brockmann, Build, Sagmeister & Walsh  |
-| **Experimental Avant-garde (13-16)** | Generative art, visual impact           | Bold / innovative choice        | Zach Lieberman, Raven Kwok, Ash Thorp, Territory Studio           |
-| **Eastern Philosophy (17-20)**       | Warm, poetic, contemplative             | Differentiation / unique choice | Takram, Kenya Hara, Irma Boom, Neo Shen                           |
-
-❌ **Forbidden**: recommending 2 or more from the same school. Insufficient differentiation = user can't tell them apart.
-
-A good triplet typically pairs **one safe + one bold + one differentiating** choice.
-
-### Phase 4 — Show Reference Examples (Visual Anchor)
-
-Before generating live demos, **show 2-3 reference images per direction** if you can fetch them (search the designer's known projects). The user calibrates "yes, that vibe" or "no, not what I meant" against real work, not your description.
-
-Phrasing: _"Before I spin up live demos, here's how each style looks in similar scenarios →"_ then show references.
-
-### Phase 5 — Generate 3 Visual Demos
-
-> **Core principle: seeing beats describing.** Don't make the user imagine — show them.
-
-For each of the 3 directions, generate one demo using the user's **real content/topic**, not lorem ipsum.
-
-- **If parallel subagents are supported:** dispatch 3 in parallel (file-disjoint, see AGENTS.md "Parallel Execution Rules")
-- **If serial:** generate one at a time, all 3 before showing
-
-| Style type        | Demo path                                                         |
-| ----------------- | ----------------------------------------------------------------- |
-| HTML-friendly     | Generate full HTML → screenshot via Playwright                    |
-| AI-image-friendly | Use image generation (e.g. nano-banana-pro) with style DNA prompt |
-| Hybrid            | HTML layout + AI-generated illustrations slotted in               |
-
-Save HTML to `_temp/design-demos/demo-<style>.html`. Screenshot to `_temp/design-demos/demo-<style>.png`. Show all 3 screenshots together.
-
-```bash
-# Reference command
-npx playwright screenshot file:///<absolute-path>.html out.png --viewport-size=1200,900
-```
-
-### Phase 6 — User Chooses
-
-Options to present:
-
-- **Pick one** to deepen
-- **Mix** ("A's palette + C's layout")
-- **Tweak** specific aspects of one
-- **Restart** → return to Phase 3 with refined understanding
-
-### Phase 7 — Generate Production Prompt (if AI image-driven)
-
-Structure: `[design philosophy constraint] + [content description] + [technical params]`
-
-- ✅ Use **specific features**, not style names: "Kenya Hara whitespace + terracotta orange #C04A1A," not "minimalist"
-- ✅ Include HEX colors, ratios, space allocation, output spec
-- ❌ Avoid AI slop list (see `anti-ai-slop` skill)
-
-### Phase 8 — Hand Off to Main Build
-
-Direction confirmed → return to the main implementation flow (`hi-fi-prototype-html`, `frontend-design`, etc.). You now have **explicit design context** — no longer guessing.
-
-## Lightweight Variant (Time-Pressured)
-
-When the user is in a rush:
-
-- Skip Phase 4 references
-- Skip Phase 5 demos
-- Just present 3 named directions in 2 sentences each
-- Let user pick by name
-
-This trades signal-fidelity for speed but still beats "generic AI default."
-
-## Why This Beats "Just Make a Reasonable Default"
-
-1. **Generic default = AI slop** (see `anti-ai-slop`). It dilutes brand identity to the average of all training data.
-2. **Named designer references** give the user concrete vocabulary to push back ("more like Pentagram, less like Sagmeister").
-3. **3 differentiated demos** convert vague preferences into testable choices in one round, instead of N rounds of "looks ok but not quite right."
-4. **The advisor restatement (Phase 2)** catches misunderstandings before any pixel is committed — the cheapest possible correction point.
-
-## Pairs Well With
-
-- `brand-asset-protocol` — runs **after** direction is locked, when brand assets must be sourced
-- `anti-ai-slop` — keeps each demo from collapsing into the AI default
-- `hi-fi-prototype-html` — production target after direction is chosen
-- `brainstorming` — for non-visual, non-design ambiguity