@xonovex/skills 0.1.0

package/skills/express.js-guidelines/reference/app-setup.md

@@ -0,0 +1,39 @@
+# app-setup: Basic Application Setup
+
+**Guideline:** Configure Express app with security, logging, body parsing, routes, and error handling in correct order.
+
+**Rationale:** Middleware order matters - security first, error handler last ensures proper request processing.
+
+**Example:**
+
+```typescript
+const app = express();
+
+// Security middleware (first)
+app.use(helmet());
+app.use(cors({origin: process.env.ALLOWED_ORIGINS?.split(","), credentials: true}));
+
+// Logging and parsing
+app.use(morgan("combined"));
+app.use(express.json());
+app.use(express.urlencoded({extended: true}));
+
+// Routes
+app.use("/api/users", userRoutes);
+app.use("/api/auth", authRoutes);
+
+// 404 handler
+app.use((req, res) => res.status(404).json({error: "Not found"}));
+
+// Error handler (last)
+app.use(errorHandler);
+```
+
+**Techniques:**
+- Middleware order: Security → logging → parsing → routes → 404 → error handler
+- helmet(): Add security headers (CSP, HSTS, X-Frame-Options, etc)
+- cors(): Configure allowed origins and credentials for cross-origin requests
+- morgan(): Log HTTP requests in combined format
+- express.json()/urlencoded(): Parse request bodies
+- 404 handler: Catch unmatched routes before error handler
+- Error handler: Must be last, receives 4 parameters (err, req, res, next)

package/skills/express.js-guidelines/reference/authentication.md

@@ -0,0 +1,39 @@
+# authentication: JWT Authentication
+
+**Guideline:** Implement JWT-based auth with middleware for authentication and role verification.
+
+**Rationale:** Stateless JWT tokens enable scalable authentication; role-based middleware enforces authorization at route level.
+
+**Example:**
+
+```typescript
+declare global { namespace Express {
+  interface Request { user?: JwtPayload; }
+}}
+
+export function requireAuth(req: Request, res: Response, next: NextFunction): void {
+  const token = req.headers.authorization?.replace("Bearer ", "");
+  if (!token) return res.status(401).json({error: "Missing token"});
+  try {
+    req.user = jwt.verify(token, process.env.JWT_SECRET!) as JwtPayload;
+    next();
+  } catch { res.status(401).json({error: "Invalid token"}); }
+}
+
+export function requireRole(...roles: string[]) {
+  return (req: Request, res: Response, next: NextFunction): void => {
+    if (!req.user) return res.status(401).json({error: "Not authenticated"});
+    if (!roles.includes(req.user.role)) return res.status(403).json({error: "Insufficient"});
+    next();
+  };
+}
+```
+
+**Techniques:**
+- Extend Express Request: Add optional user property with JwtPayload interface
+- requireAuth middleware: Verify Bearer token from Authorization header, attach user to request
+- requireRole middleware: Check user role against allowed roles, return 403 if insufficient
+- Sign tokens: Include userId, email, role with 7-day expiration
+- Bearer scheme: Use "Bearer TOKEN" format in Authorization header
+- Hash passwords: Compare with bcrypt instead of storing plaintext
+- Status codes: 401 for missing/invalid auth, 403 for insufficient permissions

package/skills/express.js-guidelines/reference/controllers.md

@@ -0,0 +1,49 @@
+# controllers: Controller Pattern
+
+**Guideline:** Implement async controllers with typed request/response, wrap in try-catch, pass errors to next().
+
+**Rationale:** Type-safe handlers with proper error handling ensure predictable API behavior.
+
+**Example:**
+
+```typescript
+export async function list(
+  req: Request<{}, {}, {}, ListUsersQuery>,
+  res: Response,
+  next: NextFunction,
+): Promise<void> {
+  try {
+    const {page, limit} = req.query;
+    const result = await userService.list({page, limit});
+    res.json({data: result.users, pagination: {page, limit, total: result.total}});
+  } catch (error) {
+    next(error);
+  }
+}
+
+export async function getById(
+  req: Request<UserParams>,
+  res: Response,
+  next: NextFunction,
+): Promise<void> {
+  try {
+    const user = await userService.getById(req.params.id);
+    if (!user) {
+      res.status(404).json({error: "User not found"});
+      return;
+    }
+    res.json({data: user});
+  } catch (error) {
+    next(error);
+  }
+}
+```
+
+**Techniques:**
+- Type generics: Use Request<Params, ResBody, ReqBody, Query> for type safety
+- Return Promise<void>: Indicates async function that doesn't return a value
+- Try-catch: Wrap all async logic and pass errors to next(error)
+- Validate first: Check for missing resources (404) before returning data
+- Service layer: Call business logic via injected service dependencies
+- Error handler: Pass errors to next() for centralized error handling
+- Standard responses: Return {data: value} or {error: message} structures

package/skills/express.js-guidelines/reference/error-handling.md

@@ -0,0 +1,54 @@
+# error-handling: Centralized Error Handler
+
+**Guideline:** Implement single error handler middleware that handles Zod errors, custom errors, and hides stack traces in production.
+
+**Rationale:** Centralized error handling ensures consistent error responses and prevents information leakage.
+
+**Example:**
+
+```typescript
+export function errorHandler(
+  err: unknown,
+  req: Request,
+  res: Response,
+  next: NextFunction,
+): void {
+  console.error("Error:", err);
+
+  if (err instanceof ZodError) {
+    res.status(400).json({error: "Validation error", details: err.flatten()});
+    return;
+  }
+
+  if (err instanceof Error) {
+    if (err.name === "NotFoundError") {
+      res.status(404).json({error: err.message});
+      return;
+    }
+    if (err.name === "UnauthorizedError") {
+      res.status(401).json({error: err.message});
+      return;
+    }
+    if (err.name === "ForbiddenError") {
+      res.status(403).json({error: err.message});
+      return;
+    }
+
+    if (process.env.NODE_ENV !== "production") {
+      res.status(500).json({error: "Internal server error", message: err.message, stack: err.stack});
+      return;
+    }
+  }
+
+  res.status(500).json({error: "Internal server error"});
+}
+```
+
+**Techniques:**
+- Four parameters: (err, req, res, next) required for Express to recognize error handler
+- Zod handling: Check instanceof ZodError, return 400 with details
+- Custom errors: Match error.name against NotFoundError, UnauthorizedError, ForbiddenError
+- Development mode: Show error.message and error.stack when NODE_ENV !== "production"
+- Production mode: Hide details, return generic "Internal server error" message
+- Register last: Error handler must be last middleware in app.use() chain
+- Logging: Log errors to console for debugging and monitoring

package/skills/express.js-guidelines/reference/project-structure.md

@@ -0,0 +1,29 @@
+# project-structure: Application Structure
+
+**Guideline:** Organize Express apps with separated concerns - routes, controllers, middleware, schemas in dedicated directories.
+
+**Rationale:** Clear separation prevents tight coupling and improves maintainability in larger codebases.
+
+**Example:**
+
+```
+src/
+├── app.ts
+├── server.ts
+├── routes/          # Route definitions with middleware chains
+├── controllers/     # Business logic handlers
+├── middleware/      # Auth, validation, error handling
+├── schemas/         # Zod schemas for validation
+├── services/        # Database/external service logic
+├── types/           # TypeScript type extensions
+└── utils/           # Helper functions
+```
+
+**Techniques:**
+- routes/: Define route handlers with middleware chaining, avoid business logic
+- controllers/: Implement typed handlers with try-catch, call services
+- middleware/: Auth, validation, CORS, logging, error handling middleware
+- schemas/: Zod schemas for type-safe request/response validation
+- services/: Database queries, external APIs, business logic
+- types/: Extend Express Request/Response interfaces globally
+- Separation: Keep concerns isolated, each file has single responsibility

package/skills/express.js-guidelines/reference/responses.md

@@ -0,0 +1,30 @@
+# responses: Response Patterns and Status Codes
+
+**Guideline:** Use consistent JSON response shapes with appropriate HTTP status codes.
+
+**Rationale:** Standardized responses simplify client-side handling and follow HTTP semantics.
+
+**Example:**
+
+```typescript
+// Success
+res.json({data: result});
+
+// Success with pagination
+res.json({data: items, pagination: {page: 1, limit: 20, total: 100}});
+
+// Error
+res.status(400).json({error: "Validation failed", details: {...}});
+
+// No content (deletion)
+res.status(204).send();
+```
+
+**Techniques:**
+- Data wrapper: Wrap all responses in {data: ...} or {error: ...} envelope
+- Status 200: GET, PUT, PATCH success - return {data: modified}
+- Status 201: POST success - return {data: created} with Location header
+- Status 204: DELETE success - return no content
+- Status 400: Validation errors - return {error: "message", details: {...}}
+- Status 401/403: Auth errors - return {error: "message"}
+- Status 404/5xx: Return {error: message} via error handler

package/skills/express.js-guidelines/reference/routes.md

@@ -0,0 +1,29 @@
+# routes: Routes with Validation and Auth
+
+**Guideline:** Chain validation and auth middleware before controller handlers in route definitions.
+
+**Rationale:** Declarative middleware chaining ensures validation/auth happens before business logic.
+
+**Example:**
+
+```typescript
+const router = express.Router();
+
+router.get("/", requireAuth, validateQuery(ListUsersQuerySchema), usersController.list);
+router.get("/:id", requireAuth, validateParams(UserParamsSchema), usersController.getById);
+router.post("/", validateBody(CreateUserSchema), usersController.create);
+router.patch("/:id", requireAuth, validateParams(UserParamsSchema), validateBody(UpdateUserSchema), usersController.update);
+router.delete("/:id", requireAuth, requireRole("admin"), validateParams(UserParamsSchema), usersController.remove);
+
+export {router as userRoutes};
+```
+
+**Techniques:**
+- Middleware order: Auth (requireAuth) before validation before controller
+- requireAuth: Verify JWT token and attach user to request
+- requireRole: Check user role after requireAuth
+- validateBody: Validate req.body against Zod schema
+- validateParams: Validate req.params against Zod schema
+- validateQuery: Validate req.query against Zod schema
+- Controller last: Place controller handler after all middleware
+- Type safety: Import schema types for typed Request generics in controllers

package/skills/express.js-guidelines/reference/testing.md

@@ -0,0 +1,39 @@
+# testing: API Testing Pattern
+
+**Guideline:** Test API endpoints using supertest with realistic request/response scenarios.
+
+**Rationale:** Integration tests validate the full middleware chain and response format.
+
+**Example:**
+
+```typescript
+import request from "supertest";
+import {app} from "../src/app";
+
+describe("POST /api/users", () => {
+  it("should create user with valid data", async () => {
+    const res = await request(app).post("/api/users").send({
+      email: "test@example.com",
+      name: "Test User",
+      password: "securepassword",
+    });
+    expect(res.status).toBe(201);
+    expect(res.body.data).toHaveProperty("id");
+  });
+
+  it("should return 400 for invalid email", async () => {
+    const res = await request(app).post("/api/users").send({email: "invalid"});
+    expect(res.status).toBe(400);
+    expect(res.body).toHaveProperty("error");
+  });
+});
+```
+
+**Techniques:**
+- supertest: Make HTTP requests to Express app without network
+- request(app).get/post/patch/delete(): Chain HTTP verb with URL path
+- .send(): Pass request body as JSON
+- expect(res.status).toBe(201): Assert HTTP status code
+- expect(res.body.data): Assert response structure
+- Integration testing: Validate full middleware chain, validation, handlers
+- Realistic scenarios: Test valid/invalid inputs, edge cases, error responses

package/skills/express.js-guidelines/reference/validation.md

@@ -0,0 +1,41 @@
+# validation: Zod Validation Pattern
+
+**Guideline:** Validate request params, body, and query at route edges using reusable Zod middleware.
+
+**Rationale:** Early validation prevents invalid data from reaching business logic, provides consistent error responses.
+
+**Example:**
+
+```typescript
+// schemas/users.ts
+export const CreateUserSchema = z.object({
+  email: z.string().email(),
+  name: z.string().min(1).max(100),
+  password: z.string().min(8),
+});
+
+export const UserParamsSchema = z.object({id: z.string().uuid()});
+
+export type CreateUser = z.infer<typeof CreateUserSchema>;
+
+// middleware/validate.ts
+export function validateBody<T extends z.ZodType>(schema: T) {
+  return (req: Request, res: Response, next: NextFunction) => {
+    const result = schema.safeParse(req.body);
+    if (!result.success) {
+      return res.status(400).json({error: "Validation failed", details: result.error.flatten()});
+    }
+    req.body = result.data;
+    next();
+  };
+}
+```
+
+**Techniques:**
+- Define schemas: Create Zod objects for body, params, query with strict types
+- Type inference: Use z.infer<typeof Schema> to export TypeScript types
+- safeParse: Use safeParse() instead of parse() to avoid exceptions
+- Middleware pattern: Create validateBody/validateParams/validateQuery factories
+- Type generics: Accept T extends z.ZodType for reusable middleware
+- Error response: Return 400 with result.error.flatten() containing field errors
+- Transform: Use .transform(Number) and .pipe() to coerce and validate strings

package/skills/general-fp-guidelines/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: general-fp-guidelines
+description: >-
+  Trigger on functional programming patterns, immutability, pure functions. Use for FP-style coding principles. Apply when preferring composition over inheritance, module-level functions, explicit context passing. Keywords: functional programming, pure functions, immutability, composition, module functions, explicit context, stateless.
+---
+
+# General Functional Programming Guidelines
+
+## Core principles
+
+- Modular design: Prefer module-level functions; pass explicit context; avoid classes.
+- Immutability: Favor immutable data; use pure functions without side effects.
+- Composition: Build complex behavior by composing simple functions.
+- Type safety: Use types consistently; derive from generated/parent types; enable strict modes.
+- Clear structure: Split logic into small, focused files/functions.
+
+## Best practices
+
+- Readability: Prefer clarity over cleverness; name things well.
+- Errors: Handle and propagate explicitly; never swallow silently.
+- Tests: Add/maintain tests to prevent regressions.
+- State: Pass state explicitly; avoid global or shared mutable state.
+
+## Code quality
+
+- Linting: Fix root causes of warnings; never suppress with disable comments.
+- Validation: Run typecheck, lint, build, test after each major change (all must pass).
+- Organization: Order pattern matching from most specific to most general.

package/skills/general-oop-guidelines/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: general-oop-guidelines
+description: >-
+  Trigger on object-oriented patterns, class hierarchies, encapsulation. Use for OOP-style coding principles. Apply when using inheritance, polymorphism, encapsulated state. Keywords: object-oriented, classes, inheritance, polymorphism, encapsulation, SOLID, design patterns, interfaces.
+---
+
+# General Object-Oriented Programming Guidelines
+
+## Core principles
+
+- Encapsulation: Keep state private; expose behavior through methods.
+- Inheritance: Use for shared behavior; prefer composition when appropriate.
+- Polymorphism: Program to interfaces; use abstract classes for shared implementation.
+- Type safety: Use types consistently; derive from generated/parent types; enable strict modes.
+- Clear structure: Split logic into focused classes with single responsibilities.
+
+## Best practices
+
+- Readability: Prefer clarity over cleverness; name things well.
+- Errors: Handle and propagate explicitly; never swallow silently.
+- Tests: Add/maintain tests to prevent regressions.
+- SOLID: Single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion.
+
+## Code quality
+
+- Linting: Fix root causes of warnings; never suppress with disable comments.
+- Validation: Run typecheck, lint, build, test after each major change (all must pass).
+- Design patterns: Apply appropriate patterns (Factory, Strategy, Observer) when they simplify code.

package/skills/git-guidelines/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: git-guidelines
+description: >-
+  Trigger on git operations and merge conflict situations. Use when working with git operations. Apply for conventional commits, merge conflict resolution, worktree management. Keywords: git, conventional commits, feat/fix/chore/docs, merge conflicts, worktrees, commit messages, history rewrite.
+---
+
+# Git Guidelines
+
+## Core Principles
+
+- **Conventional Commits** - Use type prefixes (feat, fix, chore, docs, refactor, test, ci), see [reference/commit.md](reference/commit.md)
+- **Auto-Generate Messages** - Analyze changed files and context, see [reference/commit.md](reference/commit.md)
+- **Isolated Development** - Use worktrees for feature branches, see [reference/worktree-create.md](reference/worktree-create.md)
+- **Validate Before Merge** - Run typecheck/lint/build/test, see [reference/worktree-validate.md](reference/worktree-validate.md)
+
+## Commit Operations
+
+- **Auto-commit** - Analyze changes, infer type, generate message, optional push, see [reference/commit.md](reference/commit.md)
+
+## Conflict Resolution
+
+- **Detect and classify** - Find conflicts, suggest strategy (ours/theirs/merge), see [reference/merge-resolve.md](reference/merge-resolve.md)
+- **Validate** - Run typecheck/lint after resolution before staging, see [reference/merge-resolve.md](reference/merge-resolve.md)
+
+## Worktree Operations
+
+- **Create** - `<worktree>-feature-<name>` directory with branch, see [reference/worktree-create.md](reference/worktree-create.md)
+- **Commit** - Auto-commit with plan context, see [reference/worktree-commit.md](reference/worktree-commit.md)
+- **Validate** - Pre-merge validation checkpoint, see [reference/worktree-validate.md](reference/worktree-validate.md)
+- **Merge** - Merge feature back to source branch, see [reference/worktree-merge.md](reference/worktree-merge.md)
+- **Cleanup** - Remove stale and merged worktrees, see [reference/worktree-cleanup.md](reference/worktree-cleanup.md)
+- **Abandon** - Document and remove failed feature, see [reference/worktree-abandon.md](reference/worktree-abandon.md)
+
+## Progressive Disclosure
+
+### Commit Operations
+- Read [reference/commit.md](reference/commit.md) - Commit with auto-generated conventional messages
+- Read [reference/merge-resolve.md](reference/merge-resolve.md) - Detect and resolve merge conflicts with AI assistance
+
+### Worktree Operations
+- Read [reference/worktree-create.md](reference/worktree-create.md) - Create feature worktree with branch
+- Read [reference/worktree-commit.md](reference/worktree-commit.md) - Auto-commit with plan context
+- Read [reference/worktree-validate.md](reference/worktree-validate.md) - Pre-merge validation checkpoint
+- Read [reference/worktree-merge.md](reference/worktree-merge.md) - Merge feature back to source branch
+- Read [reference/worktree-cleanup.md](reference/worktree-cleanup.md) - Remove stale and merged worktrees
+- Read [reference/worktree-abandon.md](reference/worktree-abandon.md) - Document and remove failed feature

package/skills/git-guidelines/reference/commit.md

@@ -0,0 +1,32 @@
+# commit: Auto-Commit with Smart Messages
+
+**Guideline:** Commit with conventional format `<type>: <description>` by auto-detecting type from file changes and generating descriptive messages.
+
+**Rationale:** Auto-generating messages from file changes maintains consistent commit style with minimal effort while accurately reflecting what changed in each commit.
+
+**Example:**
+
+```bash
+# Changes in 3 test files
+$ git commit
+test: add validation tests for user registration
+
+# Changes in documentation
+$ git commit
+docs: update authentication flow diagram
+
+# Bug fix in service layer
+$ git commit
+fix: handle null pointer in user service
+
+# New feature implementation
+$ git commit
+feat: add OAuth2 provider integration
+```
+
+**Techniques:**
+- Detect changes via `git status --porcelain` and `git diff --stat`
+- Auto-detect type from file patterns: test (*.test.ts), docs (*.md), ci, chore (package.json), feat (new), fix (small), refactor (large)
+- Generate message from file patterns and diff stats
+- Commit with `git add -A && git commit -m "<type>: <description>"`
+- Optionally push with `git push -o ci.skip origin HEAD:<branch>`

package/skills/git-guidelines/reference/merge-resolve.md

@@ -0,0 +1,38 @@
+# merge-resolve: Detect and Resolve Merge Conflicts
+
+**Guideline:** Detect, classify, and resolve merge conflicts with auto-resolution for simple cases and strategies for complex conflicts.
+
+**Rationale:** Simple conflicts like import statements and dependencies can be auto-resolved, while complex conflicts require manual decision-making based on strategies like keeping ours/theirs/merging intelligently.
+
+**Example:**
+
+```bash
+# Detecting conflicts
+$ git status --porcelain
+UU src/services/auth.ts
+AA package.json
+DD src/utils/old-helper.ts
+
+# Auto-resolve simple import statement conflicts
+# package.json: merge both dependency versions
+
+# Manual resolution for function body conflict
+# Review auth.ts and choose strategy (ours/theirs/merge)
+
+# Validate after resolution
+$ npm run typecheck && npm run lint
+TypeScript: PASS
+ESLint: PASS
+
+# Stage and complete merge
+$ git add .
+$ git commit -m "merge: resolve conflicts with feature branch"
+```
+
+**Techniques:**
+- Detect conflicts via `git status --porcelain` (UU, AA, DD markers)
+- Classify as simple (auto-resolvable: imports, dependencies, additions) or complex (manual: functions, types, logic)
+- Auto-resolve imports by merging lists, dependencies by newer version, additions by including both
+- For complex conflicts prompt for strategy: ours, theirs, or manual merge
+- Validate with `npm run typecheck && npm run lint` before staging
+- Stage resolved files with `git add` only after validation passes

package/skills/git-guidelines/reference/worktree-abandon.md

@@ -0,0 +1,48 @@
+# worktree-abandon: Document and Abandon Feature
+
+**Guideline:** Document why feature is abandoned and clean up worktree to preserve learnings for future decisions.
+
+**Rationale:** Recording abandonment reasons and learnings prevents repeated failed attempts and provides valuable context for future development decisions.
+
+**Example:**
+
+```bash
+# Document abandonment in insights/abandoned-features/
+cat > insights/abandoned-features/auth-redesign-2026-01.md << 'EOF'
+## Feature: Authentication UI Redesign
+
+**Goal:** Redesign login form with multi-step experience
+
+**Work Completed:**
+- Step 1: Email validation form (80% complete)
+- Step 2: Password reset flow (30% complete)
+- Custom TOTP implementation (blocked by deps)
+
+**Reason for Abandonment:**
+Third-party auth provider API changed requirements. Multi-step approach conflicts with new spec.
+
+**Alternative:** Use updated provider's OAuth 2.0 flow, leverage built-in MFA.
+
+**Learnings:** Don't commit to custom flow when third-party alternatives exist. Test assumptions with provider early.
+
+**Time Invested:** 12 hours across 5 commits
+**Date:** 2026-01-15
+**Branch:** auth/redesign-feature
+EOF
+
+# Clean up worktree and branch
+git worktree remove ../services-feature-auth-redesign
+git branch -D auth/redesign-feature
+
+# Push archived branch to preserve history
+git tag abandoned/auth-redesign-2026-01 origin/auth/redesign-feature
+git push origin abandoned/auth-redesign-2026-01
+```
+
+**Techniques:**
+- Verify in feature worktree
+- Gather context: feature name, plan, commits, work completed
+- Prompt for abandonment reason
+- Document in `insights/abandoned-features/<feature>-<date>.md`
+- Clean up: `git worktree remove <path>` and `git branch -D <branch>`
+- Clean git config entries

package/skills/git-guidelines/reference/worktree-cleanup.md

@@ -0,0 +1,40 @@
+# worktree-cleanup: Clean Up Stale and Merged Worktrees
+
+**Guideline:** Remove stale and merged feature worktrees to keep workspace clean and organized.
+
+**Rationale:** Prevents workspace clutter from old feature worktrees by identifying merged worktrees (fully integrated) and stale worktrees (30+ days without changes).
+
+**Example:**
+
+```bash
+# List all worktrees and their status
+git worktree list
+
+# Output:
+# /home/user/project             9a3c5e2 [master]
+# /home/user/project-feature-auth 7f2b1d8 [feature/auth-redesign] (merged)
+# /home/user/project-feature-db   c4a8e1f [feature/db-migration] (30+ days no commits)
+
+# Cleanup will identify and remove merged/stale worktrees
+# Merged: feature/auth-redesign (fully merged into master)
+# Stale: feature/db-migration (70 days since last commit)
+
+# Remove merged worktree
+git worktree remove ../project-feature-auth
+git branch -d feature/auth-redesign
+
+# Remove stale worktree (but keep if uncommitted changes)
+git worktree remove ../project-feature-db --force
+git branch -d feature/db-migration
+
+# Verify cleanup
+git worktree list
+# Only main worktree remains
+```
+
+**Techniques:**
+- List worktrees: `git worktree list`
+- Identify feature worktrees with `*-feature-*` pattern
+- Check merge status: `git branch --merged <source>`
+- Categorize: merged, stale (>30 days no commits), active
+- Remove selected: `git worktree remove <path>` + `git branch -d <branch>`

package/skills/git-guidelines/reference/worktree-commit.md

@@ -0,0 +1,46 @@
+# worktree-commit: Auto-Commit in Worktree with Plan Context
+
+**Guideline:** Commit worktree changes with auto-generated messages enhanced by plan context to align with implementation objectives.
+
+**Rationale:** Extending auto-commit with plan awareness generates contextual messages that document not just what changed, but how it aligns with the overall feature plan.
+
+**Example:**
+
+```bash
+# In feature worktree: services-feature-auth-flow
+cd ../services-feature-auth-flow
+
+# Add implementation and tests
+# services/auth/flow.ts (220 lines)
+# services/auth/__tests__/flow.test.ts (180 lines)
+
+# Worktree detects changes and generates message with plan context
+git status --porcelain
+# M  services/auth/flow.ts
+# A  services/auth/__tests__/flow.test.ts
+
+# Plan stored in git config was: "Implement email+password flow with TOTP"
+# Auto-generated message:
+# "feat: Implement email+password flow with TOTP
+#
+# Add LoginFlow component with email validation and TOTP verification.
+# Test coverage: happy path, invalid email, expired TOTP."
+
+git add -A
+git commit -m "feat: Implement email+password flow with TOTP
+
+Add LoginFlow component with email validation and TOTP verification.
+Test coverage: happy path, invalid email, expired TOTP."
+
+# Optional: push with CI skip
+git push -o ci.skip origin HEAD:services/feature/auth-flow
+```
+
+**Techniques:**
+- Detect worktree name from directory
+- Check changes: `git status --porcelain`
+- Analyze changed files: test, docs, source, config
+- Read plan: `git config branch.<branch>.plan`
+- Generate message using file patterns, diff stats, plan context
+- Commit: `git add -A && git commit -m "<type>: <description>"`
+- Optionally push: `git push -o ci.skip origin HEAD:<branch>`