@haus-tech/haus-workflow 4.0.1 → 4.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/CHANGELOG.md +12 -0
- package/README.md +36 -1
- package/dist/cli.js +1368 -771
- package/library/global/skills/haus-workflow/SKILL.md +5 -5
- package/library/global/skills/haus-workflow/references/new.md +116 -23
- package/package.json +2 -1
|
@@ -29,7 +29,7 @@ repo's files. The short legacy aliases still work but the names below are canoni
|
|
|
29
29
|
| `project:reinit` (`reinit`, `re-init`) | _Reinit procedure below_ | project | **Full re-setup.** Removes all haus-managed project files (backed up first, user content preserved), then re-runs `project:init` from scratch |
|
|
30
30
|
| `project:clone [name]` (`clone`) | _Clone procedure below_ | project | With a `name`: find & clone one repo by name from GitHub. No name: asks single-repo-vs-workspace first, then either mode — workspace mode clones from `repos.manifest.json` |
|
|
31
31
|
| `project:cloneandsetup [name]` (`cloneandsetup`) | _Clone & setup procedure below_ | project | Run `project:clone`, then set up each repo for local dev — deps, databases, cross-repo links, and env — via each repo's `.haus-workflow/localdev.yml` (+ the workspace's order/links/env) |
|
|
32
|
-
| `project:new [
|
|
32
|
+
| `project:new [description]` (`new`, `create`) | _New-project procedure below_ | project | Create a **brand-new** project from a plain-language request: elicit features, pick the stack (any — registry stacks use the haus new rails), scaffold, git + GitHub repo, full init, then build a walking skeleton — all in one session |
|
|
33
33
|
| `project:add-skills` (`add-skills`, `opt-in`) | _Add-skills procedure below_ | project | Add optional skills, agents, or config (ESLint/Prettier) to an already-set-up project without re-running full setup |
|
|
34
34
|
| `project:refresh` (`apply`, `refresh`, `claude-md`, `regenerate`) | _Refresh procedure below_ | project | **Full non-destructive sync.** Updates the haus package + catalog first, then re-runs `project:init`'s pipeline in place — nothing is removed up front; new catalog items get added, changed ones updated, and anything removed upstream gets pruned by `apply`'s existing orphan-pruning |
|
|
35
35
|
| `project:doctor` (`doctor`, `check`) | `haus doctor` | project | Check for install drift |
|
|
@@ -57,8 +57,8 @@ Question 1: "What would you like to do?"
|
|
|
57
57
|
Options:
|
|
58
58
|
1. [project] project:init — add haus to an existing project for the first time
|
|
59
59
|
(AI skills + commands + workflow into a repo you already have, then a deep read to write the CLAUDE.md docs body + docs/)
|
|
60
|
-
2. [project] project:new [
|
|
61
|
-
(
|
|
60
|
+
2. [project] project:new [description] — create a brand-new project from a plain-language request
|
|
61
|
+
(elicit features, pick any stack, scaffold, git + GitHub repo, full init, then build a walking skeleton)
|
|
62
62
|
3. [project] project:refresh — full non-destructive sync with the latest haus
|
|
63
63
|
(updates the haus package + catalog, then re-runs setup in place — nothing removed first)
|
|
64
64
|
4. [—] More options — see: project:clone, project:cloneandsetup, project:add-skills, and 7 more
|
|
@@ -109,7 +109,7 @@ Run the mapped command via Bash. Quote the exact command you are running before
|
|
|
109
109
|
|
|
110
110
|
**Exception — `project:cloneandsetup` (`cloneandsetup`):** clone followed by a per-repo setup pass, with confirmations. Skip to **Clone & setup (`project:cloneandsetup`)** under Step 3 and follow it.
|
|
111
111
|
|
|
112
|
-
**Exception — `project:new` (`new` / `create`):**
|
|
112
|
+
**Exception — `project:new` (`new` / `create`):** a multi-phase AI-driven procedure — elicits the request via `AskUserQuestion`, picks the stack itself, scaffolds (registry rails or a user-confirmed official scaffolder), then builds a walking skeleton. Skip to **New project (`project:new`)** under Step 3 and follow it.
|
|
113
113
|
|
|
114
114
|
**Exception — `project:add-skills` (`add-skills` / `opt-in`):** a short scan → recommend → choose → apply procedure. Skip to **Add optional skills (`project:add-skills`)** under Step 3 and follow it.
|
|
115
115
|
|
|
@@ -171,7 +171,7 @@ upstream gets pruned automatically by `apply`'s existing orphan-pruning.
|
|
|
171
171
|
|
|
172
172
|
### New project (`project:new`)
|
|
173
173
|
|
|
174
|
-
1. Open and follow `references/new.md` in this skill's directory. It
|
|
174
|
+
1. Open and follow `references/new.md` in this skill's directory. It is a seven-phase AI-driven flow: elicit the request and propose features, gate on user intent, scaffold (registry stacks via `haus new --json --yes` with a `--dry-run` preview; any other stack via a user-confirmed official scaffolder plus manual rails), install context via `haus init`, seed `docs/SPEC.md` + `docs/plans/walking-skeleton.md`, build the walking skeleton with one subagent per feature, and verify (build + lint + tests + smoke boot). Failure `detail` is relayed verbatim and nothing is ever auto-deleted. Never run bare interactive `haus new`.
|
|
175
175
|
|
|
176
176
|
### Add optional skills (`project:add-skills`)
|
|
177
177
|
|
|
@@ -1,24 +1,117 @@
|
|
|
1
|
-
# project:new — create a new project
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
1
|
+
# project:new — create a new project (AI-driven)
|
|
2
|
+
|
|
3
|
+
You own the decisions (stack, features, code); `haus` owns the rails (git/GitHub
|
|
4
|
+
mechanics, safety gates, context install). The registry is the fast path, not a
|
|
5
|
+
boundary — any stack this machine can scaffold works. The full flow runs in THIS
|
|
6
|
+
session, from request to running app.
|
|
7
|
+
|
|
8
|
+
NEVER run bare `haus new` without flags — its interactive prompts don't work through
|
|
9
|
+
the agent; collect answers with AskUserQuestion and pass everything as flags.
|
|
10
|
+
|
|
11
|
+
## Phase 0 — Entry
|
|
12
|
+
|
|
13
|
+
A description argument ("a frontend app for shopping") goes straight to Phase 1.
|
|
14
|
+
No-argument invocation: ask "What do you want to build?" as free text. Do not present
|
|
15
|
+
a stack menu.
|
|
16
|
+
|
|
17
|
+
## Phase 1 — Elicit (at most 5 AskUserQuestion rounds)
|
|
18
|
+
|
|
19
|
+
Ask about dimensions, never from a domain template:
|
|
20
|
+
|
|
21
|
+
1. Purpose — only if not given at entry.
|
|
22
|
+
2. Features — propose a domain-typical list for the stated purpose yourself (e.g.
|
|
23
|
+
shopping → cart, product pages, login, checkout, search); the user multi-selects
|
|
24
|
+
and may add their own. Generate this list per request; it is never enumerated here.
|
|
25
|
+
3. Auth (none / simple / provider) and data (mocked / real DB / external API).
|
|
26
|
+
4. Practicals: project name (lowercase letters, digits, `. _ -`), GitHub org (default:
|
|
27
|
+
WeAreHausTech; "personal" = omit `--org`), visibility (private default / public),
|
|
28
|
+
create the GitHub repo at all (default yes).
|
|
29
|
+
|
|
30
|
+
Pick the stack yourself from the answers. Confirm the stack with the user only on
|
|
31
|
+
genuine ambiguity (e.g. web vs native unclear).
|
|
32
|
+
|
|
33
|
+
## Phase 2 — Intent gate
|
|
34
|
+
|
|
35
|
+
Present: chosen stack + why, selected features, what gets mocked, walking-skeleton
|
|
36
|
+
depth (every feature wired end-to-end but minimal), and that the skeleton will be
|
|
37
|
+
committed to `main` in the new repo and pushed to the remote if one is created. Get
|
|
38
|
+
ONE explicit user OK before anything touches disk — this one approval covers those
|
|
39
|
+
actions.
|
|
40
|
+
|
|
41
|
+
## Phase 3 — Scaffold
|
|
42
|
+
|
|
43
|
+
Check the registry first: `haus new --list --json`.
|
|
44
|
+
|
|
45
|
+
**Stack in the registry (fast path):**
|
|
46
|
+
|
|
47
|
+
1. Preview:
|
|
14
48
|
`haus new <stack> <name> --json --yes --dry-run [--org <org>] [--public] [--no-github]`
|
|
15
|
-
and show the
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
- `ok: false` → report the failed step's `detail` verbatim — it contains the
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
49
|
+
and show the planned steps in plain language. Phase 2's approval already covers
|
|
50
|
+
running this for real — no further confirmation needed.
|
|
51
|
+
2. Execute the same command without `--dry-run`. Parse the JSON:
|
|
52
|
+
- `ok: true` → note project path, repo URL, and `installHint`.
|
|
53
|
+
- `ok: false` → report the failed step's `detail` verbatim — it contains the exact
|
|
54
|
+
resume commands. Do NOT retry destructively; the project directory is never
|
|
55
|
+
auto-deleted.
|
|
56
|
+
|
|
57
|
+
**Stack not in the registry:**
|
|
58
|
+
|
|
59
|
+
1. Toolchain preflight: check the binaries the scaffolder needs actually exist;
|
|
60
|
+
report anything missing instead of failing mid-flow.
|
|
61
|
+
2. Show the exact official-scaffolder command; the user confirms; execute it.
|
|
62
|
+
3. Manual rails: `git init` (if the scaffolder didn't), `git branch -M main`, initial
|
|
63
|
+
commit; then `gh repo create` (confirm first) unless the user declined a repo.
|
|
64
|
+
|
|
65
|
+
## Phase 4 — Context install
|
|
66
|
+
|
|
67
|
+
Everything from here on runs inside the new project directory — `cd` into it first and
|
|
68
|
+
stay there.
|
|
69
|
+
|
|
70
|
+
- Fast path: the chained `haus init` inside `haus new` already ran — go to seeding.
|
|
71
|
+
- Manual path:
|
|
72
|
+
- Read: run `haus init --json --dry-run` and read the envelope yourself.
|
|
73
|
+
- If it refuses with the zero-signal message — literally zero catalog items matched,
|
|
74
|
+
not merely an unknown stack (catalog defaults normally still match, so most tier-3
|
|
75
|
+
projects write fine without `--force`) — tell the user plainly: "no stack-specific
|
|
76
|
+
assets in the catalog; installing workflow defaults." Confirm with the user, then
|
|
77
|
+
re-run `haus init --json --dry-run --force`.
|
|
78
|
+
- Write: run `haus apply --write`.
|
|
79
|
+
- Guard: NEVER run write-mode `haus init` (i.e. `haus init` without `--json
|
|
80
|
+
--dry-run`) — it prompts for confirmation, and an agent's non-answer means nothing
|
|
81
|
+
is written despite exit 0.
|
|
82
|
+
- Seeding: write the elicited requirements into the project as `docs/SPEC.md`
|
|
83
|
+
(purpose, features, auth/data choices, what is mocked) and
|
|
84
|
+
`docs/plans/walking-skeleton.md` (one task per selected feature with acceptance
|
|
85
|
+
criteria and a verify command).
|
|
86
|
+
|
|
87
|
+
## Phase 5 — Build the walking skeleton
|
|
88
|
+
|
|
89
|
+
1. Install dependencies: run the install command for the chosen package manager (fast
|
|
90
|
+
path: the `installHint` from the JSON — it does not exist off-registry). The test
|
|
91
|
+
loop needs them installed either way.
|
|
92
|
+
2. Read the new project's `CLAUDE.md` and `.haus-workflow/WORKFLOW.md`; they are
|
|
93
|
+
authoritative from here on.
|
|
94
|
+
3. Per selected feature: dispatch one subagent per feature with a self-contained
|
|
95
|
+
prompt (spec excerpt, file paths, verify command); it builds the feature end-to-end
|
|
96
|
+
but minimal — pages/routes/models/navigation wired, core logic TDD-tested — and
|
|
97
|
+
makes one conventional commit on `main`. Not production-complete — a base to
|
|
98
|
+
iterate on. This session orchestrates only.
|
|
99
|
+
|
|
100
|
+
Committing to `main` is a deliberate, narrow exception to the NEVER-work-on-main
|
|
101
|
+
rule: it applies only to a freshly created single-author repo during this initial
|
|
102
|
+
walking-skeleton build; standard branch rules apply afterwards.
|
|
103
|
+
|
|
104
|
+
## Phase 6 — Verify + hand off
|
|
105
|
+
|
|
106
|
+
1. Gate: build passes, lint passes, tests green, dev server boots (smoke check).
|
|
107
|
+
Record the results in `docs/plans/walking-skeleton.md`'s verification blocks.
|
|
108
|
+
2. Push to the remote (if a repo was created).
|
|
109
|
+
3. Summarize: what exists, what is mocked, where the spec and plan live, and the
|
|
110
|
+
suggested next step — iterate per feature in fresh sessions inside the project
|
|
111
|
+
directory.
|
|
112
|
+
|
|
113
|
+
## Failure rules
|
|
114
|
+
|
|
115
|
+
- Relay `haus` failure `detail` verbatim; never retry destructively; the project
|
|
116
|
+
directory is never auto-deleted — the same rules apply on the manual path.
|
|
117
|
+
- 3 failed verifications on one build task → stop and ask the user.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@haus-tech/haus-workflow",
|
|
3
|
-
"version": "4.0
|
|
3
|
+
"version": "4.1.0",
|
|
4
4
|
"description": "Haus AI workflow CLI for Claude Code.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -50,6 +50,7 @@
|
|
|
50
50
|
"fast-glob": "3.3.3",
|
|
51
51
|
"fs-extra": "11.4.0",
|
|
52
52
|
"semver": "7.8.5",
|
|
53
|
+
"tar": "7.5.22",
|
|
53
54
|
"yaml": "2.9.0"
|
|
54
55
|
},
|
|
55
56
|
"devDependencies": {
|