worclaude 1.3.8 → 1.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "worclaude",
-  "version": "1.3.8",
+  "version": "1.4.0",
   "description": "CLI tool that scaffolds a comprehensive Claude Code workflow into any project",
   "type": "module",
   "bin": {

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

@@ -1,8 +1,15 @@
 1. Update docs/spec/PROGRESS.md with what was completed this session
-2. Stage all changes: git add -A
-3. Write a clear, conventional commit message
-4. Push to the current branch
-5. Create a PR with:
+2. **Version bump (only when on `develop` targeting `main`):**
+   - Check what changed since last version using the versioning policy in git-conventions.md
+   - Template or CLI behavior changes → patch bump
+   - New command/feature → minor bump
+   - Breaking change → major bump
+   - Only docs/CI/tests/PROGRESS.md → no bump needed
+   - If bump needed: update `version` in package.json
+3. Stage all changes: git add -A
+4. Write a clear, conventional commit message
+5. Push to the current branch
+6. Create a PR with:
    - Clear title matching conventional commit format
    - Description of changes
    - Testing done

package/templates/core/claude-md.md

@@ -15,11 +15,14 @@
 ## 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
+- claude-md-maintenance.md — CLAUDE.md self-healing
+- git-conventions.md — Commits, branches, versioning
 - planning-with-files.md — Implementation planning
+- prompt-engineering.md — Prompting patterns and quality
 - review-and-handoff.md — Session endings
 - verification.md — How to verify work
 - testing.md — Test philosophy and patterns
+- subagent-usage.md — When and how to use subagents
 - agent-routing.md — When and how to use each installed agent (READ EVERY SESSION)
 {project_specific_skills}
 

package/templates/skills/universal/git-conventions.md

@@ -1,5 +1,5 @@
 ---
-description: "Branch naming, commit message format, PR workflow, worktree conventions"
+description: "Branch naming, commit message format, PR workflow, worktree conventions, versioning policy"
 ---
 
 # Git Conventions
@@ -97,6 +97,29 @@ When using `git worktree` for parallel work:
 Agents that use worktree isolation (code-simplifier, test-writer, ci-fixer, etc.)
 create and clean up their own worktrees automatically.
 
+## Versioning Policy
+
+Follow [semver](https://semver.org/) when the project publishes releases:
+
+| What changed | Bump | Example |
+|---|---|---|
+| Bug fix, patch to existing behavior | **patch** | Fixed edge case in date parser |
+| New feature, command, or API surface | **minor** | Added CSV export option |
+| Breaking change to public API or CLI | **major** | Renamed config key, removed flag |
+| Only docs, CI, tests, internal refactor | **no bump** | Updated README, added test |
+
+**Publish from the primary branch (usually `main`),** not from feature or development branches. What is published must always match what is on the release branch.
+
+**When to bump:** Include the version change in the same PR as the work — no separate "bump version" commits after the fact.
+
+**How to publish:**
+1. Merge the release PR into `main`
+2. Pull locally: `git checkout main && git pull`
+3. Publish using your ecosystem's tool (`npm publish`, `cargo publish`, `twine upload`, etc.)
+4. Sync develop: `git checkout develop && git merge main && git push origin develop`
+
+**Rule of thumb:** If the change affects what users see, install, or depend on, it needs a version bump. If it only affects the project's internal development workflow, it does not.
+
 ## Gotchas
 
 - Never force-push to main/master. Force-push to feature branches only when you