Overview

overview.md

A Claude Code plugin that brings structure to team development — deterministic process without compromising developer momentum.

Input-driven routing: Jira URL, Jira ID, or natural language goal.
Stable command surface: /wms:ticket | fix | ship | docs | dashboard | setup.
Observable execution: route, phase, quality gates, and delivery checks.
Natural UX: concise status updates with actionable next-step prompts.

Quick Start

Requires Claude Code installed.
marketplace-install.sh (Recommended)
# 1. Add marketplace
/plugin marketplace add git@bitbucket.org:logisticsteam-dev/wms-dev-orchestrator.git
# 2. Install plugin
/plugin install orchestrator@wms-dev-orchestrator
# 3. Configure credentials (optional)
/wms:setup
# 4. Verify
/wms:ticket WISE2018-12345
team-preinstall.json (For project leads)

Add to the target project's .claude/settings.json — teammates will be prompted to install automatically when they open the project.

{
  "extraKnownMarketplaces": {
    "wms-dev-orchestrator": {
      "source": {
        "source": "url",
        "url": "git@bitbucket.org:logisticsteam-dev/wms-dev-orchestrator.git"
      }
    }
  },
  "enabledPlugins": {
    "orchestrator@wms-dev-orchestrator": true
  }
}
update.sh

Update to the latest version via marketplace:

/plugin marketplace update wms-dev-orchestrator

Command Entry

/wms:ticket
Jira-first intake for investigation and scope alignment.
/wms:ticket WISE2018-12345
/wms:fix
Bugfix or feature route with built-in planning and quality gates.
/wms:fix implement pick task validation
/wms:ship
Delivery-only mode for verification, PR readiness, and Jira closure.
/wms:ship WISE2018-12345
/wms:docs
Knowledge base search, impact analysis, and documentation maintenance.
/wms:docs pick task status flow
/wms:dashboard
Sprint timeline with progress tracking and smart next-step recommendations.
/wms:dashboard
/wms:setup
Interactive Jira and Bitbucket credential configuration.
/wms:setup
internal-components.md

Skills, agents, and hooks are internal modules. Keep teammate onboarding simple by using command entry as the public interface.

• wms:jira-pilot (ticket context + status sync)
• wms:complexity-analyzer (routing signal)
• wms:code-reviewer (quality gate review)
• wms:tdd-implementer (isolated TDD subagent per task)
• wms:docs-pilot (knowledge base search + indexing)
• wms:audit-pilot (audit generation + repo delivery)

Architecture

architecture.md
Input Jira URL · Jira ID · Goal Command Entry ticket · fix · ship · docs · dashboard Router Complexity + Context Investigation Fix Dev Shared Quality Gates Delivery Closure wms:ship
Complexity-Driven Dispatch

Tasks are analyzed by complexity and routed to investigation, fix, or dev workflow.

Quality-Gated Closure

All paths converge on the same quality gates before /wms:ship closure.

Under the Hood

complexity-analyzer.md
Complexity Scoring Engine

5-dimension weighted scoring automatically routes tasks to the optimal workflow tier.

├─ Jira Type (30%) — Bug(test-fail) -2 · Story +1 · Task +2
├─ File Impact (25%) — 1 file → 0 · 6+ files → +4
├─ Code Volume (20%) — <50 lines → 0 · 200+ → +3
├─ Architecture (15%) — config → -1 · new module → +3
└─ Clarity (10%) — detailed → -1 · vague → +1
→ 0-3 fast-track · 4-6 standard · 7-10 full
Subagent-Driven TDD
Each task dispatched to an isolated subagent with self-contained prompts. Tier-based parallel execution (max 4 concurrent). Cross-tier outputs injected as context.
5-Layer Hook Pipeline
session-start → complexity-trigger → block-plan-mode → enforce-planning-gate → stop-workflow-guard. Automated guardrails from session start to finish.
4-Dimension Code Review
Lint → Spec Align → Find Bug → Code Quality (SOLID, DRY/YAGNI). Failure-hunt mode surfaces P0/P1 issues: deadlocks, SQL injection, null safety, resource leaks.
Security by Design
Prompt injection defense on untrusted Jira content. Credential isolation via process substitution. File scope enforcement via git diff boundary checks.
Deep Jira Integration
Recursive ticket exploration with --deep mode. Dynamic status transitions — no hardcoded IDs. Structured comment templates for analysis, bug-fix, and QA notes.
Evidence Chain
Structured markers track each phase: WMS_WORKFLOW → WMS_PLAN → WMS_VERIFY → WMS_DELIVERY. Stop hook validates chain completeness before session end.
Knowledge Base Pilot
Three-layer index (forward + section + inverted) with O(1) keyword lookup. Commands: search, impact analysis, update, draft. Minimum-dispatch principle — 1 search + N direct reads.
Workflow Contracts
4 JSON schemas enforce structure at each boundary: workflow-input, workflow-state, workflow-plan, workflow-result. Machine-readable contracts for plugin extensibility.
evidence-markers.log
Structured Evidence Markers

Each workflow phase emits a structured marker. The stop-hook validates the complete chain before allowing session close.

1 [[WMS_WORKFLOW mode=standard source=jira]]
2 [[WMS_PLAN status=READY path=docs/plans/... tdd=ENFORCED]]
3 [[WMS_VERIFY status=PASSED lint=OK test=OK build=OK]]
4 [[WMS_DELIVERY pr=CREATED jira=UPDATED]]

Workflow Demo

workflow-dev.log

Guardrails & UX Principles

Evidence first — completion claims require verification output.
No forced VCS actions — commit and push stay explicit user decisions.
Guided, not rigid — each stage surfaces clear next-step suggestions.
Safe fallback — when automation stalls, degrade gracefully to a manual playbook.

FAQ

Do teammates need to learn all internal modules first?
No. Start from the command entry surface. Internal modules stay behind the interface.
How does this stay smooth without becoming rigid?
Routing is context-aware. The plugin enforces quality boundaries, not one coding style.
How do we confirm delivery readiness?
Use /wms:ship to run final checks before closure.
Is Jira required to use this plugin?
No. Use /wms:fix with natural language to run the full workflow without Jira. The same complexity routing and quality gates apply.