worclaude 1.5.0 → 1.6.1

package/README.md

@@ -10,7 +10,7 @@
 
 [Full Documentation](https://sefaertunc.github.io/Worclaude/) · [Interactive Demo](https://sefaertunc.github.io/Worclaude/demo/) · [npm](https://www.npmjs.com/package/worclaude)
 
-Worclaude scaffolds a complete Claude Code workflow into any project in seconds. It implements all [53 tips by Boris Cherny](https://www.howborisusesclaudecode.com/) — the creator of Claude Code at Anthropic — as a reusable, upgradable scaffold. One `init` command gives you 23 agents, 10 slash commands, 13 skills, hooks, permissions, and a CLAUDE.md template tuned for your tech stack. Whether you're starting fresh or adding structure to an existing project, Worclaude handles the setup so you can focus on building.
+Worclaude scaffolds a complete Claude Code workflow into any project in seconds. It implements all [53 tips by Boris Cherny](https://www.howborisusesclaudecode.com/) — the creator of Claude Code at Anthropic — as a reusable, upgradable scaffold. One `init` command gives you 23 agents, 12 slash commands, 13 skills, hooks, permissions, and a CLAUDE.md template tuned for your tech stack. Whether you're starting fresh or adding structure to an existing project, Worclaude handles the setup so you can focus on building.
 
 ---
 
@@ -23,8 +23,8 @@ Worclaude scaffolds a complete Claude Code workflow into any project in seconds.
 - 5 universal: plan-reviewer, code-simplifier, test-writer, build-validator, verify-app
 - 18 optional across 6 categories: Backend, Frontend, DevOps, Quality, Documentation, Data/AI
 
-**Slash Commands (10)**
-`/start` `/end` `/commit-push-pr` `/review-plan` `/techdebt` `/verify` `/compact-safe` `/status` `/update-claude-md` `/setup`
+**Slash Commands (12)**
+`/start` `/end` `/commit-push-pr` `/review-plan` `/techdebt` `/verify` `/compact-safe` `/status` `/update-claude-md` `/setup` `/sync` `/conflict-resolver`
 
 **Skills (13)**
 

package/package.json

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

package/src/core/remover.js

@@ -179,7 +179,7 @@ export async function cleanGitignore(projectRoot) {
   if (!(await fileExists(gitignorePath))) return false;
 
   const content = await readFile(gitignorePath);
-  const lines = content.split('\n');
+  const lines = content.split(/\r?\n/);
 
   const REMOVE_LINES = new Set(['# Worclaude (generated workflow files)', '.claude/']);
 

package/src/data/agents.js

@@ -168,6 +168,8 @@ export const COMMAND_FILES = [
   'status',
   'update-claude-md',
   'setup',
+  'sync',
+  'conflict-resolver',
 ];
 
 export const UNIVERSAL_SKILLS = [

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

@@ -1,23 +1,28 @@
-1. Update docs/spec/PROGRESS.md with what was completed this session
-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
-   - Any notes for reviewers
-
-Branch targeting rules:
-
-- Feature/bugfix branches → PR targets `develop` (`gh pr create --base develop`)
-- When on `develop` → PR targets `main` (`gh pr create --base main`) — release merges only
-
-Use `gh pr create` for PR creation.
+Determine which branch you're on, then follow the appropriate flow.
+Do not add Co-Authored-By trailers or AI-generated footers to commits or PR descriptions.
+
+## On a feature branch (feature/*, fix/*, chore/*, refactor/*)
+
+Feature branches contain ONLY the task changes. Do NOT touch shared-state
+files (see git-conventions.md for the canonical list).
+
+1. Stage all changes: git add -A
+2. Write a clear, conventional commit message
+3. Push to the current branch
+4. Create a PR targeting develop: gh pr create --base develop
+5. Include in PR description: title, changes, testing done, reviewer notes
+
+## On develop
+
+Only used for release merges after /sync has been run.
+
+1. Stage all changes: git add -A
+2. Write a clear, conventional commit message
+3. Push to develop
+4. Create a PR targeting main: gh pr create --base main
+
+## On any other branch
+
+Ask the user which base branch to target before creating a PR.
+
+Use gh pr create for PR creation.

package/templates/commands/conflict-resolver.md

@@ -0,0 +1,41 @@
+You are resolving merge conflicts. ONLY resolve conflicts — do not
+update PROGRESS.md, SPEC.md, or bump versions. That is /sync's job.
+
+## Step 1: Detect
+
+Run: git status
+Identify all files with merge conflicts (listed as "both modified").
+If no conflicts found, report "No conflicts detected" and stop.
+
+## Step 2: Understand
+
+For each conflicted file:
+- Read the file and find all <<<<<<< / ======= / >>>>>>> markers
+- Understand what EACH side was trying to do
+- Check git log for both branches to understand the intent
+
+## Step 3: Resolve
+
+For each conflict:
+- Changes in DIFFERENT parts of the code → keep both
+- Changes modify the SAME lines → combine intelligently based on intent
+- Changes truly contradict → ask the user which to keep
+- NEVER silently drop changes from either side
+
+## Step 4: Verify clean
+
+Search ALL tracked files for remaining conflict markers
+(<<<<<<, =======, >>>>>>>). If any remain, resolve them.
+
+## Step 5: Test
+
+Run /verify (or the project's test and lint commands).
+If anything fails, fix it.
+
+## Step 6: Commit resolution only
+
+- git add -A
+- git commit -m "merge: resolve conflicts on develop"
+  Use exactly this message format — no trailers or Co-Authored-By lines.
+
+Do NOT push. Do NOT create a PR. The user will run /sync next.

package/templates/commands/end.md

@@ -1,11 +1,17 @@
-Use this command ONLY when stopping mid-task (unfinished work).
-If the task is complete, use /commit-push-pr instead — it handles PROGRESS.md updates.
+Use this ONLY when stopping work mid-task without committing.
 
-When stopping mid-task:
-1. Update docs/spec/PROGRESS.md with:
-   - What's in progress
-   - Any blockers or decisions needed
-   - Next steps to resume
-2. Write a handoff document at docs/handoffs/HANDOFF_{date}.md
-   with enough context for a fresh session to continue seamlessly.
-3. Stage and commit the progress update: git add -A && git commit
+Do NOT update PROGRESS.md — /sync handles that on develop after merging.
+
+## Mid-task handoff
+
+1. Create docs/handoffs/HANDOFF-{branch-name}-{date}.md
+2. Include:
+   - What was being worked on
+   - What is done so far
+   - What is left to do
+   - Decisions or context the next session needs
+   - Files that were modified
+3. git add -A
+4. git commit -m "wip: handoff for [task description]"
+   Use exactly this message format — no trailers or Co-Authored-By lines.
+5. git push

package/templates/commands/start.md

@@ -1,3 +1,11 @@
 Read docs/spec/PROGRESS.md to understand current state.
+Read .claude/skills/agent-routing.md for agent usage guidance.
+
+Check for handoff files from previous sessions:
+- Look in docs/handoffs/ for any HANDOFF*.md files
+  (both HANDOFF-{branch}-{date}.md and legacy HANDOFF_{date}.md)
+- Prioritize files matching the current branch name
+- If found, read them for context and report what was handed off
+
 If an active implementation prompt exists, read it.
 Report: what was last completed, what's next, any blockers.

package/templates/commands/sync.md

@@ -0,0 +1,50 @@
+Update shared-state files after merging feature PRs into develop.
+Run this on the develop branch AFTER all PRs are merged and any
+conflicts are resolved.
+
+ONLY update shared-state files — do not resolve conflicts. That is
+/conflict-resolver's job. If you detect unresolved conflicts, stop
+and tell the user to run /conflict-resolver first.
+
+## Pre-check
+
+1. Confirm you are on the develop branch. If not, stop and warn.
+2. Check for unresolved conflict markers in tracked files.
+   If found, stop: "Run /conflict-resolver first."
+3. Read git log to understand what was merged since the last sync
+   or version tag. If nothing was merged, report "Nothing to sync"
+   and stop.
+
+## Update PROGRESS.md
+
+4. Update docs/spec/PROGRESS.md:
+   - Mark completed items based on merged work
+   - Update "Last Updated" date to today
+   - Update Stats section by checking actual project values
+     (run the test suite, count source files, etc.)
+   - Move "In Progress" items to "Completed" if their PRs merged
+   - Update "Next Steps" if needed
+
+## Update SPEC.md
+
+5. If any merged PRs added features or changed behavior, update
+   docs/spec/SPEC.md to reflect the current state.
+   If nothing changed spec-wise, leave it alone.
+
+## Version bump
+
+6. Determine version bump using the Versioning Policy in
+   git-conventions.md. If bump needed: update version in package.json.
+
+## Verify
+
+7. Run /verify to confirm tests and lint pass.
+   If anything fails, fix it before proceeding.
+
+## Commit, push, and PR
+
+8. git add -A
+9. git commit -m "chore: sync progress, spec, and version to [new version]"
+   Use exactly this message format — no trailers or Co-Authored-By lines.
+10. git push origin develop
+11. gh pr create --base main with description of what was merged

package/templates/core/claude-md.md

@@ -29,7 +29,9 @@ See `.claude/skills/` — load only what's relevant:
 ## Session Protocol
 **Start:** Read PROGRESS.md → Read `.claude/skills/agent-routing.md` → Read active implementation prompt if any.
 **During:** One task at a time. Commit after each. Use subagents per routing guide.
-**End:** Use /commit-push-pr (updates PROGRESS.md, commits, pushes, creates PR). Use /end only if stopping mid-task.
+**Feature branch:** /start → work → /verify → /commit-push-pr
+**After merging PRs:** git checkout develop → git pull → /conflict-resolver (if needed) → /sync
+**Mid-task stop:** /end (writes handoff file)
 
 ## Critical Rules
 1. SPEC.md is source of truth. Do not invent features.
@@ -39,6 +41,8 @@ See `.claude/skills/` — load only what's relevant:
 5. Self-healing: same mistake twice → update CLAUDE.md.
 6. Use subagents to keep main context clean.
 7. Mediocre fix → scrap it, implement elegantly.
+8. Feature branches NEVER modify shared-state files. Those are updated only on develop via /sync after merging PRs. See git-conventions.md Shared-State Files for the canonical list.
+9. Never add Co-Authored-By trailers, AI attribution footers, or "Generated with" signatures to commits or PRs.
 
 ## Gotchas
 [Grows during development]

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

@@ -46,6 +46,7 @@ Rules:
 - No period at the end of the subject line
 - Blank line between subject and body
 - Body explains motivation, not mechanics
+- Never append Co-Authored-By trailers, AI attribution lines, or "Generated with" footers
 
 ## When to Commit
 
@@ -76,6 +77,7 @@ All feature/bugfix branches are created from and merged back into `develop`. Nev
 4. PR title follows same format as commit subject: `type(scope): description`
 5. PR body includes: what changed, why, how to test, anything reviewers should know
 6. Request review if the project has reviewers configured
+7. Do not add AI-generated footers (e.g., "Generated with Claude Code") to PR descriptions
 
 ## Squash vs Merge
 
@@ -97,6 +99,17 @@ 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.
 
+## Shared-State Files
+
+These files are modified ONLY on the develop branch (via /sync), never on feature branches:
+
+- `docs/spec/PROGRESS.md` — project progress tracker
+- `docs/spec/SPEC.md` — feature specification
+- `README.md` — project documentation
+- `package.json` version field — release versioning
+
+This prevents merge conflicts when running parallel feature branches.
+
 ## Versioning Policy
 
 Follow [semver](https://semver.org/) when the project publishes releases: