specrails-core 1.7.2 → 1.7.3
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/VERSION +1 -1
- package/bin/doctor.sh +13 -4
- package/docs/changelog.md +1 -1
- package/docs/deployment.md +1 -1
- package/docs/getting-started.md +1 -1
- package/docs/installation.md +1 -1
- package/docs/user-docs/cli-reference.md +328 -0
- package/docs/user-docs/faq.md +137 -0
- package/docs/user-docs/installation.md +114 -0
- package/docs/user-docs/quick-start.md +158 -0
- package/install.sh +16 -7
- package/package.json +1 -1
package/VERSION
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
|
|
1
|
+
1.7.2
|
package/bin/doctor.sh
CHANGED
|
@@ -35,13 +35,22 @@ else
|
|
|
35
35
|
fi
|
|
36
36
|
|
|
37
37
|
# ─────────────────────────────────────────────
|
|
38
|
-
# Check 2: Claude
|
|
38
|
+
# Check 2: Claude authentication
|
|
39
39
|
# ─────────────────────────────────────────────
|
|
40
40
|
if command -v claude &>/dev/null; then
|
|
41
|
-
|
|
42
|
-
|
|
41
|
+
_claude_authed=false
|
|
42
|
+
if claude config list 2>/dev/null | grep -q "api_key"; then
|
|
43
|
+
_claude_authed=true
|
|
44
|
+
elif [[ -n "${ANTHROPIC_API_KEY:-}" ]]; then
|
|
45
|
+
_claude_authed=true
|
|
46
|
+
elif [[ -f "${HOME}/.claude.json" ]] && grep -q '"oauthAccount"' "${HOME}/.claude.json" 2>/dev/null; then
|
|
47
|
+
_claude_authed=true
|
|
48
|
+
fi
|
|
49
|
+
|
|
50
|
+
if [[ "$_claude_authed" == "true" ]]; then
|
|
51
|
+
pass "Claude: authenticated"
|
|
43
52
|
else
|
|
44
|
-
fail "
|
|
53
|
+
fail "Claude: not authenticated" "Option 1: claude config set api_key <your-key> | Option 2: claude auth login"
|
|
45
54
|
fi
|
|
46
55
|
fi
|
|
47
56
|
|
package/docs/changelog.md
CHANGED
|
@@ -141,7 +141,7 @@ All commands renamed from `/<name>` to `/sr:<name>`. All agent files renamed fro
|
|
|
141
141
|
- `update.sh` auto-migrates command namespace changes
|
|
142
142
|
|
|
143
143
|
**Distribution**
|
|
144
|
-
- `npx specrails@latest init`
|
|
144
|
+
- `npx specrails-core@latest init`
|
|
145
145
|
- `curl | bash` installer
|
|
146
146
|
- `--root-dir` flag for monorepo support
|
|
147
147
|
- `--yes` flag for non-interactive CI installs
|
package/docs/deployment.md
CHANGED
package/docs/getting-started.md
CHANGED
package/docs/installation.md
CHANGED
|
@@ -32,7 +32,7 @@ The installer checks for all of these and offers to install missing tools.
|
|
|
32
32
|
### From npx (recommended)
|
|
33
33
|
|
|
34
34
|
```bash
|
|
35
|
-
npx specrails@latest init --root-dir <your-project>
|
|
35
|
+
npx specrails-core@latest init --root-dir <your-project>
|
|
36
36
|
```
|
|
37
37
|
|
|
38
38
|
No cloning required. Downloads the latest version and runs the installer automatically.
|
|
@@ -0,0 +1,328 @@
|
|
|
1
|
+
# CLI Reference
|
|
2
|
+
|
|
3
|
+
All commands are Claude Code slash commands. Run them inside Claude Code (`claude`) from your project directory.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Core workflow
|
|
8
|
+
|
|
9
|
+
### `/sr:implement`
|
|
10
|
+
|
|
11
|
+
Implement a feature through the full agent pipeline: design → code → tests → docs → review → PR.
|
|
12
|
+
|
|
13
|
+
```
|
|
14
|
+
/sr:implement #85
|
|
15
|
+
/sr:implement #85, #71, #63
|
|
16
|
+
/sr:implement "add a health check endpoint"
|
|
17
|
+
/sr:implement UI, Analytics
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
**Flags:**
|
|
21
|
+
|
|
22
|
+
| Flag | Effect |
|
|
23
|
+
|------|--------|
|
|
24
|
+
| `--dry-run` / `--preview` | Run the full pipeline without git operations or PR creation |
|
|
25
|
+
| `--apply <name>` | Apply a previously cached dry-run |
|
|
26
|
+
|
|
27
|
+
**Pipeline phases:**
|
|
28
|
+
|
|
29
|
+
| Phase | Agent | What happens |
|
|
30
|
+
|-------|-------|-------------|
|
|
31
|
+
| 3a | Architect | Designs the implementation, creates a task list |
|
|
32
|
+
| 3b | Developer | Writes code across all affected layers |
|
|
33
|
+
| 3c | Test Writer | Generates tests for new code |
|
|
34
|
+
| 3d | Doc Sync | Updates CHANGELOG and relevant docs |
|
|
35
|
+
| 4 | Security Reviewer | Scans for secrets and vulnerabilities |
|
|
36
|
+
| 4b | Reviewer | Runs your CI suite, fixes lint/type errors |
|
|
37
|
+
| 4b-conf | — | Confidence gate: scores implementation across 5 dimensions |
|
|
38
|
+
| 5 | — | Creates a pull request |
|
|
39
|
+
|
|
40
|
+
**Single vs. parallel:**
|
|
41
|
+
|
|
42
|
+
A single issue runs sequentially on the current branch. Multiple issues run in parallel — each gets an isolated git worktree, and results are merged automatically.
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
### `/sr:retry`
|
|
47
|
+
|
|
48
|
+
Resume a failed `/sr:implement` run from the last successful phase.
|
|
49
|
+
|
|
50
|
+
```
|
|
51
|
+
/sr:retry <feature-name>
|
|
52
|
+
/sr:retry --list
|
|
53
|
+
/sr:retry <feature-name> --from architect
|
|
54
|
+
/sr:retry <feature-name> --dry-run
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
**Flags:**
|
|
58
|
+
|
|
59
|
+
| Flag | Effect |
|
|
60
|
+
|------|--------|
|
|
61
|
+
| `--list` | List all saved pipeline states |
|
|
62
|
+
| `--from <phase>` | Force resume from a specific phase |
|
|
63
|
+
| `--dry-run` | Resume in preview mode |
|
|
64
|
+
|
|
65
|
+
**Valid `--from` values:** `architect`, `developer`, `test-writer`, `doc-sync`, `reviewer`, `ship`, `ci`
|
|
66
|
+
|
|
67
|
+
Pipeline state is saved to `.claude/pipeline-state/<feature-name>.json` after each phase.
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
### `/sr:batch-implement`
|
|
72
|
+
|
|
73
|
+
Implement multiple independent features in parallel using git worktrees.
|
|
74
|
+
|
|
75
|
+
```
|
|
76
|
+
/sr:batch-implement #85, #71, #63
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
Each feature gets its own worktree, its own agent pipeline, and its own PR. Use this instead of `/sr:implement` with multiple issues when you want explicit control over parallel execution.
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## Product and backlog
|
|
84
|
+
|
|
85
|
+
### `/sr:product-backlog`
|
|
86
|
+
|
|
87
|
+
View your prioritized product backlog, ranked by VPC persona fit and estimated effort.
|
|
88
|
+
|
|
89
|
+
```
|
|
90
|
+
/sr:product-backlog
|
|
91
|
+
/sr:product-backlog UI, API
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
Reads GitHub Issues labeled `product-driven-backlog`. Produces a ranked table per area, top 3 recommendations, and a safe implementation order based on issue dependencies.
|
|
95
|
+
|
|
96
|
+
---
|
|
97
|
+
|
|
98
|
+
### `/sr:update-product-driven-backlog`
|
|
99
|
+
|
|
100
|
+
Generate new feature ideas through product discovery and create GitHub Issues.
|
|
101
|
+
|
|
102
|
+
```
|
|
103
|
+
/sr:update-product-driven-backlog
|
|
104
|
+
/sr:update-product-driven-backlog UI, API
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
The Product Manager researches your competitive landscape, generates 2–4 feature ideas per area, and scores each against your user personas. Creates GitHub Issues with full VPC evaluation if write access is available.
|
|
108
|
+
|
|
109
|
+
---
|
|
110
|
+
|
|
111
|
+
## Analysis and inspection
|
|
112
|
+
|
|
113
|
+
### `/sr:health-check`
|
|
114
|
+
|
|
115
|
+
Run a comprehensive codebase quality analysis.
|
|
116
|
+
|
|
117
|
+
```
|
|
118
|
+
/sr:health-check
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
Analyzes code quality, test coverage, technical debt, complexity, and dependency health. Compares with previous runs to detect regressions.
|
|
122
|
+
|
|
123
|
+
---
|
|
124
|
+
|
|
125
|
+
### `/sr:refactor-recommender`
|
|
126
|
+
|
|
127
|
+
Scan the codebase for refactoring opportunities, ranked by impact/effort ratio.
|
|
128
|
+
|
|
129
|
+
```
|
|
130
|
+
/sr:refactor-recommender
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
Identifies duplicates, overly long functions, large files, dead code, outdated patterns, and complex logic. Optionally creates GitHub Issues for tracking.
|
|
134
|
+
|
|
135
|
+
---
|
|
136
|
+
|
|
137
|
+
### `/sr:compat-check`
|
|
138
|
+
|
|
139
|
+
Analyze the backwards-compatibility impact of a proposed change.
|
|
140
|
+
|
|
141
|
+
```
|
|
142
|
+
/sr:compat-check #85
|
|
143
|
+
/sr:compat-check #85 --save
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
Detects removed endpoints, changed method signatures, changed response shapes, and behavioral changes. When breaking changes are found, generates a migration guide.
|
|
147
|
+
|
|
148
|
+
`--save` updates the stored API baseline so future checks compare against the new surface.
|
|
149
|
+
|
|
150
|
+
The Architect runs this automatically as part of every `/sr:implement` pipeline.
|
|
151
|
+
|
|
152
|
+
---
|
|
153
|
+
|
|
154
|
+
### `/sr:why`
|
|
155
|
+
|
|
156
|
+
Search agent explanation records in plain language.
|
|
157
|
+
|
|
158
|
+
```
|
|
159
|
+
/sr:why "why did we choose this database schema"
|
|
160
|
+
/sr:why "explain the auth middleware design"
|
|
161
|
+
/sr:why "why is pagination implemented this way"
|
|
162
|
+
```
|
|
163
|
+
|
|
164
|
+
Agents write decision rationale to `.claude/agent-memory/explanations/` as they work. `/sr:why` searches these records semantically. Useful for onboarding, code review, and revisiting past decisions.
|
|
165
|
+
|
|
166
|
+
---
|
|
167
|
+
|
|
168
|
+
### `/sr:vpc-drift`
|
|
169
|
+
|
|
170
|
+
Detect when your VPC personas have drifted from what your product actually delivers.
|
|
171
|
+
|
|
172
|
+
```
|
|
173
|
+
/sr:vpc-drift
|
|
174
|
+
/sr:vpc-drift --persona "Alex,Sara"
|
|
175
|
+
/sr:vpc-drift --verbose
|
|
176
|
+
/sr:vpc-drift --format json
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
Compares persona Jobs/Pains/Gains against your backlog, implemented features, and agent memory. Produces a per-persona alignment score and recommendations for updating your VPC.
|
|
180
|
+
|
|
181
|
+
---
|
|
182
|
+
|
|
183
|
+
### `/sr:memory-inspect`
|
|
184
|
+
|
|
185
|
+
Inspect and clean up agent memory directories.
|
|
186
|
+
|
|
187
|
+
```
|
|
188
|
+
/sr:memory-inspect
|
|
189
|
+
/sr:memory-inspect sr-developer
|
|
190
|
+
/sr:memory-inspect --stale 14
|
|
191
|
+
/sr:memory-inspect --prune
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
**Flags:**
|
|
195
|
+
|
|
196
|
+
| Flag | Effect |
|
|
197
|
+
|------|--------|
|
|
198
|
+
| `--stale <days>` | Flag files older than N days |
|
|
199
|
+
| `--prune` | Delete stale files (prompts for confirmation) |
|
|
200
|
+
|
|
201
|
+
Agent memory lives in `.claude/agent-memory/sr-*/`.
|
|
202
|
+
|
|
203
|
+
---
|
|
204
|
+
|
|
205
|
+
### `/sr:propose-spec`
|
|
206
|
+
|
|
207
|
+
Explore a feature idea and produce a structured proposal ready for the OpenSpec pipeline.
|
|
208
|
+
|
|
209
|
+
```
|
|
210
|
+
/sr:propose-spec "add rate limiting to the API"
|
|
211
|
+
```
|
|
212
|
+
|
|
213
|
+
Produces: problem statement, proposed solution, out-of-scope items, acceptance criteria, technical considerations, and a complexity estimate.
|
|
214
|
+
|
|
215
|
+
---
|
|
216
|
+
|
|
217
|
+
## OpenSpec commands
|
|
218
|
+
|
|
219
|
+
OpenSpec is the structured design-to-code workflow. Use these commands when you want explicit control over each artifact: proposal → design → tasks → implementation.
|
|
220
|
+
|
|
221
|
+
### `/opsx:ff` — Fast Forward
|
|
222
|
+
|
|
223
|
+
Create all OpenSpec artifacts at once (proposal + design + tasks + context bundle), then hand off to the developer.
|
|
224
|
+
|
|
225
|
+
```
|
|
226
|
+
/opsx:ff
|
|
227
|
+
```
|
|
228
|
+
|
|
229
|
+
Use this when you know what you want to build and don't need to review each artifact step by step.
|
|
230
|
+
|
|
231
|
+
---
|
|
232
|
+
|
|
233
|
+
### `/opsx:new` — New Change
|
|
234
|
+
|
|
235
|
+
Start a new change by creating a proposal. Advances through artifacts one at a time.
|
|
236
|
+
|
|
237
|
+
```
|
|
238
|
+
/opsx:new
|
|
239
|
+
```
|
|
240
|
+
|
|
241
|
+
---
|
|
242
|
+
|
|
243
|
+
### `/opsx:continue` — Continue Change
|
|
244
|
+
|
|
245
|
+
Create the next artifact in the sequence for the current in-progress change.
|
|
246
|
+
|
|
247
|
+
```
|
|
248
|
+
/opsx:continue
|
|
249
|
+
```
|
|
250
|
+
|
|
251
|
+
Typical sequence: proposal → design → tasks → context bundle.
|
|
252
|
+
|
|
253
|
+
---
|
|
254
|
+
|
|
255
|
+
### `/opsx:apply` — Apply Change
|
|
256
|
+
|
|
257
|
+
Implement the tasks from a designed change. Hands off to the Developer agent.
|
|
258
|
+
|
|
259
|
+
```
|
|
260
|
+
/opsx:apply
|
|
261
|
+
```
|
|
262
|
+
|
|
263
|
+
---
|
|
264
|
+
|
|
265
|
+
### `/opsx:verify` — Verify Change
|
|
266
|
+
|
|
267
|
+
Validate that the implementation matches the change artifacts before archiving.
|
|
268
|
+
|
|
269
|
+
```
|
|
270
|
+
/opsx:verify
|
|
271
|
+
```
|
|
272
|
+
|
|
273
|
+
---
|
|
274
|
+
|
|
275
|
+
### `/opsx:archive` — Archive Change
|
|
276
|
+
|
|
277
|
+
Finalize and archive a completed change.
|
|
278
|
+
|
|
279
|
+
```
|
|
280
|
+
/opsx:archive
|
|
281
|
+
```
|
|
282
|
+
|
|
283
|
+
---
|
|
284
|
+
|
|
285
|
+
### `/opsx:explore` — Explore
|
|
286
|
+
|
|
287
|
+
Open-ended thinking mode for brainstorming, investigating problems, or clarifying requirements before starting a change.
|
|
288
|
+
|
|
289
|
+
```
|
|
290
|
+
/opsx:explore
|
|
291
|
+
```
|
|
292
|
+
|
|
293
|
+
---
|
|
294
|
+
|
|
295
|
+
### Typical OpenSpec flows
|
|
296
|
+
|
|
297
|
+
**Fast path:**
|
|
298
|
+
```
|
|
299
|
+
/opsx:ff → create all artifacts
|
|
300
|
+
/opsx:apply → implement
|
|
301
|
+
/opsx:verify → validate
|
|
302
|
+
/opsx:archive → finalize
|
|
303
|
+
```
|
|
304
|
+
|
|
305
|
+
**Step by step:**
|
|
306
|
+
```
|
|
307
|
+
/opsx:new → proposal
|
|
308
|
+
/opsx:continue → design
|
|
309
|
+
/opsx:continue → tasks
|
|
310
|
+
/opsx:continue → context bundle
|
|
311
|
+
/opsx:apply → implement
|
|
312
|
+
/opsx:archive → finalize
|
|
313
|
+
```
|
|
314
|
+
|
|
315
|
+
---
|
|
316
|
+
|
|
317
|
+
## Installer flags
|
|
318
|
+
|
|
319
|
+
The `npx specrails-core@latest init` command accepts:
|
|
320
|
+
|
|
321
|
+
| Flag | Effect |
|
|
322
|
+
|------|--------|
|
|
323
|
+
| `--root-dir <path>` | Install into this directory (default: current directory) |
|
|
324
|
+
| `--yes` / `-y` | Skip confirmation prompts |
|
|
325
|
+
|
|
326
|
+
---
|
|
327
|
+
|
|
328
|
+
[← Quick Start](quick-start.md) · [FAQ →](faq.md) · [← Installation](installation.md)
|
|
@@ -0,0 +1,137 @@
|
|
|
1
|
+
# FAQ
|
|
2
|
+
|
|
3
|
+
## Setup and installation
|
|
4
|
+
|
|
5
|
+
**Do I need a Claude API account to use SpecRails?**
|
|
6
|
+
|
|
7
|
+
Yes. SpecRails runs on top of Claude Code, which requires an Anthropic account. Claude Code handles authentication — SpecRails just orchestrates it. See [Claude Code's installation guide](https://docs.anthropic.com/en/docs/claude-code) for setup.
|
|
8
|
+
|
|
9
|
+
**What does the installer actually do to my project?**
|
|
10
|
+
|
|
11
|
+
It creates a `.claude/` directory with agent templates, commands, and configuration files. It does not modify your source code, create commits, or push anything. Your project is unchanged — `.claude/` is the only addition.
|
|
12
|
+
|
|
13
|
+
**Do I need Node.js if my project is not JavaScript?**
|
|
14
|
+
|
|
15
|
+
Yes. Node 18+ is required to run `npx specrails-core@latest`. Once installed, SpecRails works with any language or framework — the agents adapt to whatever stack your project uses.
|
|
16
|
+
|
|
17
|
+
**Can I run SpecRails on a project that doesn't have GitHub Issues?**
|
|
18
|
+
|
|
19
|
+
Yes. During `/setup`, you can choose "none" as your backlog provider. Commands like `/sr:implement` will accept plain text descriptions instead of issue numbers:
|
|
20
|
+
|
|
21
|
+
```
|
|
22
|
+
/sr:implement "add rate limiting to the API"
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
**How long does /setup take?**
|
|
26
|
+
|
|
27
|
+
About 5 minutes. Most of the time is spent on Phase 2 (persona generation), which does web research on your domain.
|
|
28
|
+
|
|
29
|
+
---
|
|
30
|
+
|
|
31
|
+
## Using SpecRails
|
|
32
|
+
|
|
33
|
+
**Can I run SpecRails on an existing project with existing code?**
|
|
34
|
+
|
|
35
|
+
Yes, that's the intended use case. The `/setup` wizard analyzes your existing codebase — your tech stack, layers, CI commands, and conventions — and generates agents configured specifically for it.
|
|
36
|
+
|
|
37
|
+
**Does /sr:implement always create a PR?**
|
|
38
|
+
|
|
39
|
+
By default, yes. If you want to preview the changes first without creating commits or a PR, use dry-run mode:
|
|
40
|
+
|
|
41
|
+
```
|
|
42
|
+
/sr:implement --dry-run "add dark mode"
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
Then apply the cached result when you're ready:
|
|
46
|
+
|
|
47
|
+
```
|
|
48
|
+
/sr:implement --apply dark-mode
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
**What happens if the pipeline fails mid-run?**
|
|
52
|
+
|
|
53
|
+
SpecRails saves pipeline state after each phase. If a run fails, use `/sr:retry` to resume from the last successful phase instead of starting over:
|
|
54
|
+
|
|
55
|
+
```
|
|
56
|
+
/sr:retry dark-mode
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
**Can I implement multiple features at once?**
|
|
60
|
+
|
|
61
|
+
Yes. Pass multiple issue numbers or descriptions:
|
|
62
|
+
|
|
63
|
+
```
|
|
64
|
+
/sr:implement #42, #43, #44
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
Each feature gets an isolated git worktree. Pipelines run concurrently and the results are merged automatically at the end.
|
|
68
|
+
|
|
69
|
+
**Can I customize the agents?**
|
|
70
|
+
|
|
71
|
+
Yes. After setup, the generated agent files are in `.claude/agents/`. Edit them directly to change behavior, add constraints, or update instructions. Changes take effect on the next run.
|
|
72
|
+
|
|
73
|
+
For layer-specific coding conventions, edit `.claude/rules/*.md`.
|
|
74
|
+
|
|
75
|
+
**What is a VPC persona?**
|
|
76
|
+
|
|
77
|
+
VPC stands for Value Proposition Canvas. Personas are structured profiles of your target users with their Jobs (what they're trying to accomplish), Pains (what frustrates them), and Gains (what they want). The Product Manager and Architect use these to make better design decisions. They're generated during `/setup` and stored in `.claude/agents/personas/`.
|
|
78
|
+
|
|
79
|
+
---
|
|
80
|
+
|
|
81
|
+
## Project compatibility
|
|
82
|
+
|
|
83
|
+
**Does SpecRails work with monorepos?**
|
|
84
|
+
|
|
85
|
+
Yes. During `/setup`, the architect detects your monorepo structure and generates separate layer configurations for each package or service.
|
|
86
|
+
|
|
87
|
+
**Which languages and frameworks are supported?**
|
|
88
|
+
|
|
89
|
+
SpecRails works with any stack. The agents are general-purpose and adapt based on what `/setup` detects in your codebase. It's been used with Node.js, Python, Go, Ruby, Rust, and mixed-stack projects.
|
|
90
|
+
|
|
91
|
+
**Does it work with private repositories?**
|
|
92
|
+
|
|
93
|
+
Yes, for code generation. For features that require GitHub integration (PR creation, Issue reading), you need the GitHub CLI authenticated against your private repo.
|
|
94
|
+
|
|
95
|
+
---
|
|
96
|
+
|
|
97
|
+
## Keeping SpecRails up to date
|
|
98
|
+
|
|
99
|
+
**How do I update SpecRails?**
|
|
100
|
+
|
|
101
|
+
Run the installer again in your project:
|
|
102
|
+
|
|
103
|
+
```bash
|
|
104
|
+
npx specrails-core@latest init --root-dir .
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
Then re-run `/setup` to regenerate agents with any new templates. See the [updating guide](../updating.md) for details.
|
|
108
|
+
|
|
109
|
+
**How do I know which version is installed?**
|
|
110
|
+
|
|
111
|
+
```bash
|
|
112
|
+
cat .specrails-version
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## Troubleshooting
|
|
118
|
+
|
|
119
|
+
**The /setup command isn't available after installing.**
|
|
120
|
+
|
|
121
|
+
Claude Code loads commands from `.claude/commands/`. Make sure you opened Claude Code from inside your project directory (the one where you ran `npx specrails-core@latest init`).
|
|
122
|
+
|
|
123
|
+
**Generated files contain `{{PLACEHOLDER}}` text.**
|
|
124
|
+
|
|
125
|
+
The `/setup` wizard did not complete all phases. Re-run `/setup` — it will pick up where it left off.
|
|
126
|
+
|
|
127
|
+
**The pipeline created a PR but the CI checks failed.**
|
|
128
|
+
|
|
129
|
+
The reviewer agent runs your CI suite and attempts to fix failures automatically. If it can't fix them within its budget, it creates the PR with a note describing what failed and why. You can fix the remaining issues manually or run `/sr:retry` to try the reviewer phase again.
|
|
130
|
+
|
|
131
|
+
**I got a "409 Conflict" error during a pipeline run.**
|
|
132
|
+
|
|
133
|
+
This means another agent tried to check out the same issue simultaneously. The pipeline will detect this and stop — re-run the command after the conflicting run finishes.
|
|
134
|
+
|
|
135
|
+
---
|
|
136
|
+
|
|
137
|
+
[← Quick Start](quick-start.md) · [CLI Reference →](cli-reference.md)
|
|
@@ -0,0 +1,114 @@
|
|
|
1
|
+
# Installation
|
|
2
|
+
|
|
3
|
+
Install SpecRails into any git repository in two steps: run the installer, then run `/setup` inside Claude Code.
|
|
4
|
+
|
|
5
|
+
## Requirements
|
|
6
|
+
|
|
7
|
+
| Tool | Version | Notes |
|
|
8
|
+
|------|---------|-------|
|
|
9
|
+
| **Node.js** | 18+ | Required for the installer |
|
|
10
|
+
| **Claude Code** | Latest | The AI CLI that runs the agents — [install guide](https://docs.anthropic.com/en/docs/claude-code) |
|
|
11
|
+
| **Git** | Any | Your project must be a git repository |
|
|
12
|
+
|
|
13
|
+
Optional but recommended:
|
|
14
|
+
|
|
15
|
+
| Tool | Why |
|
|
16
|
+
|------|-----|
|
|
17
|
+
| **GitHub CLI** (`gh`) | Automatic PR creation and Issue integration |
|
|
18
|
+
|
|
19
|
+
## Install
|
|
20
|
+
|
|
21
|
+
Run the installer from inside your project directory:
|
|
22
|
+
|
|
23
|
+
```bash
|
|
24
|
+
cd your-project
|
|
25
|
+
npx specrails-core@latest init --root-dir .
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
The installer copies agent templates, commands, and configuration files into `.claude/` inside your project. It does not modify your existing code.
|
|
29
|
+
|
|
30
|
+
### Flags
|
|
31
|
+
|
|
32
|
+
| Flag | Effect |
|
|
33
|
+
|------|--------|
|
|
34
|
+
| `--root-dir <path>` | Target directory (default: current directory) |
|
|
35
|
+
| `--yes` / `-y` | Skip confirmation prompts |
|
|
36
|
+
|
|
37
|
+
### What gets installed
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
your-project/
|
|
41
|
+
└── .claude/
|
|
42
|
+
├── commands/setup.md # The /setup wizard
|
|
43
|
+
├── setup-templates/ # Agent and command templates
|
|
44
|
+
├── web-manager/ # Pipeline Monitor dashboard (optional)
|
|
45
|
+
└── security-exemptions.yaml # Security scanner config
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
The installer also writes `.specrails-version` and `.specrails-manifest.json` to track the installed version.
|
|
49
|
+
|
|
50
|
+
## Configure with /setup
|
|
51
|
+
|
|
52
|
+
After installation, open Claude Code in your project and run the setup wizard:
|
|
53
|
+
|
|
54
|
+
```bash
|
|
55
|
+
claude # open Claude Code
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
```
|
|
59
|
+
/setup
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
The wizard runs 5 phases:
|
|
63
|
+
|
|
64
|
+
| Phase | What happens |
|
|
65
|
+
|-------|-------------|
|
|
66
|
+
| **1. Analyze** | Detects your tech stack, architecture layers, and CI commands |
|
|
67
|
+
| **2. Personas** | Researches your domain and generates VPC user profiles |
|
|
68
|
+
| **3. Configure** | Asks about your backlog provider, git workflow, and agent selection |
|
|
69
|
+
| **4. Generate** | Fills all templates with your project-specific context |
|
|
70
|
+
| **5. Cleanup** | Removes setup files, leaving only your tailored workflow |
|
|
71
|
+
|
|
72
|
+
After setup, `.claude/` contains fully configured agents and commands ready to use. The `/setup` command removes itself — it only runs once.
|
|
73
|
+
|
|
74
|
+
## Verify
|
|
75
|
+
|
|
76
|
+
Check that everything installed correctly:
|
|
77
|
+
|
|
78
|
+
```bash
|
|
79
|
+
# List generated agents
|
|
80
|
+
ls .claude/agents/
|
|
81
|
+
|
|
82
|
+
# Check for unresolved placeholders (should return nothing)
|
|
83
|
+
grep -r '{{[A-Z_]*}}' .claude/agents/ .claude/commands/ .claude/rules/
|
|
84
|
+
|
|
85
|
+
# Check the installed version
|
|
86
|
+
cat .specrails-version
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
## Troubleshooting
|
|
90
|
+
|
|
91
|
+
### "This appears to be the specrails source repository"
|
|
92
|
+
|
|
93
|
+
You ran the installer from inside the SpecRails source repo. Run it from your target project instead:
|
|
94
|
+
|
|
95
|
+
```bash
|
|
96
|
+
cd /path/to/your-project
|
|
97
|
+
npx specrails-core@latest init --root-dir .
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
### Existing `.claude/` directory detected
|
|
101
|
+
|
|
102
|
+
The installer warns if SpecRails artifacts already exist. You can merge (install alongside existing files) or abort to review manually.
|
|
103
|
+
|
|
104
|
+
### Placeholders not resolved
|
|
105
|
+
|
|
106
|
+
If you see `{{PLACEHOLDER}}` in generated files, the `/setup` wizard did not complete. Re-run `/setup` or fill the values manually.
|
|
107
|
+
|
|
108
|
+
### Claude Code not found
|
|
109
|
+
|
|
110
|
+
Install Claude Code following [Anthropic's guide](https://docs.anthropic.com/en/docs/claude-code), then re-run the installer.
|
|
111
|
+
|
|
112
|
+
---
|
|
113
|
+
|
|
114
|
+
[Quick Start →](quick-start.md) · [CLI Reference →](cli-reference.md)
|
|
@@ -0,0 +1,158 @@
|
|
|
1
|
+
# Quick Start
|
|
2
|
+
|
|
3
|
+
Get SpecRails running in your project in under 10 minutes.
|
|
4
|
+
|
|
5
|
+
## Before you begin
|
|
6
|
+
|
|
7
|
+
You need:
|
|
8
|
+
- **Node.js 18+** — check with `node --version`
|
|
9
|
+
- **Claude Code** — install from [docs.anthropic.com/en/docs/claude-code](https://docs.anthropic.com/en/docs/claude-code)
|
|
10
|
+
- **A git repository** — your project must have a `.git` directory
|
|
11
|
+
|
|
12
|
+
Optional:
|
|
13
|
+
- **GitHub CLI** (`gh`) — enables automatic PR creation
|
|
14
|
+
|
|
15
|
+
## Step 1: Install
|
|
16
|
+
|
|
17
|
+
From inside your project directory:
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
npx specrails-core@latest init --root-dir .
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Expected output:
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
✓ Prerequisites checked
|
|
27
|
+
✓ Templates installed → .claude/
|
|
28
|
+
✓ Version tracked → .specrails-version
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
This copies agent templates and commands into `.claude/`. Your existing code is not touched.
|
|
32
|
+
|
|
33
|
+
## Step 2: Run the setup wizard
|
|
34
|
+
|
|
35
|
+
Open Claude Code in your project:
|
|
36
|
+
|
|
37
|
+
```bash
|
|
38
|
+
claude
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
Then run:
|
|
42
|
+
|
|
43
|
+
```
|
|
44
|
+
/setup
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
The wizard runs automatically and takes about 5 minutes. It analyzes your codebase and configures SpecRails for your specific project:
|
|
48
|
+
|
|
49
|
+
```
|
|
50
|
+
Phase 1/5 Analyzing codebase...
|
|
51
|
+
→ Detected: TypeScript, Express, PostgreSQL
|
|
52
|
+
→ Found 3 architecture layers
|
|
53
|
+
→ Identified CI commands: npm test, npm run lint
|
|
54
|
+
|
|
55
|
+
Phase 2/5 Generating user personas...
|
|
56
|
+
→ Researching your domain
|
|
57
|
+
→ Created 3 VPC profiles
|
|
58
|
+
|
|
59
|
+
Phase 3/5 Configuration...
|
|
60
|
+
→ Backlog provider: GitHub Issues
|
|
61
|
+
→ Git workflow: trunk-based
|
|
62
|
+
|
|
63
|
+
Phase 4/5 Generating files...
|
|
64
|
+
→ sr-architect.md (adapted to your stack)
|
|
65
|
+
→ sr-developer.md (knows your CI commands)
|
|
66
|
+
→ sr-reviewer.md (runs your specific checks)
|
|
67
|
+
→ 9 more agents
|
|
68
|
+
|
|
69
|
+
Phase 5/5 Cleanup complete. /setup removed.
|
|
70
|
+
|
|
71
|
+
✓ SpecRails is ready. Run /sr:implement to start building.
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
After setup, the `/setup` command is gone — it's a one-time wizard.
|
|
75
|
+
|
|
76
|
+
## Step 3: Implement your first feature
|
|
77
|
+
|
|
78
|
+
Pick something small. Either reference a GitHub Issue or describe it in plain text:
|
|
79
|
+
|
|
80
|
+
```
|
|
81
|
+
/sr:implement #42
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
or:
|
|
85
|
+
|
|
86
|
+
```
|
|
87
|
+
/sr:implement "add a health check endpoint to the API"
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
The pipeline runs automatically:
|
|
91
|
+
|
|
92
|
+
```
|
|
93
|
+
Phase 3a Architect designing...
|
|
94
|
+
→ Design: GET /health endpoint + middleware
|
|
95
|
+
→ Tasks: 3 steps
|
|
96
|
+
|
|
97
|
+
Phase 3b Developer implementing...
|
|
98
|
+
→ src/routes/health.ts (created)
|
|
99
|
+
→ src/middleware/health.ts (created)
|
|
100
|
+
→ src/app.ts (modified)
|
|
101
|
+
|
|
102
|
+
Phase 3c Test Writer generating...
|
|
103
|
+
→ tests/routes/health.test.ts (created)
|
|
104
|
+
→ 5 tests, all passing
|
|
105
|
+
|
|
106
|
+
Phase 3d Doc Sync updating...
|
|
107
|
+
→ CHANGELOG.md updated
|
|
108
|
+
|
|
109
|
+
Phase 4 Security Reviewer scanning...
|
|
110
|
+
→ No critical findings
|
|
111
|
+
|
|
112
|
+
Phase 4b Reviewer running CI...
|
|
113
|
+
→ ✓ lint ✓ typecheck ✓ tests
|
|
114
|
+
|
|
115
|
+
Phase 4b-conf Confidence: 91% — threshold met
|
|
116
|
+
|
|
117
|
+
PR #43 created: feat: add health check endpoint
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
One command. The PR is ready for human review.
|
|
121
|
+
|
|
122
|
+
## What's next?
|
|
123
|
+
|
|
124
|
+
**Explore the backlog:**
|
|
125
|
+
|
|
126
|
+
```
|
|
127
|
+
/sr:product-backlog
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
See your GitHub Issues ranked by persona fit and effort. The top 3 are safe to implement next.
|
|
131
|
+
|
|
132
|
+
**Generate new feature ideas:**
|
|
133
|
+
|
|
134
|
+
```
|
|
135
|
+
/sr:update-product-driven-backlog
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
The Product Manager researches your competitive landscape and creates well-formed GitHub Issues for new features.
|
|
139
|
+
|
|
140
|
+
**Run multiple features in parallel:**
|
|
141
|
+
|
|
142
|
+
```
|
|
143
|
+
/sr:implement #42, #43, #44
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
Each feature gets its own git worktree. Pipelines run concurrently and merge automatically.
|
|
147
|
+
|
|
148
|
+
**Ask why a decision was made:**
|
|
149
|
+
|
|
150
|
+
```
|
|
151
|
+
/sr:why "why did we choose this database schema"
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
Agents record their reasoning as they work. `/sr:why` searches those records in plain language.
|
|
155
|
+
|
|
156
|
+
---
|
|
157
|
+
|
|
158
|
+
[← Installation](installation.md) · [CLI Reference →](cli-reference.md) · [FAQ →](faq.md)
|
package/install.sh
CHANGED
|
@@ -200,16 +200,25 @@ else
|
|
|
200
200
|
exit 1
|
|
201
201
|
fi
|
|
202
202
|
|
|
203
|
-
# 1.3 API key
|
|
204
|
-
|
|
205
|
-
|
|
203
|
+
# 1.3 Claude authentication (API key or OAuth)
|
|
204
|
+
CLAUDE_AUTHED=false
|
|
205
|
+
if claude config list 2>/dev/null | grep -q "api_key"; then
|
|
206
|
+
CLAUDE_AUTHED=true
|
|
207
|
+
elif [[ -n "${ANTHROPIC_API_KEY:-}" ]]; then
|
|
208
|
+
CLAUDE_AUTHED=true
|
|
209
|
+
elif [[ -f "${HOME}/.claude.json" ]] && grep -q '"oauthAccount"' "${HOME}/.claude.json" 2>/dev/null; then
|
|
210
|
+
CLAUDE_AUTHED=true
|
|
211
|
+
fi
|
|
212
|
+
|
|
213
|
+
if [[ "$CLAUDE_AUTHED" == "true" ]]; then
|
|
214
|
+
ok "Claude: authenticated"
|
|
206
215
|
elif [[ "$SKIP_PREREQS" == "1" ]]; then
|
|
207
|
-
warn "
|
|
216
|
+
warn "Claude authentication not found (skipped — SPECRAILS_SKIP_PREREQS=1)"
|
|
208
217
|
else
|
|
209
|
-
fail "No Claude
|
|
218
|
+
fail "No Claude authentication found."
|
|
210
219
|
echo ""
|
|
211
|
-
echo "
|
|
212
|
-
echo "
|
|
220
|
+
echo " Option 1 (API key): claude config set api_key <your-key>"
|
|
221
|
+
echo " Option 2 (OAuth): claude auth login"
|
|
213
222
|
exit 1
|
|
214
223
|
fi
|
|
215
224
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "specrails-core",
|
|
3
|
-
"version": "1.7.
|
|
3
|
+
"version": "1.7.3",
|
|
4
4
|
"description": "AI agent workflow system for Claude Code — installs 12 specialized agents, orchestration commands, and persona-driven product discovery into any repository",
|
|
5
5
|
"bin": {
|
|
6
6
|
"specrails-core": "bin/specrails-core.js"
|