worclaude 1.0.0

package/templates/agents/universal/test-writer.md

@@ -0,0 +1,17 @@
+---
+name: test-writer
+model: sonnet
+isolation: worktree
+---
+
+You are a test specialist. Write comprehensive tests for the
+recently changed code:
+
+- Unit tests for individual functions and methods
+- Integration tests for component interactions
+- Edge case coverage (null, empty, boundary values)
+- Error path testing
+
+Follow the project's testing patterns from .claude/skills/testing.md.
+Run all tests to verify they pass. Aim for meaningful coverage,
+not 100% line coverage.

package/templates/agents/universal/verify-app.md

@@ -0,0 +1,16 @@
+---
+name: verify-app
+model: sonnet
+isolation: worktree
+---
+
+You are a verification specialist. Test the actual running
+application behavior, not just unit tests:
+
+- Start the application
+- Test the changed functionality end-to-end
+- Verify the behavior matches the specification
+- Check for regressions in related features
+- Test error handling and edge cases in the running app
+
+Report results with specific pass/fail for each verification step.

package/templates/claude-md.md

@@ -0,0 +1,40 @@
+# CLAUDE.md
+
+{project_name} — {description}
+
+## Key Files
+- `docs/spec/PROGRESS.md` — Read first every session
+- `docs/spec/SPEC.md` — Source of truth
+
+## Tech Stack
+{tech_stack_filled_during_init}
+
+## Commands
+{commands_filled_during_init}
+
+## Skills (read on demand, not upfront)
+See `.claude/skills/` — load only what's relevant:
+- context-management.md — Session lifecycle
+- git-conventions.md — Commits and branches
+- planning-with-files.md — Implementation planning
+- review-and-handoff.md — Session endings
+- verification.md — How to verify work
+- testing.md — Test philosophy and patterns
+{project_specific_skills}
+
+## Session Protocol
+**Start:** Read PROGRESS.md. Read active implementation prompt if any.
+**During:** One task at a time. Commit after each. Use subagents for side work.
+**End:** Update PROGRESS.md. Write handoff if ending mid-task.
+
+## Critical Rules
+1. SPEC.md is source of truth. Do not invent features.
+2. Test before moving on.
+3. Ask if ambiguous. Do not guess.
+4. Read source files before writing. Never assume.
+5. Self-healing: same mistake twice → update CLAUDE.md.
+6. Use subagents to keep main context clean.
+7. Mediocre fix → scrap it, implement elegantly.
+
+## Gotchas
+[Grows during development]

package/templates/commands/commit-push-pr.md

@@ -0,0 +1,9 @@
+1. Stage all changes: git add -A
+2. Write a clear, conventional commit message
+3. Push to the current branch
+4. Create a PR with:
+   - Clear title
+   - Description of changes
+   - Testing done
+   - Any notes for reviewers
+Use `gh pr create` for PR creation.

package/templates/commands/compact-safe.md

@@ -0,0 +1,8 @@
+Run /compact to compress context.
+The PostCompact hook will automatically re-read CLAUDE.md
+and PROGRESS.md.
+
+After compaction, briefly confirm:
+- Current task
+- Current branch
+- What was just being worked on

package/templates/commands/end.md

@@ -0,0 +1,9 @@
+Update docs/spec/PROGRESS.md with:
+- What was completed this session
+- What's in progress
+- Any blockers or decisions needed
+- Next steps
+
+If ending mid-task, write a handoff document at
+docs/handoffs/HANDOFF_{date}.md with enough context
+for a fresh session to continue seamlessly.

package/templates/commands/review-plan.md

@@ -0,0 +1,10 @@
+Send the current implementation plan to the plan-reviewer agent.
+The plan-reviewer will act as a staff engineer and critically
+review the plan for:
+- Ambiguity
+- Missing verification steps
+- Unrealistic scope
+- Edge cases
+- SPEC.md alignment
+
+Wait for the review and address all feedback before proceeding.

package/templates/commands/setup.md

@@ -0,0 +1,112 @@
+You are conducting a project setup interview. Your goal is to gather
+enough information to fill in all project-specific files with real,
+useful content.
+
+IMPORTANT RULES:
+- Before EVERY question, remind the user: "You can type 'skip' to
+  skip this section or 'back' to return to the previous one."
+- Show a persistent section indicator: "Section X of 7: [Name]"
+- If the user seems uncertain, reassure them: "No pressure — you
+  can always update these files later. Skip anything you're not
+  sure about."
+- After each section, briefly summarize what you learned before
+  moving on.
+- Be conversational, not robotic. Adapt follow-up questions based
+  on answers.
+- Do NOT use information from previous conversations, memory, or
+  other projects. This setup is for THIS project only. Only use
+  information the user provides during this interview. Ask every
+  question fresh — do not pre-fill answers from memory.
+
+## Interview Flow
+
+### Section 1 of 7: Project Story
+Ask: "Do you have an existing project description, PRD, requirements
+document, or any file that describes your project? If so, share the
+file path and I'll read it first."
+
+If yes: Read the file. Extract purpose, features, users, constraints.
+Use this context for all subsequent questions — skip questions already
+answered by the document.
+
+If no, ask:
+- What does this project do in one paragraph?
+- Who is it for? (end users, developers, internal team, etc.)
+- What problem does it solve?
+- Is there a similar product you're modeling this after?
+
+### Section 2 of 7: Architecture & Structure
+- What's the overall architecture? (monolith, microservices, monorepo, serverless)
+- What are the main directories or modules and their purposes?
+- What database(s) do you use? What are the main entities/tables?
+- Does it integrate with any external services or APIs?
+- How is it deployed? (Vercel, Railway, AWS, Docker, etc.)
+
+### Section 3 of 7: Tech Stack Details
+- Specific frameworks and versions? (e.g., FastAPI 0.100+, Next.js 14)
+- Package manager? (npm, yarn, pnpm, bun, pip, poetry)
+- ORM or database client? (Prisma, SQLAlchemy, Drizzle, etc.)
+- Testing framework? (pytest, vitest, jest, etc.)
+- Linting/formatting tools already configured?
+
+### Section 4 of 7: Core Features
+- What are the main features or modules?
+- Which are already built vs planned?
+- What's the priority order?
+- Any complex business logic Claude should understand?
+- Any tricky edge cases or gotchas you've discovered?
+
+### Section 5 of 7: Development Workflow
+- How do you start the project locally? (exact commands)
+- How do you run tests? (exact commands)
+- How do you build for production?
+- Any environment variables needed? (names only, not values)
+- CI/CD pipeline? (GitHub Actions, GitLab CI, etc.)
+- Any setup steps for new developers?
+
+### Section 6 of 7: Coding Conventions
+- Any specific patterns? (repository pattern, service layer, clean architecture, etc.)
+- Error handling approach?
+- Logging approach?
+- API response format conventions?
+- Naming conventions for files, functions, variables?
+- Any "never do this" rules specific to this project?
+- Any "always do this" rules?
+
+### Section 7 of 7: Verification Strategy
+- How should Claude verify its changes work?
+- Are there specific test commands beyond the standard ones?
+- Can Claude run the app and test it manually? How?
+- Any browser testing needed? How to set up?
+- Is there a staging or preview environment?
+- Any CI checks that must pass before merging?
+
+## After Interview
+
+Summarize everything learned in a brief overview. Then write/update
+these files with real, project-specific content:
+
+1. **CLAUDE.md** — Update Tech Stack section with exact tools and
+   versions. Update Commands section with real project commands.
+   Add any project-specific critical rules or gotchas.
+
+2. **docs/spec/SPEC.md** — Write a comprehensive specification
+   from the interview answers. Include all features, data models,
+   architecture decisions, and implementation phases.
+
+3. **.claude/skills/backend-conventions.md** — Fill with real
+   backend patterns, framework-specific conventions, database
+   patterns specific to this project.
+
+4. **.claude/skills/frontend-design-system.md** — Fill with real
+   design system, component patterns, styling approach if
+   applicable.
+
+5. **.claude/skills/project-patterns.md** — Fill with real
+   architectural patterns, directory structure explanation,
+   module interaction patterns.
+
+6. **docs/spec/PROGRESS.md** — Update with actual phases and
+   features from the interview, marking completed items.
+
+Show the user what files were updated and offer to review each one.

package/templates/commands/start.md

@@ -0,0 +1,3 @@
+Read docs/spec/PROGRESS.md to understand current state.
+If an active implementation prompt exists, read it.
+Report: what was last completed, what's next, any blockers.

package/templates/commands/status.md

@@ -0,0 +1,6 @@
+Report current session state:
+- Current task / what you're working on
+- Git branch and recent commits
+- Test status (last run results)
+- Context usage estimate
+- Any blockers or pending decisions

package/templates/commands/techdebt.md

@@ -0,0 +1,9 @@
+Scan the codebase for technical debt:
+- Duplicated code
+- Dead code (unused functions, imports, variables)
+- TODO/FIXME/HACK comments
+- Overly complex functions
+- Missing tests for critical paths
+- Inconsistent patterns
+
+Report findings organized by severity. Fix quick wins directly.

package/templates/commands/update-claude-md.md

@@ -0,0 +1,9 @@
+Based on this session's work, propose updates to CLAUDE.md:
+
+Review what happened:
+- Any mistakes that should become rules
+- Any patterns discovered that should be documented
+- Any gotchas encountered
+
+Write the proposed additions to the Gotchas section or
+Critical Rules section. Show the diff before applying.

package/templates/commands/verify.md

@@ -0,0 +1,8 @@
+Run full project verification:
+1. Run the test suite
+2. Run the build
+3. Run the linter
+4. Run type checking (if applicable)
+5. Run any domain-specific verification
+
+Report results clearly. Do not proceed if any check fails.

package/templates/mcp-json.json

@@ -0,0 +1,3 @@
+{
+  "mcpServers": {}
+}

package/templates/progress-md.md

@@ -0,0 +1,21 @@
+# PROGRESS.md
+
+## Current Status
+**Phase:** Not started
+**Last Updated:** {timestamp}
+
+## Completed
+- [x] Project setup with Worclaude
+
+## In Progress
+- [ ] Define project spec in SPEC.md
+
+## Next Steps
+1. Write your SPEC.md with project requirements
+2. Fill in CLAUDE.md with project-specific details
+3. Start your first Claude Code session
+
+## Blockers
+None
+
+## Notes

package/templates/settings/base.json

@@ -0,0 +1,64 @@
+{
+  "permissions": {
+    "allow": [
+      "// -- Read-only / Exploration --",
+      "Bash(find:*)", "Bash(grep:*)", "Bash(cat:*)", "Bash(ls:*)",
+      "Bash(head:*)", "Bash(tail:*)", "Bash(wc:*)", "Bash(which:*)",
+      "Bash(tree:*)", "Bash(diff:*)", "Bash(sort:*)", "Bash(uniq:*)",
+      "Bash(awk:*)", "Bash(sed:*)", "Bash(cut:*)", "Bash(jq:*)",
+      "Bash(xargs:*)",
+      "Bash(ps:*)", "Bash(du:*)", "Bash(df:*)",
+      "Bash(env:*)", "Bash(printenv:*)",
+
+      "// -- Git --",
+      "Bash(git status:*)", "Bash(git log:*)", "Bash(git diff:*)",
+      "Bash(git branch:*)", "Bash(git checkout:*)",
+      "Bash(git add:*)", "Bash(git commit:*)", "Bash(git push:*)",
+      "Bash(git pull:*)", "Bash(git fetch:*)", "Bash(git merge:*)",
+      "Bash(git stash:*)", "Bash(git worktree:*)",
+      "Bash(git rebase:*)", "Bash(git cherry-pick:*)", "Bash(git tag:*)",
+      "Bash(gh:*)",
+
+      "// -- Common Dev Tools --",
+      "Bash(echo:*)", "Bash(mkdir:*)", "Bash(touch:*)",
+      "Bash(cp:*)", "Bash(mv:*)",
+      "Bash(curl:*)", "Bash(wget:*)",
+      "Bash(tar:*)", "Bash(zip:*)", "Bash(unzip:*)",
+      "Bash(make:*)",
+
+      "// -- Edit Permissions --",
+      "Edit(.claude/**)", "Edit(docs/**)",
+      "Edit(src/**)", "Edit(tests/**)", "Edit(test/**)",
+      "Edit(README*)", "Edit(*.md)",
+      "Edit(package.json)", "Edit(pyproject.toml)",
+      "Edit(.github/**)"
+    ]
+  },
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Write|Edit",
+        "hooks": [{
+          "type": "command",
+          "command": "{formatter_command}"
+        }]
+      },
+      {
+        "matcher": "Stop",
+        "hooks": [{
+          "type": "command",
+          "command": "{notification_command}"
+        }]
+      }
+    ],
+    "PostCompact": [
+      {
+        "matcher": "",
+        "hooks": [{
+          "type": "command",
+          "command": "cat CLAUDE.md && cat docs/spec/PROGRESS.md 2>/dev/null || true"
+        }]
+      }
+    ]
+  }
+}

package/templates/settings/docker.json

@@ -0,0 +1,9 @@
+{
+  "permissions": {
+    "allow": [
+      "// -- Docker --",
+      "Bash(docker:*)", "Bash(docker-compose:*)", "Bash(docker compose:*)",
+      "Edit(Dockerfile*)", "Edit(docker-compose*)", "Edit(.dockerignore)"
+    ]
+  }
+}

package/templates/settings/go.json

@@ -0,0 +1,10 @@
+{
+  "permissions": {
+    "allow": [
+      "// -- Go --",
+      "Bash(go:*)", "Bash(gofmt:*)", "Bash(golangci-lint:*)",
+      "Edit(*.go)", "Edit(go.mod)", "Edit(go.sum)"
+    ]
+  },
+  "formatter": "gofmt -w . || true"
+}

package/templates/settings/node.json

@@ -0,0 +1,17 @@
+{
+  "permissions": {
+    "allow": [
+      "// -- Node.js / TypeScript --",
+      "Bash(npm:*)", "Bash(npx:*)", "Bash(node:*)",
+      "Bash(tsc:*)", "Bash(tsx:*)",
+      "Bash(jest:*)", "Bash(vitest:*)",
+      "Bash(eslint:*)", "Bash(prettier:*)",
+      "Bash(pnpm:*)", "Bash(yarn:*)", "Bash(bun:*)",
+      "Edit(*.ts)", "Edit(*.tsx)", "Edit(*.js)", "Edit(*.jsx)",
+      "Edit(*.json)", "Edit(*.css)", "Edit(*.scss)",
+      "Edit(tsconfig*.json)", "Edit(.eslintrc*)",
+      "Edit(vite.config.*)", "Edit(next.config.*)", "Edit(webpack.config.*)"
+    ]
+  },
+  "formatter": "npx prettier --write . || true"
+}

package/templates/settings/python.json

@@ -0,0 +1,16 @@
+{
+  "permissions": {
+    "allow": [
+      "// -- Python --",
+      "Bash(python:*)", "Bash(python3:*)",
+      "Bash(pip:*)", "Bash(pip3:*)",
+      "Bash(uv:*)", "Bash(uvx:*)",
+      "Bash(pytest:*)", "Bash(ruff:*)", "Bash(mypy:*)",
+      "Bash(black:*)", "Bash(isort:*)", "Bash(flake8:*)",
+      "Bash(poetry:*)", "Bash(pdm:*)",
+      "Edit(*.py)", "Edit(pyproject.toml)",
+      "Edit(requirements*.txt)", "Edit(setup.py)", "Edit(setup.cfg)"
+    ]
+  },
+  "formatter": "ruff format . || true"
+}

package/templates/settings/rust.json

@@ -0,0 +1,11 @@
+{
+  "permissions": {
+    "allow": [
+      "// -- Rust --",
+      "Bash(cargo:*)", "Bash(rustc:*)", "Bash(rustup:*)",
+      "Bash(clippy:*)",
+      "Edit(*.rs)", "Edit(Cargo.toml)", "Edit(Cargo.lock)"
+    ]
+  },
+  "formatter": "cargo fmt || true"
+}

package/templates/skills/templates/backend-conventions.md

@@ -0,0 +1,57 @@
+---
+description: "Stack-specific backend patterns, API design, database access, error handling conventions"
+---
+
+# Backend Conventions
+
+> Fill in each section with your project's specific patterns. Delete sections that
+> don't apply. Add sections for patterns unique to your stack.
+
+## API Patterns
+
+<!-- How are endpoints structured? REST, GraphQL, RPC?
+     What's the URL naming convention?
+     How are request/response bodies structured?
+     What authentication is required per endpoint?
+     How is pagination handled?
+     How are API versions managed? -->
+
+## Database Access
+
+<!-- Which ORM/query builder/driver is used?
+     Where do migrations live? How are they run?
+     What's the naming convention for tables and columns?
+     How are transactions handled?
+     Are there read replicas or connection pooling concerns?
+     What's the seeding strategy for development? -->
+
+## Error Handling
+
+<!-- What error types/classes exist?
+     How are errors propagated to the API response?
+     What HTTP status codes map to which error types?
+     How are errors logged?
+     What information is safe to expose to clients vs internal-only? -->
+
+## Authentication
+
+<!-- What auth mechanism is used (JWT, sessions, API keys)?
+     Where is auth middleware applied?
+     How are roles/permissions structured?
+     How are tokens refreshed?
+     What's the password hashing strategy? -->
+
+## Logging
+
+<!-- What logging library is used?
+     What log levels mean what?
+     What structured fields are required on every log entry?
+     Where do logs go (stdout, file, service)?
+     What should NEVER be logged (PII, secrets)? -->
+
+## Configuration Management
+
+<!-- How is config loaded (env vars, config files, secrets manager)?
+     What's the hierarchy (defaults < config file < env vars)?
+     How are secrets managed in dev vs production?
+     What validation runs on config at startup? -->

package/templates/skills/templates/frontend-design-system.md

@@ -0,0 +1,48 @@
+---
+description: "Design system, component library, styling approach, accessibility and responsive design standards"
+---
+
+# Frontend Design System
+
+> Fill in each section with your project's specific patterns. Delete sections that
+> don't apply. Add sections for patterns unique to your stack.
+
+## Component Library
+
+<!-- What component library is used (custom, Material UI, Shadcn, etc.)?
+     Where do shared components live?
+     What's the naming convention for components?
+     How are component variants handled (props, composition)?
+     What's the component documentation strategy (Storybook, etc.)? -->
+
+## Styling Approach
+
+<!-- CSS-in-JS, CSS modules, Tailwind, plain CSS?
+     What's the naming convention (BEM, utility-first)?
+     Where do design tokens live (colors, spacing, typography)?
+     How are themes handled (dark mode, brand variants)?
+     What's the z-index strategy? -->
+
+## State Management
+
+<!-- What state management solution is used?
+     What goes in global state vs local state?
+     How is server state cached and synchronized?
+     What's the data fetching pattern (React Query, SWR, etc.)?
+     How are loading and error states handled consistently? -->
+
+## Accessibility Standards
+
+<!-- What WCAG level is targeted (A, AA, AAA)?
+     How is keyboard navigation handled?
+     What ARIA patterns are used for common widgets?
+     How are focus management and screen reader support tested?
+     What color contrast requirements apply? -->
+
+## Responsive Design
+
+<!-- What breakpoints are used?
+     Mobile-first or desktop-first approach?
+     How are images handled at different sizes?
+     What layouts change at which breakpoints?
+     How is touch vs mouse interaction handled? -->

package/templates/skills/templates/project-patterns.md

@@ -0,0 +1,48 @@
+---
+description: "Architectural patterns, naming conventions, file organization, and error handling philosophy for this project"
+---
+
+# Project Patterns
+
+> Fill in each section with your project's specific patterns. Delete sections that
+> don't apply. Add sections for patterns unique to your architecture.
+
+## Architecture Overview
+
+<!-- What's the high-level architecture (monolith, microservices, serverless)?
+     What are the major components and how do they communicate?
+     Where does the domain logic live vs infrastructure?
+     What external services does this project depend on?
+     Is there a diagram or reference document? -->
+
+## Naming Conventions
+
+<!-- How are files named (camelCase, kebab-case, PascalCase)?
+     How are functions/methods named?
+     How are constants named?
+     How are database tables/columns named?
+     Are there domain-specific naming rules? -->
+
+## File Organization
+
+<!-- What's the directory structure philosophy (feature-based, layer-based)?
+     Where do new features go?
+     Where do shared utilities live?
+     Where do types/interfaces live?
+     How are test files organized relative to source files? -->
+
+## Common Patterns
+
+<!-- What design patterns are used consistently (repository, factory, observer)?
+     How is dependency injection handled?
+     What's the pattern for adding a new feature end-to-end?
+     What's the pattern for adding a new API endpoint?
+     Are there code generation tools or templates for common tasks? -->
+
+## Error Handling Philosophy
+
+<!-- How are errors classified (operational vs programmer)?
+     How do errors propagate through layers?
+     What's the retry strategy for transient failures?
+     How are errors reported to monitoring/alerting?
+     What's the circuit breaker strategy for external dependencies? -->