shipwright-cli 1.10.0 → 2.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +221 -55
- package/completions/_shipwright +264 -32
- package/completions/shipwright.bash +118 -26
- package/completions/shipwright.fish +80 -2
- package/dashboard/server.ts +208 -0
- package/docs/strategy/01-market-research.md +619 -0
- package/docs/strategy/02-mission-and-brand.md +587 -0
- package/docs/strategy/03-gtm-and-roadmap.md +759 -0
- package/docs/strategy/QUICK-START.txt +289 -0
- package/docs/strategy/README.md +172 -0
- package/docs/tmux-research/TMUX-ARCHITECTURE.md +567 -0
- package/docs/tmux-research/TMUX-AUDIT.md +925 -0
- package/docs/tmux-research/TMUX-BEST-PRACTICES-2025-2026.md +829 -0
- package/docs/tmux-research/TMUX-QUICK-REFERENCE.md +543 -0
- package/docs/tmux-research/TMUX-RESEARCH-INDEX.md +438 -0
- package/package.json +4 -2
- package/scripts/lib/helpers.sh +7 -0
- package/scripts/sw +323 -2
- package/scripts/sw-activity.sh +500 -0
- package/scripts/sw-adaptive.sh +925 -0
- package/scripts/sw-adversarial.sh +1 -1
- package/scripts/sw-architecture-enforcer.sh +1 -1
- package/scripts/sw-auth.sh +613 -0
- package/scripts/sw-autonomous.sh +754 -0
- package/scripts/sw-changelog.sh +704 -0
- package/scripts/sw-checkpoint.sh +1 -1
- package/scripts/sw-ci.sh +602 -0
- package/scripts/sw-cleanup.sh +1 -1
- package/scripts/sw-code-review.sh +698 -0
- package/scripts/sw-connect.sh +1 -1
- package/scripts/sw-context.sh +605 -0
- package/scripts/sw-cost.sh +44 -3
- package/scripts/sw-daemon.sh +568 -138
- package/scripts/sw-dashboard.sh +1 -1
- package/scripts/sw-db.sh +1380 -0
- package/scripts/sw-decompose.sh +539 -0
- package/scripts/sw-deps.sh +551 -0
- package/scripts/sw-developer-simulation.sh +1 -1
- package/scripts/sw-discovery.sh +412 -0
- package/scripts/sw-docs-agent.sh +539 -0
- package/scripts/sw-docs.sh +1 -1
- package/scripts/sw-doctor.sh +107 -1
- package/scripts/sw-dora.sh +615 -0
- package/scripts/sw-durable.sh +710 -0
- package/scripts/sw-e2e-orchestrator.sh +535 -0
- package/scripts/sw-eventbus.sh +393 -0
- package/scripts/sw-feedback.sh +479 -0
- package/scripts/sw-fix.sh +1 -1
- package/scripts/sw-fleet-discover.sh +567 -0
- package/scripts/sw-fleet-viz.sh +404 -0
- package/scripts/sw-fleet.sh +8 -1
- package/scripts/sw-github-app.sh +596 -0
- package/scripts/sw-github-checks.sh +4 -4
- package/scripts/sw-github-deploy.sh +1 -1
- package/scripts/sw-github-graphql.sh +1 -1
- package/scripts/sw-guild.sh +569 -0
- package/scripts/sw-heartbeat.sh +1 -1
- package/scripts/sw-hygiene.sh +559 -0
- package/scripts/sw-incident.sh +656 -0
- package/scripts/sw-init.sh +237 -24
- package/scripts/sw-instrument.sh +699 -0
- package/scripts/sw-intelligence.sh +1 -1
- package/scripts/sw-jira.sh +1 -1
- package/scripts/sw-launchd.sh +363 -28
- package/scripts/sw-linear.sh +1 -1
- package/scripts/sw-logs.sh +1 -1
- package/scripts/sw-loop.sh +267 -21
- package/scripts/sw-memory.sh +18 -1
- package/scripts/sw-mission-control.sh +487 -0
- package/scripts/sw-model-router.sh +545 -0
- package/scripts/sw-otel.sh +596 -0
- package/scripts/sw-oversight.sh +764 -0
- package/scripts/sw-pipeline-composer.sh +1 -1
- package/scripts/sw-pipeline-vitals.sh +1 -1
- package/scripts/sw-pipeline.sh +947 -35
- package/scripts/sw-pm.sh +758 -0
- package/scripts/sw-pr-lifecycle.sh +522 -0
- package/scripts/sw-predictive.sh +8 -1
- package/scripts/sw-prep.sh +1 -1
- package/scripts/sw-ps.sh +1 -1
- package/scripts/sw-public-dashboard.sh +798 -0
- package/scripts/sw-quality.sh +595 -0
- package/scripts/sw-reaper.sh +1 -1
- package/scripts/sw-recruit.sh +2248 -0
- package/scripts/sw-regression.sh +642 -0
- package/scripts/sw-release-manager.sh +736 -0
- package/scripts/sw-release.sh +706 -0
- package/scripts/sw-remote.sh +1 -1
- package/scripts/sw-replay.sh +520 -0
- package/scripts/sw-retro.sh +691 -0
- package/scripts/sw-scale.sh +444 -0
- package/scripts/sw-security-audit.sh +505 -0
- package/scripts/sw-self-optimize.sh +1 -1
- package/scripts/sw-session.sh +1 -1
- package/scripts/sw-setup.sh +263 -127
- package/scripts/sw-standup.sh +712 -0
- package/scripts/sw-status.sh +44 -2
- package/scripts/sw-strategic.sh +806 -0
- package/scripts/sw-stream.sh +450 -0
- package/scripts/sw-swarm.sh +620 -0
- package/scripts/sw-team-stages.sh +511 -0
- package/scripts/sw-templates.sh +4 -4
- package/scripts/sw-testgen.sh +566 -0
- package/scripts/sw-tmux-pipeline.sh +554 -0
- package/scripts/sw-tmux-role-color.sh +58 -0
- package/scripts/sw-tmux-status.sh +128 -0
- package/scripts/sw-tmux.sh +1 -1
- package/scripts/sw-trace.sh +485 -0
- package/scripts/sw-tracker-github.sh +188 -0
- package/scripts/sw-tracker-jira.sh +172 -0
- package/scripts/sw-tracker-linear.sh +251 -0
- package/scripts/sw-tracker.sh +117 -2
- package/scripts/sw-triage.sh +627 -0
- package/scripts/sw-upgrade.sh +1 -1
- package/scripts/sw-ux.sh +677 -0
- package/scripts/sw-webhook.sh +627 -0
- package/scripts/sw-widgets.sh +530 -0
- package/scripts/sw-worktree.sh +1 -1
- package/templates/pipelines/autonomous.json +2 -2
- package/tmux/shipwright-overlay.conf +35 -17
- package/tmux/tmux.conf +23 -21
|
@@ -0,0 +1,587 @@
|
|
|
1
|
+
# Shipwright: Mission, Brand & Strategy
|
|
2
|
+
|
|
3
|
+
## Executive Summary
|
|
4
|
+
|
|
5
|
+
Shipwright orchestrates autonomous Claude Code agent teams with full-cycle delivery pipelines, transforming how engineering teams move code from issue to production. This document establishes Shipwright's mission, brand positioning, voice, and target personas to guide all future marketing, communication, and product decisions.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## 1. Mission Statement
|
|
10
|
+
|
|
11
|
+
**Build the autonomous delivery platform that empowers engineering teams to ship faster, safer, and with zero toil.**
|
|
12
|
+
|
|
13
|
+
### Why This Works
|
|
14
|
+
|
|
15
|
+
- **"Build"** — homage to the shipwright metaphor (a builder of ships)
|
|
16
|
+
- **"Autonomous"** — captures the core differentiator (agents + orchestration)
|
|
17
|
+
- **"Delivery platform"** — positions as full-cycle, not just code generation
|
|
18
|
+
- **"Empowers"** — teams remain in control, not replaced by automation
|
|
19
|
+
- **"Ship faster, safer, with zero toil"** — addresses three core pain points simultaneously
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## 2. Vision Statement
|
|
24
|
+
|
|
25
|
+
**A world where every engineering team has an infinite, tireless delivery force — capable of handling any task from feature development to incident response — removing the friction between idea and production so teams can focus on what matters most: innovation and impact.**
|
|
26
|
+
|
|
27
|
+
### 3-5 Year Horizon
|
|
28
|
+
|
|
29
|
+
- Shipwright becomes the default CI/CD orchestration layer for teams using Claude Code
|
|
30
|
+
- Multi-repo fleets become standard (teams manage 5-50 repos with one daemon)
|
|
31
|
+
- Self-healing, learning systems eliminate most incident response overhead
|
|
32
|
+
- Predictive intelligence prevents bugs before they're written (anomaly detection, risk scoring)
|
|
33
|
+
- Multi-model routing allows teams to optimize for cost, speed, or safety per pipeline
|
|
34
|
+
- Community-driven agent templates enable domain-specific delivery patterns (web, mobile, data, infra)
|
|
35
|
+
|
|
36
|
+
---
|
|
37
|
+
|
|
38
|
+
## 3. Brand Positioning
|
|
39
|
+
|
|
40
|
+
**For** software engineering teams and CTOs managing high-velocity delivery
|
|
41
|
+
|
|
42
|
+
**Who** struggle with the gap between developer velocity and deployment safety, manual code review bottlenecks, and toil in shipping routine features
|
|
43
|
+
|
|
44
|
+
**Shipwright is** an autonomous delivery orchestration platform
|
|
45
|
+
|
|
46
|
+
**That** breaks the ship-faster/ship-safer tradeoff by automating the entire pipeline (intake through monitoring) while keeping humans in control of gates and deployment decisions
|
|
47
|
+
|
|
48
|
+
**Unlike** traditional CI/CD (Jenkins, GitHub Actions) which are task execution engines, and AI code generators (Copilot, Claude) which focus on single-file edits
|
|
49
|
+
|
|
50
|
+
**Shipwright** coordinates autonomous agent teams working in parallel on design, build, test, and review — with persistent memory, self-healing loops, and intelligence-driven routing that improves with every delivery
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## 4. Value Propositions
|
|
55
|
+
|
|
56
|
+
### 1. **Zero-Toil Delivery Pipeline**
|
|
57
|
+
|
|
58
|
+
**Headline:** From GitHub issue to merged PR with zero human in the loop
|
|
59
|
+
**Description:** Label a GitHub issue with `shipwright` and walk away. The daemon watches, triages, plans, designs, builds, tests, reviews, gates, and merges — all while learning from failures and adapting its approach. Teams get back 20+ hours per engineer per month by eliminating manual triage, code review, and routine feature shipping.
|
|
60
|
+
**Proof Point:** Shipwright dogfoods itself — this repo processes its own issues with zero human intervention. See [live examples](../../actions/workflows/shipwright-pipeline.yml).
|
|
61
|
+
|
|
62
|
+
### 2. **Autonomous Teams That Learn**
|
|
63
|
+
|
|
64
|
+
**Headline:** Agents that remember failures and never repeat mistakes
|
|
65
|
+
**Description:** Shipwright's memory system captures failure patterns, root causes, and successful fixes from every pipeline run. Fresh agent sessions inject this learnings context, so the team gets smarter with every issue. No more debugging the same bug twice; no more repeating past architectural mistakes.
|
|
66
|
+
**Proof Point:** Memory injection reduces retry rate by 60%+ in long-running daemons. Agents explicitly reference prior solutions when faced with similar problems.
|
|
67
|
+
|
|
68
|
+
### 3. **Intelligence-Driven Pipeline Routing**
|
|
69
|
+
|
|
70
|
+
**Headline:** Every delivery gets the right-sized pipeline, right-sized team, right model
|
|
71
|
+
**Description:** Shipwright analyzes incoming issues to predict complexity, risk, and required expertise. The pipeline composer auto-selects templates (fast, standard, full) based on codebase intelligence. Model routing allocates expensive fast models only where needed. Teams optimize for cost without sacrificing quality.
|
|
72
|
+
**Proof Point:** Average token cost per delivery drops 40% with composer routing. Production deployments get extra review gates. Hotfixes bypass unnecessary quality stages.
|
|
73
|
+
|
|
74
|
+
### 4. **Full-Cycle Automation Without Losing Control**
|
|
75
|
+
|
|
76
|
+
**Headline:** Humans decide the gates; agents execute the pipeline
|
|
77
|
+
**Description:** Unlike code generators that replace developers, Shipwright enhances them. Configurable gates let teams approve before planning, before deploying, before merging. All work is visible in GitHub (Checks API, PR timeline). Agents never deploy, merge, or spend money without approval. Teams keep the human in the loop where it matters.
|
|
78
|
+
**Proof Point:** 8 pipeline templates support risk/speed tradeoffs. Enterprise template requires approval on every gate. Cost intelligence prevents runaway spending.
|
|
79
|
+
|
|
80
|
+
### 5. **Multi-Repo Fleet Operations at Scale**
|
|
81
|
+
|
|
82
|
+
**Headline:** One daemon manages your entire monorepo or microservices architecture
|
|
83
|
+
**Description:** Ship's fleet automation orchestrates daemons across dozens of repos, auto-distributing team capacity based on queue depth. Shared memory and learnings flow across repos. Teams don't need separate CI/CD configs per repo; Shipwright handles it.
|
|
84
|
+
**Proof Point:** Fleet example: 50-repo microservices platform run by single daemon with 2-3 parallel workers. Auto-discovery populates fleet from GitHub org in minutes.
|
|
85
|
+
|
|
86
|
+
---
|
|
87
|
+
|
|
88
|
+
## 5. Brand Voice & Personality
|
|
89
|
+
|
|
90
|
+
### Tone
|
|
91
|
+
|
|
92
|
+
- **Technical yet approachable** — We speak the language of engineers without sacrificing clarity
|
|
93
|
+
- **Confident, not arrogant** — Shipwright has earned this confidence through real delivery, not hype
|
|
94
|
+
- **Practical and results-driven** — Every claim backed by measurable outcomes (hours saved, cost reduced, bugs prevented)
|
|
95
|
+
- **Honest about tradeoffs** — We acknowledge complexity, edge cases, and when human judgment beats automation
|
|
96
|
+
|
|
97
|
+
### Language & Vocabulary
|
|
98
|
+
|
|
99
|
+
- Prefer **action verbs** over abstract nouns: "ship faster" > "enhanced shipping velocity"
|
|
100
|
+
- Use **"autonomous agents"** not "AI" (more specific, less buzzwordy)
|
|
101
|
+
- Use **"zero toil"** not "serverless" or "frictionless" (more memorable, nautical)
|
|
102
|
+
- Use **"delivery"** not "deployment" (broader, includes testing and validation)
|
|
103
|
+
- Use **"daemon"** not "service" (Unix-rooted, technical, honest about what it is)
|
|
104
|
+
- Use **"pipeline"** not "workflow" (more precise, 12 stages, fully specified)
|
|
105
|
+
|
|
106
|
+
### The Shipwright Metaphor
|
|
107
|
+
|
|
108
|
+
A shipwright is a craftsperson who builds ships. The metaphor captures:
|
|
109
|
+
|
|
110
|
+
- **Intentional construction** — ships are built carefully, for a purpose
|
|
111
|
+
- **Durability** — well-built ships endure; shoddy ones sink
|
|
112
|
+
- **Journey** — the ship's job is to move cargo safely from origin to destination (like code → production)
|
|
113
|
+
- **Team effort** — shipbuilding requires coordination (like autonomous agents)
|
|
114
|
+
|
|
115
|
+
**Use the metaphor consistently:**
|
|
116
|
+
|
|
117
|
+
- "Build the vessel that carries your code to production"
|
|
118
|
+
- "Let your delivery vessel sail on its own"
|
|
119
|
+
- "A crew of autonomous agents at the helm"
|
|
120
|
+
- Avoid: "shipwrecking," "sinking," or nautical puns that muddy the message
|
|
121
|
+
|
|
122
|
+
---
|
|
123
|
+
|
|
124
|
+
## 6. Target Personas
|
|
125
|
+
|
|
126
|
+
### Persona 1: The Platform Engineer
|
|
127
|
+
|
|
128
|
+
**Name:** Alex
|
|
129
|
+
**Role:** Senior engineer responsible for CI/CD, delivery automation, and team velocity
|
|
130
|
+
**Team Size:** 10-30 engineers
|
|
131
|
+
**Pain Points:**
|
|
132
|
+
|
|
133
|
+
- Custom CI/CD scripts accumulate technical debt
|
|
134
|
+
- New repos require boilerplate config (GitHub Actions, branch protections, review policies)
|
|
135
|
+
- Can't scale human code review; bottleneck at 15-20 engineers
|
|
136
|
+
- Incident response is manual; no predictive alerts
|
|
137
|
+
- Cost intelligence is fragmented across tools
|
|
138
|
+
|
|
139
|
+
**Why Shipwright:** One command (`shipwright daemon start`) replaces 500+ lines of config. Fleet auto-discovery scales to 50+ repos. Intelligence layer provides early warning. Memory system bakes lessons into future runs.
|
|
140
|
+
|
|
141
|
+
**Success Metrics:** Time to ship (-40%), human review overhead (-60%), cost per delivery (-30%), incident response time (-50%)
|
|
142
|
+
|
|
143
|
+
---
|
|
144
|
+
|
|
145
|
+
### Persona 2: The CTO / Tech Lead
|
|
146
|
+
|
|
147
|
+
**Name:** Jordan
|
|
148
|
+
**Role:** Technical leader accountable for delivery velocity, code quality, and team morale
|
|
149
|
+
**Team Size:** 50-200 engineers
|
|
150
|
+
**Pain Points:**
|
|
151
|
+
|
|
152
|
+
- Shipping speed vs. safety tradeoff (ship fast = more bugs; ship safe = slower)
|
|
153
|
+
- Junior developers need mentorship; senior engineers are bottleneck
|
|
154
|
+
- Difficult to scale code review standards across growing team
|
|
155
|
+
- Can't measure DORA metrics; limited visibility into delivery process
|
|
156
|
+
- Toil (code review, triage, routine features) burns out senior engineers
|
|
157
|
+
|
|
158
|
+
**Why Shipwright:** Configurable gates let teams choose their risk profile (fast, standard, full, enterprise). Autonomous agents and code reviewer agents mentor junior developers. Team dashboard provides DORA visibility. Zero-toil pipeline frees up senior engineers for high-impact work.
|
|
159
|
+
|
|
160
|
+
**Success Metrics:** DORA metrics (+40% deployment frequency, -50% lead time, -70% CFR, -80% MTTR), team satisfaction (+25% engagement), senior engineer utilization on strategic work (+30%)
|
|
161
|
+
|
|
162
|
+
---
|
|
163
|
+
|
|
164
|
+
### Persona 3: The Developer (Full-Stack)
|
|
165
|
+
|
|
166
|
+
**Name:** Sam
|
|
167
|
+
**Role:** Full-stack engineer shipping features and fixing bugs
|
|
168
|
+
**Team Size:** 5-15 engineers (startup or small team)
|
|
169
|
+
**Pain Points:**
|
|
170
|
+
|
|
171
|
+
- No CI/CD; shipping is manual (npm publish, git tag, deploy script)
|
|
172
|
+
- Code review is slow; async feedback is painful
|
|
173
|
+
- Shipping requires babysitting; can't parallelize build, test, review
|
|
174
|
+
- Debugging production issues is slow; no structured incident response
|
|
175
|
+
- Would hire more engineers but can't afford the overhead
|
|
176
|
+
|
|
177
|
+
**Why Shipwright:** One issue label triggers full delivery. No more manual shipping. Autonomous reviewer catches 70%+ of common issues. Self-healing loops mean fewer production incidents. Small team stays lean.
|
|
178
|
+
|
|
179
|
+
**Success Metrics:** Time to ship (-60%), human code review overhead (-80%), production incident rate (-70%), team hiring can stay flat while velocity increases
|
|
180
|
+
|
|
181
|
+
---
|
|
182
|
+
|
|
183
|
+
### Persona 4: The Engineering Manager / VP
|
|
184
|
+
|
|
185
|
+
**Name:** Casey
|
|
186
|
+
**Role:** Engineering leader responsible for team velocity, cost, and predictability
|
|
187
|
+
**Team Size:** 100-500 engineers
|
|
188
|
+
**Pain Points:**
|
|
189
|
+
|
|
190
|
+
- Can't predict shipping timelines; each feature takes wildly different time
|
|
191
|
+
- Difficult to measure engineering velocity; limited visibility into what teams do
|
|
192
|
+
- Cost is opaque; cloud bills are unpredictable
|
|
193
|
+
- Technical debt accumulates; hard to invest in refactoring without slowing shipping
|
|
194
|
+
- Hard to scale delivery practices across teams; everyone has different tools
|
|
195
|
+
|
|
196
|
+
**Why Shipwright:** Predictive scoring tells you which issues will take 1 day vs. 1 week. DORA dashboard shows deployment frequency, lead time, CFR, MTTR across teams. Cost intelligence prevents surprises. Shared daemon + agents across teams enforce consistent practices.
|
|
197
|
+
|
|
198
|
+
**Success Metrics:** Predictability (+50% estimate accuracy), visibility (DORA on every team), cost control (-20% LLM spend with intelligent routing), velocity consistency (+15%)
|
|
199
|
+
|
|
200
|
+
---
|
|
201
|
+
|
|
202
|
+
## 7. Positioning Against Alternatives
|
|
203
|
+
|
|
204
|
+
### vs. Traditional CI/CD (GitHub Actions, Jenkins)
|
|
205
|
+
|
|
206
|
+
| Aspect | GitHub Actions | Shipwright |
|
|
207
|
+
| ------------------- | ---------------------------------------- | ------------------------------------------------------------------- |
|
|
208
|
+
| **What it does** | Runs tasks when events fire | Orchestrates autonomous agents through a 12-stage delivery pipeline |
|
|
209
|
+
| **Coding required** | Yes (YAML config) | No (label an issue) |
|
|
210
|
+
| **Intelligence** | None | Risk scoring, model routing, memory, predictive analysis |
|
|
211
|
+
| **Self-healing** | No (fails, requires manual intervention) | Yes (re-enters build loop on test failure with error context) |
|
|
212
|
+
| **Learning** | No | Yes (captures failure patterns, success patterns) |
|
|
213
|
+
| **Scope** | Task executor | Full delivery: intake → production → monitoring |
|
|
214
|
+
|
|
215
|
+
### vs. AI Code Generators (GitHub Copilot, Claude)
|
|
216
|
+
|
|
217
|
+
| Aspect | Copilot | Shipwright |
|
|
218
|
+
| -------------------- | ------------------------- | ----------------------------------------------------------- |
|
|
219
|
+
| **What it does** | Suggests code completions | Plans, designs, builds, tests, reviews, gates, deploys code |
|
|
220
|
+
| **Scope** | Single file | Full issue → PR → production |
|
|
221
|
+
| **Continuous** | Per-keystroke | Per-pipeline (intake to monitor) |
|
|
222
|
+
| **Automated Review** | No | Yes (adversarial, security, performance) |
|
|
223
|
+
| **Learning** | No | Yes (memory system) |
|
|
224
|
+
| **Deployment** | No | Yes (with gates) |
|
|
225
|
+
|
|
226
|
+
### vs. "AI DevOps" Tools
|
|
227
|
+
|
|
228
|
+
| Aspect | Generic AI DevOps | Shipwright |
|
|
229
|
+
| --------------- | ------------------------ | ---------------------------------------------------- |
|
|
230
|
+
| **Built for** | Any language, any stack | Claude Code + Bash + tmux (opinionated) |
|
|
231
|
+
| **Pipeline** | Configurable but generic | 12 specific stages (intake → monitor) |
|
|
232
|
+
| **Agents** | Generic LLM chat | Specialized agents (builder, reviewer, tester, etc.) |
|
|
233
|
+
| **Learning** | No | Yes (memory, DORA, failure patterns) |
|
|
234
|
+
| **Open source** | Often no | Yes (MIT) |
|
|
235
|
+
| **Cost** | Black box pricing | Transparent (token dashboard) |
|
|
236
|
+
|
|
237
|
+
---
|
|
238
|
+
|
|
239
|
+
## 8. Core Differentiators (Rank Order)
|
|
240
|
+
|
|
241
|
+
1. **Orchestrated Teams** — Not a code generator. Autonomous agents working _together_ with roles (builder, reviewer, tester, optimizer). Parallel work on design, build, test, review.
|
|
242
|
+
|
|
243
|
+
2. **Full-Cycle Pipeline** — Not just code generation. Intake, triage, plan, design, build, test, review, quality gates, PR, merge, deploy, validate, monitor. Self-healing when tests fail.
|
|
244
|
+
|
|
245
|
+
3. **Persistent Memory** — Agents learn from every failure. Memory injection into fresh sessions means learnings compound over time. No repeated mistakes.
|
|
246
|
+
|
|
247
|
+
4. **Built-in Intelligence** — Predictive risk scoring, model routing, anomaly detection, self-optimization. Pipeline improves itself based on DORA metrics.
|
|
248
|
+
|
|
249
|
+
5. **Open Source & Transparent** — MIT licensed. Token costs visible. No black boxes. Community-driven. Dogfoods itself.
|
|
250
|
+
|
|
251
|
+
6. **Human-in-Loop Gates** — Configurable approval gates (before plan, before deploy, before merge). Autonomous agents execute; humans decide. Different risk profiles (fast, standard, full, enterprise).
|
|
252
|
+
|
|
253
|
+
7. **Multi-Repo Fleet** — One daemon manages dozens of repos. Auto-discovery, shared learnings, intelligent capacity distribution.
|
|
254
|
+
|
|
255
|
+
---
|
|
256
|
+
|
|
257
|
+
## 9. Key Messages (for all channels)
|
|
258
|
+
|
|
259
|
+
### For Engineering Blogs & Thought Leadership
|
|
260
|
+
|
|
261
|
+
"Shipwright isn't another code generation tool. It's an orchestration platform for autonomous agent teams that builds, tests, reviews, and ships your entire pipeline — while learning from every failure so the team gets smarter with time."
|
|
262
|
+
|
|
263
|
+
### For Product Demos
|
|
264
|
+
|
|
265
|
+
"Watch this: I label a GitHub issue `shipwright`. The daemon triages it, plans the work, designs the solution, writes code, runs tests, reviews itself, gates the PR, and merges. Zero human intervention. Here's the GitHub timeline showing every step."
|
|
266
|
+
|
|
267
|
+
### For Integration Docs
|
|
268
|
+
|
|
269
|
+
"Shipwright uses GitHub Issues and Pull Requests as its interface. No new tools to learn. Label an issue, watch it build itself. All work happens in your existing repo."
|
|
270
|
+
|
|
271
|
+
### For Sales / Pitch
|
|
272
|
+
|
|
273
|
+
"We help teams ship 3x faster without sacrificing safety. Autonomous agents handle triage, design, build, and review. Your team focuses on high-impact work. Memory and intelligence layers mean the system improves with every delivery."
|
|
274
|
+
|
|
275
|
+
### For Pricing (when relevant)
|
|
276
|
+
|
|
277
|
+
"Shipwright is open source (MIT). You pay only for Claude API tokens (transparent). Average cost per delivery: $2-10 depending on issue complexity and template choice. Saves teams 20+ hours/engineer/month."
|
|
278
|
+
|
|
279
|
+
---
|
|
280
|
+
|
|
281
|
+
## 10. Brand Personality Traits
|
|
282
|
+
|
|
283
|
+
- **Competent** — Built by experienced engineers, ships real code, handles edge cases
|
|
284
|
+
- **Honest** — Acknowledges limitations, failure modes, when humans should intervene
|
|
285
|
+
- **Pragmatic** — Focused on measurable outcomes, not hype
|
|
286
|
+
- **Inclusive** — Works with existing tools (GitHub, Claude Code, bash, tmux)
|
|
287
|
+
- **Ambitious** — Vision of autonomous delivery at scale, but realistic about current constraints
|
|
288
|
+
- **Teachable** — Memory + intelligence layers show system learning and improving
|
|
289
|
+
|
|
290
|
+
---
|
|
291
|
+
|
|
292
|
+
## 11. Visual & Linguistic Identity
|
|
293
|
+
|
|
294
|
+
### Colors (existing palette, maintain consistency)
|
|
295
|
+
|
|
296
|
+
- **Cyan (#00d4ff)** — Primary accent, energy, motion
|
|
297
|
+
- **Purple (#7c3aed)** — Tertiary accent, intelligence, depth
|
|
298
|
+
- **Blue (#0066ff)** — Secondary accent, trust, infrastructure
|
|
299
|
+
- **Green (#4ade80)** — Success, completion, shipped
|
|
300
|
+
|
|
301
|
+
### Typography
|
|
302
|
+
|
|
303
|
+
- Prefer **sans-serif** (clean, modern, technical)
|
|
304
|
+
- Use **monospace for code** and CLI examples
|
|
305
|
+
- Use **bold for action verbs** and key differentiators
|
|
306
|
+
|
|
307
|
+
### Imagery & Metaphors
|
|
308
|
+
|
|
309
|
+
- **Ship-building metaphors:** construction, craftsmanship, durability, journey
|
|
310
|
+
- **Teamwork metaphors:** crew, coordinated action, roles
|
|
311
|
+
- **Motion metaphors:** flow, autonomous movement, sailing
|
|
312
|
+
- **Growth metaphors:** learning, improvement, getting smarter
|
|
313
|
+
- Avoid: nautical puns, drowning/sinking metaphors, pirate imagery
|
|
314
|
+
|
|
315
|
+
### Logo Usage
|
|
316
|
+
|
|
317
|
+
- Lockup: Logo + "Shipwright" (full branding)
|
|
318
|
+
- Icon: Ship silhouette (simplified mark)
|
|
319
|
+
- Context: Always include tagline "The Autonomous Delivery Platform"
|
|
320
|
+
|
|
321
|
+
---
|
|
322
|
+
|
|
323
|
+
## 12. Messaging Hierarchy (What to Lead With)
|
|
324
|
+
|
|
325
|
+
1. **Problem statement:** "Shipping code has a speed/safety tradeoff"
|
|
326
|
+
2. **Solution category:** "Autonomous delivery orchestration"
|
|
327
|
+
3. **Differentiation:** "Full-cycle pipeline + agent teams + learning"
|
|
328
|
+
4. **Proof:** "Dogfoods itself, merges 50+ PRs monthly with zero human intervention"
|
|
329
|
+
5. **Call to action:** "Label an issue. Watch it build itself."
|
|
330
|
+
|
|
331
|
+
---
|
|
332
|
+
|
|
333
|
+
## 13. Success Metrics & KPIs
|
|
334
|
+
|
|
335
|
+
### Brand Health
|
|
336
|
+
|
|
337
|
+
- **Awareness:** GitHub stars, npm downloads, Twitter mentions
|
|
338
|
+
- **Consideration:** Blog reads, demo video views, "how it works" guide completeness
|
|
339
|
+
- **Adoption:** Active daemons, issue processing volume, fleet size
|
|
340
|
+
- **Advocacy:** Community contributions, agent templates, integrations
|
|
341
|
+
|
|
342
|
+
### Messaging Effectiveness
|
|
343
|
+
|
|
344
|
+
- **Clarity:** % of users who correctly describe "what Shipwright does" (should be 90%+)
|
|
345
|
+
- **Differentiation:** % of users who understand unique positioning vs. GitHub Actions / Copilot
|
|
346
|
+
- **Motivation:** % of issues labeled `shipwright` per org (growth week-over-week)
|
|
347
|
+
|
|
348
|
+
### Product Metrics (tied to brand promises)
|
|
349
|
+
|
|
350
|
+
- **Zero-toil delivery:** Average time from issue creation to merged PR (goal: <2 hours)
|
|
351
|
+
- **Learning system:** Retry rate decline over time in long-running daemons (goal: 50% drop in 3 months)
|
|
352
|
+
- **Intelligence routing:** Cost savings from model routing (goal: 30%+ reduction)
|
|
353
|
+
- **Multi-repo fleet:** Repos per daemon (goal: 50+ repos per daemon)
|
|
354
|
+
|
|
355
|
+
---
|
|
356
|
+
|
|
357
|
+
## 14. Rollout & Activation Plan
|
|
358
|
+
|
|
359
|
+
### Phase 1: Foundation (Weeks 1-4)
|
|
360
|
+
|
|
361
|
+
- Update README.md with new brand messaging
|
|
362
|
+
- Refresh website copy (homepage, feature pages) with positioning
|
|
363
|
+
- Update CLI help text (`shipwright --help`) with voice/tone
|
|
364
|
+
- Create brand guidelines (this document) for team
|
|
365
|
+
|
|
366
|
+
### Phase 2: Content (Weeks 4-8)
|
|
367
|
+
|
|
368
|
+
- Blog post: "Why Shipwright Isn't Another Code Generator"
|
|
369
|
+
- Demo video: Label an issue, watch it build (2-3 min)
|
|
370
|
+
- Case study: How Shipwright ships Shipwright (self-dogfooding story)
|
|
371
|
+
- Comparison matrix: Shipwright vs. GitHub Actions / Copilot
|
|
372
|
+
- Twitter thread: Explaining the 12-stage pipeline in simple terms
|
|
373
|
+
|
|
374
|
+
### Phase 3: Awareness (Weeks 8-12)
|
|
375
|
+
|
|
376
|
+
- Reach out to engineering blogs (Dev.to, HashiCorp blog, Anthropic blog)
|
|
377
|
+
- Launch GitHub Discussions for community storytelling
|
|
378
|
+
- Tag helpful examples / "how to" content
|
|
379
|
+
- Gather early adopter stories (2-3 teams)
|
|
380
|
+
|
|
381
|
+
### Phase 4: Sustain (Ongoing)
|
|
382
|
+
|
|
383
|
+
- Keep docs updated with real examples
|
|
384
|
+
- Celebrate community contributions
|
|
385
|
+
- Monthly metrics review (brand health + product metrics)
|
|
386
|
+
- Adjust messaging based on feedback
|
|
387
|
+
|
|
388
|
+
---
|
|
389
|
+
|
|
390
|
+
## 15. Frequently Asked Questions (Brand Level)
|
|
391
|
+
|
|
392
|
+
**Q: Why "Shipwright" and not something more obvious like "DeliveryBot" or "AutoDeploy"?**
|
|
393
|
+
A: Shipwright is a builder of ships. It captures the core idea: we're building the autonomous vessel that carries your code to production. It's memorable, technical (ships are complex systems requiring coordination), and unique. Plus, it's nautical without being cheesy.
|
|
394
|
+
|
|
395
|
+
**Q: Is Shipwright replacing developers?**
|
|
396
|
+
A: No. Shipwright augments teams by eliminating toil. Developers focus on design decisions and high-impact problems. Shipwright handles the routine work: triage, build, test, review, gates, merge, monitor.
|
|
397
|
+
|
|
398
|
+
**Q: Why open source?**
|
|
399
|
+
A: Shipwright is infrastructure. Teams need to inspect it, extend it, trust it. Open source (MIT) removes adoption friction and builds community. Plus, we dogfood ourselves — the community can see it work.
|
|
400
|
+
|
|
401
|
+
**Q: How is this different from hiring more engineers?**
|
|
402
|
+
A: It's cheaper (pay per use), faster (deploys immediately), and scalable (works across 50+ repos). It also frees your team to focus on impact instead of toil. Not a replacement; an accelerant.
|
|
403
|
+
|
|
404
|
+
**Q: What's the catch? Why does this work so well?**
|
|
405
|
+
A: Three reasons: (1) Modern LLMs are good at code tasks, (2) most software delivery is routine (design + build + test + review follow patterns), (3) agents + orchestration + memory compound benefits. No catch; just good engineering.
|
|
406
|
+
|
|
407
|
+
---
|
|
408
|
+
|
|
409
|
+
## 16. Competitive Positioning: The SWOT Analysis
|
|
410
|
+
|
|
411
|
+
### Strengths
|
|
412
|
+
|
|
413
|
+
- **Full-cycle automation** — Intake to monitoring, not just code generation
|
|
414
|
+
- **Persistent memory** — Systems learn and improve over time
|
|
415
|
+
- **Open source** — No vendor lock-in, transparent costs
|
|
416
|
+
- **Opinionated 12-stage pipeline** — No YAML hell; just label an issue
|
|
417
|
+
- **Self-hosted or cloud** — Runs in tmux, operates in your environment
|
|
418
|
+
- **Multi-repo fleet** — Manages entire organizations
|
|
419
|
+
- **Dogfooding** — Proof it works: Shipwright ships Shipwright
|
|
420
|
+
|
|
421
|
+
### Weaknesses
|
|
422
|
+
|
|
423
|
+
- **Requires Claude Code** — Not a standalone tool (feature, not bug, but barrier)
|
|
424
|
+
- **Bash/tmux stack** — Opinionated tech choices (some teams prefer other UIs)
|
|
425
|
+
- **Early in adoption curve** — Smaller community vs. GitHub Actions or Copilot
|
|
426
|
+
- **Learning curve** — Understanding 12 stages, templates, memory takes time
|
|
427
|
+
- **No UI** — tmux + CLI can be intimidating for non-technical stakeholders
|
|
428
|
+
|
|
429
|
+
### Opportunities
|
|
430
|
+
|
|
431
|
+
- **Enterprise market** — Compliance, cost control, deployment visibility
|
|
432
|
+
- **MLOps/DataOps** — Workflows beyond code shipping (notebooks, pipelines)
|
|
433
|
+
- **Multi-cloud & hybrid** — Fleet automation across AWS, GCP, on-premise
|
|
434
|
+
- **Industry vertical templates** — Pre-built agent teams for web, mobile, data
|
|
435
|
+
- **Community agents** — Third-party roles (security, performance, documentation)
|
|
436
|
+
- **Vendor partnerships** — GitHub, Anthropic, popular dev tools
|
|
437
|
+
|
|
438
|
+
### Threats
|
|
439
|
+
|
|
440
|
+
- **GitHub Actions improvements** — If GitHub adds intelligent routing, reduces differentiation
|
|
441
|
+
- **Copilot improvements** — If Copilot becomes 10x better at full-file editing
|
|
442
|
+
- **Competing autonomous platforms** — Other orchestration frameworks emerge
|
|
443
|
+
- **Model cost increases** — If Claude API tokens become 5x more expensive
|
|
444
|
+
- **Team consolidation** — If developers prefer single tool (GitHub Actions + Copilot)
|
|
445
|
+
|
|
446
|
+
---
|
|
447
|
+
|
|
448
|
+
## 17. Brand Voice Examples (Across Channels)
|
|
449
|
+
|
|
450
|
+
### Website Hero Section
|
|
451
|
+
|
|
452
|
+
**Headline:** "The Autonomous Delivery Platform"
|
|
453
|
+
**Subheadline:** "From labeled GitHub issue to merged PR — zero human intervention."
|
|
454
|
+
**CTA:** "Label an issue. Watch it build itself."
|
|
455
|
+
|
|
456
|
+
### CLI Help Output
|
|
457
|
+
|
|
458
|
+
```
|
|
459
|
+
shipwright — orchestrates autonomous Claude Code agent teams with full delivery pipelines
|
|
460
|
+
|
|
461
|
+
Usage:
|
|
462
|
+
shipwright <command> [options]
|
|
463
|
+
|
|
464
|
+
Popular commands:
|
|
465
|
+
daemon start watch repo for labeled issues, auto-process
|
|
466
|
+
pipeline start --issue N run full 12-stage pipeline on issue #N
|
|
467
|
+
loop "<goal>" continuous autonomous build loop
|
|
468
|
+
|
|
469
|
+
For teams shipping at scale:
|
|
470
|
+
fleet start orchestrate daemons across multiple repos
|
|
471
|
+
memory show view captured learnings from previous runs
|
|
472
|
+
cost show token usage and spending dashboard
|
|
473
|
+
|
|
474
|
+
Get help:
|
|
475
|
+
shipwright doctor validate setup and diagnose issues
|
|
476
|
+
shipwright templates list browse 12 pipeline templates
|
|
477
|
+
|
|
478
|
+
Learn more:
|
|
479
|
+
https://shipwright.dev
|
|
480
|
+
https://github.com/sethdford/shipwright
|
|
481
|
+
```
|
|
482
|
+
|
|
483
|
+
### Twitter / Social Media
|
|
484
|
+
|
|
485
|
+
- **Educational:** "Did you know? Your code review process is your biggest bottleneck. Autonomous code reviewers (powered by Claude) catch 70%+ of issues before human review. What would you build with that time back?"
|
|
486
|
+
- **Feature launch:** "Shipwright's memory system now captures failure patterns and injects them into future agent sessions. Your delivery system learns and improves with every issue. Retry rate down 60%."
|
|
487
|
+
- **Community:** "We love seeing teams integrate Shipwright into their stack. Shout-out to [Team X] who cut their deploy time in half and ship 3x per week now."
|
|
488
|
+
|
|
489
|
+
### Blog Post (Sample Intro)
|
|
490
|
+
|
|
491
|
+
"Shipwright isn't another code generation tool. It's an orchestration platform for autonomous agent teams that builds, tests, reviews, and ships your entire pipeline — while learning from every failure so the system improves over time. Here's how it works, why it's different, and what teams are shipping with it today."
|
|
492
|
+
|
|
493
|
+
---
|
|
494
|
+
|
|
495
|
+
## 18. Messaging for Different Channels
|
|
496
|
+
|
|
497
|
+
### GitHub (README, Discussions)
|
|
498
|
+
|
|
499
|
+
- **Tone:** Technical, pragmatic, example-driven
|
|
500
|
+
- **Content:** How to use, architecture, customization, community
|
|
501
|
+
- **CTA:** Label an issue with `shipwright`
|
|
502
|
+
|
|
503
|
+
### Product Blog
|
|
504
|
+
|
|
505
|
+
- **Tone:** Thought leadership, engineering deep-dives, transparency
|
|
506
|
+
- **Content:** Why we built this, DORA metrics, lessons learned, roadmap
|
|
507
|
+
- **CTA:** Subscribe for updates
|
|
508
|
+
|
|
509
|
+
### Social Media
|
|
510
|
+
|
|
511
|
+
- **Tone:** Punchy, relatable, conversational
|
|
512
|
+
- **Content:** Quick wins, community stories, Behind-the-scenes
|
|
513
|
+
- **CTA:** Follow, share, star the repo
|
|
514
|
+
|
|
515
|
+
### Sales / Corporate Site
|
|
516
|
+
|
|
517
|
+
- **Tone:** Solution-focused, ROI-driven, risk/tradeoff language
|
|
518
|
+
- **Content:** Personas, pain points, metrics, case studies, pricing
|
|
519
|
+
- **CTA:** Schedule a demo
|
|
520
|
+
|
|
521
|
+
### Docs / Getting Started
|
|
522
|
+
|
|
523
|
+
- **Tone:** Clear, structured, no assumptions
|
|
524
|
+
- **Content:** Install, quick start, concepts, troubleshooting
|
|
525
|
+
- **CTA:** Try it now
|
|
526
|
+
|
|
527
|
+
---
|
|
528
|
+
|
|
529
|
+
## 19. Appendix: The Shipwright Metaphor Deep Dive
|
|
530
|
+
|
|
531
|
+
### Why "Shipwright"?
|
|
532
|
+
|
|
533
|
+
A shipwright is a master craftsperson who designs and builds ships. The metaphor works on multiple levels:
|
|
534
|
+
|
|
535
|
+
1. **Intentional Construction** — Like a shipwright studying plans before cutting wood, Shipwright analyzes issues before executing. No wasted motion.
|
|
536
|
+
|
|
537
|
+
2. **Quality & Durability** — A poorly-built ship sinks. A well-built ship survives decades. Code quality is built in, not bolted on.
|
|
538
|
+
|
|
539
|
+
3. **Journey** — A ship's job is to move cargo safely from origin to destination. Shipwright moves code safely from issue to production.
|
|
540
|
+
|
|
541
|
+
4. **Team Effort** — Shipbuilding requires carpenters, sailmakers, riggers, caulkers working in concert. Shipwright orchestrates agent teams (builder, reviewer, tester) in parallel.
|
|
542
|
+
|
|
543
|
+
5. **Specialization** — Specialized trades make ships better. Shipwright uses specialized agents for their domains (testing, security, performance).
|
|
544
|
+
|
|
545
|
+
6. **Continuous Improvement** — Shipwrights studied failures, refined designs, improved techniques. Shipwright's memory system captures lessons.
|
|
546
|
+
|
|
547
|
+
### How to Use the Metaphor
|
|
548
|
+
|
|
549
|
+
**Good examples:**
|
|
550
|
+
|
|
551
|
+
- "Build the vessel that carries your code to production"
|
|
552
|
+
- "A crew of autonomous agents at the helm"
|
|
553
|
+
- "Let your delivery vessel sail on its own"
|
|
554
|
+
- "Well-crafted pipelines that endure the voyage"
|
|
555
|
+
|
|
556
|
+
**Avoid:**
|
|
557
|
+
|
|
558
|
+
- "Don't let your code shipwreck" (too negative)
|
|
559
|
+
- "Sink your technical debt" (confusing)
|
|
560
|
+
- "We're the pirates of delivery" (not the brand image)
|
|
561
|
+
- "Smooth sailing from idea to production" (cliche)
|
|
562
|
+
|
|
563
|
+
---
|
|
564
|
+
|
|
565
|
+
## 20. Living Document
|
|
566
|
+
|
|
567
|
+
This document will evolve. Update it when:
|
|
568
|
+
|
|
569
|
+
- Product direction changes
|
|
570
|
+
- New competitors emerge
|
|
571
|
+
- Customer feedback contradicts positioning
|
|
572
|
+
- Metrics show messaging isn't landing
|
|
573
|
+
- Team adds new features that shift differentiation
|
|
574
|
+
|
|
575
|
+
**Last updated:** 2025-02-14
|
|
576
|
+
**Next review:** 2025-05-14 (quarterly)
|
|
577
|
+
**Owner:** Brand / Product Marketing
|
|
578
|
+
|
|
579
|
+
---
|
|
580
|
+
|
|
581
|
+
## References & Related Documents
|
|
582
|
+
|
|
583
|
+
- **README.md** — Overview and quick start
|
|
584
|
+
- **.claude/CLAUDE.md** — Technical architecture and development guidelines
|
|
585
|
+
- **DORA metrics dashboard** — Measuring delivery performance
|
|
586
|
+
- **Daemon configuration** — Intelligence layer feature flags
|
|
587
|
+
- **Community issue template** — How users request features
|