@glxmart/boss-cli 1.0.0-beta.0

package/dist/assets/worker-configs/devops-engineer/CLAUDE.md

@@ -0,0 +1,111 @@
+# ${workerName} Worker Instructions
+
+This worker is responsible for ${workerRoleDescription}
+
+## Worker-Specific Guidelines
+
+- Follow the prompt in \`prompt.md\` for detailed role instructions
+- Use container-use environments for all operations
+- Reference \`.claude/commands/\`, \`.claude/skills/\`, and \`.claude/agents/\` for worker-specific resources
+
+## Environment Operations
+
+All file, code, and shell operations MUST use container-use environments.
+
+- DO NOT use git CLI directly
+- All operations must go through container-use MCP
+- Inform user: \`container-use log <env_id>\` AND \`container-use checkout <env_id>\`
+
+## Project Status & Configuration
+
+**CRITICAL:** Always check `.boss/project-config.json` to understand project state before starting work.
+
+**Read project-config.json to understand:**
+- Current branch and workflow stage
+- Active workers and their status
+- Completed tasks
+- Repository information
+- Initialization status
+
+**Update project-config.json when:**
+- Starting work: Add your environment ID to `workflow.activeWorkers`
+- Completing work: Add a summary to `workers.summaries` with:
+  - Environment ID
+  - Tasks completed
+  - Artifacts created (CI/CD configs, infrastructure code, deployment docs)
+  - Deployment environments configured
+  - Any blockers or issues encountered
+- After merging: Remove from `workflow.activeWorkers` and add to `workflow.completedTasks`
+
+**Example worker summary format:**
+```json
+{
+  "envId": "env-abc123",
+  "workerType": "${workerName}",
+  "completedAt": "2026-01-15T10:30:00Z",
+  "tasksCompleted": ["CI/CD pipeline", "Infrastructure setup"],
+  "artifactsCreated": [".github/workflows/ci.yml", "terraform/", ".specify/specs/001-feature/quickstart.md"],
+  "environments": ["dev", "staging", "production"],
+  "notes": "Set up CI/CD pipeline and infrastructure for feature deployment"
+}
+```
+
+**IMPORTANT:**
+- NEVER use git commands to check project status - read project-config.json instead
+- ALWAYS update project-config.json when completing work
+- Keep summaries concise but informative for BOSS to track progress
+
+## Git Commit Strategy
+
+**IMPORTANT:** Batch related changes into logical commits to reduce overhead and improve workflow efficiency.
+
+### Batching Guidelines
+
+1. **Group files by feature/fix** (not by file type)
+2. **Aim for 1-3 commits per task** instead of 5-10
+3. **Use meaningful commit messages** following Conventional Commits
+4. **Only commit when reaching a logical checkpoint**
+
+### Good Practice ✅
+
+```bash
+# Create infrastructure files in one commit
+git add .github/workflows/ci.yml .github/workflows/deploy.yml
+git commit -m "ci: add CI/CD pipeline workflows"
+
+# Or batch complete infrastructure setup
+git add terraform/main.tf terraform/variables.tf .specify/specs/001-feature/quickstart.md
+git commit -m "feat: add infrastructure configuration with deployment docs"
+```
+
+### Bad Practice ❌
+
+```bash
+# Individual commits for related work (too granular)
+git add .github/workflows/ci.yml
+git commit -m "ci: add CI"
+
+git add .github/workflows/deploy.yml
+git commit -m "ci: add deploy"
+
+git add terraform/main.tf
+git commit -m "feat: add terraform"
+```
+
+### Commit Message Format
+
+Follow Conventional Commits:
+- `ci:` - CI/CD changes (primary for devops)
+- `feat:` - New infrastructure features
+- `fix:` - Infrastructure bug fixes
+- `docs:` - Documentation changes
+- `chore:` - Maintenance tasks
+
+### Expected Behavior
+
+- **Simple task:** 1-2 commits (setup + configuration)
+- **Complex task:** 2-3 commits (major infrastructure phases)
+- **Avoid:** 5-10 commits for small changes
+
+This batching strategy reduces git overhead by ~10-15 seconds per task and creates cleaner commit history.
+

package/dist/assets/worker-configs/planner/.claude/commands/.gitkeep

@@ -0,0 +1 @@
+

package/dist/assets/worker-configs/planner/.claude/skills/.gitkeep

@@ -0,0 +1 @@
+

package/dist/assets/worker-configs/planner/CLAUDE.md

@@ -0,0 +1,111 @@
+# ${workerName} Worker Instructions
+
+This worker is responsible for ${workerRoleDescription}
+
+## Worker-Specific Guidelines
+
+- Follow the prompt in \`prompt.md\` for detailed role instructions
+- Use container-use environments for all operations
+- Reference \`.claude/commands/\`, \`.claude/skills/\`, and \`.claude/agents/\` for worker-specific resources
+
+## Environment Operations
+
+All file, code, and shell operations MUST use container-use environments.
+
+- DO NOT use git CLI directly
+- All operations must go through container-use MCP
+- Inform user: \`container-use log <env_id>\` AND \`container-use checkout <env_id>\`
+
+## Project Status & Configuration
+
+**CRITICAL:** Always check `.boss/project-config.json` to understand project state before starting work.
+
+**Read project-config.json to understand:**
+- Current branch and workflow stage
+- Active workers and their status
+- Completed tasks
+- Repository information
+- Initialization status
+
+**Update project-config.json when:**
+- Starting work: Add your environment ID to `workflow.activeWorkers`
+- Completing work: Add a summary to `workers.summaries` with:
+  - Environment ID
+  - Tasks completed
+  - Artifacts created (plan.md, data-model.md, tasks.md, contracts/)
+  - Tasks broken down
+  - Parallel tasks identified
+  - Any blockers or issues encountered
+- After merging: Remove from `workflow.activeWorkers` and add to `workflow.completedTasks`
+
+**Example worker summary format:**
+```json
+{
+  "envId": "env-abc123",
+  "workerType": "${workerName}",
+  "completedAt": "2026-01-15T10:30:00Z",
+  "tasksCompleted": ["Planning phase"],
+  "artifactsCreated": [".specify/specs/001-feature/plan.md", ".specify/specs/001-feature/tasks.md"],
+  "tasksBrokenDown": 35,
+  "parallelTasksIdentified": 12,
+  "notes": "Created technical plan with 35 tasks, 12 marked for parallel execution"
+}
+```
+
+**IMPORTANT:**
+- NEVER use git commands to check project status - read project-config.json instead
+- ALWAYS update project-config.json when completing work
+- Keep summaries concise but informative for BOSS to track progress
+
+## Git Commit Strategy
+
+**IMPORTANT:** Batch related changes into logical commits to reduce overhead and improve workflow efficiency.
+
+### Batching Guidelines
+
+1. **Group files by feature/fix** (not by file type)
+2. **Aim for 1-3 commits per task** instead of 5-10
+3. **Use meaningful commit messages** following Conventional Commits
+4. **Only commit when reaching a logical checkpoint**
+
+### Good Practice ✅
+
+```bash
+# Create planning artifacts in one commit
+git add .specify/specs/001-feature/plan.md .specify/specs/001-feature/tasks.md
+git commit -m "docs: add technical plan with task breakdown"
+
+# Or batch complete planning phase
+git add .specify/specs/001-feature/plan.md .specify/specs/001-feature/data-model.md .specify/specs/001-feature/contracts/
+git commit -m "docs: complete planning phase with data model and API contracts"
+```
+
+### Bad Practice ❌
+
+```bash
+# Individual commits for related work (too granular)
+git add .specify/specs/001-feature/plan.md
+git commit -m "docs: add plan"
+
+git add .specify/specs/001-feature/tasks.md
+git commit -m "docs: add tasks"
+
+git add .specify/specs/001-feature/data-model.md
+git commit -m "docs: add data model"
+```
+
+### Commit Message Format
+
+Follow Conventional Commits:
+- `docs:` - Documentation changes (primary for planner)
+- `feat:` - New planning features
+- `refactor:` - Plan refinements
+
+### Expected Behavior
+
+- **Simple task:** 1-2 commits (initial plan + refinements)
+- **Complex task:** 2-3 commits (major planning phases)
+- **Avoid:** 5-10 commits for small changes
+
+This batching strategy reduces git overhead by ~10-15 seconds per task and creates cleaner commit history.
+

package/dist/assets/worker-configs/product-owner/CLAUDE.md

@@ -0,0 +1,108 @@
+# ${workerName} Worker Instructions
+
+This worker is responsible for ${workerRoleDescription}
+
+## Worker-Specific Guidelines
+
+- Follow the prompt in \`prompt.md\` for detailed role instructions
+- Use container-use environments for all operations
+- Reference \`.claude/commands/\`, \`.claude/skills/\`, and \`.claude/agents/\` for worker-specific resources
+
+## Environment Operations
+
+All file, code, and shell operations MUST use container-use environments.
+
+- DO NOT use git CLI directly
+- All operations must go through container-use MCP
+- Inform user: \`container-use log <env_id>\` AND \`container-use checkout <env_id>\`
+
+## Project Status & Configuration
+
+**CRITICAL:** Always check `.boss/project-config.json` to understand project state before starting work.
+
+**Read project-config.json to understand:**
+- Current branch and workflow stage
+- Active workers and their status
+- Completed tasks
+- Repository information
+- Initialization status
+
+**Update project-config.json when:**
+- Starting work: Add your environment ID to `workflow.activeWorkers`
+- Completing work: Add a summary to `workers.summaries` with:
+  - Environment ID
+  - Tasks completed
+  - Artifacts created (prioritized user stories, acceptance criteria)
+  - Business value delivered
+  - Any blockers or issues encountered
+- After merging: Remove from `workflow.activeWorkers` and add to `workflow.completedTasks`
+
+**Example worker summary format:**
+```json
+{
+  "envId": "env-abc123",
+  "workerType": "${workerName}",
+  "completedAt": "2026-01-15T10:30:00Z",
+  "tasksCompleted": ["User story prioritization", "Acceptance criteria validation"],
+  "artifactsCreated": [".specify/specs/001-feature/spec.md"],
+  "priorities": {"P1": 3, "P2": 5, "P3": 2},
+  "notes": "Prioritized user stories and validated acceptance criteria for feature"
+}
+```
+
+**IMPORTANT:**
+- NEVER use git commands to check project status - read project-config.json instead
+- ALWAYS update project-config.json when completing work
+- Keep summaries concise but informative for BOSS to track progress
+
+## Git Commit Strategy
+
+**IMPORTANT:** Batch related changes into logical commits to reduce overhead and improve workflow efficiency.
+
+### Batching Guidelines
+
+1. **Group files by feature/fix** (not by file type)
+2. **Aim for 1-3 commits per task** instead of 5-10
+3. **Use meaningful commit messages** following Conventional Commits
+4. **Only commit when reaching a logical checkpoint**
+
+### Good Practice ✅
+
+```bash
+# Create spec artifacts in one commit
+git add .specify/specs/001-feature/spec.md .specify/specs/001-feature/acceptance-criteria.md
+git commit -m "docs: add user stories and acceptance criteria"
+
+# Or batch complete specification phase
+git add .specify/specs/001-feature/spec.md .specify/specs/001-feature/user-flows.md
+git commit -m "docs: complete specification with user stories and flows"
+```
+
+### Bad Practice ❌
+
+```bash
+# Individual commits for related work (too granular)
+git add .specify/specs/001-feature/spec.md
+git commit -m "docs: add spec"
+
+git add .specify/specs/001-feature/acceptance-criteria.md
+git commit -m "docs: add criteria"
+
+git add .specify/specs/001-feature/user-flows.md
+git commit -m "docs: add flows"
+```
+
+### Commit Message Format
+
+Follow Conventional Commits:
+- `docs:` - Documentation changes (primary for product-owner)
+- `feat:` - New features in spec
+
+### Expected Behavior
+
+- **Simple task:** 1-2 commits (initial spec + refinements)
+- **Complex task:** 2-3 commits (major spec phases)
+- **Avoid:** 5-10 commits for small changes
+
+This batching strategy reduces git overhead by ~10-15 seconds per task and creates cleaner commit history.
+

package/dist/assets/worker-configs/reviewer/.claude/commands/.gitkeep

@@ -0,0 +1 @@
+

package/dist/assets/worker-configs/reviewer/.claude/skills/.gitkeep

@@ -0,0 +1 @@
+

package/dist/assets/worker-configs/reviewer/CLAUDE.md

@@ -0,0 +1,110 @@
+# ${workerName} Worker Instructions
+
+This worker is responsible for ${workerRoleDescription}
+
+## Worker-Specific Guidelines
+
+- Follow the prompt in \`prompt.md\` for detailed role instructions
+- Use container-use environments for all operations
+- Reference \`.claude/commands/\`, \`.claude/skills/\`, and \`.claude/agents/\` for worker-specific resources
+
+## Environment Operations
+
+All file, code, and shell operations MUST use container-use environments.
+
+- DO NOT use git CLI directly
+- All operations must go through container-use MCP
+- Inform user: \`container-use log <env_id>\` AND \`container-use checkout <env_id>\`
+
+## Project Status & Configuration
+
+**CRITICAL:** Always check `.boss/project-config.json` to understand project state before starting work.
+
+**Read project-config.json to understand:**
+- Current branch and workflow stage
+- Active workers and their status
+- Completed tasks
+- Repository information
+- Initialization status
+
+**Update project-config.json when:**
+- Starting work: Add your environment ID to `workflow.activeWorkers`
+- Completing work: Add a summary to `workers.summaries` with:
+  - Environment ID
+  - Tasks completed
+  - Artifacts created (validation-report.md)
+  - Compliance checks performed
+  - Issues found (if any)
+  - Any blockers or issues encountered
+- After merging: Remove from `workflow.activeWorkers` and add to `workflow.completedTasks`
+
+**Example worker summary format:**
+```json
+{
+  "envId": "env-abc123",
+  "workerType": "${workerName}",
+  "completedAt": "2026-01-15T10:30:00Z",
+  "tasksCompleted": ["Validation phase"],
+  "artifactsCreated": [".specify/specs/001-feature/validation-report.md"],
+  "complianceChecksPerformed": ["TDD", "BDD", "Documentation"],
+  "issuesFound": 0,
+  "notes": "Validated plan against constitution - all checks passed"
+}
+```
+
+**IMPORTANT:**
+- NEVER use git commands to check project status - read project-config.json instead
+- ALWAYS update project-config.json when completing work
+- Keep summaries concise but informative for BOSS to track progress
+
+## Git Commit Strategy
+
+**IMPORTANT:** Batch related changes into logical commits to reduce overhead and improve workflow efficiency.
+
+### Batching Guidelines
+
+1. **Group files by feature/fix** (not by file type)
+2. **Aim for 1-3 commits per task** instead of 5-10
+3. **Use meaningful commit messages** following Conventional Commits
+4. **Only commit when reaching a logical checkpoint**
+
+### Good Practice ✅
+
+```bash
+# Create validation artifacts in one commit
+git add .specify/specs/001-feature/validation-report.md .specify/specs/001-feature/compliance-checks.md
+git commit -m "docs: add validation report and compliance checks"
+
+# Or batch validation findings
+git add .specify/specs/001-feature/validation-report.md .specify/specs/001-feature/plan.md
+git commit -m "docs: complete validation and update plan with compliance requirements"
+```
+
+### Bad Practice ❌
+
+```bash
+# Individual commits for related work (too granular)
+git add .specify/specs/001-feature/validation-report.md
+git commit -m "docs: add report"
+
+git add .specify/specs/001-feature/compliance-checks.md
+git commit -m "docs: add checks"
+
+git add .specify/specs/001-feature/plan.md
+git commit -m "docs: update plan"
+```
+
+### Commit Message Format
+
+Follow Conventional Commits:
+- `docs:` - Documentation changes (primary for reviewer)
+- `fix:` - Compliance issue fixes
+
+### Expected Behavior
+
+- **Simple task:** 1-2 commits (validation + updates)
+- **Complex task:** 2-3 commits (major validation phases)
+- **Avoid:** 5-10 commits for small changes
+
+This batching strategy reduces git overhead by ~10-15 seconds per task and creates cleaner commit history.
+

package/dist/assets/worker-configs/security-engineer/CLAUDE.md

@@ -0,0 +1,109 @@
+# ${workerName} Worker Instructions
+
+This worker is responsible for ${workerRoleDescription}
+
+## Worker-Specific Guidelines
+
+- Follow the prompt in \`prompt.md\` for detailed role instructions
+- Use container-use environments for all operations
+- Reference \`.claude/commands/\`, \`.claude/skills/\`, and \`.claude/agents/\` for worker-specific resources
+
+## Environment Operations
+
+All file, code, and shell operations MUST use container-use environments.
+
+- DO NOT use git CLI directly
+- All operations must go through container-use MCP
+- Inform user: \`container-use log <env_id>\` AND \`container-use checkout <env_id>\`
+
+## Project Status & Configuration
+
+**CRITICAL:** Always check `.boss/project-config.json` to understand project state before starting work.
+
+**Read project-config.json to understand:**
+- Current branch and workflow stage
+- Active workers and their status
+- Completed tasks
+- Repository information
+- Initialization status
+
+**Update project-config.json when:**
+- Starting work: Add your environment ID to `workflow.activeWorkers`
+- Completing work: Add a summary to `workers.summaries` with:
+  - Environment ID
+  - Tasks completed
+  - Artifacts created (security checklists, threat models, security docs)
+  - Vulnerabilities found and remediated
+  - Any blockers or issues encountered
+- After merging: Remove from `workflow.activeWorkers` and add to `workflow.completedTasks`
+
+**Example worker summary format:**
+```json
+{
+  "envId": "env-abc123",
+  "workerType": "${workerName}",
+  "completedAt": "2026-01-15T10:30:00Z",
+  "tasksCompleted": ["Security review", "Threat modeling", "Vulnerability scanning"],
+  "artifactsCreated": [".specify/specs/001-feature/checklists/security.md"],
+  "vulnerabilities": {"found": 2, "remediated": 2, "critical": 0},
+  "notes": "Completed security review and threat modeling for feature"
+}
+```
+
+**IMPORTANT:**
+- NEVER use git commands to check project status - read project-config.json instead
+- ALWAYS update project-config.json when completing work
+- Keep summaries concise but informative for BOSS to track progress
+
+## Git Commit Strategy
+
+**IMPORTANT:** Batch related changes into logical commits to reduce overhead and improve workflow efficiency.
+
+### Batching Guidelines
+
+1. **Group files by feature/fix** (not by file type)
+2. **Aim for 1-3 commits per task** instead of 5-10
+3. **Use meaningful commit messages** following Conventional Commits
+4. **Only commit when reaching a logical checkpoint**
+
+### Good Practice ✅
+
+```bash
+# Create security artifacts in one commit
+git add .specify/specs/001-feature/checklists/security.md threat-model.md
+git commit -m "docs: add security checklist and threat model"
+
+# Or batch security fixes
+git add src/api/auth.ts .specify/specs/001-feature/checklists/security.md
+git commit -m "fix: implement security recommendations from threat model"
+```
+
+### Bad Practice ❌
+
+```bash
+# Individual commits for related work (too granular)
+git add .specify/specs/001-feature/checklists/security.md
+git commit -m "docs: add checklist"
+
+git add threat-model.md
+git commit -m "docs: add threat model"
+
+git add src/api/auth.ts
+git commit -m "fix: security fix"
+```
+
+### Commit Message Format
+
+Follow Conventional Commits:
+- `fix:` - Security vulnerability fixes (primary)
+- `docs:` - Security documentation
+- `feat:` - New security features
+
+### Expected Behavior
+
+- **Simple task:** 1-2 commits (security review + fixes)
+- **Complex task:** 2-3 commits (major security phases)
+- **Avoid:** 5-10 commits for small changes
+
+This batching strategy reduces git overhead by ~10-15 seconds per task and creates cleaner commit history.
+

package/dist/assets/worker-configs/spec-writer/.claude/commands/.gitkeep

@@ -0,0 +1 @@
+

package/dist/assets/worker-configs/spec-writer/.claude/skills/.gitkeep

@@ -0,0 +1 @@
+

package/dist/assets/worker-configs/spec-writer/CLAUDE.md

@@ -0,0 +1,110 @@
+# ${workerName} Worker Instructions
+
+This worker is responsible for ${workerRoleDescription}
+
+## Worker-Specific Guidelines
+
+- Follow the prompt in \`prompt.md\` for detailed role instructions
+- Use container-use environments for all operations
+- Reference \`.claude/commands/\`, \`.claude/skills/\`, and \`.claude/agents/\` for worker-specific resources
+
+## Environment Operations
+
+All file, code, and shell operations MUST use container-use environments.
+
+- DO NOT use git CLI directly
+- All operations must go through container-use MCP
+- Inform user: \`container-use log <env_id>\` AND \`container-use checkout <env_id>\`
+
+## Project Status & Configuration
+
+**CRITICAL:** Always check `.boss/project-config.json` to understand project state before starting work.
+
+**Read project-config.json to understand:**
+- Current branch and workflow stage
+- Active workers and their status
+- Completed tasks
+- Repository information
+- Initialization status
+
+**Update project-config.json when:**
+- Starting work: Add your environment ID to `workflow.activeWorkers`
+- Completing work: Add a summary to `workers.summaries` with:
+  - Environment ID
+  - Tasks completed
+  - Artifacts created (spec.md)
+  - User stories written
+  - Acceptance criteria defined
+  - Any blockers or issues encountered
+- After merging: Remove from `workflow.activeWorkers` and add to `workflow.completedTasks`
+
+**Example worker summary format:**
+```json
+{
+  "envId": "env-abc123",
+  "workerType": "${workerName}",
+  "completedAt": "2026-01-15T10:30:00Z",
+  "tasksCompleted": ["Specification phase"],
+  "artifactsCreated": [".specify/specs/001-feature/spec.md"],
+  "userStoriesWritten": 8,
+  "acceptanceCriteriaDefined": 24,
+  "notes": "Created specification with 8 user stories in Given/When/Then format"
+}
+```
+
+**IMPORTANT:**
+- NEVER use git commands to check project status - read project-config.json instead
+- ALWAYS update project-config.json when completing work
+- Keep summaries concise but informative for BOSS to track progress
+
+## Git Commit Strategy
+
+**IMPORTANT:** Batch related changes into logical commits to reduce overhead and improve workflow efficiency.
+
+### Batching Guidelines
+
+1. **Group files by feature/fix** (not by file type)
+2. **Aim for 1-3 commits per task** instead of 5-10
+3. **Use meaningful commit messages** following Conventional Commits
+4. **Only commit when reaching a logical checkpoint**
+
+### Good Practice ✅
+
+```bash
+# Create spec artifacts in one commit
+git add .specify/specs/001-feature/spec.md .specify/specs/001-feature/acceptance-criteria.md
+git commit -m "docs: add specification with user stories and acceptance criteria"
+
+# Or batch complete specification phase
+git add .specify/specs/001-feature/spec.md .specify/specs/001-feature/examples.md
+git commit -m "docs: complete specification with Given/When/Then scenarios"
+```
+
+### Bad Practice ❌
+
+```bash
+# Individual commits for related work (too granular)
+git add .specify/specs/001-feature/spec.md
+git commit -m "docs: add spec"
+
+git add .specify/specs/001-feature/acceptance-criteria.md
+git commit -m "docs: add criteria"
+
+git add .specify/specs/001-feature/examples.md
+git commit -m "docs: add examples"
+```
+
+### Commit Message Format
+
+Follow Conventional Commits:
+- `docs:` - Documentation changes (primary for spec-writer)
+- `feat:` - New features in specification
+
+### Expected Behavior
+
+- **Simple task:** 1-2 commits (initial spec + refinements)
+- **Complex task:** 2-3 commits (major spec phases)
+- **Avoid:** 5-10 commits for small changes
+
+This batching strategy reduces git overhead by ~10-15 seconds per task and creates cleaner commit history.
+