@ultrakit/ultrakit 0.0.0 → 0.0.2

package/dist/template/opencode/skill/codemap/SKILL.md

@@ -0,0 +1,166 @@
+---
+name: codemap
+description: "Use when entering an unfamiliar repository or large subsystem and you need a concise Repository Atlas: directory responsibilities, entry points, data flow, integration points, and change-risk notes without dumping whole files into context"
+version: 1.0.0
+tags: [workflow, documentation, context]
+dependencies: []
+---
+
+# Codemap / Repository Atlas
+
+> **Replaces** repeated blind exploration with durable, scoped maps that explain what each directory does and where changes are risky.
+
+## When to Use
+
+- You are working in an unfamiliar repo, package, or large subsystem
+- Multiple agents need the same codebase orientation
+- A feature spans several directories and you need responsibilities, entry points, and data flow
+- You need to update stale architecture notes after meaningful structural changes
+- You are preparing a plan and discovery keeps re-reading the same files
+
+## When NOT to Use
+
+- You already know the exact file and symbol to edit
+- The task touches one small file and discovery would be cheaper than maintaining a map
+- The map would duplicate an existing accurate `codemap.md` or AGENTS.md section
+- You are tempted to paste full files into the map; codemaps summarize structure, not source code
+
+## Core Principle
+
+A codemap is a **Repository Atlas**: compact, navigable, and evidence-backed. It should help a future agent decide where to look next, not replace reading the code.
+
+## Output Shape
+
+Write maps as `codemap.md` files at the smallest useful scope:
+
+```markdown
+# Codemap: [directory or project]
+
+## Purpose
+
+[1-3 sentences describing this area's responsibility]
+
+## Entry Points
+
+- `path/file.ts:42` — [what enters here]
+
+## Key Modules
+
+| Path         | Responsibility | Notes             |
+| ------------ | -------------- | ----------------- |
+| `src/foo.ts` | [role]         | [risk/convention] |
+
+## Data / Control Flow
+
+1. [source] → [transform] → [sink]
+
+## Integration Points
+
+- [external service/config/command] via `path/file.ts:line`
+
+## Conventions
+
+- [naming, error handling, testing, permission patterns]
+
+## Change Risks
+
+- [what breaks easily and how to verify]
+
+## Last Verified
+
+- Date: YYYY-MM-DD
+- Evidence: [commands/files read]
+```
+
+## Workflow
+
+### 1. Discover narrowly
+
+- Read existing `AGENTS.md`, `codemap.md`, README, and nearby tests first
+- Use `@explore` or code-search tools for symbol and caller maps
+- Prefer references with `file_path:line_number`
+- Stop discovery once responsibilities and key flows are clear
+
+### 2. Map responsibilities, not implementation
+
+Include:
+
+- directory purpose
+- public entry points
+- important modules and boundaries
+- data/control flow
+- integration points
+- conventions and risky seams
+
+Exclude:
+
+- full function bodies
+- generated files or build output
+- speculative architecture not backed by code
+- secrets, environment values, or private credentials
+
+### 3. Keep maps small
+
+- Target 100-250 lines per map
+- Split large maps by directory instead of creating one huge file
+- Link child maps from the root map
+- Summarize examples; do not paste code blocks unless a tiny snippet is essential
+
+### 4. Track freshness
+
+Use `.opencode/memory/project/codemap.json` as optional local state for generated maps. UltraKit preserves `.opencode/memory/project/` during reinitialization, so this advisory file survives with project memory:
+
+```json
+{
+  "maps": {
+    "src/codemap.md": {
+      "scope": "src",
+      "lastVerified": "2026-05-09",
+      "files": ["src/index.ts", "src/commands/init.ts"]
+    }
+  }
+}
+```
+
+The state file is advisory, not a separate codemap-specific preservation mechanism. If it is missing, inspect the relevant files and regenerate the map.
+
+### 5. Verify before relying on a map
+
+Before using a codemap for implementation:
+
+- Check `Last Verified`
+- Spot-check the key files it references
+- Re-run search for the symbol or directory you will modify
+- Update the map if the code has drifted
+
+## Optional Helper Script
+
+This skill may ship a small dependency-free helper at `scripts/codemap.mjs` for scaffolding map files and listing changed scopes. The script is optional; the source of truth is the SKILL.md workflow above.
+
+## Guardrails
+
+- Do not auto-inject large codemaps into every prompt
+- Do not create maps for vendored, generated, or dependency directories
+- Do not mark inferred behavior as fact; label it as inference
+- Do not let codemap work replace targeted verification for the actual change
+
+## Verification
+
+After creating or updating maps:
+
+```bash
+# Confirm maps exist
+find . -name codemap.md -not -path "*/node_modules/*" -print
+
+# Spot-check referenced paths still exist
+# Run project-specific typecheck/lint/tests after implementation changes
+npm run typecheck
+npm run lint
+npm test
+```
+
+## See Also
+
+- `index-knowledge` — Generate or refresh AGENTS.md hierarchy documentation
+- `code-search-patterns` — Search-first code navigation
+- `deep-research` — Thorough codebase/domain research protocol

package/dist/template/opencode/skill/codemap/scripts/codemap.mjs

@@ -0,0 +1,75 @@
+#!/usr/bin/env node
+import { mkdirSync, writeFileSync } from "node:fs";
+import { basename, dirname, join, relative, resolve, sep } from "node:path";
+
+const args = process.argv.slice(2);
+const command = args[0] ?? "--help";
+
+function usage() {
+	console.log(`codemap helper
+
+Usage:
+  node scripts/codemap.mjs init [scope]
+  node scripts/codemap.mjs path [scope]
+  node scripts/codemap.mjs changes
+  node scripts/codemap.mjs --help
+
+Creates a starter codemap.md for a project-local directory scope. This helper is optional; follow SKILL.md for the mapping workflow.`);
+}
+
+function resolveScope(scopeArg = ".") {
+	const cwd = resolve(process.cwd());
+	const normalizedScopeArg = scopeArg.trim();
+	if (normalizedScopeArg.length === 0) {
+		throw new Error("scope must not be blank");
+	}
+	const scope = resolve(cwd, normalizedScopeArg);
+	if (scope !== cwd && !scope.startsWith(`${cwd}${sep}`)) {
+		throw new Error(`scope must stay inside the current project: ${scopeArg}`);
+	}
+	return scope;
+}
+
+function codemapPath(scopeArg = ".") {
+	return join(resolveScope(scopeArg), "codemap.md");
+}
+
+function init(scopeArg = ".") {
+	try {
+		const target = codemapPath(scopeArg);
+
+		mkdirSync(dirname(target), { recursive: true });
+		writeFileSync(
+			target,
+			`# Codemap: ${basename(dirname(target)) || "."}\n\n## Purpose\n\n[Describe this directory's responsibility.]\n\n## Entry Points\n\n- \`path/file.ts:line\` — [what enters here]\n\n## Key Modules\n\n| Path | Responsibility | Notes |\n| ---- | -------------- | ----- |\n\n## Data / Control Flow\n\n1. [source] → [transform] → [sink]\n\n## Integration Points\n\n- [service/config/command] via \`path/file.ts:line\`\n\n## Conventions\n\n- [patterns to preserve]\n\n## Change Risks\n\n- [risk and verification]\n\n## Last Verified\n\n- Date: ${new Date().toISOString().slice(0, 10)}\n- Evidence: [files read / commands run]\n`,
+			{ flag: "wx" },
+		);
+		console.log(`created ${relative(process.cwd(), target)}`);
+	} catch (error) {
+		if (error && typeof error === "object" && "code" in error && error.code === "EEXIST") {
+			console.log(`exists ${relative(process.cwd(), codemapPath(scopeArg))}`);
+			return;
+		}
+		console.error(error instanceof Error ? error.message : String(error));
+		process.exitCode = 1;
+	}
+}
+
+if (command === "--help" || command === "help") {
+	usage();
+} else if (command === "init") {
+	init(args[1]);
+} else if (command === "path") {
+	try {
+		console.log(relative(process.cwd(), codemapPath(args[1])));
+	} catch (error) {
+		console.error(error instanceof Error ? error.message : String(error));
+		process.exitCode = 1;
+	}
+} else if (command === "changes") {
+	console.log("Inspect changed scopes with your VCS, then update affected codemap.md files. Example: git status --short");
+} else {
+	console.error(`unknown command: ${command}`);
+	usage();
+	process.exitCode = 1;
+}

package/dist/template/{.opencode → opencode}/skill/context-condensation/SKILL.md

@@ -1,12 +1,21 @@
 ---
 name: context-condensation
 description: Use when context is approaching budget limits and you need to compress, OR when handing off to another session. Provides the explicit keep/drop rubric for what survives compression — preserve goals, progress, critical files, failing tests; drop exploration noise and resolved threads. Pairs with `/dcp compress` and `/handoff`. Adapted from OpenHands context-condensation, Manus context engineering, HumanLayer backpressure.
+version: 1.0.0
+tags: [context, workflow]
+dependencies: []
 ---
 
 # Context Condensation
 
 > Compression is not deletion — it is **selection of what survives**. The wrong selection makes the agent restart from zero. This skill defines what to keep.
 
+
+## When NOT to Use
+
+- When the current raw context is still actively needed for exact edits or error messages.
+- For short conversations where compression would remove useful detail.
+
 ## When to Use
 
 - Context >100k tokens and growing

package/dist/template/{.opencode → opencode}/skill/context-management/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: context-management
 description: Unified protocol for context health and session lifecycle management using DCP tools, thresholds, handoff, resume workflows, and post-compaction restoration.
-version: 3.0.0
-tags: [context, workflow, session]
+version: 1.0.0
+tags: [context, workflow]
 dependencies: []
 ---
 

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

@@ -105,16 +105,23 @@ grep({ pattern: "<function name>", include: "*test*" });
 
 ### Phase 4: External Research (If Needed)
 
-Only if internal exploration doesn't answer the question:
+Only if internal exploration doesn't answer the question, apply [research-tool-routing](../research-tool-routing/SKILL.md): Context7 for library/API docs, Webclaw for URL extraction/crawling/current web content, and Exa only as optional power-preset semantic/deep search.
 
 ```typescript
 // Official docs
 context7({ operation: "resolve", libraryName: "<lib>" });
 context7({ operation: "query", libraryId: "<id>", topic: "<specific question>" });
 
+// URL/current web content (primary for arbitrary pages)
+webclaw_scrape({ url: "<url>", format: "markdown" });
+webclaw_crawl({ url: "<docs-site>", depth: 2, max_pages: 50 });
+
 // Real-world patterns (adapt language parameter to project)
 codesearch({ query: "<API usage pattern>", tokensNum: 5000 });
 grepsearch({ query: "<code pattern>", language: "<project language>" });
+
+// Optional power preset only: semantic/deep web search
+// exa({ query: "<semantic/deep-search query>" });
 ```
 
 ## Confidence Levels

package/dist/template/{.opencode → opencode}/skill/deprecation-and-migration/SKILL.md

@@ -2,7 +2,7 @@
 name: deprecation-and-migration
 description: Use when deprecating APIs, migrating between library versions, removing legacy code, or planning breaking changes — covers deprecation notices, migration guides, codemods, and staged rollout
 version: 1.0.0
-tags: [architecture, workflow]
+tags: [documentation, workflow]
 dependencies: []
 ---
 

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

@@ -1,21 +1,28 @@
 ---
 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.
+version: 1.0.0
+tags: [design, ui, planning]
+dependencies: [anti-ai-slop]
 ---
 
 # 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
+## When to Use
 
+- When the design brief is vague or no brand/design context exists.
+- When the user needs concrete style directions before implementation.
 - 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
+## When NOT to Use
 
+- When the user already supplied a clear style, brand kit, Figma, screenshot, or reference site.
+- When implementation is mechanical and no design direction decision is needed.
 - 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

package/dist/template/{.opencode → opencode}/skill/design-system-audit/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: design-system-audit
 description: Use when auditing an existing design system for consistency — token audits, pattern analysis, visual comparison against design specs. Load AFTER implementation to review, not during initial build.
-version: 2.0.0
-tags: [design, audit, ui]
+version: 1.0.0
+tags: [design, ui, code-quality]
 dependencies: []
 ---
 

package/dist/template/{.opencode → opencode}/skill/design-taste-frontend/SKILL.md

@@ -1,6 +1,9 @@
 ---
 name: design-taste-frontend
 description: Use when building any web UI as the BASE aesthetic layer to override default LLM design biases. Enforces strict typography, color, spacing, and component architecture rules. Load BEFORE frontend-design when premium visual quality is required.
+version: 1.0.0
+tags: [design, ui, code-quality]
+dependencies: [frontend-design]
 ---
 
 ## When to Use

package/dist/template/{.opencode → opencode}/skill/development-lifecycle/SKILL.md

@@ -3,16 +3,7 @@ name: development-lifecycle
 description: Orchestrates the full feature development lifecycle from ideation through verification. Guides through phases (brainstorm → design → specify → plan → implement → verify) and loads appropriate sub-skills at each stage.
 version: 1.0.0
 tags: [workflow, planning]
-dependencies:
-  [
-    brainstorming,
-    prd,
-    writing-plans,
-    executing-plans,
-    verification-before-completion,
-    requesting-code-review,
-    finishing-a-development-branch,
-  ]
+dependencies: [brainstorming, prd, writing-plans, executing-plans, verification-before-completion, requesting-code-review, finishing-a-development-branch]
 ---
 
 ---

package/dist/template/{.opencode → opencode}/skill/executing-plans/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: executing-plans
 description: Use when a complete implementation plan exists — parses dependency waves, executes independent tasks in parallel via subagents, runs review checkpoints between waves
-version: 2.0.0
-tags: [workflow, planning, parallel]
-dependencies: [writing-plans]
+version: 1.0.0
+tags: [workflow, agent-coordination, planning]
+dependencies: []
 ---
 
 # Executing Plans

package/dist/template/{.opencode → opencode}/skill/figma-go/SKILL.md

@@ -6,7 +6,7 @@ mcp:
     command: npx
     args: ["-y", "@vkhanhqui/figma-mcp-go@latest"]
 version: 1.0.0
-tags: [design, mcp, figma]
+tags: [design, integration, mcp]
 dependencies: []
 ---
 

package/dist/template/{.opencode → opencode}/skill/finishing-a-development-branch/SKILL.md

@@ -176,20 +176,37 @@ Then: Cleanup worktree (Step 5)
 
 **For Options 1, 2, 4:**
 
-Check if in worktree:
+Check if the bead has a tracked worktree:
 
 ```bash
-git worktree list | grep $(git branch --show-current)
-```
-
-If yes:
-
-```bash
-git worktree remove <worktree-path>
+BEAD_ID="[current bead]"
+WORKTREE_FILE=".beads/artifacts/$BEAD_ID/worktree.txt"
+
+if [ -f "$WORKTREE_FILE" ]; then
+  WORKTREE_PATH="$(cat "$WORKTREE_FILE")"
+  CURRENT_ROOT="$(git rev-parse --show-toplevel)"
+
+  if [ "$CURRENT_ROOT" = "$WORKTREE_PATH" ]; then
+    echo "Currently in tracked bead worktree: $WORKTREE_PATH"
+  fi
+
+  # Validate worktree still exists
+  if git worktree list --porcelain | grep -F "worktree $WORKTREE_PATH" >/dev/null; then
+    echo "Valid worktree found. Removing..."
+    git worktree remove "$WORKTREE_PATH"
+    rm -f "$WORKTREE_FILE"
+  else
+    echo "Stale worktree reference. Cleaning up tracking file..."
+    rm -f "$WORKTREE_FILE"
+    git worktree prune
+  fi
+fi
 ```
 
 **For Option 3:** Keep worktree.
 
+**Recommendation:** Use `/cleanup <bead-id>` for the full cleanup flow including PR status verification and bead closing.
+
 ## Quick Reference
 
 | Option           | Merge | Push | Keep Worktree | Cleanup Branch |

package/dist/template/{.opencode → opencode}/skill/full-output-enforcement/SKILL.md

@@ -1,6 +1,9 @@
 ---
 name: full-output-enforcement
 description: MUST load when generating complete files, long code blocks, or any output where truncation or placeholder comments like '// ... rest of code' would be harmful. Bans all placeholder patterns and enforces exhaustive, unabridged output.
+version: 1.0.0
+tags: [code-quality, documentation]
+dependencies: []
 ---
 
 ## When to Use

package/dist/template/{.opencode → opencode}/skill/hi-fi-prototype-html/SKILL.md

@@ -1,12 +1,23 @@
 ---
 name: hi-fi-prototype-html
 description: Use when building high-fidelity HTML prototypes, interactive product mockups, app/iOS/Android screen demos, or design-variation explorations (NOT production web apps — use frontend-design for that). Enforces Junior Designer mode (show assumptions early, iterate), single-file inline React for double-clickable mockups, real images instead of generic placeholders, and Playwright click-test before delivery.
+version: 1.0.0
+tags: [design, ui, automation]
+dependencies: [playwright]
 ---
 
 # Hi-Fi Prototype (HTML as Medium)
 
 > Adapted from `huashu-design`. HTML is your **medium**, not your destination. You are a designer who happens to use HTML, not a developer who happens to be designing.
 
+## When NOT to Use
+
+- For production web apps with real backends; use frontend-design instead.
+- For low-fidelity sketches where a static wireframe is enough.
+- Production web apps with real backends → `frontend-design` + `react-best-practices`
+- SEO/marketing sites → `frontend-design`
+- Component library work → `mockup-to-code` (mockup → production component)
+
 ## When to Use
 
 - **Interactive prototypes** — clickable product mockups for user testing or design review
@@ -15,12 +26,6 @@ description: Use when building high-fidelity HTML prototypes, interactive produc
 - **Concept demos** — convey an interaction or feel before any production code
 - **Information graphics** with hand-tuned typography
 
-**Don't use for**:
-
-- Production web apps with real backends → `frontend-design` + `react-best-practices`
-- SEO/marketing sites → `frontend-design`
-- Component library work → `mockup-to-code` (mockup → production component)
-
 ## Core Discipline
 
 ### 1. Start From Existing Context — Don't Design From Air

package/dist/template/{.opencode → opencode}/skill/high-end-visual-design/SKILL.md

@@ -1,6 +1,9 @@
 ---
 name: high-end-visual-design
 description: Use INSTEAD OF design-taste-frontend when user explicitly requests premium, agency-quality, or luxury visual design. Defines exact fonts, spacing, shadows, and animations that make websites feel expensive. Blocks cheap AI defaults.
+version: 1.0.0
+tags: [design, ui]
+dependencies: [frontend-design]
 ---
 
 ## When to Use

package/dist/template/{.opencode → opencode}/skill/html-deck-export/SKILL.md

@@ -1,12 +1,27 @@
 ---
 name: html-deck-export
 description: Use when building HTML-based slide decks that need to ship as PDF or editable PPTX. MUST load BEFORE writing the first line of HTML if PPTX (with editable text) is a delivery target — choosing the wrong architecture costs 2-3 hours of rework. Covers multi-file vs single-file deck architecture, browser presentation, PDF export, and the 4 hard constraints for editable PPTX.
+version: 1.0.0
+tags: [design, documentation, automation]
+dependencies: []
 ---
 
 # HTML Deck Export
 
 > Adapted from `huashu-design`. The hardest checkpoint isn't "single-file or multi-file" — it's **"what's the final delivery format?"** Get this wrong and you're rewriting 17 pages of HTML.
 
+
+
+## When NOT to Use
+
+- When the deliverable is not a slide deck.
+- When the deck already has a settled non-HTML authoring workflow.
+
+## When to Use
+
+- When building HTML slide decks that must ship as PDF or editable PPTX.
+- Before writing deck HTML when the final export format is not yet settled.
+
 ## The Critical Decision (Before First Line of HTML)
 
 ```

package/dist/template/{.opencode → opencode}/skill/incremental-implementation/SKILL.md

@@ -2,8 +2,8 @@
 name: incremental-implementation
 description: Use when implementing features or fixes to enforce thin vertical slices with verify-after-each — prevents large, untested changes by requiring working code at every step
 version: 1.0.0
-tags: [workflow, implementation, code-quality]
-dependencies: [test-driven-development, verification-before-completion]
+tags: [workflow, code-quality, testing]
+dependencies: []
 ---
 
 # Incremental Implementation

package/dist/template/{.opencode → opencode}/skill/industrial-brutalist-ui/SKILL.md

@@ -1,6 +1,9 @@
 ---
 name: industrial-brutalist-ui
 description: Use INSTEAD OF design-taste-frontend when user requests brutalist, military-terminal, or raw mechanical aesthetics. Swiss typographic print meets utilitarian color. For data-heavy dashboards or editorial sites needing declassified-blueprint energy.
+version: 1.0.0
+tags: [design, ui]
+dependencies: [frontend-design]
 ---
 
 ## When to Use

package/dist/template/{.opencode → opencode}/skill/memory-grounding/SKILL.md

@@ -3,7 +3,8 @@ name: memory-grounding
 description: >
   Use at the start of any command that needs prior context — searches memory for decisions, patterns, and handoffs before execution to avoid re-solving solved problems.
 version: 1.0.0
-tags: [memory, grounding, pre-flight]
+tags: [context, workflow]
+dependencies: []
 ---
 
 # Memory Grounding

package/dist/template/{.opencode → opencode}/skill/minimalist-ui/SKILL.md

@@ -1,6 +1,9 @@
 ---
 name: minimalist-ui
 description: Use INSTEAD OF design-taste-frontend when user requests clean, editorial, or minimalist aesthetics. Warm monochrome palette, typographic contrast, flat bento grids, muted pastels. No gradients, no heavy shadows.
+version: 1.0.0
+tags: [design, ui]
+dependencies: [frontend-design]
 ---
 
 ## When to Use

package/dist/template/{.opencode → opencode}/skill/performance-optimization/SKILL.md

@@ -2,7 +2,7 @@
 name: performance-optimization
 description: Use when profiling, optimizing, or adding performance budgets to applications — covers measure-first workflow, Core Web Vitals, common anti-patterns, and performance regression prevention
 version: 1.0.0
-tags: [performance, code-quality]
+tags: [code-quality, testing]
 dependencies: []
 ---
 

package/dist/template/{.opencode → opencode}/skill/prd-task/SKILL.md

@@ -175,7 +175,7 @@ Next: Create detailed implementation plan
   skill({ name: "writing-plans" })
 
 Or start execution directly:
-  /start <bead-id>
+  /ship <bead-id>
 
 Full lifecycle reference:
   skill({ name: "development-lifecycle" })

package/dist/template/{.opencode → opencode}/skill/prompt-leverage/SKILL.md

@@ -4,12 +4,23 @@ description: >-
   Strengthen raw user prompts into execution-ready instruction sets. Use when processing
   user input to upgrade it with clear objective, context, work style, tool rules, output
   contract, verification, and done criteria before planning or execution.
-metadata:
-  dependencies: []
+version: 1.0.0
+tags: [workflow, planning, code-quality]
+dependencies: []
 ---
 
 # Prompt Leverage
 
+## When NOT to Use
+
+- When the user prompt is already execution-ready and precise.
+- When the task is a simple factual answer or one-command action.
+
+## When to Use
+
+- When a raw user prompt needs to be strengthened before planning or execution.
+- When objectives, constraints, tool rules, or done criteria are implicit and need to be made explicit.
+
 Strengthen the user's current prompt into a stronger working instruction set without changing the underlying intent. Preserve the task, fill in missing execution structure, and add only enough scaffolding to improve reliability.
 
 This skill acts as a **pre-processing layer** — it runs on user input BEFORE planning/execution to ensure every prompt is execution-ready.

package/dist/template/{.opencode → opencode}/skill/reconcile/SKILL.md

@@ -5,8 +5,8 @@ description: >
   and actual code, identifies missing features, extra features, and diverged behavior. Load after /ship
   or before closing a bead.
 version: 1.0.0
-tags: [workflow, verification, quality]
-dependencies: [verification-before-completion]
+tags: [testing, code-quality, planning]
+dependencies: []
 ---
 
 # Reconcile — Spec↔Code Drift Detection

package/dist/template/{.opencode → opencode}/skill/redesign-existing-projects/SKILL.md

@@ -1,6 +1,9 @@
 ---
 name: redesign-existing-projects
 description: Use when upgrading an existing website or app's visual design to premium quality. Audits current design, identifies generic AI patterns, applies high-end standards without breaking functionality. MUST load before any design overhaul of existing projects.
+version: 1.0.0
+tags: [design, ui, code-quality]
+dependencies: [frontend-design]
 ---
 
 ## When to Use