// Manages Git worktrees for isolated parallel development. Use when creating separate working directories for branches without switching the main repo.
Per-repo commit worker. Analyzes ALL changed files independently, groups them by ticket, and makes MULTIPLE focused commits — one per logical group. Spawned in parallel by /pwf-commit-changes (one instance per repo). Never create branches or push.
Commit uncommitted changes across all workspace repos and tag commits with ticket numbers. Each repo gets its own subagent that analyzes files individually, groups them by ticket, and makes multiple focused commits. Use when the user pastes issue text (with TICKET-XXX) and wants to commit, or says "commit with these tickets" / "commit my changes".
Deploy AWS Lambdas using the guaranteed deploy scripts only. Never deploy via IAC (CDK). Requires AWS SSO login first. Use when deploying any AWS Lambda repo.
Load and enforce mandatory project documentation baseline before implementation work.
Run standardized post-implementation documentation maintenance and quality checks.
Use when implementation is complete to close branch/worktree with a disciplined decision flow (merge, PR, keep, discard) plus cleanup.
| name | git-worktree |
| description | Manages Git worktrees for isolated parallel development. Use when creating separate working directories for branches without switching the main repo. |
Create and use Git worktrees so multiple branches can be worked on in separate directories.
Commands (run from repo root):
git worktree listgit worktree add <path> <branch> (e.g. git worktree add ../project-feat ../feature-branch)git worktree remove <path> (after switching away and committing or discarding)Use case: Run a separate agent or human in another branch in a different folder without touching the current branch. Each worktree has its own working directory but shares the same .git history.
Note: Repo root is the workspace root; backend/frontend/lambdas may be sibling folders or monorepo structure. Create worktrees from the repo that contains the branch you need.
When implementation in a worktree is complete, use finishing-a-development-branch to close with a consistent decision flow:
This avoids dangling worktrees and branch confusion.