create-issflow 1.7.0 → 1.8.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 +6 -6
- package/bin/cli.js +12 -17
- package/package.json +1 -1
- package/template/.claude/commands/change-request.md +35 -14
- package/template/.claude/commands/design.md +51 -0
- package/template/.claude/commands/log-issue.md +3 -0
- package/template/.claude/commands/overview.md +10 -3
- package/template/.claude/commands/phase.md +10 -0
- package/template/.claude/commands/propose.md +49 -18
- package/template/.claude/commands/release.md +13 -4
- package/template/.claude/commands/support.md +43 -0
- package/template/.claude/istartsoft-flow/METHODOLOGY.md +73 -24
- package/template/.claude/skills/support-triage/SKILL.md +40 -0
- package/template/.claude/skills/ux-design/SKILL.md +8 -3
- package/template/.claude/templates/ARCHITECTURE-template.md +53 -0
- package/template/.claude/templates/CR-template.md +34 -0
- package/template/.claude/templates/UX-PACK-template.md +37 -0
- package/template/.claude/templates/proposal.html +2 -1
package/README.md
CHANGED
|
@@ -7,14 +7,14 @@ and tool-agnostic. Non-destructive: it never overwrites your files.
|
|
|
7
7
|
|
|
8
8
|
```bash
|
|
9
9
|
cd my-project
|
|
10
|
-
npx create-issflow #
|
|
11
|
-
npx create-issflow --tool=
|
|
12
|
-
# then open your tool
|
|
10
|
+
npx create-issflow # omit --tool = install EVERY adapter
|
|
11
|
+
npx create-issflow --tool=cursor # claude | codex | cursor | gemini | aider | all
|
|
12
|
+
# then open your tool and run:
|
|
13
13
|
/overview # bootstrap the project
|
|
14
14
|
```
|
|
15
15
|
|
|
16
16
|
Flags:
|
|
17
|
-
- `--tool=<name>` — pick the target tool
|
|
17
|
+
- `--tool=<name>` — pick the target tool. **Omit = `all`** (every adapter).
|
|
18
18
|
- `--ci` — also write `.github/workflows/issflow-feature.yml` (headless `/feature`
|
|
19
19
|
via GitHub Actions: label an issue `feature:approved` → the lane runs).
|
|
20
20
|
- `--docker` — also write `Dockerfile.issflow` + `scripts/feature-docker.js`
|
|
@@ -36,15 +36,15 @@ The portable kit (every tool) in `<project>/.claude/`:
|
|
|
36
36
|
- `hooks/` — session-start · context-guard · plan-gate (rule-13 enforcement) · pre-compact · subagent-stop · feature-gate (Stop gate for `/feature`, artifact-verified)
|
|
37
37
|
- `istartsoft-flow/METHODOLOGY.md` — the full methodology (single source of truth)
|
|
38
38
|
|
|
39
|
-
Plus a root
|
|
39
|
+
Plus a root **`AGENTS.md`** (open standard — primary entry) and the per-tool adapter:
|
|
40
40
|
|
|
41
41
|
| Tool | Adds |
|
|
42
42
|
|------|------|
|
|
43
|
-
| `claude` | merges hooks into `.claude/settings.json` |
|
|
44
43
|
| `codex` | nothing extra — `AGENTS.md` is read natively |
|
|
45
44
|
| `cursor` | `.cursor/rules/` + `.cursor/commands/` + `.cursor/hooks.json` |
|
|
46
45
|
| `gemini` | `GEMINI.md` pointer |
|
|
47
46
|
| `aider` | `.aider.conf.yml` that loads the methodology |
|
|
47
|
+
| `claude` | thin `CLAUDE.md` (`@AGENTS.md`) + merges hooks into `.claude/settings.json` |
|
|
48
48
|
| `all` | every adapter above |
|
|
49
49
|
|
|
50
50
|
It also un-ignores the workflow dirs in `.gitignore` if `.claude/*` was ignored.
|
package/bin/cli.js
CHANGED
|
@@ -40,7 +40,7 @@ function printHelp() {
|
|
|
40
40
|
|
|
41
41
|
Usage: npx create-issflow [--tool=<name>] [--dry-run] [--force]
|
|
42
42
|
|
|
43
|
-
Tools (--tool
|
|
43
|
+
Tools (--tool=). Omit --tool to install EVERY adapter (same as --tool=all):`);
|
|
44
44
|
for (const [k, v] of Object.entries(TOOLS)) log(` ${k.padEnd(7)} ${v}`);
|
|
45
45
|
log(`
|
|
46
46
|
Flags:
|
|
@@ -51,27 +51,22 @@ Flags:
|
|
|
51
51
|
-h, --help this message
|
|
52
52
|
|
|
53
53
|
Every tool installs the portable kit in .claude/ + a root AGENTS.md (the open
|
|
54
|
-
standard). The full methodology lives in
|
|
54
|
+
standard — primary entry for most hosts). The full methodology lives in
|
|
55
|
+
.claude/istartsoft-flow/METHODOLOGY.md. Claude Code also gets a thin CLAUDE.md
|
|
56
|
+
shim (@AGENTS.md) because that host only auto-loads CLAUDE.md.`);
|
|
55
57
|
}
|
|
56
58
|
|
|
57
|
-
//
|
|
59
|
+
// Typo / alias map → canonical TOOLS key
|
|
60
|
+
const TOOL_ALIASES = { cusor: 'cursor' };
|
|
61
|
+
|
|
62
|
+
// Resolve the target tool: --tool= flag → default 'all' when omitted.
|
|
58
63
|
function pickTool() {
|
|
59
64
|
if (toolArg) {
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
if (process.stdin.isTTY && process.stdout.isTTY && !DRY) {
|
|
64
|
-
const keys = Object.keys(TOOLS);
|
|
65
|
-
process.stdout.write('\nWhich AI coding tool? (the kit is portable — pick your primary)\n');
|
|
66
|
-
keys.forEach((k, i) => process.stdout.write(` ${i + 1}) ${k} — ${TOOLS[k]}\n`));
|
|
67
|
-
process.stdout.write('> ');
|
|
68
|
-
let line = '';
|
|
69
|
-
try { line = (fs.readFileSync(0, 'utf8').split('\n')[0] || '').trim().toLowerCase(); } catch (_) {}
|
|
70
|
-
const chosen = TOOLS[line] ? line : keys[parseInt(line, 10) - 1];
|
|
71
|
-
if (!chosen) { console.error('create-issflow: no valid choice; defaulting to claude.'); return 'claude'; }
|
|
72
|
-
return chosen;
|
|
65
|
+
const key = TOOL_ALIASES[toolArg] || toolArg;
|
|
66
|
+
if (!TOOLS[key]) { console.error(`create-issflow: unknown --tool=${toolArg}. One of: ${Object.keys(TOOLS).join(', ')}`); process.exit(1); }
|
|
67
|
+
return key;
|
|
73
68
|
}
|
|
74
|
-
return '
|
|
69
|
+
return 'all'; // omit --tool = every adapter
|
|
75
70
|
}
|
|
76
71
|
|
|
77
72
|
// write a single file, non-destructive (honors DRY/FORCE).
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "create-issflow",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.8.0",
|
|
4
4
|
"description": "Scaffold the iStartSoftFlow AI-coding workflow into a project. Stack-agnostic, tool-agnostic (Claude Code, Codex, Cursor, Gemini, Aider), non-destructive.",
|
|
5
5
|
"bin": {
|
|
6
6
|
"create-issflow": "bin/cli.js"
|
|
@@ -33,36 +33,57 @@ Is this an in-scope **clarification** (no cost change) or a real **scope change*
|
|
|
33
33
|
(add / remove / alter)? Clarification -> log it, proceed, no re-price. Scope change
|
|
34
34
|
-> continue.
|
|
35
35
|
|
|
36
|
+
Also classify commercial lane:
|
|
37
|
+
- **Warranty / defect** (bug vs approved scope, inside support window) → prefer
|
|
38
|
+
`/support` or `/quick` — not a billable CR unless the client expands scope.
|
|
39
|
+
- **Billable CR** → continue below.
|
|
40
|
+
|
|
36
41
|
## STEP 2 — IMPACT ANALYSIS
|
|
37
42
|
Determine:
|
|
38
43
|
- phases affected — **done phases are frozen** (their cost is already spent and
|
|
39
44
|
counts); new / changed phases; cut phases (credit back the un-started effort).
|
|
40
|
-
- knock-on effects — architecture, **security (re-threat-model?)**,
|
|
45
|
+
- knock-on effects — architecture, **UX pack**, **security (re-threat-model?)**,
|
|
46
|
+
tests, timeline. If UX or arch artifacts change, those gates re-open (rule 15).
|
|
41
47
|
- dispatch `researcher` (DESIGN or IMPL) if the change needs grounding in facts.
|
|
42
48
|
|
|
43
|
-
## STEP 3 — RE-ESTIMATE (the DELTA only
|
|
44
|
-
-
|
|
45
|
-
contingency)
|
|
49
|
+
## STEP 3 — RE-ESTIMATE (the DELTA only)
|
|
50
|
+
- Reuse the SAME estimation config used for the approved proposal’s **internal**
|
|
51
|
+
math (unit, rate card, currency, contingency) if still available in a private
|
|
52
|
+
estimate memo or chat-recorded answers.
|
|
53
|
+
- If rate / contingency is missing → **ASK once** (same rule as `/propose`). Never
|
|
54
|
+
invent a kit default rate; never commit personal rates into public kit files.
|
|
46
55
|
- added effort × rate = added cost; cut effort = credit.
|
|
47
|
-
- **net cost Δ** + **new total** vs the approved baseline — as a range
|
|
56
|
+
- **net cost Δ** + **new total** vs the approved baseline — as a range.
|
|
57
|
+
- Show rate math **in chat to the human only**.
|
|
48
58
|
- **timeline Δ**. State what stays the SAME so the client sees the price is fair.
|
|
49
59
|
|
|
50
|
-
|
|
60
|
+
### CLIENT-DOC RULE
|
|
61
|
+
Anything the client sees (CR summary, updated PROPOSAL.md / proposal.html) shows
|
|
62
|
+
**Δ cost + new total** (and effort/timeline) only — **never** rate, rate card, or
|
|
63
|
+
contingency %.
|
|
64
|
+
|
|
65
|
+
## STEP 4 — LOG the change order
|
|
66
|
+
1. Append a one-line summary to `docs/CHANGES.md` (append-only):
|
|
51
67
|
```
|
|
52
68
|
CR-<n> | <date> | <change> | impact: <phases> | effort Δ: <±days> |
|
|
53
69
|
cost Δ: <±amount> | new total: <amount> | status: proposed
|
|
54
70
|
```
|
|
71
|
+
2. Fill `.claude/templates/CR-template.md` → `docs/changes/CR-<n>.md` (detail:
|
|
72
|
+
classification, impact, Δ cost, warranty vs billable, status). Keep the detail
|
|
73
|
+
file client-safe on money fields (totals only).
|
|
55
74
|
|
|
56
75
|
## STEP 5 — APPROVAL GATE
|
|
57
|
-
Show me CR-<n> (impact + price delta + new total). **STOP for approval**
|
|
58
|
-
gate — always interactive).
|
|
76
|
+
Show me CR-<n> (impact + price delta + new total — no rate). **STOP for approval**
|
|
77
|
+
(commercial gate — always interactive).
|
|
59
78
|
- **Approved** -> set CR status `approved`; bump PROPOSAL.md to a new version (vN+1)
|
|
60
|
-
with the delta folded in; re-render `docs/proposal.html` from it
|
|
61
|
-
language); then dispatch `/replan` to
|
|
62
|
-
phases stay frozen). Update STATE.md.
|
|
63
|
-
`> Approval: PENDING` and re-runs the
|
|
64
|
-
|
|
65
|
-
`/sprint` stay blocked until you also
|
|
79
|
+
with the delta folded in (**totals only**); re-render `docs/proposal.html` from it
|
|
80
|
+
(same template + language; no contingency note / rate); then dispatch `/replan` to
|
|
81
|
+
apply the phase changes to PLAN.md (done phases stay frozen). Update STATE.md.
|
|
82
|
+
NOTE: `/replan` reverts PLAN.md to `> Approval: PENDING` and re-runs the
|
|
83
|
+
PLAN-APPROVAL gate (hard rule 13) — the commercial CR sign-off is SEPARATE from
|
|
84
|
+
the plan sign-off, so `/phase` and `/sprint` stay blocked until you also
|
|
85
|
+
re-approve the revised plan. If UX/arch scope changed, reset `design:` /
|
|
86
|
+
`architecture:` in STATE to PENDING (rule 15) before build resumes.
|
|
66
87
|
- **Rejected** -> set CR status `rejected`; PLAN + PROPOSAL unchanged.
|
|
67
88
|
|
|
68
89
|
## STEP 6 — RECORD
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Post-proposal DESIGN + ARCHITECTURE gates — produce UX pack and architecture note, stop for human approve before /phase (hard rule 15).
|
|
3
|
+
argument-hint: [optional: "ux" | "arch" | "both" · "dry-run"]
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Caveman ULTRA mode. You are the ORCHESTRATOR.
|
|
7
|
+
|
|
8
|
+
Purpose: after a **client proposal is signed** (or when the project opts into these
|
|
9
|
+
gates), produce build-ready design + architecture artifacts and get human approve
|
|
10
|
+
**before** `/phase` runs. Vertical slices still build UX+code together — these gates
|
|
11
|
+
lock the *frame* first (model B).
|
|
12
|
+
|
|
13
|
+
DRY-RUN: if `$ARGUMENTS` contains `dry-run`/`--dry-run`, outline what you'd write
|
|
14
|
+
and STOP. Write nothing.
|
|
15
|
+
|
|
16
|
+
## PRE-FLIGHT
|
|
17
|
+
- Read `docs/OVERVIEW.md`, `docs/PLAN.md`, `docs/PROPOSAL.md` (if any), `docs/STATE.md`.
|
|
18
|
+
- PLAN must be approved (rule 13). If a proposal exists for quoted work, it should
|
|
19
|
+
be signed off first (`/propose`) — otherwise warn and confirm they want design
|
|
20
|
+
gates without a commercial proposal (internal projects may skip `/propose` and
|
|
21
|
+
still run `/design`, or skip rule 15 entirely when STATE has `design: n/a` and
|
|
22
|
+
`architecture: n/a` set deliberately for non-quoted work).
|
|
23
|
+
|
|
24
|
+
Target: `$ARGUMENTS` → `ux` | `arch` | `both` (default **both**).
|
|
25
|
+
|
|
26
|
+
## STEP 1 — UX PACK (if ux|both)
|
|
27
|
+
1. Apply `ux-design` skill (authoring mode): wireframe baseline + cookbook direction.
|
|
28
|
+
2. Scaffold or update `docs/UX-PACK.md` from `.claude/templates/UX-PACK-template.md`.
|
|
29
|
+
3. Fill flows, screen inventory, tokens/frame, a11y notes from OVERVIEW + PLAN.
|
|
30
|
+
4. SHOW me UX-PACK.md. **STOP for approval.**
|
|
31
|
+
5. On approve: stamp `> Approval: approved <date> v<n>`; set `design: approved <date>`
|
|
32
|
+
in STATE.md; HISTORY line `design v<n> approved`.
|
|
33
|
+
6. On change request: revise and re-show; header stays PENDING.
|
|
34
|
+
|
|
35
|
+
## STEP 2 — ARCHITECTURE (if arch|both)
|
|
36
|
+
1. Dispatch `researcher` (DESIGN) only if open unknowns remain; else use OVERVIEW.
|
|
37
|
+
2. Scaffold or update `docs/ARCHITECTURE.md` from
|
|
38
|
+
`.claude/templates/ARCHITECTURE-template.md`.
|
|
39
|
+
3. Apply `code-standards` architecture guidance; security trust boundaries via
|
|
40
|
+
`security` skill when relevant.
|
|
41
|
+
4. SHOW me ARCHITECTURE.md. **STOP for approval.**
|
|
42
|
+
5. On approve: stamp header; set `architecture: approved <date>` in STATE.md;
|
|
43
|
+
HISTORY line `architecture v<n> approved`. Optionally `/log-decision` for
|
|
44
|
+
material pattern choices.
|
|
45
|
+
6. On change request: revise and re-show.
|
|
46
|
+
|
|
47
|
+
## STEP 3 — HANDOFF
|
|
48
|
+
When both required gates are approved (or N/A for internal skip):
|
|
49
|
+
- Tell me `/phase` is unblocked for rule 15.
|
|
50
|
+
- Reminder: frontend phases still run the `ux-design` CLOSE check (rule 9);
|
|
51
|
+
architecture drift still needs `/log-decision` (rule 8).
|
|
@@ -13,6 +13,8 @@ Canonical format:
|
|
|
13
13
|
### <short error title — searchable, literal error keywords>
|
|
14
14
|
|
|
15
15
|
- [ ] open (or “- [x] resolved” once fixed)
|
|
16
|
+
- severity: P1 | P2 | P3 (optional; required when filed via /support)
|
|
17
|
+
- commercial: warranty | billable | n/a
|
|
16
18
|
- symptom: <what was observed>
|
|
17
19
|
- root cause: <the REAL underlying cause>
|
|
18
20
|
- solution: <exact fix, or “pending”>
|
|
@@ -26,5 +28,6 @@ Rules:
|
|
|
26
28
|
- open issues use the empty box `- [ ]`; resolved are checked `- [x] resolved`
|
|
27
29
|
(the SessionStart hook surfaces every `- [ ]` as open — keep the box empty until fixed).
|
|
28
30
|
- open issues go at the TOP; resolved below; archived oldest at bottom.
|
|
31
|
+
- For after-go-live tickets prefer `/support` first (triage), then this log.
|
|
29
32
|
|
|
30
33
|
Confirm the entry back in 2 lines.
|
|
@@ -104,10 +104,14 @@ proceeds to the planner. (This is the planning confirmation gate.)
|
|
|
104
104
|
|
|
105
105
|
phase: 0 (pending)
|
|
106
106
|
plan: PENDING
|
|
107
|
+
design: PENDING
|
|
108
|
+
architecture: PENDING
|
|
107
109
|
completed: project bootstrapped — design research done, double grill done
|
|
108
110
|
blocker: none
|
|
109
111
|
|
|
110
112
|
```
|
|
113
|
+
(For internal non-quoted work you may set `design: n/a` and `architecture: n/a`
|
|
114
|
+
instead of PENDING so rule 15 does not block `/phase`.)
|
|
111
115
|
8. Create docs/ISSUES.md with header `# Issues` and `## Archived` section.
|
|
112
116
|
|
|
113
117
|
9. Create empty docs/HISTORY.md.
|
|
@@ -138,6 +142,9 @@ blocker: none
|
|
|
138
142
|
|
|
139
143
|
AUTO governs the development loop that runs AFTER this gate, never the gate itself.
|
|
140
144
|
|
|
141
|
-
Optional next
|
|
142
|
-
|
|
143
|
-
|
|
145
|
+
Optional next steps (client / quoted work):
|
|
146
|
+
1. `/propose` — proposal + estimate (asks rate in chat; client docs stay totals-only).
|
|
147
|
+
2. `/design` — UX pack + architecture approve gates (hard rule 15) before `/phase`.
|
|
148
|
+
|
|
149
|
+
Internal or personal projects may skip `/propose` and set `design: n/a` /
|
|
150
|
+
`architecture: n/a` in STATE, then go to `/phase`.
|
|
@@ -29,6 +29,16 @@ a. PLAN-APPROVAL CHECK (hard rule 13): Read the docs/PLAN.md `> Approval:` heade
|
|
|
29
29
|
start. Route me to the `/overview` PLAN-APPROVAL gate (or `/replan` then re-approve).
|
|
30
30
|
Approved -> continue.
|
|
31
31
|
|
|
32
|
+
a2. DESIGN + ARCHITECTURE GATES (hard rule 15): Read `docs/STATE.md` for `design:`
|
|
33
|
+
and `architecture:`.
|
|
34
|
+
- Quoted / client work (approved `docs/PROPOSAL.md` exists): both must read
|
|
35
|
+
`approved <date>` (or explicit `n/a` only if the human waived the gate in
|
|
36
|
+
writing). Still PENDING / missing -> STOP. Route me to `/design`.
|
|
37
|
+
- Internal / no proposal: if STATE has `design: n/a` and `architecture: n/a`,
|
|
38
|
+
continue; if fields are missing, treat as n/a once (set them) unless OVERVIEW
|
|
39
|
+
opted into the gates.
|
|
40
|
+
Approved / n/a -> continue.
|
|
41
|
+
|
|
32
42
|
b. INFRA CHECK (phases > 0): Read the declared infra in docs/OVERVIEW.md.
|
|
33
43
|
- Managed infra -> confirm it is reachable; no provisioning step is needed.
|
|
34
44
|
- Self-managed infra -> confirm Phase 0 (infra) ran and is healthy.
|
|
@@ -34,18 +34,37 @@ Derive the vertical-slice phases (or read `docs/PLAN.md` if it exists). Size eac
|
|
|
34
34
|
- effort: an ideal-days RANGE (e.g. 2–3d), + story points if your team uses them
|
|
35
35
|
- risk / unknowns: what could move the estimate
|
|
36
36
|
|
|
37
|
-
## STEP 3 — ESTIMATE (
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
37
|
+
## STEP 3 — ESTIMATE (ask rate · never invent a kit default)
|
|
38
|
+
Estimation config is **project-private**. The public kit ships **no** default rate
|
|
39
|
+
card and **no** sample salary/rate numbers — rates are confidential.
|
|
40
|
+
|
|
41
|
+
1. Read estimation fields from OVERVIEW **only if the human already put them there
|
|
42
|
+
for this project** (unit, rate card, currency, contingency, milestones, language).
|
|
43
|
+
2. If **rate card** or **contingency** is missing → **ASK once** in chat (commercial
|
|
44
|
+
input, allowed). Do not guess. Do not copy rates from other repos or prior chats
|
|
45
|
+
into kit files.
|
|
46
|
+
3. Optional: store the answered rate/contingency in a **project-local** file the
|
|
47
|
+
team keeps private (e.g. `docs/ESTIMATE.local.md` gitignored, or OVERVIEW fields
|
|
48
|
+
that never get published). Never commit personal rate/salary into a public kit
|
|
49
|
+
or template.
|
|
50
|
+
4. Configurable fields (ask or read — no invented kit defaults for money):
|
|
51
|
+
- **unit:** ideal-days | hours | story-points | both
|
|
52
|
+
- **rate card:** blended OR per-role (senior / mid / junior…)
|
|
53
|
+
- **currency:** as declared (ask if unset; THB is common for Thai clients)
|
|
54
|
+
- **contingency:** % buffer for unknowns (ask if unset)
|
|
55
|
+
- **payment milestones:** by-phase, split (e.g. 30/40/30), or none
|
|
56
|
+
- **language:** rendered doc language (default = project language)
|
|
57
|
+
|
|
58
|
+
Compute cost per phase, then a **Total as a RANGE (low–high)** that already folds
|
|
59
|
+
in contingency. Show the math **in chat to the human** (rate × effort + contingency).
|
|
60
|
+
**Timeline:** phases in dependency order → calendar estimate (note parallelism).
|
|
61
|
+
|
|
62
|
+
### CLIENT-DOC RULE (hard — commercial privacy)
|
|
63
|
+
Client-facing artifacts (`docs/PROPOSAL.md` client sections, `docs/proposal.html`,
|
|
64
|
+
and any PDF/print) MUST show **totals and phase costs only**.
|
|
65
|
+
**Never** print: hourly/day rates, rate cards, contingency %, “incl. X% buffer”,
|
|
66
|
+
salary, or the estimate math. Contingency is already inside the numbers — do not
|
|
67
|
+
label it on the client page.
|
|
49
68
|
|
|
50
69
|
## STEP 4 — ASSUMPTIONS & EXCLUSIONS
|
|
51
70
|
List every assumption the estimate rests on (infra provided, third-party/licence
|
|
@@ -54,29 +73,41 @@ change-orders re-price against.
|
|
|
54
73
|
|
|
55
74
|
## STEP 5 — WRITE + RENDER
|
|
56
75
|
1. Write `docs/PROPOSAL.md` — the SOURCE OF TRUTH (versioned v1 + date). This is
|
|
57
|
-
what `CHANGES.md` re-prices against.
|
|
76
|
+
what `CHANGES.md` re-prices against. **Client-safe** body (no rate / no
|
|
77
|
+
contingency %):
|
|
58
78
|
```
|
|
59
79
|
# Proposal — <project> (v1, <date>)
|
|
60
80
|
## Scope — in-scope: … | out-of-scope: …
|
|
61
81
|
## Phases — table: phase | complexity | effort (range) | cost
|
|
62
|
-
## Total — <low>–<high>
|
|
82
|
+
## Total — <low>–<high> ← totals only; no “incl. X% contingency”
|
|
63
83
|
## Timeline — <estimate>, dependency order
|
|
64
84
|
## Assumptions — …
|
|
65
85
|
## Exclusions — …
|
|
66
86
|
## Payment — milestones (if any)
|
|
67
87
|
## Sign-off — approved by: ___ date: ___ version: v1
|
|
68
88
|
```
|
|
89
|
+
If you keep an internal rate memo, put it in a **separate private** file (not
|
|
90
|
+
the client PROPOSAL.md / HTML). PROPOSAL.md itself stays client-safe so it can
|
|
91
|
+
be shared.
|
|
92
|
+
|
|
69
93
|
2. RENDER a client-facing `docs/proposal.html` from `.claude/templates/proposal.html`:
|
|
70
94
|
copy it, replace every `{{PLACEHOLDER}}`, and fill the CONTENT in the declared
|
|
71
95
|
language (the section labels are already bilingual TH / EN). It must fit ONE A4
|
|
72
96
|
page — be terse (≈ 3–6 phase rows, ≈ 4 assumptions, short scope items); trim before
|
|
73
97
|
it spills to a second page. Fill `{{COMPANY}}` / `{{COMPANY_TAGLINE}}` / `{{LOGO}}`
|
|
74
98
|
from the ISSUING company's brand declared in OVERVIEW (or ask once) — white-label,
|
|
75
|
-
never hardcode the kit's name.
|
|
76
|
-
|
|
99
|
+
never hardcode the kit's name. Leave `{{TOTAL_NOTE}}` empty or a non-rate line
|
|
100
|
+
(e.g. currency / “ราคารวมทั้งโครงการ”) — **never** a contingency % or rate.
|
|
101
|
+
Print-ready (Ctrl/Cmd-P → A4 → Save as PDF). Keep PROPOSAL.md and proposal.html
|
|
102
|
+
in sync.
|
|
77
103
|
|
|
78
104
|
## STEP 6 — SIGN-OFF GATE
|
|
79
105
|
Show me the proposal. **STOP for approval** (commercial gate — always interactive).
|
|
80
106
|
On approval: record the approved version + date in PROPOSAL.md and STATE.md, and
|
|
81
|
-
append a HISTORY line `proposal v<n> approved (<total>)`.
|
|
82
|
-
|
|
107
|
+
append a HISTORY line `proposal v<n> approved (<total>)`.
|
|
108
|
+
|
|
109
|
+
**Next (quoted / client work):** before `/phase`, run the **DESIGN + ARCHITECTURE
|
|
110
|
+
gates** (METHODOLOGY lifecycle · hard rule 15) — produce `docs/UX-PACK.md` +
|
|
111
|
+
`docs/ARCHITECTURE.md`, get human approve, stamp STATE. Building starts only after
|
|
112
|
+
proposal sign-off **and** those gates (or explicit skip for internal non-quoted
|
|
113
|
+
work). On rejection: revise per feedback and re-show.
|
|
@@ -49,7 +49,16 @@ sign-off** — a release gate, always interactive in both modes.
|
|
|
49
49
|
On a SIGNED sign-off only: deploy to production, smoke-test prod (health 200), update
|
|
50
50
|
`docs/ENDPOINTS.md` base URL, tag the release. HISTORY line: `released v<n> (<date>)`.
|
|
51
51
|
|
|
52
|
-
## STAGE 8 — GO-LIVE & SUPPORT
|
|
53
|
-
Enter after-go-live support
|
|
54
|
-
|
|
55
|
-
|
|
52
|
+
## STAGE 8 — GO-LIVE & SUPPORT (hypercare)
|
|
53
|
+
Enter after-go-live support:
|
|
54
|
+
|
|
55
|
+
1. **Watch** — incidents, error budgets, critical paths; keep `docs/ISSUES.md` live.
|
|
56
|
+
2. **Front door** — route client/prod reports through `/support` (severity P1–P3,
|
|
57
|
+
warranty vs billable). Warranty defects → `/quick` (or larger lane); do not
|
|
58
|
+
silently expand scope for free.
|
|
59
|
+
3. **New scope** → `/change-request` (impact + re-price + sign-off).
|
|
60
|
+
4. **Ops memory** — update `/runbook` when a fix changes operational steps.
|
|
61
|
+
5. Default warranty window if unset: **30 days** from this promote (STATE/HISTORY);
|
|
62
|
+
override from PROPOSAL assumptions when present.
|
|
63
|
+
|
|
64
|
+
The project is live; the loop continues through `/support` and change requests.
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: After-go-live support triage — severity, warranty vs billable CR, hotfix via /quick or route to /change-request. Use for bugs and issues in hypercare / warranty.
|
|
3
|
+
argument-hint: [symptom or ticket summary · "dry-run"]
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
Caveman ULTRA mode. You are the ORCHESTRATOR.
|
|
7
|
+
|
|
8
|
+
Purpose: handle production / post-release issues like a small software house —
|
|
9
|
+
triage first, then fix under warranty or open a billable CR. Issue: $ARGUMENTS
|
|
10
|
+
|
|
11
|
+
DRY-RUN: if `$ARGUMENTS` contains `dry-run`/`--dry-run`, print the triage plan and
|
|
12
|
+
STOP. Log and fix nothing.
|
|
13
|
+
|
|
14
|
+
Apply the `support-triage` skill.
|
|
15
|
+
|
|
16
|
+
## PRE-FLIGHT
|
|
17
|
+
Read `docs/PROPOSAL.md` (warranty / support assumptions if any), `docs/STATE.md`,
|
|
18
|
+
`docs/ISSUES.md`, `docs/RUNBOOK.md` (if present), and recent HISTORY release lines.
|
|
19
|
+
No live release yet → say so; may still log the issue for pre-prod.
|
|
20
|
+
|
|
21
|
+
## STEP 1 — TRIAGE
|
|
22
|
+
Brief-back (rule 14) then classify:
|
|
23
|
+
|
|
24
|
+
| Field | Values |
|
|
25
|
+
|-------|--------|
|
|
26
|
+
| Severity | **P1** (down / data loss / security) · **P2** (major feature broken, workaround) · **P3** (minor / cosmetic) |
|
|
27
|
+
| Type | defect vs approved scope · clarification · **new scope** |
|
|
28
|
+
| Commercial | **warranty** (in support window, defect) · **billable** (out of window or new scope) · **unclear** (ask) |
|
|
29
|
+
|
|
30
|
+
Default warranty window if unset in PROPOSAL/OVERVIEW: **30 days** after production
|
|
31
|
+
promote (`released` HISTORY line). Ask once if the human wants a different window.
|
|
32
|
+
|
|
33
|
+
## STEP 2 — ROUTE
|
|
34
|
+
- **Warranty defect** → `/log-issue` (severity in title/symptom) → fix with `/quick`
|
|
35
|
+
(or `/phase` / `/feature` if phase-worthy — do not dodge TDD via quick for large
|
|
36
|
+
work, rule 10). P1: prioritize; note runbook updates via `/runbook` if ops-related.
|
|
37
|
+
- **Billable / new scope** → `/change-request` (do not silently build free work).
|
|
38
|
+
- **Unclear** → STOP and ask warranty vs billable before coding.
|
|
39
|
+
|
|
40
|
+
## STEP 3 — CLOSE THE LOOP
|
|
41
|
+
- Confirm ISSUES entry + HISTORY note `support P<n>: <title> → <route>`.
|
|
42
|
+
- If fixed under warranty: mark issue resolved; no PROPOSAL bump.
|
|
43
|
+
- Reminder: release STAGE 8 hypercare keeps ISSUES live; `/support` is the front door.
|
|
@@ -106,34 +106,55 @@ from idea to closeout:
|
|
|
106
106
|
5. **Proposal & estimate (OPTIONAL — depends on the job)** — for client / quoted
|
|
107
107
|
work, `/propose` reads OVERVIEW + PLAN → `docs/PROPOSAL.md` + a rendered
|
|
108
108
|
`docs/proposal.html`: scope, phase breakdown, effort + cost estimate, timeline,
|
|
109
|
-
assumptions, with a **client sign-off gate** before build.
|
|
110
|
-
|
|
111
|
-
|
|
109
|
+
assumptions, with a **client sign-off gate** before build. **Ask rate +
|
|
110
|
+
contingency in chat** when missing — the kit stores **no** default rate (rates
|
|
111
|
+
are confidential). Client docs show **totals only** (never rate or contingency %).
|
|
112
|
+
Internal / personal projects skip straight from plan to build (and may set
|
|
113
|
+
design/architecture gates to `n/a`).
|
|
114
|
+
6. **Design + architecture gates (rule 15 — after proposal, before build)** —
|
|
115
|
+
`/design` produces `docs/UX-PACK.md` + `docs/ARCHITECTURE.md` and stops for
|
|
116
|
+
human approve. Vertical slices still implement UI+code together; these gates
|
|
117
|
+
lock the *frame* first (software-house shape without abandoning slices).
|
|
118
|
+
7. **Build** — the loop, one phase at a time (`/phase`, AUTO dev loop). Each phase's
|
|
112
119
|
tests (unit + integration + e2e) are automated and MUST pass before the next phase.
|
|
113
120
|
Optionally wrap the phases in the **sprint layer** (`/sprint`): group them into
|
|
114
121
|
capacity-bounded sprints, each shipping one demoable increment with planning →
|
|
115
122
|
standups → review → retro. `/sprint run` drives this end-to-end (see Sprint layer).
|
|
116
|
-
|
|
117
|
-
change order (`docs/CHANGES.md`) + sign-off, then
|
|
118
|
-
change silently.
|
|
119
|
-
|
|
123
|
+
8. **Change mid-flight** — `/change-request`: impact analysis + re-estimate + a logged
|
|
124
|
+
change order (`docs/CHANGES.md` + `docs/changes/CR-<n>.md`) + sign-off, then
|
|
125
|
+
`/replan`. Scope and cost never change silently. Client-facing CR = Δ cost + new
|
|
126
|
+
total only.
|
|
127
|
+
9. **Release** — `/release`: full regression (functional/integration/e2e) → auto
|
|
120
128
|
audits (UI / QA / security / code) → smoke → **manual UAT** (`/uat`, scenario sheet
|
|
121
129
|
+ captured results) → defect loop → **sign-off** (`docs/SIGNOFF-…`) → promote to
|
|
122
130
|
production (a human-signed hard-stop).
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
131
|
+
10. **Go-live & support** — hypercare + `/support` triage (severity, warranty vs
|
|
132
|
+
billable CR, hotfix via `/quick`). New scope → `/change-request`.
|
|
133
|
+
11. **Closeout** — `/synthesize` → a project summary: what was built, key decisions,
|
|
126
134
|
every change order, and the final cost vs the original estimate.
|
|
127
135
|
|
|
128
136
|
**Logging is continuous and total.** Every stage writes to a durable artifact:
|
|
129
|
-
requirements (PRD / OVERVIEW), commercial (PROPOSAL / CHANGES),
|
|
130
|
-
(
|
|
131
|
-
Nothing important lives only in chat — it
|
|
132
|
-
reconstructed and summarised.
|
|
137
|
+
requirements (PRD / OVERVIEW), commercial (PROPOSAL / CHANGES), design
|
|
138
|
+
(UX-PACK / ARCHITECTURE), execution (PLAN / HISTORY), decisions (DESIGN_LOG),
|
|
139
|
+
errors (ISSUES), research (research/). Nothing important lives only in chat — it
|
|
140
|
+
is on disk, so the project can always be reconstructed and summarised.
|
|
133
141
|
|
|
134
142
|
**Approval gates are always interactive** (both modes): the **PLAN-APPROVAL** gate
|
|
135
|
-
(rule 13), the proposal sign-off,
|
|
136
|
-
AUTO governs the *dev loop between*
|
|
143
|
+
(rule 13), the proposal sign-off, **DESIGN + ARCHITECTURE** (rule 15), and every
|
|
144
|
+
change-order approval pause for the human. AUTO governs the *dev loop between*
|
|
145
|
+
those gates, never the plan, the money, or the design/arch frame.
|
|
146
|
+
|
|
147
|
+
### Software-house roles → kit map
|
|
148
|
+
|
|
149
|
+
| House role | Kit surface |
|
|
150
|
+
|------------|-------------|
|
|
151
|
+
| BA / PM | `/overview` grill · `grill-me` · PLAN / PROPOSAL / CR gates |
|
|
152
|
+
| UX / UI | `/design` (UX pack) · `ux-design` skill · `/ui-audit` · rule 9 CLOSE |
|
|
153
|
+
| Architect | `/design` (ARCHITECTURE) · `researcher` DESIGN · `code-standards` · `/log-decision` |
|
|
154
|
+
| Developer | `implementer` · `/phase` · `/feature` · `/quick` |
|
|
155
|
+
| QA | `test-author` · `e2e-runner` · `/qa-audit` · `/uat` |
|
|
156
|
+
| DevOps | final-phase deploy · `/release` promote |
|
|
157
|
+
| Support | `/support` · `/log-issue` · `/runbook` · release hypercare |
|
|
137
158
|
|
|
138
159
|
-----
|
|
139
160
|
|
|
@@ -280,12 +301,22 @@ Named procedures, each with a canonical body in `.claude/commands/<name>.md`.
|
|
|
280
301
|
|
|
281
302
|
**Lane routing — which entry point for which job:**
|
|
282
303
|
|
|
304
|
+
**Default paths** (most days — elevate these in HOW-TO / landing):
|
|
305
|
+
|
|
283
306
|
| The job | Lane |
|
|
284
307
|
|---------|------|
|
|
285
|
-
| Brand-new project (no OVERVIEW yet) | `/overview` → `/phase` (optionally `/sprint`) |
|
|
308
|
+
| Brand-new project (no OVERVIEW yet) | `/overview` → (`/propose` if quoted) → `/design` → `/phase` (optionally `/sprint`) |
|
|
286
309
|
| New FEATURE on an existing product | `/feature` (scaffold the doc with `/feature new`) |
|
|
287
310
|
| Small, obvious, non-phase change (a fix, a rename, a copy tweak) | `/quick` |
|
|
311
|
+
|
|
312
|
+
**Advanced** (same kit — do not cut; use when the job needs them):
|
|
313
|
+
|
|
314
|
+
| The job | Lane |
|
|
315
|
+
|---------|------|
|
|
316
|
+
| Client quote after plan approval | `/propose` (asks rate; client totals only) |
|
|
317
|
+
| UX pack + architecture sign-off | `/design` (rule 15) |
|
|
288
318
|
| Scope change to already-approved work | `/change-request` |
|
|
319
|
+
| After-go-live bug / triage | `/support` |
|
|
289
320
|
| An OUTCOME spanning several units ("clear the feature queue") | `/goal` (drives the lanes above) |
|
|
290
321
|
| Whole-product quality sweep / pre-release | `/ui-audit` · `/qa-audit` · `/security-audit` · `/release` |
|
|
291
322
|
|
|
@@ -310,8 +341,14 @@ surface or need its own acceptance criteria? -> `/feature`. Otherwise `/quick`.
|
|
|
310
341
|
holds state; its `Approved:` line arms headless passes.
|
|
311
342
|
- **propose** — turn approved requirements + stack into `PROPOSAL.md` (scope, phase
|
|
312
343
|
breakdown, effort + cost estimate, assumptions) with a client sign-off gate.
|
|
344
|
+
Asks rate/contingency in chat when missing; client artifacts are totals-only.
|
|
345
|
+
- **design** — post-proposal UX pack + architecture note (`UX-PACK.md` /
|
|
346
|
+
`ARCHITECTURE.md`) with human approve (rule 15) before `/phase`.
|
|
313
347
|
- **change-request** — a mid-project scope change: impact analysis + re-estimate +
|
|
314
|
-
a logged change order (`CHANGES.md`) + sign-off, then
|
|
348
|
+
a logged change order (`CHANGES.md` + `docs/changes/CR-<n>.md`) + sign-off, then
|
|
349
|
+
`replan`. Client sees Δ cost + new total only.
|
|
350
|
+
- **support** — after-go-live triage: severity P1–P3, warranty vs billable CR,
|
|
351
|
+
hotfix via `/quick` or route to `/change-request`.
|
|
315
352
|
- **phase [n]** — run one phase end-to-end with the circuit breaker. Chooses the
|
|
316
353
|
TDD or non-TDD order at RESEARCH. CLOSE runs the regression guard + ENDPOINTS
|
|
317
354
|
coverage gate. When a sprint is active, CLOSE also fires a `/sprint standup` tick.
|
|
@@ -462,7 +499,7 @@ Mirrors the installer's `--dry-run`. (In a dry-run, even AUTO never acts — it
|
|
|
462
499
|
|
|
463
500
|
-----
|
|
464
501
|
|
|
465
|
-
## Hard rules (1–
|
|
502
|
+
## Hard rules (1–15)
|
|
466
503
|
|
|
467
504
|
1. Before debugging ANY error: grep `docs/ISSUES.md` AND `docs/research/INDEX.md`.
|
|
468
505
|
The SESSION-OPEN ritual surfaces ISSUES.md — there is no excuse to miss it.
|
|
@@ -536,6 +573,14 @@ Mirrors the installer's `--dry-run`. (In a dry-run, even AUTO never acts — it
|
|
|
536
573
|
change · `Approved:` goal → goal runs) — that is exactly what arms headless.
|
|
537
574
|
Rationale: a wrong understanding burns tokens and context at 100× the cost
|
|
538
575
|
of one confirm turn. AUTO governs execution AFTER intake, never instead of it.
|
|
576
|
+
15. **DESIGN + ARCHITECTURE gates.** After a client proposal is signed (quoted
|
|
577
|
+
work), no `/phase` / `/sprint` build starts until `docs/UX-PACK.md` and
|
|
578
|
+
`docs/ARCHITECTURE.md` carry human approval, recorded as `design:` /
|
|
579
|
+
`architecture:` in `docs/STATE.md` plus HISTORY lines. Run `/design` to
|
|
580
|
+
author and stop for sign-off. Internal / non-quoted projects may set both to
|
|
581
|
+
`n/a`. A CR that reshapes UX or architecture reverts the affected gate to
|
|
582
|
+
`PENDING`. Client-facing commercial docs never include rate cards or
|
|
583
|
+
contingency percentages (ask rates in chat; totals only on the page).
|
|
539
584
|
|
|
540
585
|
-----
|
|
541
586
|
|
|
@@ -571,14 +616,17 @@ the KB. The kit works normally without a KB.
|
|
|
571
616
|
## File contract
|
|
572
617
|
|
|
573
618
|
- `docs/PRD.md` — crystallised product requirements (or your BMAD/iSSM stories).
|
|
574
|
-
- `docs/PROPOSAL.md` — scope + phase breakdown + effort/cost
|
|
575
|
-
+ sign-off. Versioned;
|
|
619
|
+
- `docs/PROPOSAL.md` — scope + phase breakdown + effort/cost totals + assumptions
|
|
620
|
+
+ sign-off. Versioned; client-safe commercial baseline (no rate / contingency %).
|
|
576
621
|
- `docs/proposal.html` — the client-facing proposal, rendered from PROPOSAL.md via
|
|
577
622
|
`.claude/templates/proposal.html`, in the project language; print-ready (PDF).
|
|
578
|
-
-
|
|
579
|
-
|
|
623
|
+
- `docs/UX-PACK.md` · `docs/ARCHITECTURE.md` — pre-build design/arch frames
|
|
624
|
+
(rule 15); templates under `.claude/templates/`.
|
|
625
|
+
- `.claude/templates/` — document templates (proposal.html, UX-PACK, ARCHITECTURE,
|
|
626
|
+
CR, FEATURE, …) the commands render into `docs/`.
|
|
580
627
|
- `docs/CHANGES.md` — change-order log (append-only): each scope change with its
|
|
581
628
|
impact, effort/cost delta, new total, and approval status. The commercial audit trail.
|
|
629
|
+
- `docs/changes/CR-<n>.md` — detailed CR from `CR-template.md` (client-safe totals).
|
|
582
630
|
- `docs/UAT-<date>.md` — UAT scenario sheet (all cases) + captured tester results
|
|
583
631
|
(PASS/FAIL + notes). Drives the release defect loop.
|
|
584
632
|
- `docs/SIGNOFF-<date>.md` — release sign-off: scope delivered, test/audit/UAT
|
|
@@ -601,7 +649,8 @@ the KB. The kit works normally without a KB.
|
|
|
601
649
|
(Done-when · Budget · `Approved:` line · progress ticks). Maintained by `/goal`.
|
|
602
650
|
- `.claude/templates/FEATURE-template.md` — the Feature-doc form `/feature new`
|
|
603
651
|
scaffolds (Approval/Automation headers + spec sections).
|
|
604
|
-
- `docs/STATE.md` — current position. Small. Rewritten, not appended.
|
|
652
|
+
- `docs/STATE.md` — current position. Small. Rewritten, not appended. Includes
|
|
653
|
+
`plan:`, `design:`, `architecture:` gate pointers (approved · PENDING · n/a).
|
|
605
654
|
- `docs/ISSUES.md` — error log. Deduped by synthesizer.
|
|
606
655
|
- `docs/PLAN.md` — the phase plan (the product backlog). Carries an `> Approval:`
|
|
607
656
|
header — `PENDING` until the rule-13 PLAN-APPROVAL gate stamps `approved <date> v<n>`;
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: support-triage
|
|
3
|
+
description: >
|
|
4
|
+
After-go-live issue triage for software-house support — severity P1–P3,
|
|
5
|
+
warranty vs billable CR, hotfix vs change-request routing. Use with /support,
|
|
6
|
+
production incidents, hypercare, client bug reports, or when classifying
|
|
7
|
+
whether a fix is free warranty work. Keywords: support, hypercare, warranty,
|
|
8
|
+
P1, severity, ticket, hotfix, aftercare, ซัพพอร์ต, รับประกัน.
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# support-triage — post-release front door
|
|
12
|
+
|
|
13
|
+
Caveman ULTRA mode. Triage before you code. Wrong commercial lane (free vs
|
|
14
|
+
billable) is a process defect.
|
|
15
|
+
|
|
16
|
+
## Severity
|
|
17
|
+
|
|
18
|
+
| Level | Meaning | Response shape |
|
|
19
|
+
|-------|---------|----------------|
|
|
20
|
+
| **P1** | Service down, data loss, active security incident | Drop-everything; runbook; fix or mitigate now |
|
|
21
|
+
| **P2** | Major feature broken; workaround exists | Same-day / next business day aim |
|
|
22
|
+
| **P3** | Minor, cosmetic, nice-to-have | Queue; batch with other P3s |
|
|
23
|
+
|
|
24
|
+
## Warranty vs billable
|
|
25
|
+
|
|
26
|
+
- **Warranty:** defect against **approved** scope inside the support window
|
|
27
|
+
(default 30 days after prod `released` unless PROPOSAL/OVERVIEW says otherwise)
|
|
28
|
+
→ log + `/quick` (or larger lane if needed) — **no** proposal bump.
|
|
29
|
+
- **Billable:** new scope, enhancement, or outside window → `/change-request`.
|
|
30
|
+
- **Unclear:** ask once; do not assume free work.
|
|
31
|
+
|
|
32
|
+
## Routing checklist
|
|
33
|
+
|
|
34
|
+
1. Reproduce / capture symptom (prefer client steps).
|
|
35
|
+
2. Grep `docs/ISSUES.md` + runbook — known issue?
|
|
36
|
+
3. Assign P1–P3 + warranty/billable.
|
|
37
|
+
4. Route: support fix · CR · or escalate (infra / vendor).
|
|
38
|
+
5. HISTORY line for the triage decision.
|
|
39
|
+
|
|
40
|
+
Never put personal rate cards into public tickets or client emails from this skill.
|
|
@@ -27,18 +27,23 @@ against the cookbook + wireframe and produces a UX CHECK verdict; nothing UI shi
|
|
|
27
27
|
without it. New visual direction (a layout or look the wireframe doesn't cover) is
|
|
28
28
|
confirmed with the user before building — design is where human taste matters.
|
|
29
29
|
|
|
30
|
+
- **Authoring the UX pack** (`/design` → `docs/UX-PACK.md`) after proposal sign-off
|
|
31
|
+
and before `/phase` (hard rule 15) — produce the frame the build must stay inside.
|
|
30
32
|
- Building a screen / page / component.
|
|
31
33
|
- Reviewing a UI diff (the "ตรวจ" pass).
|
|
32
34
|
- CLOSE gate of any frontend phase — the cookbook check MUST pass.
|
|
33
35
|
|
|
34
|
-
This skill is the STANDARD + the inline GATE (one screen, at phase close)
|
|
35
|
-
|
|
36
|
-
`/ui-audit` (same rubric,
|
|
36
|
+
This skill is the STANDARD + the inline GATE (one screen, at phase close) **and**
|
|
37
|
+
the authoring guide for the pre-build UX pack. For a WHOLE-PRODUCT sweep against
|
|
38
|
+
this same cookbook — periodic or before a release — run `/ui-audit` (same rubric,
|
|
39
|
+
broader scope, a scored report).
|
|
37
40
|
|
|
38
41
|
Order: **wireframe first** (does the layout match the baseline frame?) ->
|
|
39
42
|
**cookbook** (do the details obey the system?). Never invent layout the
|
|
40
43
|
wireframe does not have. If the design truly needs a frame the wireframe lacks,
|
|
41
44
|
STOP and update the wireframe baseline first (a design decision -> `log-decision`).
|
|
45
|
+
When an approved `docs/UX-PACK.md` exists, treat it as the project frame — drift
|
|
46
|
+
from the pack is a defect unless the pack is re-approved.
|
|
42
47
|
|
|
43
48
|
-----
|
|
44
49
|
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
# Architecture — <project>
|
|
2
|
+
|
|
3
|
+
> Approval: PENDING
|
|
4
|
+
> (Stamp on sign-off: `approved <YYYY-MM-DD> v<n>` — hard rule 15)
|
|
5
|
+
|
|
6
|
+
## Purpose
|
|
7
|
+
Build-ready architecture note after commercial sign-off. Refines OVERVIEW stack
|
|
8
|
+
into concrete boundaries the implementer follows per phase.
|
|
9
|
+
|
|
10
|
+
## Context
|
|
11
|
+
- OVERVIEW stack summary:
|
|
12
|
+
- Constraints / non-goals:
|
|
13
|
+
|
|
14
|
+
## Pattern
|
|
15
|
+
- Declared architecture: Feature-Based (default) | layered | hexagonal | other:
|
|
16
|
+
- Why this fits:
|
|
17
|
+
|
|
18
|
+
## System diagram (text)
|
|
19
|
+
```
|
|
20
|
+
(clients) → (API / BFF) → (domain) → (data / external)
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
## Boundaries & modules
|
|
24
|
+
| Module | Owns | Talks to |
|
|
25
|
+
|--------|------|----------|
|
|
26
|
+
| | | |
|
|
27
|
+
|
|
28
|
+
## Data
|
|
29
|
+
- Stores / schemas (high level):
|
|
30
|
+
- Migrations approach:
|
|
31
|
+
|
|
32
|
+
## Auth & trust boundaries
|
|
33
|
+
- Authn / authz:
|
|
34
|
+
- Secrets:
|
|
35
|
+
- Threat notes (STRIDE if security-touching):
|
|
36
|
+
|
|
37
|
+
## Integrations
|
|
38
|
+
| Service | Use | Failure mode |
|
|
39
|
+
|---------|-----|--------------|
|
|
40
|
+
| | | |
|
|
41
|
+
|
|
42
|
+
## Quality & ops
|
|
43
|
+
- Test + E2E runners (from OVERVIEW):
|
|
44
|
+
- Deploy target:
|
|
45
|
+
- Observability / runbook hooks:
|
|
46
|
+
|
|
47
|
+
## Decisions open
|
|
48
|
+
-
|
|
49
|
+
|
|
50
|
+
## Sign-off
|
|
51
|
+
- Approved by: ___
|
|
52
|
+
- Date: ___
|
|
53
|
+
- Version: v1
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# CR-<n> — <short title>
|
|
2
|
+
|
|
3
|
+
> Status: proposed | approved | rejected
|
|
4
|
+
> Date: <YYYY-MM-DD>
|
|
5
|
+
> Baseline: PROPOSAL v<n> | FEATURE `<slug>`
|
|
6
|
+
|
|
7
|
+
## Classification
|
|
8
|
+
- [ ] Clarification (no cost change)
|
|
9
|
+
- [ ] Billable scope change (add / remove / alter)
|
|
10
|
+
- [ ] Warranty defect (prefer `/support` / `/quick` — not billable unless scope expands)
|
|
11
|
+
|
|
12
|
+
## Request
|
|
13
|
+
<what the client / stakeholder asked>
|
|
14
|
+
|
|
15
|
+
## Impact
|
|
16
|
+
- Phases affected (done phases frozen):
|
|
17
|
+
- UX pack impact: none | amend → re-approve (rule 15)
|
|
18
|
+
- Architecture impact: none | amend → re-approve (rule 15)
|
|
19
|
+
- Security re-threat-model?: no | yes
|
|
20
|
+
- Timeline Δ:
|
|
21
|
+
|
|
22
|
+
## Commercial (client-safe)
|
|
23
|
+
| | |
|
|
24
|
+
|--|--|
|
|
25
|
+
| Effort Δ | <± range> |
|
|
26
|
+
| Cost Δ | <± amount · currency> |
|
|
27
|
+
| New total | <amount> |
|
|
28
|
+
|
|
29
|
+
**Do not** put rate, rate card, or contingency % in this file if it is shared with
|
|
30
|
+
the client. Show math with rates only in private chat / private estimate memo.
|
|
31
|
+
|
|
32
|
+
## Decision
|
|
33
|
+
- Approved by: ___ · Date: ___
|
|
34
|
+
- Or rejected because:
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# UX pack — <project>
|
|
2
|
+
|
|
3
|
+
> Approval: PENDING
|
|
4
|
+
> (Stamp on sign-off: `approved <YYYY-MM-DD> v<n>` — hard rule 15)
|
|
5
|
+
|
|
6
|
+
## Purpose
|
|
7
|
+
Hi-fi-enough UI direction for build: screens, flows, and frame the implementer
|
|
8
|
+
must stay inside. Wireframe baseline first; visual direction confirmed here.
|
|
9
|
+
|
|
10
|
+
## Users & jobs
|
|
11
|
+
-
|
|
12
|
+
|
|
13
|
+
## Key flows
|
|
14
|
+
1.
|
|
15
|
+
2.
|
|
16
|
+
|
|
17
|
+
## Screen inventory
|
|
18
|
+
| Screen | Job | Priority |
|
|
19
|
+
|--------|-----|----------|
|
|
20
|
+
| | | |
|
|
21
|
+
|
|
22
|
+
## Frame & tokens
|
|
23
|
+
- Wireframe baseline: (link or summary)
|
|
24
|
+
- Brand / tokens: (or “follow OVERVIEW UX direction”)
|
|
25
|
+
- Breakpoints: XS · SM · MD · LG · XL
|
|
26
|
+
|
|
27
|
+
## States & a11y notes
|
|
28
|
+
- Empty / loading / error covered for each primary view
|
|
29
|
+
- WCAG 2.1 AA targets
|
|
30
|
+
|
|
31
|
+
## Out of scope (design)
|
|
32
|
+
-
|
|
33
|
+
|
|
34
|
+
## Sign-off
|
|
35
|
+
- Approved by: ___
|
|
36
|
+
- Date: ___
|
|
37
|
+
- Version: v1
|
|
@@ -91,7 +91,8 @@
|
|
|
91
91
|
|
|
92
92
|
<div class="total">
|
|
93
93
|
<span><span class="lbl" style="margin:0">ราคารวม <em>Total</em></span><br><span class="muted" style="font-size:9px">{{TIMELINE}}</span></span>
|
|
94
|
-
|
|
94
|
+
<!-- CLIENT-SAFE: totals only. Never put rate, rate card, or contingency % in {{TOTAL_NOTE}}. Leave empty or a non-rate label (e.g. currency). -->
|
|
95
|
+
<span class="amt">{{TOTAL_COST}} <small>{{TOTAL_NOTE}}</small></span>
|
|
95
96
|
</div>
|
|
96
97
|
|
|
97
98
|
<div class="cols">
|