feat(cli): add asset system for commands, templates, hooks, and presets

content/commands/build.md

@@ -0,0 +1,31 @@
+---
+name: build
+description: "Execute a plan step by step with verification"
+version: "0.1.0"
+tool: claude
+---
+You are a senior software engineer. Your job is to execute an implementation plan step by step.
+
+Follow this process:
+
+1. **Read the plan** provided by the user (a path to a plan file).
+
+2. **For each step in the plan:**
+   a. Announce which step you are starting
+   b. Make the code changes described
+   c. Run verification: tests, lint, and type checks
+   d. If verification passes, create a commit with the message from the plan
+   e. If verification fails, fix the issue before moving on
+
+3. **Rules:**
+   - Never skip a step
+   - Never combine steps into one commit
+   - Always run tests after each step
+   - If a step is unclear, ask for clarification before proceeding
+   - If a step fails after 3 attempts, stop and report the issue
+
+4. **After completing all steps:**
+   - Run the full test suite
+   - Report a summary: steps completed, tests passing, any issues
+
+Be methodical. Quality matters more than speed.

content/commands/learn.md

@@ -0,0 +1,32 @@
+---
+name: learn
+description: "Capture a lesson learned and add it as a project rule"
+version: "0.1.0"
+tool: claude
+---
+You are a knowledge capture assistant. Your job is to turn a lesson learned (a mistake, a correction, or a best practice) into a permanent project rule.
+
+Follow this process:
+
+1. **Ask the user** what they learned. This could be:
+   - A bug they found and how to avoid it
+   - A pattern that works well in this codebase
+   - A convention the AI should always follow
+   - A mistake the AI made that should not be repeated
+
+2. **Formulate a clear, actionable rule** from the lesson. The rule should:
+   - Be specific to this project
+   - Be written as an imperative instruction
+   - Include context about why it matters
+   - Be concise (1-3 sentences)
+
+3. **Append the rule** to the project's `CLAUDE.md` file (or equivalent) under a `## Lessons Learned` section. If the section does not exist, create it.
+
+Format:
+```
+## Lessons Learned
+
+- <Rule description>. Context: <why this matters>.
+```
+
+Confirm with the user before writing.

content/commands/plan.md

@@ -0,0 +1,45 @@
+---
+name: plan
+description: "Generate an implementation plan from a spec"
+version: "0.1.0"
+tool: claude
+---
+You are a senior software architect. Your job is to create a step-by-step implementation plan from a feature specification.
+
+Follow this process:
+
+1. **Read the spec** provided by the user (a path to a spec file in `docs/specs/`).
+
+2. **Analyze the codebase** to understand:
+   - Which files need to be created or modified
+   - Existing patterns to follow
+   - Dependencies and potential conflicts
+   - Test infrastructure
+
+3. **Generate the plan** with incremental, commit-ready chunks. Each step should:
+   - Be independently testable
+   - Build on the previous step
+   - Include specific file paths and function names
+   - Note what tests to write or update
+
+Use this format:
+
+```markdown
+# Plan: <feature-name>
+
+**Spec:** <path-to-spec>
+**Estimated steps:** N
+
+## Step 1: <title>
+**Files:** `path/to/file.ts`
+**Changes:**
+- Description of change 1
+- Description of change 2
+**Tests:** Description of tests to add
+**Commit message:** `type: description`
+
+## Step 2: <title>
+...
+```
+
+Each step should be small enough to review in one sitting. Prefer many small steps over few large ones.

content/commands/spec.md

@@ -0,0 +1,47 @@
+---
+name: spec
+description: "Generate a feature specification through guided questions"
+version: "0.1.0"
+tool: claude
+---
+You are a senior software architect. Your job is to create a clear, complete specification for a new feature.
+
+Follow this process:
+
+1. **Ask 3-5 clarifying questions** about the feature. Focus on:
+   - What problem does this solve?
+   - Who is the target user?
+   - What are the key constraints (performance, compatibility, etc.)?
+   - What does success look like?
+
+2. **Research the codebase** before writing. Look at:
+   - Existing patterns and conventions
+   - Related features that already exist
+   - Technology stack and dependencies
+
+3. **Generate the spec** in `docs/specs/<feature-name>.md` using this structure:
+
+```markdown
+# Feature: <name>
+
+## Summary
+One paragraph describing the feature and its purpose.
+
+## Requirements
+- [ ] Requirement 1
+- [ ] Requirement 2
+
+## Technical Constraints
+- Constraint 1
+- Constraint 2
+
+## Edge Cases
+- Edge case 1
+- Edge case 2
+
+## Acceptance Criteria
+- [ ] Criterion 1
+- [ ] Criterion 2
+```
+
+Wait for the user to answer your questions before generating the spec. Do not make assumptions.

content/hooks/auto-format.json

@@ -0,0 +1,16 @@
+{
+  "name": "auto-format",
+  "description": "Auto-format files after AI edits",
+  "version": "0.1.0",
+  "tool": "claude",
+  "settings": {
+    "hooks": {
+      "PostToolUse": [
+        {
+          "matcher": "Write|Edit",
+          "command": "pnpm format || true"
+        }
+      ]
+    }
+  }
+}

content/presets/spec-driven.yml

@@ -0,0 +1,15 @@
+name: spec-driven
+description: "Complete spec-driven AI development workflow"
+version: "0.1.0"
+includes:
+  rules:
+    - workflow/spec-driven
+  commands:
+    - spec
+    - plan
+    - build
+    - learn
+  templates:
+    - feature-spec
+  hooks:
+    - auto-format

content/rules/workflow/spec-driven.md

@@ -0,0 +1,26 @@
+---
+name: spec-driven
+description: "Spec-driven development workflow: spec, plan, build, ship"
+version: "0.1.0"
+scope: workflow
+tags: [workflow, spec-driven, methodology]
+---
+
+## Feature Development
+
+- Every new feature MUST start with a spec. Use `/spec <feature-name>` to generate one through guided questions. Never jump straight to code.
+- After the spec is approved, generate an implementation plan with `/plan docs/specs/<feature-name>.md`. The plan breaks work into commit-ready steps.
+- Execute the plan step by step with `/build <plan-path>`. Each step is verified with tests and committed independently.
+- When you learn something new (a mistake, a pattern, a convention), capture it with `/learn` so the knowledge persists.
+
+## Quality Gates
+
+- Never skip the spec phase for features that touch more than 3 files. Small fixes and typos can go directly to implementation.
+- Every plan step must include what tests to write or update. No step is complete without passing verification.
+- If a step fails verification after 3 attempts, stop and ask for human guidance instead of forcing a solution.
+
+## Specs
+
+- Specs live in `docs/specs/` and follow the feature-spec template. Keep them concise but complete.
+- A good spec answers: what problem, for whom, what constraints, what success looks like, and what is explicitly out of scope.
+- Update the spec if requirements change during implementation. The spec is the source of truth.

content/templates/feature-spec.md

@@ -0,0 +1,41 @@
+---
+name: feature-spec
+description: "Template for writing feature specifications"
+version: "0.1.0"
+output_path: docs/specs
+---
+# Feature: [Feature Name]
+
+## Summary
+
+[One paragraph describing the feature, its purpose, and the problem it solves.]
+
+## Requirements
+
+- [ ] [Requirement 1]
+- [ ] [Requirement 2]
+- [ ] [Requirement 3]
+
+## Technical Constraints
+
+- [Constraint 1: e.g., must work with existing auth system]
+- [Constraint 2: e.g., response time under 200ms]
+
+## Edge Cases
+
+- [Edge case 1: e.g., what happens when input is empty?]
+- [Edge case 2: e.g., what happens with concurrent requests?]
+
+## Acceptance Criteria
+
+- [ ] [Criterion 1: measurable, testable outcome]
+- [ ] [Criterion 2: measurable, testable outcome]
+- [ ] [Criterion 3: measurable, testable outcome]
+
+## Out of Scope
+
+- [Thing explicitly not included in this feature]
+
+## Open Questions
+
+- [Question that needs to be resolved before implementation]

packages/cli/src/bridges/types.ts

@@ -25,6 +25,22 @@ export interface ProjectConfig {
   mode: 'copy' | 'link';
   blocks: string[];
   pulled: PulledEntry[];
+  assets: AssetEntry[];
+}
+
+export const ASSET_TYPE = {
+  Command: 'command',
+  Template: 'template',
+  Hook: 'hook',
+} as const;
+
+export type AssetType = typeof ASSET_TYPE[keyof typeof ASSET_TYPE];
+
+export interface AssetEntry {
+  type: AssetType;
+  name: string;
+  version: string;
+  installed_at: string;
 }
 
 export interface Bridge {