bump-version
Bump Version
Update package.json, .claude-plugin/plugin.json, and .sd0x/install-state.json versions in sync.
Workflow
- Read current versions from all files
- Determine new version (from argument or auto-increment)
- Update all files to the same version
- Report result
Step 1: Read Current Versions
grep '"version"' package.json .claude-plugin/plugin.json
Also check manifest:
grep '"plugin_version"' .sd0x/install-state.json 2>/dev/null || echo "(no manifest)"
If versions are already out of sync, warn user before proceeding.
Step 2: Determine New Version
| Input | Action |
|---|---|
Explicit version (e.g., 1.9.0) |
Use as-is |
major |
Bump major: 1.8.1 → 2.0.0 |
minor |
Bump minor: 1.8.1 → 1.9.0 |
patch (default) |
Bump patch: 1.8.1 → 1.8.2 |
| No argument | Default to patch |
Step 3: Update All Files
Use Edit tool to update version fields:
package.json—"version"field.claude-plugin/plugin.json—"version"field.sd0x/install-state.json—"plugin_version"field (if file exists)
All must be set to the exact same version string.
The manifest update prevents the SessionStart drift sentinel from firing false warnings after every version bump in the plugin source repo.
Step 4: Report
## Version Bump
| File | Field | Before | After |
|------|-------|--------|-------|
| package.json | version | x.y.z | a.b.c |
| .claude-plugin/plugin.json | version | x.y.z | a.b.c |
| .sd0x/install-state.json | plugin_version | x.y.z | a.b.c |
Prohibited
- Never set different versions across the files
- Never modify other fields in the JSON files
More from sd0xdev/sd0x-dev-flow
statusline-config
Customize Claude Code statusline. Use when: user says 'statusline', 'status line', 'customize statusline', 'modify statusline', 'statusline settings', 'statusline theme', 'change theme', 'color scheme', wants to add/remove/change segments (cost, git, model, context), switch color themes (catppuccin, dracula, nord), or asks what can be shown in the statusline.
52tech-spec
Tech spec generation and review. Use when: designing features, writing specs, spec review. Not for: requirements analysis (use req-analyze), implementation (use feature-dev), architecture advice (use codex-architect). Output: numbered tech spec document.
45codex-brainstorm
Adversarial brainstorming via Claude+Codex debate. Use when: exploring solutions, feasibility analysis, exhaustive enumeration. Not for: implementation (use feature-dev), architecture only (use codex-architect). Output: Nash equilibrium consensus + action items.
7security-review
Security review via Codex MCP. Use when: OWASP Top 10 audit, dependency vulnerability check, security-sensitive changes. Not for: code review (use codex-code-review), test review (use test-review). Output: security findings + audit report.
7test-review
Test coverage review via Codex MCP. Use when: reviewing test sufficiency, identifying coverage gaps, test quality audit. Not for: generating tests (use codex-test-gen), code review (use codex-code-review). Output: coverage analysis + gap report.
7post-dev-test
Post-development test completion. Use when: checking test coverage after feature-dev, writing missing integration/e2e tests. Not for: unit test generation (use codex-test-gen), test review (use test-review). Output: test files + coverage report.
6