wormclaude 1.0.12 → 1.0.13

package/extensions/conductor/templates/code_styleguides/go.md

@@ -0,0 +1,48 @@
+# Effective Go Style Guide Summary
+
+This document summarizes key rules and best practices from the official "Effective Go" guide for writing idiomatic Go code.
+
+## 1. Formatting
+- **gofmt**: All Go code must be formatted with `gofmt` (or `go fmt`). This is a non-negotiable, automated standard.
+- **Indentation**: Use tabs for indentation (gofmt handles this).
+- **Line Length**: Go has no strict line length limit. Let gofmt handle line wrapping.
+
+## 2. Naming
+- **MixedCaps**: Use `MixedCaps` or `mixedCaps` for multi-word names. Do not use underscores.
+- **Exported vs. Unexported**: Names starting with an uppercase letter are exported (public). Names starting with a lowercase letter are not exported (private).
+- **Package Names**: Short, concise, single-word, lowercase names.
+- **Getters**: Do not name getters with a `Get` prefix. A getter for a field named `owner` should be named `Owner()`.
+- **Interface Names**: One-method interfaces are named by the method name plus an `-er` suffix (e.g., `Reader`, `Writer`).
+
+## 3. Control Structures
+- **if**: No parentheses around the condition. Braces are mandatory. Can include an initialization statement (e.g., `if err := file.Chmod(0664); err != nil`).
+- **for**: Go's only looping construct. Unifies `for` and `while`. Use `for...range` to iterate over slices, maps, strings, and channels.
+- **switch**: More general than in C. Cases do not fall through by default (use `fallthrough` explicitly). Can be used without an expression to function as a cleaner if-else-if chain.
+
+## 4. Functions
+- **Multiple Returns**: Functions can return multiple values. This is the standard way to return a result and an error (e.g., `value, err`).
+- **Named Result Parameters**: Return parameters can be named. This can make code clearer and more concise.
+- **defer**: Schedules a function call to be run immediately before the function executing `defer` returns. Use it for cleanup tasks like closing files.
+
+## 5. Data
+- **new vs. make**:
+  - `new(T)`: Allocates memory for a new item of type T, zeroes it, and returns a pointer (`*T`).
+  - `make(T, ...)`: Creates and initializes slices, maps, and channels only. Returns an initialized value of type T (not a pointer).
+- **Slices**: The preferred way to work with sequences. They are more flexible than arrays.
+- **Maps**: Use the "comma ok" idiom to check for the existence of a key: `value, ok := myMap[key]`.
+
+## 6. Interfaces
+- **Implicit Implementation**: A type implements an interface by implementing its methods. No `implements` keyword is needed.
+- **Small Interfaces**: Prefer many small interfaces over one large one. The standard library is full of single-method interfaces (e.g., `io.Reader`).
+
+## 7. Concurrency
+- **Share Memory By Communicating**: This is the core philosophy. Do not communicate by sharing memory; instead, share memory by communicating.
+- **Goroutines**: Lightweight, concurrently executing functions. Start one with the `go` keyword.
+- **Channels**: Typed conduits for communication between goroutines. Use `make` to create them.
+
+## 8. Errors
+- **error type**: The built-in `error` interface is the standard way to handle errors.
+- **Explicit Error Handling**: Do not discard errors with the blank identifier (`_`). Check for errors explicitly.
+- **panic**: Reserved for truly exceptional, unrecoverable situations. Generally, libraries should not panic.
+
+Source: Effective Go

package/extensions/conductor/templates/code_styleguides/html-css.md

@@ -0,0 +1,49 @@
+# Google HTML/CSS Style Guide Summary
+
+This document summarizes key rules and best practices from the Google HTML/CSS Style Guide.
+
+## 1. General Rules
+- **Protocol**: Use HTTPS for all embedded resources.
+- **Indentation**: Indent by 2 spaces. Do not use tabs.
+- **Capitalization**: Use only lowercase for all code (element names, attributes, selectors, properties).
+- **Trailing Whitespace**: Remove all trailing whitespace.
+- **Encoding**: Use UTF-8 (without a BOM). Specify `<meta charset="utf-8">` in HTML.
+
+## 2. HTML Style Rules
+- **Document Type**: Use `<!doctype html>`.
+- **HTML Validity**: Use valid HTML.
+- **Semantics**: Use HTML elements according to their intended purpose (e.g., use `<p>` for paragraphs, not for spacing).
+- **Multimedia Fallback**: Provide `alt` text for images and transcripts/captions for audio/video.
+- **Separation of Concerns**: Strictly separate structure (HTML), presentation (CSS), and behavior (JavaScript). Link to CSS and JS from external files.
+- **type Attributes**: Omit `type` attributes for stylesheets (`<link>`) and scripts (`<script>`).
+
+## 3. HTML Formatting Rules
+- **General**: Use a new line for every block, list, or table element, and indent its children.
+- **Quotation Marks**: Use double quotation marks (`""`) for attribute values.
+
+## 4. CSS Style Rules
+- **CSS Validity**: Use valid CSS.
+- **Class Naming**: Use meaningful, generic names. Separate words with a hyphen (`-`).
+  - Good: `.video-player`, `.site-navigation`
+  - Bad: `.vid`, `.red-text`
+- **ID Selectors**: Avoid using ID selectors for styling. Prefer class selectors.
+- **Shorthand Properties**: Use shorthand properties where possible (e.g., `padding`, `font`).
+- **0 and Units**: Omit units for 0 values (e.g., `margin: 0;`).
+- **Leading 0s**: Always include leading 0s for decimal values (e.g., `font-size: 0.8em;`).
+- **Hexadecimal Notation**: Use 3-character hex notation where possible (e.g., `#fff`).
+- **!important**: Avoid using `!important`.
+
+## 5. CSS Formatting Rules
+- **Declaration Order**: Alphabetize declarations within a rule.
+- **Indentation**: Indent all block content.
+- **Semicolons**: Use a semicolon after every declaration.
+- **Spacing**:
+  - Use a space after a property name's colon (`font-weight: bold;`).
+  - Use a space between the last selector and the opening brace (`.foo {`).
+  - Start a new line for each selector and declaration.
+- **Rule Separation**: Separate rules with a new line.
+- **Quotation Marks**: Use single quotes (`''`) for attribute selectors and property values (e.g., `[type='text']`).
+
+BE CONSISTENT. When editing code, match the existing style.
+
+Source: Google HTML/CSS Style Guide

package/extensions/conductor/templates/code_styleguides/javascript.md

@@ -0,0 +1,51 @@
+# Google JavaScript Style Guide Summary
+
+This document summarizes key rules and best practices from the Google JavaScript Style Guide.
+
+## 1. Source File Basics
+- **File Naming**: All lowercase, with underscores (`_`) or dashes (`-`). Extension must be `.js`.
+- **File Encoding**: UTF-8.
+- **Whitespace**: Use only ASCII horizontal spaces (0x20). Tabs are forbidden for indentation.
+
+## 2. Source File Structure
+- New files should be ES modules (`import`/`export`).
+- **Exports**: Use named exports (`export {MyClass};`). Do not use default exports.
+- **Imports**: Do not use line-wrapped imports. The `.js` extension in import paths is mandatory.
+
+## 3. Formatting
+- **Braces**: Required for all control structures (`if`, `for`, `while`, etc.), even single-line blocks. Use K&R style ("Egyptian brackets").
+- **Indentation**: +2 spaces for each new block.
+- **Semicolons**: Every statement must be terminated with a semicolon.
+- **Column Limit**: 80 characters.
+- **Line-wrapping**: Indent continuation lines at least +4 spaces.
+- **Whitespace**: Use single blank lines between methods. No trailing whitespace.
+
+## 4. Language Features
+- **Variable Declarations**: Use `const` by default, `let` if reassignment is needed. `var` is forbidden.
+- **Array Literals**: Use trailing commas. Do not use the `Array` constructor.
+- **Object Literals**: Use trailing commas and shorthand properties. Do not use the `Object` constructor.
+- **Classes**: Do not use JavaScript getter/setter properties (`get name()`). Provide ordinary methods instead.
+- **Functions**: Prefer arrow functions for nested functions to preserve `this` context.
+- **String Literals**: Use single quotes (`'`). Use template literals (`` ` ``) for multi-line strings or complex interpolation.
+- **Control Structures**: Prefer `for-of` loops. `for-in` loops should only be used on dict-style objects.
+- **this**: Only use `this` in class constructors, methods, or in arrow functions defined within them.
+- **Equality Checks**: Always use identity operators (`===` / `!==`).
+
+## 5. Disallowed Features
+- `with` keyword.
+- `eval()` or `Function(...string)`.
+- Automatic Semicolon Insertion.
+- Modifying builtin objects (`Array.prototype.foo = ...`).
+
+## 6. Naming
+- **Classes**: `UpperCamelCase`.
+- **Methods & Functions**: `lowerCamelCase`.
+- **Constants**: `CONSTANT_CASE` (all uppercase with underscores).
+- **Non-constant Fields & Variables**: `lowerCamelCase`.
+
+## 7. JSDoc
+- JSDoc is used on all classes, fields, and methods.
+- Use `@param`, `@return`, `@override`, `@deprecated`.
+- Type annotations are enclosed in braces (e.g., `/** @param {string} userName */`).
+
+Source: Google JavaScript Style Guide

package/extensions/conductor/templates/code_styleguides/python.md

@@ -0,0 +1,37 @@
+# Google Python Style Guide Summary
+
+This document summarizes key rules and best practices from the Google Python Style Guide.
+
+## 1. Python Language Rules
+- **Linting**: Run `pylint` on your code to catch bugs and style issues.
+- **Imports**: Use `import x` for packages/modules. Use `from x import y` only when `y` is a submodule.
+- **Exceptions**: Use built-in exception classes. Do not use bare `except:` clauses.
+- **Global State**: Avoid mutable global state. Module-level constants are okay and should be `ALL_CAPS_WITH_UNDERSCORES`.
+- **Comprehensions**: Use for simple cases. Avoid for complex logic where a full loop is more readable.
+- **Default Argument Values**: Do not use mutable objects (like `[]` or `{}`) as default values.
+- **True/False Evaluations**: Use implicit false (e.g., `if not my_list:`). Use `if foo is None:` to check for None.
+- **Type Annotations**: Strongly encouraged for all public APIs.
+
+## 2. Python Style Rules
+- **Line Length**: Maximum 80 characters.
+- **Indentation**: 4 spaces per indentation level. Never use tabs.
+- **Blank Lines**: Two blank lines between top-level definitions (classes, functions). One blank line between method definitions.
+- **Whitespace**: Avoid extraneous whitespace. Surround binary operators with single spaces.
+- **Docstrings**: Use `"""triple double quotes"""`. Every public module, function, class, and method must have a docstring.
+  - Format: Start with a one-line summary. Include `Args:`, `Returns:`, and `Raises:` sections.
+- **Strings**: Use f-strings for formatting. Be consistent with single (`'`) or double (`"`) quotes.
+- **TODO Comments**: Use `TODO(username): Fix this.` format.
+- **Imports Formatting**: Imports should be on separate lines and grouped: standard library, third-party, and your own application's imports.
+
+## 3. Naming
+- **General**: `snake_case` for modules, functions, methods, and variables.
+- **Classes**: `PascalCase`.
+- **Constants**: `ALL_CAPS_WITH_UNDERSCORES`.
+- **Internal Use**: Use a single leading underscore (`_internal_variable`) for internal module/class members.
+
+## 4. Main
+- All executable files should have a `main()` function that contains the main logic, called from a `if __name__ == '__main__':` block.
+
+BE CONSISTENT. When editing code, match the existing style.
+
+Source: Google Python Style Guide

package/extensions/conductor/templates/code_styleguides/typescript.md

@@ -0,0 +1,43 @@
+# Google TypeScript Style Guide Summary
+
+This document summarizes key rules and best practices from the Google TypeScript Style Guide, which is enforced by the `gts` tool.
+
+## 1. Language Features
+- **Variable Declarations**: Always use `const` or `let`. `var` is forbidden. Use `const` by default.
+- **Modules**: Use ES6 modules (`import`/`export`). Do not use `namespace`.
+- **Exports**: Use named exports (`export {MyClass};`). Do not use default exports.
+- **Classes**:
+  - Do not use `#private` fields. Use TypeScript's `private` visibility modifier.
+  - Mark properties never reassigned outside the constructor with `readonly`.
+  - Never use the `public` modifier (it's the default). Restrict visibility with `private` or `protected` where possible.
+- **Functions**: Prefer function declarations for named functions. Use arrow functions for anonymous functions/callbacks.
+- **String Literals**: Use single quotes (`'`). Use template literals (`` ` ``) for interpolation and multi-line strings.
+- **Equality Checks**: Always use triple equals (`===`) and not equals (`!==`).
+- **Type Assertions**: Avoid type assertions (`x as SomeType`) and non-nullability assertions (`y!`). If you must use them, provide a clear justification.
+
+## 2. Disallowed Features
+- **any Type**: Avoid `any`. Prefer `unknown` or a more specific type.
+- **Wrapper Objects**: Do not instantiate `String`, `Boolean`, or `Number` wrapper classes.
+- **Automatic Semicolon Insertion (ASI)**: Do not rely on it. Explicitly end all statements with a semicolon.
+- **const enum**: Do not use `const enum`. Use plain `enum` instead.
+- **eval() and Function(...string)**: Forbidden.
+
+## 3. Naming
+- **UpperCamelCase**: For classes, interfaces, types, enums, and decorators.
+- **lowerCamelCase**: For variables, parameters, functions, methods, and properties.
+- **CONSTANT_CASE**: For global constant values, including enum values.
+- **_ Prefix/Suffix**: Do not use `_` as a prefix or suffix for identifiers, including for private properties.
+
+## 4. Type System
+- **Type Inference**: Rely on type inference for simple, obvious types. Be explicit for complex types.
+- **undefined and null**: Both are supported. Be consistent within your project.
+- **Optional vs. |undefined**: Prefer optional parameters and fields (`?`) over adding `|undefined` to the type.
+- **Array<T> Type**: Use `T[]` for simple types. Use `Array<T>` for more complex union types (e.g., `Array<string | number>`).
+- **{} Type**: Do not use `{}`. Prefer `unknown`, `Record<string, unknown>`, or `object`.
+
+## 5. Comments and Documentation
+- **JSDoc**: Use `/** JSDoc */` for documentation, `//` for implementation comments.
+- **Redundancy**: Do not declare types in `@param` or `@return` blocks (e.g., `/** @param {string} user */`). This is redundant in TypeScript.
+- **Add Information**: Comments must add information, not just restate the code.
+
+Source: Google TypeScript Style Guide

package/extensions/conductor/templates/general.md

@@ -0,0 +1,23 @@
+# General Code Style Principles
+
+This document outlines general coding principles that apply across all languages and frameworks used in this project.
+
+## Readability
+- Code should be easy to read and understand by humans.
+- Avoid overly clever or obscure constructs.
+
+## Consistency
+- Follow existing patterns in the codebase.
+- Maintain consistent formatting, naming, and structure.
+
+## Simplicity
+- Prefer simple solutions over complex ones.
+- Break down complex problems into smaller, manageable parts.
+
+## Maintainability
+- Write code that is easy to modify and extend.
+- Minimize dependencies and coupling.
+
+## Documentation
+- Document why something is done, not just what.
+- Keep documentation up-to-date with code changes.

package/extensions/conductor/templates/plan.md

@@ -0,0 +1,18 @@
+# Project Plan
+
+> Source of truth for all work. Status markers: `[ ]` todo · `[~]` in progress · `[x]` done.
+> Append the short commit SHA after a task when it is committed.
+
+## Phase 1: <phase name> [checkpoint: <sha>]
+
+- [ ] Task: <small, specific, testable task with clear acceptance criteria>
+- [ ] Task: <...>
+
+## Phase 2: <phase name>
+
+- [ ] Task: <...>
+
+---
+
+## Backlog / Ideas
+- <things noticed but not yet scheduled>

package/extensions/conductor/templates/product-guidelines.md

@@ -0,0 +1,25 @@
+# Product & Design Guidelines
+
+## Design Principles
+- Clean, modern aesthetics with generous whitespace.
+- Responsive and accessible by default (keyboard, contrast, screen readers).
+- Consistency over novelty — reuse existing components and patterns.
+
+## UX Rules
+- Prioritize the user's primary task; reduce steps and friction.
+- Clear, human error messages; never expose raw stack traces to users.
+- Feedback for every action (loading, success, failure states).
+
+## Visual
+- Typography-led hierarchy; import fonts from Google Fonts.
+- Do not add icon libraries unless explicitly requested.
+- Mobile: adequate touch targets (~44x44px), readable without zoom.
+
+## Content & Tone
+- Concise, direct, friendly. Match the product's audience.
+
+## Accessibility Checklist
+- [ ] Semantic HTML / proper roles
+- [ ] Keyboard navigable
+- [ ] Sufficient color contrast
+- [ ] Alt text for meaningful images

package/extensions/conductor/templates/product.md

@@ -0,0 +1,21 @@
+# Product Specification
+
+## Overall Goal
+<One or two sentences: what this product is and who it's for.>
+
+## Core Features
+1. <feature> — <what it does, why it matters>
+2. <feature> — <...>
+
+## User Stories
+- As a <user>, I want to <action> so that <benefit>.
+
+## Requirements
+- **Functional:** <what the system must do>
+- **Non-functional:** <performance, security, accessibility, platforms>
+
+## Out of Scope
+- <explicitly not building, to avoid scope creep>
+
+## Success Criteria
+- <how we know it works / is done>

package/extensions/conductor/templates/tech-stack.md

@@ -0,0 +1,25 @@
+# Tech Stack
+
+> Document technology decisions here BEFORE implementing changes that deviate from them.
+> Add a dated note whenever a decision changes.
+
+## Languages & Runtimes
+- <e.g. TypeScript (Node.js 20), Python 3.12>
+
+## Frameworks & Key Libraries
+- <e.g. Next.js, FastAPI, Tailwind — and why>
+
+## Data & Infrastructure
+- <database, hosting, queues, external services>
+
+## Build / Test / Lint Commands
+- Setup: <e.g. npm install>
+- Dev: <e.g. npm run dev>
+- Test: <e.g. npm test>
+- Lint/Format/Types: <e.g. npm run lint · tsc>
+
+## Architecture Notes
+- <high-level structure, important patterns, directory layout>
+
+## Decision Log
+- YYYY-MM-DD — <decision and the reason>

package/extensions/conductor/templates/workflow.md

@@ -0,0 +1,138 @@
+# Project Workflow
+
+How WormClaude works on software tasks inside a user's project. Adapt every concrete command to the project's actual language, framework, and OS (Windows/PowerShell vs. POSIX).
+
+## Guiding Principles
+
+1. **Track the work as you go:** Use `TodoWrite` for any task with 3+ steps. The todo list is the live source of truth for what is done and what remains.
+2. **Project conventions live in `WORMCLAUDE.md`:** Run `/init` to scaffold it. Record the tech stack, build/test commands, and architectural decisions there. Update it *before* implementing a change that deviates from what is documented.
+3. **Test where a test setup exists:** When the project has (or warrants) tests, write or update them alongside the change. Prefer test-first for well-specified logic; confirm tests fail before, pass after.
+4. **Reasonable coverage:** Aim to cover new logic and its obvious edge/failure cases — not a coverage number for its own sake.
+5. **Match the existing code:** Follow the project's established patterns and the rules in `code_styleguides/` and `general.md`. Consistency beats personal preference.
+6. **Non-interactive & OS-aware:** Prefer non-interactive commands. Pass `CI=true` / `-y` / `--yes` to avoid watch-mode and prompts. On Windows use PowerShell-correct commands; do not assume a Unix shell.
+7. **Act, don't just describe:** When asked to build or change something, use the tools (Write/Edit/Bash) to actually do it — don't paste code and stop.
+
+## Task Workflow
+
+For a typical coding task:
+
+1. **Understand & track:** Read the relevant files first. Break the task into a `TodoWrite` list; mark one item `in_progress` at a time.
+
+2. **(If testing) Write the test first:** Create/extend a test that defines the expected behavior. Run it and confirm it fails for the right reason before implementing.
+
+3. **Implement:** Write the minimum code to satisfy the requirement (and make the test pass). Read a file before you Edit/overwrite it.
+
+4. **Verify:** Run the test suite and/or exercise the feature with a Bash command. Run the project's linter/formatter/type-checker if it has one.
+
+5. **Refactor (optional):** With tests green, tidy naming, remove duplication, and simplify — then re-run tests.
+
+6. **Document deviations:** If the implementation diverges from `WORMCLAUDE.md` (new dependency, different approach), update `WORMCLAUDE.md` with a short dated note explaining why, then continue.
+
+7. **Report:** Briefly state what changed — files created/modified and how to run/test it. Do not reprint full file contents unless asked.
+
+8. **Commit (only when the user asks):** Stage the related changes and commit with a clear conventional message (see below). For large or multi-step work, a one-paragraph summary of *why* in the commit body is enough — no special tooling required.
+
+> For large multi-phase work, treat each finished phase as a checkpoint: make sure its tests pass, summarize what was verified, and (if the user wants) tag/commit it before moving on.
+
+## Quality Gates
+
+Before calling a task done, check what applies:
+
+- [ ] Tests pass (where tests exist)
+- [ ] New logic and its edge/failure cases are covered
+- [ ] Code follows the project's style (`code_styleguides/`, `general.md`) and existing patterns
+- [ ] Public functions/types are documented where the project documents them (docstrings, JSDoc, GoDoc)
+- [ ] Type safety respected (type hints / TS types / Go types)
+- [ ] No new linting or static-analysis errors
+- [ ] Works on the target surfaces (incl. mobile/responsive **if** it's a web/mobile UI)
+- [ ] Docs updated if behavior changed
+- [ ] No secrets committed and no obvious vulnerability introduced
+
+## Development Commands
+
+Adapt to the project's language/framework/build tools. Record the real commands in `WORMCLAUDE.md` once known.
+
+```bash
+# Setup       — install deps / configure   (e.g. npm install · go mod tidy · pip install -r requirements.txt)
+# Develop     — run/test/lint               (e.g. npm run dev · npm test · go test ./... · pytest)
+# Pre-commit  — format + lint + types       (e.g. npm run check · go fmt ./... · ruff check)
+```
+
+## Testing Requirements
+
+**Unit**
+- Cover each module's core logic; test both success and failure paths.
+- Use the project's setup/teardown idioms (fixtures, beforeEach/afterEach).
+- Mock external dependencies (network, DB, filesystem) where appropriate.
+
+**Integration** (when relevant)
+- Exercise complete flows, auth/authorization, DB transactions, and form/API submissions.
+
+**Mobile / responsive** (only if the project has a mobile or web UI)
+- Verify responsive layouts and touch interactions; check performance on slower networks.
+
+## Self-Review Checklist
+
+Before considering a change finished:
+
+1. **Functionality** — works as specified; edge cases handled; error messages are clear and user-friendly.
+2. **Code quality** — follows the style guide; DRY; clear names; comments explain *why*, not *what*.
+3. **Testing** — tests are meaningful and pass; coverage adequate for the change.
+4. **Security** — no hardcoded secrets; input validated; injection (SQL/command/SSTI) and XSS prevented.
+5. **Performance** — queries/loops reasonable; assets and caching sensible where it matters.
+6. **UX** — if there's a UI: adequate touch targets, readable text, responsive, interactions feel native.
+
+## Commit Guidelines
+
+Conventional Commits format:
+
+```
+<type>(<scope>): <description>
+
+[optional body — the "why"]
+[optional footer]
+```
+
+**Types:** `feat` (feature) · `fix` (bug) · `docs` · `style` (formatting) · `refactor` · `test` · `chore` (maintenance).
+
+```bash
+git commit -m "feat(auth): add remember-me option"
+git commit -m "fix(posts): correct excerpt for short posts"
+git commit -m "test(comments): cover emoji reaction limits"
+```
+
+## Definition of Done
+
+1. Implemented to spec.
+2. Tests written and passing (where tests apply).
+3. Coverage adequate for the change.
+4. Docs updated if behavior changed.
+5. Passes the project's lint / static-analysis.
+6. Works on the target surfaces (incl. mobile **if** applicable).
+7. Notable decisions noted in `WORMCLAUDE.md`.
+8. (If the user asked) committed with a proper message.
+
+## Emergency Procedures
+
+**Critical bug in production**
+1. Branch a hotfix from main. 2. Write a failing test for the bug. 3. Implement the minimal fix. 4. Test thoroughly. 5. Deploy. 6. Note the incident in `WORMCLAUDE.md`.
+
+**Data loss**
+1. Stop write operations. 2. Restore from the latest backup. 3. Verify integrity. 4. Document the incident. 5. Improve the backup procedure.
+
+**Security breach**
+1. Rotate all secrets immediately. 2. Review access logs. 3. Patch the vulnerability. 4. Notify affected users if any. 5. Document and harden.
+
+## Deployment Workflow
+
+**Pre-deploy:** tests passing · no lint errors · env vars configured · DB migrations ready · backup created.
+
+**Deploy:** merge to main → tag the release → push to the deployment target → run migrations → verify → smoke-test critical paths → watch for errors.
+
+**Post-deploy:** monitor logs/analytics, gather feedback, plan the next iteration.
+
+## Continuous Improvement
+
+- Revisit this workflow when something repeatedly hurts; adjust it.
+- Document lessons learned in `WORMCLAUDE.md`.
+- Keep things simple and maintainable; optimize for the user's outcome.

package/extensions/conductor/wormclaude-extension.json

@@ -0,0 +1,6 @@
+{
+  "name": "conductor",
+  "version": "1.0.0",
+  "description": "Context-Driven Development: spec-driven planning, TDD workflow, and execution tracking.",
+  "contextFileName": "README.md"
+}

package/extensions/git-helper/README.md

@@ -0,0 +1,16 @@
+# Git Helper Extension
+
+Provides helpful Git workflow automation commands for common operations.
+
+## Commands
+
+- `/git:smart-commit` - Analyzes staged changes and generates a conventional commit message
+- `/git:branch-cleanup` - Helps clean up merged branches
+
+## Installation
+
+```
+wormclaude extensions install --from-registry git-helper
+```
+
+Or use `/browse-extensions` in the CLI and select this extension.

package/extensions/git-helper/commands/git/branch-cleanup.toml

@@ -0,0 +1,13 @@
+description = "Find and help delete local branches already merged into the main branch"
+prompt = """
+Help the user clean up stale local branches.
+
+Steps:
+1. Determine the main branch (`main` or `master`) and the current branch via `git branch` and `git symbolic-ref refs/remotes/origin/HEAD` (fallback: ask).
+2. List local branches already merged into main: `git branch --merged <main>` (exclude the main branch and the current branch).
+3. Show the list to the user with a one-line note that these appear fully merged and safe to delete.
+4. Only after the user confirms, delete them with `git branch -d <branch>` (safe delete — never `-D`/force unless the user explicitly insists).
+5. Report what was deleted.
+
+Never delete the main or current branch. Never touch remote branches. Never force-delete without explicit confirmation.
+"""

package/extensions/git-helper/commands/git/smart-commit.toml

@@ -0,0 +1,13 @@
+description = "Analyze staged changes and create a conventional commit message"
+prompt = """
+Create a high-quality commit for the currently staged changes.
+
+Steps:
+1. Run `git status` and `git diff --staged` to see exactly what is staged. If nothing is staged, run `git status` and ask the user what to stage (or suggest `git add`), then stop.
+2. Run `git log -n 5 --oneline` to match the repository's existing commit style.
+3. Write a Conventional Commits message: `<type>(<scope>): <description>` where type is one of feat, fix, docs, style, refactor, test, chore. Keep the subject under ~72 chars, imperative mood. Add a short body explaining the "why" only if the change is non-trivial.
+4. Show the user the proposed message and run `git commit -m "..."`.
+5. Confirm success with `git status`.
+
+Do NOT stage files the user didn't intend, and never push.
+"""

package/extensions/git-helper/wormclaude-extension.json

@@ -0,0 +1,6 @@
+{
+  "name": "git-helper",
+  "version": "1.0.0",
+  "description": "Git workflow automation: smart conventional commits and branch cleanup.",
+  "contextFileName": "README.md"
+}

package/extensions/greet/README.md

@@ -0,0 +1,76 @@
+# Greet Extension
+
+A simple greeting extension that demonstrates how to create on-demand extensions for WormClaude CLI.
+
+## Description
+
+This extension adds a friendly greeting command that says hello to users. It's a minimal example showing the basic structure of an on-demand extension.
+
+## Commands
+
+- `/greet` - Displays a friendly greeting message
+
+## Installation
+
+### Via Browse Extensions Dialog (Recommended)
+
+```bash
+# In the CLI
+/browse-extensions
+# Navigate to "greet" and press Enter or 'i' to install
+```
+
+### Via Command Line
+
+```bash
+wormclaude extensions install --from-registry greet
+```
+
+After installation, restart the CLI to use the extension.
+
+## Usage
+
+```bash
+# Start the CLI
+wormclaude
+
+# Use the greet command
+/greet
+```
+
+The command will display a friendly greeting message.
+
+## Example Output
+
+```
+👋 Hello! Welcome to WormClaude CLI!
+
+I'm here to help you with your development tasks.
+Have a great day! 🌟
+```
+
+## Extension Details
+
+- **Name**: greet
+- **Version**: 1.0.0
+- **Category**: fun
+- **Author**: WormClaude Team
+
+## Purpose
+
+This extension serves as:
+1. A simple example for developers learning to create extensions
+2. A friendly welcome message for new users
+3. A demonstration of the on-demand extension system
+
+## Contributing
+
+Feel free to enhance this extension by:
+- Adding personalized greetings
+- Including time-based greetings (morning, afternoon, evening)
+- Adding multi-language support
+- Including motivational quotes
+
+## License
+
+Same as WormClaude CLI

package/extensions/greet/commands/greet.toml

@@ -0,0 +1,4 @@
+description = "Display a friendly greeting"
+prompt = """
+Greet the user warmly as WormClaude CLI. Say hello, mention you can help with coding and security tasks, and wish them a productive session. Keep it to 2-3 short lines. Reply in the user's language.
+"""

package/extensions/greet/wormclaude-extension.json

@@ -0,0 +1,6 @@
+{
+  "name": "greet",
+  "version": "1.0.0",
+  "description": "A simple greeting command — minimal example extension.",
+  "contextFileName": "README.md"
+}