@maggit/claude-workspace 0.1.1

package/assets/skills/test/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: test
+description: "Generate unit tests for code. Use when the user says /test, asks to write tests, create test cases, add unit tests, or test a function/class/module. Triggers: test, unit test, write tests, add tests, test cases, spec, jest, pytest, mocha, vitest."
+---
+
+# Unit Test Generator
+
+Generate comprehensive unit tests for code.
+
+## Workflow
+
+1. **Detect the testing ecosystem:**
+   - Check for existing test config: `jest.config.*`, `vitest.config.*`, `pytest.ini`, `pyproject.toml [tool.pytest]`, `Cargo.toml`, `.rspec`, `go test`.
+   - Check for existing test files to match patterns and conventions.
+   - Identify the test runner, assertion library, and mocking framework in use.
+
+2. **Analyze the target code:**
+   - Read the function/class/module to test.
+   - Identify: inputs, outputs, side effects, dependencies, edge cases, error paths.
+   - Map out the code paths (happy path, error paths, boundary conditions).
+
+3. **Generate tests following the project's patterns:**
+   - Match existing file naming: `*.test.ts`, `*_test.go`, `test_*.py`, `*_spec.rb`, etc.
+   - Match existing directory structure (`__tests__/`, `tests/`, co-located, etc.).
+   - Use the same assertion style and patterns as existing tests.
+
+4. **Write tests covering:**
+
+### Test Categories
+
+| Category | What to test |
+|----------|-------------|
+| **Happy path** | Normal inputs produce expected outputs |
+| **Edge cases** | Empty inputs, zero, null/undefined, max values, single element |
+| **Error handling** | Invalid inputs throw/return appropriate errors |
+| **Boundary values** | Min, max, off-by-one, type boundaries |
+| **State changes** | Side effects, mutations, event emissions |
+| **Async behavior** | Promises, callbacks, timeouts (if applicable) |
+
+5. **Structure each test with AAA pattern:**
+   - **Arrange** — set up preconditions and inputs.
+   - **Act** — execute the code under test.
+   - **Assert** — verify the expected outcome.
+
+6. **Run the tests** to ensure they pass.
+
+## Guidelines
+
+- Tests should be independent — no shared mutable state between tests.
+- Use descriptive test names that explain the scenario: `"returns empty array when input is empty"`.
+- Mock external dependencies (APIs, databases, file system) but not the code under test.
+- Prefer `toEqual` deep comparison over `toBe` reference comparison for objects.
+- If the code is untestable, suggest refactoring to improve testability.
+- Don't test implementation details — test behavior and public interfaces.
+- Include at least one negative test (what should NOT happen).

package/assets/skills/testcoverage/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: testcoverage
+description: "Analyze test coverage and identify gaps. Use when the user says /testcoverage, asks about test coverage, wants to improve coverage, find untested code, or reach a coverage target. Triggers: test coverage, coverage report, untested code, coverage gap, coverage target, uncovered lines, branch coverage."
+---
+
+# Test Coverage Analyzer
+
+Analyze test coverage and generate tests to fill gaps.
+
+## Workflow
+
+1. **Run coverage analysis:**
+   - Detect the test framework and run with coverage enabled:
+     - **JS/TS**: `npx jest --coverage` or `npx vitest --coverage` or `npx nyc mocha`
+     - **Python**: `pytest --cov=<package> --cov-report=term-missing`
+     - **Go**: `go test -coverprofile=coverage.out ./... && go tool cover -func=coverage.out`
+     - **Rust**: `cargo tarpaulin` or `cargo llvm-cov`
+   - Parse the coverage output.
+
+2. **Analyze coverage gaps:**
+   - Identify files with lowest coverage.
+   - Identify uncovered lines and branches.
+   - Categorize gaps:
+     - **Critical**: Business logic, data validation, security checks.
+     - **Important**: Error handling, edge cases.
+     - **Low priority**: Logging, formatting, simple getters/setters.
+
+3. **Present a coverage report:**
+
+```
+Coverage Summary: XX.X% (target: YY%)
+
+Critical Gaps:
+  src/auth/login.ts        45%  — lines 23-40, 67-89 (authentication logic)
+  src/api/payments.ts      38%  — lines 12-35 (payment processing)
+
+Important Gaps:
+  src/utils/validator.ts   62%  — lines 44-58 (error handling)
+
+Files at 100%: 12/30
+```
+
+4. **Generate tests for the highest-priority gaps:**
+   - Start with critical business logic.
+   - Focus on untested branches and error paths.
+   - Follow the project's existing test patterns.
+
+5. **Re-run coverage to verify improvement.**
+
+## Guidelines
+
+- Focus on meaningful coverage, not just hitting a number.
+- 100% coverage doesn't mean bug-free — test quality matters more than quantity.
+- Prioritize branch coverage over line coverage.
+- Don't test trivially obvious code just for the coverage number.
+- If coverage tooling isn't set up, help configure it first.
+- Consider setting up coverage thresholds in CI config if not already present.

package/assets/skills/todo/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: todo
+description: "Break down a project into actionable tasks. Use when the user says /todo, asks to create a task breakdown, decompose a feature into tasks, or plan work items. Triggers: todo, task breakdown, break down, decompose, work items, sprint planning, task list."
+---
+
+# Task Breakdown
+
+## Purpose
+
+Decompose a project, feature, or initiative into actionable, well-defined tasks. Produce a structured checklist that a team can immediately pick up and work from, with clear priorities, effort estimates, and dependencies.
+
+## When to Use
+
+- Breaking down a feature or project into sprint-ready work items
+- Creating a personal task list from a broad goal
+- Estimating effort and identifying the critical path for a body of work
+
+## Inputs
+
+- **Work description**: The feature, project, or goal to decompose
+- **Scope constraints**: Any boundaries on what to include or exclude (optional)
+- **Team context**: Team size, roles, skill sets (optional)
+- **Timeline**: Target completion date or sprint length (optional)
+
+## Output Format
+
+Produce a markdown document with the following structure:
+
+### 1. Objective
+One sentence stating what "done" looks like for this body of work.
+
+### 2. Task List
+
+For each task, use this checklist format:
+
+```
+- [ ] **Task title**
+  - Description: What needs to be done (1-2 sentences)
+  - Priority: P0 / P1 / P2
+  - Effort: S (< 2h) / M (2-8h) / L (1-3d) / XL (3-5d)
+  - Dependencies: List any tasks that must complete first
+  - Acceptance criteria: How to verify this task is done
+```
+
+Group tasks into logical phases or categories using H3 headers.
+
+### 3. Dependency Graph
+A text summary of the critical path: which tasks block others and what can be parallelized.
+
+### 4. Effort Summary
+A quick table:
+
+| Priority | Count | Total Effort |
+|----------|-------|--------------|
+| P0       |       |              |
+| P1       |       |              |
+| P2       |       |              |
+
+### 5. Risks and Blockers
+List anything that could delay or prevent completion.
+
+## Example
+
+**Input**: "Break down the work to add dark mode to our web app."
+
+**Output**:
+- Objective: Users can toggle between light and dark themes across all pages.
+- Tasks grouped into phases:
+  - **Design**: Audit existing color tokens, define dark palette, update design system
+  - **Infrastructure**: Implement theme provider, add user preference storage, set up CSS variable system
+  - **Implementation**: Update core components, update page layouts, handle third-party widget theming
+  - **Testing**: Visual regression tests, accessibility contrast checks, cross-browser testing
+  - **Rollout**: Feature flag setup, beta rollout, documentation update
+- Dependency graph showing design must precede implementation, infrastructure can parallel with design
+- Effort summary showing total estimated work
+
+## Guidelines
+
+- Make each task small enough to complete in one sitting (aim for S or M when possible)
+- Every task should have a clear "done" state -- no vague tasks like "work on styling"
+- Order tasks within each phase by dependency, then priority
+- Flag tasks that require specific expertise or access
+- Include testing and documentation tasks -- they are real work
+- If a task is XL, consider whether it should be broken down further

package/assets/templates/DECISION_RECORD_TEMPLATE.md

@@ -0,0 +1,59 @@
+# ADR-NNN: [Short Title of Decision]
+
+**Status:** Proposed | Accepted | Deprecated | Superseded
+**Date:** [YYYY-MM-DD]
+**Decision Makers:** [List names or roles]
+**Supersedes:** [ADR-XXX, if applicable]
+**Superseded by:** [ADR-XXX, if applicable]
+
+---
+
+## Context
+
+*What is the issue or situation that motivates this decision? Include relevant technical, business, or organizational constraints. Link to related documents or discussions.*
+
+## Decision
+
+*State the decision clearly and directly. Use active voice: "We will..." or "The system will..."*
+
+## Consequences
+
+### Positive
+
+*Benefits and improvements resulting from this decision.*
+
+1.
+
+### Negative
+
+*Trade-offs, costs, or risks introduced by this decision.*
+
+1.
+
+### Neutral
+
+*Side effects that are neither clearly positive nor negative, but worth noting.*
+
+1.
+
+## Alternatives Considered
+
+### Alternative 1: [Name]
+
+*Brief description of the alternative approach.*
+
+- **Pros:** [advantages]
+- **Cons:** [disadvantages]
+- **Reason rejected:** [why this was not chosen]
+
+### Alternative 2: [Name]
+
+*Brief description of the alternative approach.*
+
+- **Pros:** [advantages]
+- **Cons:** [disadvantages]
+- **Reason rejected:** [why this was not chosen]
+
+---
+
+*To propose a new ADR, copy this template and assign the next available number. Update the status as the decision progresses through review.*

package/assets/templates/ENG_SPEC_TEMPLATE.md

@@ -0,0 +1,84 @@
+# [Feature Name]: Engineering Specification
+
+**Status:** Draft
+**Author:** [Your Name]
+**Date:** [YYYY-MM-DD]
+**PRD Link:** [Link to related PRD]
+
+---
+
+## Overview
+
+*High-level summary of what is being built and why. Keep to 2-3 sentences.*
+
+## Architecture
+
+*Describe the system design. Include a diagram if helpful (e.g., Mermaid, ASCII).*
+
+### Components
+
+*List the major components or services involved and their responsibilities.*
+
+- **Component A** -- [responsibility]
+- **Component B** -- [responsibility]
+
+### Dependencies
+
+*External services, libraries, or systems this design depends on.*
+
+1.
+
+## Data Model
+
+*Define new or modified data structures, database tables, or schemas.*
+
+```
+Table/Model Name
+-----------------
+field_name    type        constraints
+```
+
+*Note any migrations required.*
+
+## API Design
+
+*Define new or modified endpoints, RPCs, or interfaces.*
+
+### `METHOD /path`
+
+- **Request:** describe body/params
+- **Response:** describe shape
+- **Errors:** list error codes and meanings
+
+## Error Handling
+
+*How will the system handle failures? Cover retries, fallbacks, and user-facing errors.*
+
+| Error Scenario | Handling Strategy |
+|---------------|-------------------|
+| | |
+
+## Testing Strategy
+
+*Describe your approach to validating this work.*
+
+- **Unit tests:** [scope and coverage targets]
+- **Integration tests:** [what interactions are tested]
+- **Manual/QA testing:** [key scenarios to verify]
+
+## Rollout Plan
+
+*How will this be deployed? Include feature flags, phased rollout, or canary steps.*
+
+1. **Phase 1:** [description]
+2. **Phase 2:** [description]
+
+### Rollback Plan
+
+*Steps to revert if something goes wrong.*
+
+## Open Questions
+
+| # | Question | Owner | Status |
+|---|----------|-------|--------|
+| 1 | | | |

package/assets/templates/PRD_TEMPLATE.md

@@ -0,0 +1,72 @@
+# [Product Name]: Product Requirements Document
+
+**Status:** Draft
+**Author:** [Your Name]
+**Date:** [YYYY-MM-DD]
+**Reviewers:** [List reviewers]
+
+---
+
+## Problem Statement
+
+*Describe the problem you are solving. Who experiences it, how often, and what is the impact?*
+
+## Goals & Non-Goals
+
+### Goals
+
+*What this project aims to achieve. Be specific and measurable.*
+
+1.
+
+### Non-Goals
+
+*What this project explicitly will not address. This is just as important as goals.*
+
+1.
+
+## User Stories
+
+*Describe the key user interactions in "As a [role], I want [action], so that [benefit]" format.*
+
+1. As a ..., I want ..., so that ...
+
+## Functional Requirements
+
+*What the system must do. Number each requirement for easy reference.*
+
+| ID | Requirement | Priority (P0/P1/P2) |
+|----|-------------|----------------------|
+| FR-1 | | |
+| FR-2 | | |
+
+## Non-Functional Requirements
+
+*Performance, security, scalability, accessibility, and other quality attributes.*
+
+| ID | Requirement | Target |
+|----|-------------|--------|
+| NFR-1 | | |
+| NFR-2 | | |
+
+## Success Metrics
+
+*How will you know this project succeeded? Define measurable outcomes.*
+
+| Metric | Current Baseline | Target | Measurement Method |
+|--------|-----------------|--------|-------------------|
+| | | | |
+
+## Out of Scope
+
+*Items deliberately excluded from this effort. Reference future work if applicable.*
+
+1.
+
+## Open Questions
+
+*Unresolved questions that need answers before or during implementation.*
+
+| # | Question | Owner | Status |
+|---|----------|-------|--------|
+| 1 | | | |

package/assets/templates/PROJECT_INDEX_TEMPLATE.md

@@ -0,0 +1,65 @@
+# [Project Name]
+
+*[One-sentence description of what this project does and who it serves.]*
+
+---
+
+## Quick Links
+
+- **Repository:** [link]
+- **CI/CD:** [link]
+- **Production:** [link]
+- **Monitoring/Dashboard:** [link]
+- **Issue Tracker:** [link]
+
+## Team
+
+| Role | Name | Contact |
+|------|------|---------|
+| Tech Lead | | |
+| Product Owner | | |
+| Engineers | | |
+| Designer | | |
+
+## Tech Stack
+
+*List the primary languages, frameworks, infrastructure, and tools.*
+
+| Layer | Technology |
+|-------|-----------|
+| Frontend | |
+| Backend | |
+| Database | |
+| Infrastructure | |
+| CI/CD | |
+
+## Key Documents
+
+*Link to living documents that drive this project.*
+
+- [PRD](link) -- product requirements
+- [Engineering Spec](link) -- technical design
+- [ADRs](link) -- architectural decision records
+- [Runbook](link) -- operational procedures
+
+## Architecture Overview
+
+*Brief description of how the system is structured. Include a diagram link or inline diagram if available.*
+
+## Getting Started
+
+*Steps for a new contributor to get the project running locally.*
+
+1. Clone the repository
+2. Install dependencies: `[command]`
+3. Set up environment: `cp .env.example .env`
+4. Run locally: `[command]`
+5. Run tests: `[command]`
+
+## Current Status
+
+*What phase is the project in? Note any active workstreams or upcoming milestones.*
+
+| Milestone | Target Date | Status |
+|-----------|-------------|--------|
+| | | |

package/assets/templates/WEEKLY_REVIEW_TEMPLATE.md

@@ -0,0 +1,57 @@
+# Weekly Review
+
+**Week Of:** [YYYY-MM-DD]
+**Author:** [Your Name]
+
+---
+
+## Accomplishments
+
+*What was completed this week? Link to PRs, tickets, or documents where relevant.*
+
+- [ ]
+- [ ]
+
+## In Progress
+
+*Work that is actively underway but not yet complete. Note expected completion.*
+
+| Item | Status | ETA |
+|------|--------|-----|
+| | | |
+
+## Blocked
+
+*Items that cannot proceed. Identify the blocker and who can resolve it.*
+
+| Item | Blocker | Owner |
+|------|---------|-------|
+| | | |
+
+## Key Metrics
+
+*Relevant numbers for the week: deploys, incidents, velocity, etc.*
+
+| Metric | This Week | Last Week | Trend |
+|--------|-----------|-----------|-------|
+| | | | |
+
+## Learnings
+
+*What did you learn this week? Technical insights, process improvements, or retrospective notes.*
+
+1.
+
+## Next Week Priorities
+
+*Top priorities for the coming week, ordered by importance.*
+
+1.
+2.
+3.
+
+## Notes
+
+*Anything else worth capturing: upcoming PTO, schedule changes, shoutouts, risks.*
+
+-

package/assets/vault/README.md

@@ -0,0 +1,34 @@
+# Context Vault
+
+This vault is a structured Markdown knowledge base for your project. It is designed to be readable and writable by both humans and AI tools.
+
+## Folder Taxonomy
+
+| Folder | Purpose |
+|--------|---------|
+| `00_inbox/` | Unsorted notes, quick captures, raw inputs |
+| `01_specs/` | Requirements, PRDs, feature specs |
+| `02_architecture/` | System design, technical specs, diagrams |
+| `03_decisions/` | Architectural Decision Records (ADRs) |
+| `04_knowledge/` | Reusable concepts, reference material, guides |
+| `05_prompts/` | LLM prompts, prompt templates |
+| `06_agents/` | Agent roles, rules, memory, configuration |
+| `07_diagrams/` | Mermaid diagrams, visual references |
+| `08_todos/` | Task lists, backlogs, sprint plans |
+
+## Naming Conventions
+
+- Use lowercase with hyphens: `my-feature-spec.md`
+- Prefix with date when chronology matters: `2026-02-07-auth-decision.md`
+- Keep filenames descriptive and specific
+- One topic per file — keep documents small and composable
+
+## File Format
+
+- All files should be UTF-8 Markdown (`.md`)
+- Start each file with a `# Title` heading
+- Use relative Markdown links between documents: `[link text](../01_specs/feature.md)`
+
+## Working with AI Tools
+
+AI tools can freely read any file and create new `.md` files. Overwriting or deleting existing files requires explicit permission.

package/assets/vault/_index.md

@@ -0,0 +1,27 @@
+# Project Index
+
+> Navigation hub for your project context. Update this file as your project evolves.
+
+## Quick Links
+
+- [Vault README](./README.md)
+
+## Specs & Requirements
+
+<!-- Add links to specs as you create them -->
+<!-- Example: - [Feature X PRD](./01_specs/feature-x-prd.md) -->
+
+## Architecture
+
+<!-- Add links to architecture docs -->
+<!-- Example: - [System Overview](./02_architecture/system-overview.md) -->
+
+## Decisions
+
+<!-- Add links to ADRs -->
+<!-- Example: - [ADR-001: Use PostgreSQL](./03_decisions/adr-001-use-postgresql.md) -->
+
+## Active Tasks
+
+<!-- Add links to current task lists -->
+<!-- Example: - [Sprint 1 Tasks](./08_todos/sprint-1.md) -->