ship-create 1.3.1 → 1.5.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.
@@ -1,56 +1,73 @@
1
1
  # SHIP Agent Rules
2
2
 
3
- **This file is the canonical ruleset.** Copies of this exact content live at `AGENTS.md`, `CLAUDE.md`, `.cursorrules`, and `.windsurfrules` so that whichever AI coding tool opens this repository, it picks up these rules automatically — no manual prompt-pasting required. If you edit this file, copy the change into the other four so they stay identical.
3
+ **This file is the canonical ruleset for this project.** Copies of this exact content live at `AGENTS.md`, `CLAUDE.md`, `.cursorrules`, and `.windsurfrules` so that whichever AI coding tool opens this repository, it picks up these rules automatically.
4
4
 
5
5
  ---
6
6
 
7
- ## What This Repository Is
7
+ ## What This Project Is
8
8
 
9
- This is a project built using **The SHIP Method** — a four-phase discipline for building products with AI:
9
+ This project was scaffolded with **The SHIP Method** — a four-phase discipline for building products with AI:
10
10
 
11
11
  ```
12
12
  S — STRUCTURE → H — HUMAN FLOW → I — INSTRUCTION → P — PUBLISH
13
13
  (what & why) (the experience) (AI-ready specs) (ship it)
14
14
  ```
15
15
 
16
- Full reference docs live in: `01-STRUCTURE/`, `02-HUMAN-FLOW/`, `03-INSTRUCTION/`, `04-PUBLISH/`, `05-SOP/`, `06-TEMPLATES/`, `07-PROMPTS/`, `08-EXAMPLES/`, `09-CASE-STUDIES/`, `10-LAUNCH/`, `11-STANDARDS/`, `12-DESIGN-SYSTEM/`, `13-TECH-STACK/`.
16
+ All docs live under `docs/`:
17
+
18
+ | File | Purpose |
19
+ |---|---|
20
+ | `docs/PROJECT.md` | What & why — vision, audience, problem, MVP scope |
21
+ | `docs/HUMAN_FLOW.md` | How users move through the product, screen by screen |
22
+ | `docs/AI_BUILD_SPEC.md` | Functional requirements, data model, API contract (created at build time) |
23
+ | `docs/tech-stack/STACK_DECISION_MATRIX.md` | How to choose databases, auth, hosting, etc. |
24
+ | `docs/tech-stack/TECH_STACK.md` | Full stack reference for this project type |
25
+ | `docs/PROMPTS.md` | Full SHIP prompt chain (Stages 1-6) for reference |
26
+
27
+ **For UI/design decisions:** invoke the `ui-ux-pro-max` skill — it provides palette, typography, component patterns, and layout guidance specific to this project type. Do not rely on generic static design files.
17
28
 
18
29
  ## Mandatory Behavior for Any AI Agent Working in This Repo
19
30
 
20
31
  1. **Check Structure and Human Flow before generating application code.**
21
- - Look for `01-STRUCTURE/PROJECT.md` and `02-HUMAN-FLOW/HUMAN_FLOW.md`.
22
- - If either is missing, or still contains unfilled `[bracket placeholders]` in its core sections (Vision, Problem Statement, MVP Scope; Happy Path, Core Screens), **do not generate product code**. Instead, help the user fill in the missing sections first, asking one question at a time.
23
- - Exception: scaffolding, boilerplate, config files, and infra setup (package.json, folder structure, CI config) are fine to generate at any time — the gate is on *feature/business logic* code.
32
+ - Read `docs/PROJECT.md` and `docs/HUMAN_FLOW.md` at the start of every session.
33
+ - If either is missing, or still contains unfilled `[fill in]` / `[bracket placeholders]` in its core sections (Vision, Problem Statement, MVP Scope; User Journey, Core Screens), **do not generate feature code**. Instead, run `/ship` to guide the user through filling the gaps.
34
+ - Exception: scaffolding, config files, and infra setup are fine to generate at any time — the gate is on *feature/business logic* code only.
24
35
 
25
- 2. **Treat `03-INSTRUCTION/AI_BUILD_SPEC.md` as the source of truth** for functional requirements, data model, and API contract once it exists. If a user's code request conflicts with it, point out the conflict instead of silently overriding the spec.
36
+ 2. **Use `docs/AI_BUILD_SPEC.md` as the source of truth** for functional requirements, data model, and API contract once it exists. If a user's code request conflicts with it, flag the conflict instead of silently overriding the spec.
26
37
 
27
38
  3. **Use the right reference file for the job:**
28
39
  | Need | File |
29
40
  |---|---|
30
- | Product type starter (CRM, SaaS, marketplace, etc.) | `06-TEMPLATES/*_TEMPLATE.md` |
31
- | Database schema | `03-INSTRUCTION/DATABASE_SPEC.md` |
32
- | Stack choice | `13-TECH-STACK/STACK_DECISION_MATRIX.md` |
33
- | UI/component consistency | `12-DESIGN-SYSTEM/DESIGN_SYSTEM.md`, `UI_COMPONENT_SPEC.md` |
34
- | Pre-launch checks | `04-PUBLISH/QA_CHECKLIST.md`, `LAUNCH_CHECKLIST.md` |
41
+ | Vision, audience, MVP scope | `docs/PROJECT.md` |
42
+ | User flow, screens | `docs/HUMAN_FLOW.md` |
43
+ | Functional requirements, data model | `docs/AI_BUILD_SPEC.md` |
44
+ | Stack choice | `docs/tech-stack/STACK_DECISION_MATRIX.md` |
45
+ | UI/design decisions | invoke `ui-ux-pro-max` skill — derives palette, font, components from the project context |
46
+ | Product-type feature checklist | `docs/*_TEMPLATE.md` |
35
47
 
36
- 4. **After generating a new feature**, remind the user to add relevant test cases to `04-PUBLISH/QA_CHECKLIST.md` and update `01-STRUCTURE/FEATURE_MATRIX.md` if scope changed.
48
+ 4. **After generating a new feature**, remind the user to update `docs/PROJECT.md` Section 6 (MVP Scope) if scope changed.
37
49
 
38
50
  5. **If the user explicitly insists on skipping the gate** ("just build it, skip the docs"), comply — but say once, briefly, what's being skipped and why it usually causes rework later. Don't refuse repeatedly or lecture.
39
51
 
40
- 6. **Never invent business facts** (market size, pricing, real metrics, real user quotes) into these docs. Draft clearly-labeled placeholders or ask the user instead.
52
+ 6. **Never invent business facts** (market size, pricing, real metrics, real user quotes). Draft clearly-labeled `[TBD: ...]` placeholders or ask the user.
41
53
 
42
- 7. **Once the spec is complete, run the "Theme & First Screen" step before polishing or shipping.** When `01-STRUCTURE/PROJECT.md`, `02-HUMAN-FLOW/HUMAN_FLOW.md`, and `03-INSTRUCTION/AI_BUILD_SPEC.md` are filled (no `[bracket placeholders]`), and before calling anything ship-ready:
43
- - **Theme:** Derive 2-3 theme candidates (color palette as HSL token values + a font pairing) from the business in `PROJECT.md`, present them, let the user pick one, then apply it to the app's `app/globals.css` and `app/layout.tsx` and record the choice in `12-DESIGN-SYSTEM/DESIGN_SYSTEM.md`.
44
- - **Home:** Read `02-HUMAN-FLOW/HUMAN_FLOW.md`, determine the real entry point for this business, and replace the starter kit's generic `app/page.tsx` ("Pick your area") with it.
45
- - Don't pick a theme silently and don't require brand assets the user didn't provide. See the `ship-method` skill's `theme-guide.md` for the business-type palette/font reference. (In `ship-create` projects these docs live under `docs/`; in this OS repo the app lives under `starter-kit/`.)
54
+ 7. **Once the spec is complete, apply white theme and replace the home screen do this first, before any features.**
55
+ When `docs/PROJECT.md` and `docs/HUMAN_FLOW.md` are filled and `docs/AI_BUILD_SPEC.md` exists:
56
+ - **Home first:** Replace the starter kit's generic `app/page.tsx` immediately with the real entry point from `docs/HUMAN_FLOW.md`. This is always the first build output so the user sees something real right away.
57
+ - **Theme (shadcn/ui):** Use Tailwind CSS v4 + shadcn/ui. Apply the user's chosen shadcn color palette (zinc/slate/blue/green/orange/rose/violet) via its CSS variable block in `app/globals.css`. Always white background. Font: modern (Inter/Geist) or luxury (Playfair Display + DM Sans). Do not write custom HSL tokens manually.
58
+ - See `.claude/skills/ship-method/theme-guide.md` for product-type → palette reference.
46
59
 
47
60
  ## Quick Orientation for a New Agent Session
48
61
 
49
- If you (the AI agent) are opening this repo for the first time in a session:
50
- 1. Read `01-STRUCTURE/PROJECT.md` and `02-HUMAN-FLOW/HUMAN_FLOW.md` first to learn what's being built.
51
- 2. Read `03-INSTRUCTION/AI_BUILD_SPEC.md` if it exists, for the technical contract.
52
- 3. Then proceed with whatever the user asked, applying the rules above.
62
+ 1. Read `docs/PROJECT.md` to learn what's being built and for whom.
63
+ 2. Read `docs/HUMAN_FLOW.md` to understand the user experience.
64
+ 3. Check if `docs/AI_BUILD_SPEC.md` exists — if yes, read it for the technical contract.
65
+ 4. Then proceed with what the user asked, applying the rules above.
66
+
67
+ **Shortcut commands available:**
68
+ - `/ship` — interactive gate-by-gate guide through Structure → Human Flow → Instruction → Publish
69
+ - `/build` — assumes docs are filled, creates build spec and starts coding the MVP
53
70
 
54
71
  ## Source
55
72
 
56
- These rules are part of **The SHIP Method OS**. See `README.md` and `START-HERE.md` at the repo root for the full system this project was built from.
73
+ This project was created with `npx ship-create`. The SHIP Method OS lives at github.com/nireadaddy/the-ship-method-os.
@@ -1,56 +1,73 @@
1
1
  # SHIP Agent Rules
2
2
 
3
- **This file is the canonical ruleset.** Copies of this exact content live at `AGENTS.md`, `CLAUDE.md`, `.cursorrules`, and `.windsurfrules` so that whichever AI coding tool opens this repository, it picks up these rules automatically — no manual prompt-pasting required. If you edit this file, copy the change into the other four so they stay identical.
3
+ **This file is the canonical ruleset for this project.** Copies of this exact content live at `AGENTS.md`, `CLAUDE.md`, `.cursorrules`, and `.windsurfrules` so that whichever AI coding tool opens this repository, it picks up these rules automatically.
4
4
 
5
5
  ---
6
6
 
7
- ## What This Repository Is
7
+ ## What This Project Is
8
8
 
9
- This is a project built using **The SHIP Method** — a four-phase discipline for building products with AI:
9
+ This project was scaffolded with **The SHIP Method** — a four-phase discipline for building products with AI:
10
10
 
11
11
  ```
12
12
  S — STRUCTURE → H — HUMAN FLOW → I — INSTRUCTION → P — PUBLISH
13
13
  (what & why) (the experience) (AI-ready specs) (ship it)
14
14
  ```
15
15
 
16
- Full reference docs live in: `01-STRUCTURE/`, `02-HUMAN-FLOW/`, `03-INSTRUCTION/`, `04-PUBLISH/`, `05-SOP/`, `06-TEMPLATES/`, `07-PROMPTS/`, `08-EXAMPLES/`, `09-CASE-STUDIES/`, `10-LAUNCH/`, `11-STANDARDS/`, `12-DESIGN-SYSTEM/`, `13-TECH-STACK/`.
16
+ All docs live under `docs/`:
17
+
18
+ | File | Purpose |
19
+ |---|---|
20
+ | `docs/PROJECT.md` | What & why — vision, audience, problem, MVP scope |
21
+ | `docs/HUMAN_FLOW.md` | How users move through the product, screen by screen |
22
+ | `docs/AI_BUILD_SPEC.md` | Functional requirements, data model, API contract (created at build time) |
23
+ | `docs/tech-stack/STACK_DECISION_MATRIX.md` | How to choose databases, auth, hosting, etc. |
24
+ | `docs/tech-stack/TECH_STACK.md` | Full stack reference for this project type |
25
+ | `docs/PROMPTS.md` | Full SHIP prompt chain (Stages 1-6) for reference |
26
+
27
+ **For UI/design decisions:** invoke the `ui-ux-pro-max` skill — it provides palette, typography, component patterns, and layout guidance specific to this project type. Do not rely on generic static design files.
17
28
 
18
29
  ## Mandatory Behavior for Any AI Agent Working in This Repo
19
30
 
20
31
  1. **Check Structure and Human Flow before generating application code.**
21
- - Look for `01-STRUCTURE/PROJECT.md` and `02-HUMAN-FLOW/HUMAN_FLOW.md`.
22
- - If either is missing, or still contains unfilled `[bracket placeholders]` in its core sections (Vision, Problem Statement, MVP Scope; Happy Path, Core Screens), **do not generate product code**. Instead, help the user fill in the missing sections first, asking one question at a time.
23
- - Exception: scaffolding, boilerplate, config files, and infra setup (package.json, folder structure, CI config) are fine to generate at any time — the gate is on *feature/business logic* code.
32
+ - Read `docs/PROJECT.md` and `docs/HUMAN_FLOW.md` at the start of every session.
33
+ - If either is missing, or still contains unfilled `[fill in]` / `[bracket placeholders]` in its core sections (Vision, Problem Statement, MVP Scope; User Journey, Core Screens), **do not generate feature code**. Instead, run `/ship` to guide the user through filling the gaps.
34
+ - Exception: scaffolding, config files, and infra setup are fine to generate at any time — the gate is on *feature/business logic* code only.
24
35
 
25
- 2. **Treat `03-INSTRUCTION/AI_BUILD_SPEC.md` as the source of truth** for functional requirements, data model, and API contract once it exists. If a user's code request conflicts with it, point out the conflict instead of silently overriding the spec.
36
+ 2. **Use `docs/AI_BUILD_SPEC.md` as the source of truth** for functional requirements, data model, and API contract once it exists. If a user's code request conflicts with it, flag the conflict instead of silently overriding the spec.
26
37
 
27
38
  3. **Use the right reference file for the job:**
28
39
  | Need | File |
29
40
  |---|---|
30
- | Product type starter (CRM, SaaS, marketplace, etc.) | `06-TEMPLATES/*_TEMPLATE.md` |
31
- | Database schema | `03-INSTRUCTION/DATABASE_SPEC.md` |
32
- | Stack choice | `13-TECH-STACK/STACK_DECISION_MATRIX.md` |
33
- | UI/component consistency | `12-DESIGN-SYSTEM/DESIGN_SYSTEM.md`, `UI_COMPONENT_SPEC.md` |
34
- | Pre-launch checks | `04-PUBLISH/QA_CHECKLIST.md`, `LAUNCH_CHECKLIST.md` |
41
+ | Vision, audience, MVP scope | `docs/PROJECT.md` |
42
+ | User flow, screens | `docs/HUMAN_FLOW.md` |
43
+ | Functional requirements, data model | `docs/AI_BUILD_SPEC.md` |
44
+ | Stack choice | `docs/tech-stack/STACK_DECISION_MATRIX.md` |
45
+ | UI/design decisions | invoke `ui-ux-pro-max` skill — derives palette, font, components from the project context |
46
+ | Product-type feature checklist | `docs/*_TEMPLATE.md` |
35
47
 
36
- 4. **After generating a new feature**, remind the user to add relevant test cases to `04-PUBLISH/QA_CHECKLIST.md` and update `01-STRUCTURE/FEATURE_MATRIX.md` if scope changed.
48
+ 4. **After generating a new feature**, remind the user to update `docs/PROJECT.md` Section 6 (MVP Scope) if scope changed.
37
49
 
38
50
  5. **If the user explicitly insists on skipping the gate** ("just build it, skip the docs"), comply — but say once, briefly, what's being skipped and why it usually causes rework later. Don't refuse repeatedly or lecture.
39
51
 
40
- 6. **Never invent business facts** (market size, pricing, real metrics, real user quotes) into these docs. Draft clearly-labeled placeholders or ask the user instead.
52
+ 6. **Never invent business facts** (market size, pricing, real metrics, real user quotes). Draft clearly-labeled `[TBD: ...]` placeholders or ask the user.
41
53
 
42
- 7. **Once the spec is complete, run the "Theme & First Screen" step before polishing or shipping.** When `01-STRUCTURE/PROJECT.md`, `02-HUMAN-FLOW/HUMAN_FLOW.md`, and `03-INSTRUCTION/AI_BUILD_SPEC.md` are filled (no `[bracket placeholders]`), and before calling anything ship-ready:
43
- - **Theme:** Derive 2-3 theme candidates (color palette as HSL token values + a font pairing) from the business in `PROJECT.md`, present them, let the user pick one, then apply it to the app's `app/globals.css` and `app/layout.tsx` and record the choice in `12-DESIGN-SYSTEM/DESIGN_SYSTEM.md`.
44
- - **Home:** Read `02-HUMAN-FLOW/HUMAN_FLOW.md`, determine the real entry point for this business, and replace the starter kit's generic `app/page.tsx` ("Pick your area") with it.
45
- - Don't pick a theme silently and don't require brand assets the user didn't provide. See the `ship-method` skill's `theme-guide.md` for the business-type palette/font reference. (In `ship-create` projects these docs live under `docs/`; in this OS repo the app lives under `starter-kit/`.)
54
+ 7. **Once the spec is complete, apply white theme and replace the home screen do this first, before any features.**
55
+ When `docs/PROJECT.md` and `docs/HUMAN_FLOW.md` are filled and `docs/AI_BUILD_SPEC.md` exists:
56
+ - **Home first:** Replace the starter kit's generic `app/page.tsx` immediately with the real entry point from `docs/HUMAN_FLOW.md`. This is always the first build output so the user sees something real right away.
57
+ - **Theme (shadcn/ui):** Use Tailwind CSS v4 + shadcn/ui. Apply the user's chosen shadcn color palette (zinc/slate/blue/green/orange/rose/violet) via its CSS variable block in `app/globals.css`. Always white background. Font: modern (Inter/Geist) or luxury (Playfair Display + DM Sans). Do not write custom HSL tokens manually.
58
+ - See `.claude/skills/ship-method/theme-guide.md` for product-type → palette reference.
46
59
 
47
60
  ## Quick Orientation for a New Agent Session
48
61
 
49
- If you (the AI agent) are opening this repo for the first time in a session:
50
- 1. Read `01-STRUCTURE/PROJECT.md` and `02-HUMAN-FLOW/HUMAN_FLOW.md` first to learn what's being built.
51
- 2. Read `03-INSTRUCTION/AI_BUILD_SPEC.md` if it exists, for the technical contract.
52
- 3. Then proceed with whatever the user asked, applying the rules above.
62
+ 1. Read `docs/PROJECT.md` to learn what's being built and for whom.
63
+ 2. Read `docs/HUMAN_FLOW.md` to understand the user experience.
64
+ 3. Check if `docs/AI_BUILD_SPEC.md` exists — if yes, read it for the technical contract.
65
+ 4. Then proceed with what the user asked, applying the rules above.
66
+
67
+ **Shortcut commands available:**
68
+ - `/ship` — interactive gate-by-gate guide through Structure → Human Flow → Instruction → Publish
69
+ - `/build` — assumes docs are filled, creates build spec and starts coding the MVP
53
70
 
54
71
  ## Source
55
72
 
56
- These rules are part of **The SHIP Method OS**. See `README.md` and `START-HERE.md` at the repo root for the full system this project was built from.
73
+ This project was created with `npx ship-create`. The SHIP Method OS lives at github.com/nireadaddy/the-ship-method-os.
@@ -1,56 +1,73 @@
1
1
  # SHIP Agent Rules
2
2
 
3
- **This file is the canonical ruleset.** Copies of this exact content live at `AGENTS.md`, `CLAUDE.md`, `.cursorrules`, and `.windsurfrules` so that whichever AI coding tool opens this repository, it picks up these rules automatically — no manual prompt-pasting required. If you edit this file, copy the change into the other four so they stay identical.
3
+ **This file is the canonical ruleset for this project.** Copies of this exact content live at `AGENTS.md`, `CLAUDE.md`, `.cursorrules`, and `.windsurfrules` so that whichever AI coding tool opens this repository, it picks up these rules automatically.
4
4
 
5
5
  ---
6
6
 
7
- ## What This Repository Is
7
+ ## What This Project Is
8
8
 
9
- This is a project built using **The SHIP Method** — a four-phase discipline for building products with AI:
9
+ This project was scaffolded with **The SHIP Method** — a four-phase discipline for building products with AI:
10
10
 
11
11
  ```
12
12
  S — STRUCTURE → H — HUMAN FLOW → I — INSTRUCTION → P — PUBLISH
13
13
  (what & why) (the experience) (AI-ready specs) (ship it)
14
14
  ```
15
15
 
16
- Full reference docs live in: `01-STRUCTURE/`, `02-HUMAN-FLOW/`, `03-INSTRUCTION/`, `04-PUBLISH/`, `05-SOP/`, `06-TEMPLATES/`, `07-PROMPTS/`, `08-EXAMPLES/`, `09-CASE-STUDIES/`, `10-LAUNCH/`, `11-STANDARDS/`, `12-DESIGN-SYSTEM/`, `13-TECH-STACK/`.
16
+ All docs live under `docs/`:
17
+
18
+ | File | Purpose |
19
+ |---|---|
20
+ | `docs/PROJECT.md` | What & why — vision, audience, problem, MVP scope |
21
+ | `docs/HUMAN_FLOW.md` | How users move through the product, screen by screen |
22
+ | `docs/AI_BUILD_SPEC.md` | Functional requirements, data model, API contract (created at build time) |
23
+ | `docs/tech-stack/STACK_DECISION_MATRIX.md` | How to choose databases, auth, hosting, etc. |
24
+ | `docs/tech-stack/TECH_STACK.md` | Full stack reference for this project type |
25
+ | `docs/PROMPTS.md` | Full SHIP prompt chain (Stages 1-6) for reference |
26
+
27
+ **For UI/design decisions:** invoke the `ui-ux-pro-max` skill — it provides palette, typography, component patterns, and layout guidance specific to this project type. Do not rely on generic static design files.
17
28
 
18
29
  ## Mandatory Behavior for Any AI Agent Working in This Repo
19
30
 
20
31
  1. **Check Structure and Human Flow before generating application code.**
21
- - Look for `01-STRUCTURE/PROJECT.md` and `02-HUMAN-FLOW/HUMAN_FLOW.md`.
22
- - If either is missing, or still contains unfilled `[bracket placeholders]` in its core sections (Vision, Problem Statement, MVP Scope; Happy Path, Core Screens), **do not generate product code**. Instead, help the user fill in the missing sections first, asking one question at a time.
23
- - Exception: scaffolding, boilerplate, config files, and infra setup (package.json, folder structure, CI config) are fine to generate at any time — the gate is on *feature/business logic* code.
32
+ - Read `docs/PROJECT.md` and `docs/HUMAN_FLOW.md` at the start of every session.
33
+ - If either is missing, or still contains unfilled `[fill in]` / `[bracket placeholders]` in its core sections (Vision, Problem Statement, MVP Scope; User Journey, Core Screens), **do not generate feature code**. Instead, run `/ship` to guide the user through filling the gaps.
34
+ - Exception: scaffolding, config files, and infra setup are fine to generate at any time — the gate is on *feature/business logic* code only.
24
35
 
25
- 2. **Treat `03-INSTRUCTION/AI_BUILD_SPEC.md` as the source of truth** for functional requirements, data model, and API contract once it exists. If a user's code request conflicts with it, point out the conflict instead of silently overriding the spec.
36
+ 2. **Use `docs/AI_BUILD_SPEC.md` as the source of truth** for functional requirements, data model, and API contract once it exists. If a user's code request conflicts with it, flag the conflict instead of silently overriding the spec.
26
37
 
27
38
  3. **Use the right reference file for the job:**
28
39
  | Need | File |
29
40
  |---|---|
30
- | Product type starter (CRM, SaaS, marketplace, etc.) | `06-TEMPLATES/*_TEMPLATE.md` |
31
- | Database schema | `03-INSTRUCTION/DATABASE_SPEC.md` |
32
- | Stack choice | `13-TECH-STACK/STACK_DECISION_MATRIX.md` |
33
- | UI/component consistency | `12-DESIGN-SYSTEM/DESIGN_SYSTEM.md`, `UI_COMPONENT_SPEC.md` |
34
- | Pre-launch checks | `04-PUBLISH/QA_CHECKLIST.md`, `LAUNCH_CHECKLIST.md` |
41
+ | Vision, audience, MVP scope | `docs/PROJECT.md` |
42
+ | User flow, screens | `docs/HUMAN_FLOW.md` |
43
+ | Functional requirements, data model | `docs/AI_BUILD_SPEC.md` |
44
+ | Stack choice | `docs/tech-stack/STACK_DECISION_MATRIX.md` |
45
+ | UI/design decisions | invoke `ui-ux-pro-max` skill — derives palette, font, components from the project context |
46
+ | Product-type feature checklist | `docs/*_TEMPLATE.md` |
35
47
 
36
- 4. **After generating a new feature**, remind the user to add relevant test cases to `04-PUBLISH/QA_CHECKLIST.md` and update `01-STRUCTURE/FEATURE_MATRIX.md` if scope changed.
48
+ 4. **After generating a new feature**, remind the user to update `docs/PROJECT.md` Section 6 (MVP Scope) if scope changed.
37
49
 
38
50
  5. **If the user explicitly insists on skipping the gate** ("just build it, skip the docs"), comply — but say once, briefly, what's being skipped and why it usually causes rework later. Don't refuse repeatedly or lecture.
39
51
 
40
- 6. **Never invent business facts** (market size, pricing, real metrics, real user quotes) into these docs. Draft clearly-labeled placeholders or ask the user instead.
52
+ 6. **Never invent business facts** (market size, pricing, real metrics, real user quotes). Draft clearly-labeled `[TBD: ...]` placeholders or ask the user.
41
53
 
42
- 7. **Once the spec is complete, run the "Theme & First Screen" step before polishing or shipping.** When `01-STRUCTURE/PROJECT.md`, `02-HUMAN-FLOW/HUMAN_FLOW.md`, and `03-INSTRUCTION/AI_BUILD_SPEC.md` are filled (no `[bracket placeholders]`), and before calling anything ship-ready:
43
- - **Theme:** Derive 2-3 theme candidates (color palette as HSL token values + a font pairing) from the business in `PROJECT.md`, present them, let the user pick one, then apply it to the app's `app/globals.css` and `app/layout.tsx` and record the choice in `12-DESIGN-SYSTEM/DESIGN_SYSTEM.md`.
44
- - **Home:** Read `02-HUMAN-FLOW/HUMAN_FLOW.md`, determine the real entry point for this business, and replace the starter kit's generic `app/page.tsx` ("Pick your area") with it.
45
- - Don't pick a theme silently and don't require brand assets the user didn't provide. See the `ship-method` skill's `theme-guide.md` for the business-type palette/font reference. (In `ship-create` projects these docs live under `docs/`; in this OS repo the app lives under `starter-kit/`.)
54
+ 7. **Once the spec is complete, apply white theme and replace the home screen do this first, before any features.**
55
+ When `docs/PROJECT.md` and `docs/HUMAN_FLOW.md` are filled and `docs/AI_BUILD_SPEC.md` exists:
56
+ - **Home first:** Replace the starter kit's generic `app/page.tsx` immediately with the real entry point from `docs/HUMAN_FLOW.md`. This is always the first build output so the user sees something real right away.
57
+ - **Theme (shadcn/ui):** Use Tailwind CSS v4 + shadcn/ui. Apply the user's chosen shadcn color palette (zinc/slate/blue/green/orange/rose/violet) via its CSS variable block in `app/globals.css`. Always white background. Font: modern (Inter/Geist) or luxury (Playfair Display + DM Sans). Do not write custom HSL tokens manually.
58
+ - See `.claude/skills/ship-method/theme-guide.md` for product-type → palette reference.
46
59
 
47
60
  ## Quick Orientation for a New Agent Session
48
61
 
49
- If you (the AI agent) are opening this repo for the first time in a session:
50
- 1. Read `01-STRUCTURE/PROJECT.md` and `02-HUMAN-FLOW/HUMAN_FLOW.md` first to learn what's being built.
51
- 2. Read `03-INSTRUCTION/AI_BUILD_SPEC.md` if it exists, for the technical contract.
52
- 3. Then proceed with whatever the user asked, applying the rules above.
62
+ 1. Read `docs/PROJECT.md` to learn what's being built and for whom.
63
+ 2. Read `docs/HUMAN_FLOW.md` to understand the user experience.
64
+ 3. Check if `docs/AI_BUILD_SPEC.md` exists — if yes, read it for the technical contract.
65
+ 4. Then proceed with what the user asked, applying the rules above.
66
+
67
+ **Shortcut commands available:**
68
+ - `/ship` — interactive gate-by-gate guide through Structure → Human Flow → Instruction → Publish
69
+ - `/build` — assumes docs are filled, creates build spec and starts coding the MVP
53
70
 
54
71
  ## Source
55
72
 
56
- These rules are part of **The SHIP Method OS**. See `README.md` and `START-HERE.md` at the repo root for the full system this project was built from.
73
+ This project was created with `npx ship-create`. The SHIP Method OS lives at github.com/nireadaddy/the-ship-method-os.
@@ -0,0 +1,50 @@
1
+ # Design Spec
2
+
3
+ > Screen-by-screen design decisions. Auto-populated by the `uiux-frontend` skill during `/build`. Each section is filled when that screen is built — do not write speculative specs for unbuilt screens.
4
+
5
+ ---
6
+
7
+ ## Global decisions
8
+
9
+ | Decision | Value |
10
+ |----------|-------|
11
+ | Site type | `[FILL: Landing page / Member system]` |
12
+ | Language | `[FILL: Thai / English]` |
13
+ | Font | `[FILL]` |
14
+ | Color palette | `[FILL: shadcn palette name]` |
15
+ | UI trend | `[FILL]` |
16
+ | Trend source | `[FILL: URL or publication that confirmed this trend is current]` |
17
+
18
+ ---
19
+
20
+ ## Screen specs
21
+
22
+ Each screen gets one entry. Format:
23
+
24
+ ```
25
+ ### [Screen name] — [route e.g. /dashboard]
26
+ Status: [planned / in-progress / done]
27
+ Layout: [pattern used]
28
+ Trend application: [how the trend is expressed here]
29
+ Key components: [shadcn components used]
30
+ States: [loading ✓/✗ | empty ✓/✗ | error ✓/✗ | success ✓/✗]
31
+ Revenue link: [how this screen connects to money]
32
+ Notes: [any deviations from the design system, or decisions to revisit]
33
+ ```
34
+
35
+ ---
36
+
37
+ <!-- SCREENS BELOW — filled by uiux-frontend skill during /build -->
38
+
39
+ ### Home / Entry screen — /
40
+ Status: planned
41
+ Layout:
42
+ Trend application:
43
+ Key components:
44
+ States: loading ✗ | empty ✗ | error ✗ | success ✗
45
+ Revenue link:
46
+ Notes:
47
+
48
+ ---
49
+
50
+ <!-- Add a new entry below for each screen as it gets built -->
@@ -0,0 +1,145 @@
1
+ # Design System
2
+
3
+ > Auto-generated by `/build`. Update here when design decisions change — this is the source of truth for all visual decisions in this project.
4
+
5
+ ---
6
+
7
+ ## Stack
8
+
9
+ | Layer | Choice |
10
+ |-------|--------|
11
+ | CSS framework | Tailwind CSS v4 |
12
+ | Component library | shadcn/ui |
13
+ | Font loading | `next/font/google` |
14
+
15
+ ---
16
+
17
+ ## Color Palette
18
+
19
+ **Base theme:** `[FILL: zinc / slate / blue / green / orange / rose / violet]`
20
+
21
+ All color tokens are from shadcn's CSS variable system. Do not hardcode hex or rgb values anywhere — use only these tokens:
22
+
23
+ | Token | Usage |
24
+ |-------|-------|
25
+ | `bg-background` | Page background (always white in light mode) |
26
+ | `text-foreground` | Primary text |
27
+ | `text-muted-foreground` | Secondary text, captions, placeholders |
28
+ | `bg-primary` | Primary action background |
29
+ | `text-primary-foreground` | Text on primary background |
30
+ | `bg-secondary` | Secondary/subtle backgrounds |
31
+ | `border` | Dividers, card borders |
32
+ | `bg-destructive` | Error states, delete actions |
33
+ | `bg-accent` | Hover/active backgrounds |
34
+ | `bg-card` | Card surfaces |
35
+ | `bg-sidebar` | Sidebar background |
36
+
37
+ **Dark mode:** not scoped for MVP — defer until user requests it.
38
+
39
+ ---
40
+
41
+ ## Typography
42
+
43
+ **Language:** `[FILL: Thai / English]`
44
+
45
+ **Font:** `[FILL: Prompt / IBM Plex Thai / Noto Sans Thai / Anuphan / Inter / Geist / Playfair Display + DM Sans]`
46
+
47
+ **Font stack type:** `[FILL: Single-stack (Thai) / Sans-only (Modern) / Serif + Sans (Luxury)]`
48
+
49
+ | Role | Tailwind classes | Notes |
50
+ |------|-----------------|-------|
51
+ | Display / Hero h1 | `[FILL]` | Used in hero sections only |
52
+ | Page title h1 | `text-3xl font-bold` (Thai) / `text-3xl font-bold tracking-tight` (EN) | |
53
+ | Section heading h2 | `text-xl font-semibold` | |
54
+ | Card heading h3 | `text-base font-semibold` | |
55
+ | Body | `text-base font-normal leading-relaxed` | Thai: `leading-loose` for denser text |
56
+ | Caption / helper | `text-sm text-muted-foreground` | |
57
+ | Label | `text-sm font-medium` | Form labels |
58
+ | Button | `text-sm font-medium` | |
59
+
60
+ ---
61
+
62
+ ## Spacing Scale
63
+
64
+ Using Tailwind's default spacing scale. These are the project's agreed units — don't introduce other values:
65
+
66
+ | Use | Class | px |
67
+ |-----|-------|----|
68
+ | Page horizontal padding | `px-4 sm:px-6 lg:px-8` | 16 / 24 / 32 |
69
+ | Section vertical gap | `space-y-8` / `gap-8` | 32 |
70
+ | Card padding | `p-6` | 24 |
71
+ | Form field gap | `space-y-4` | 16 |
72
+ | Inline item gap | `gap-2` / `gap-3` | 8 / 12 |
73
+ | Min touch target | `h-11` | 44 |
74
+
75
+ ---
76
+
77
+ ## Border Radius
78
+
79
+ | Token | Class | Usage |
80
+ |-------|-------|-------|
81
+ | Default | `rounded-md` | Buttons, inputs, badges |
82
+ | Card | `rounded-lg` | Cards, modals, sheets |
83
+ | Full | `rounded-full` | Avatars, tags, pills |
84
+
85
+ ---
86
+
87
+ ## Shadow
88
+
89
+ | Class | Usage |
90
+ |-------|-------|
91
+ | `shadow-sm` | Cards, inputs on focus |
92
+ | `shadow-md` | Dropdowns, popovers |
93
+ | `shadow-lg` | Modals, dialogs |
94
+ | `shadow-none` | Flat/minimal screens |
95
+
96
+ ---
97
+
98
+ ## UI Trend
99
+
100
+ **Selected trend:** `[FILL: trend name]`
101
+ **Reason:** `[FILL: why this trend fits this product + audience]`
102
+
103
+ **Trend implementation rules for this project:**
104
+ `[FILL: specific Tailwind classes and patterns used to express the trend — filled by /build Step 4]`
105
+
106
+ **Trend scope:** Applied to `[FILL: hero section / cards / overall layout / specific screens]`. Not applied to: forms, error states, data tables (keep those neutral for usability).
107
+
108
+ ---
109
+
110
+ ## Component Decisions
111
+
112
+ | Need | Component | Notes |
113
+ |------|-----------|-------|
114
+ | Navigation | `[FILL]` | |
115
+ | Data entry | `[FILL]` | |
116
+ | Data display | `[FILL]` | |
117
+ | Modals | `[FILL]` | |
118
+ | Feedback | `[FILL]` | |
119
+ | Global search | `[FILL: Command / none]` | |
120
+
121
+ ---
122
+
123
+ ## Icons
124
+
125
+ Use `lucide-react` (already bundled with shadcn). Do not mix icon libraries.
126
+
127
+ ---
128
+
129
+ ## Animation
130
+
131
+ Keep animations subtle and intentional:
132
+ - Micro-interactions: `transition-all duration-150`
133
+ - Modal/sheet open: shadcn built-in (Radix transitions)
134
+ - Trend-specific animation: `[FILL: if any — e.g. spring scale for Squishy UI]`
135
+ - Disable if `prefers-reduced-motion`: wrap custom animations in `@media (prefers-reduced-motion: no-preference)`
136
+
137
+ ---
138
+
139
+ ## Accessibility Baseline
140
+
141
+ - Contrast: ≥ 4.5:1 for body text, ≥ 3:1 for large text/UI components
142
+ - Focus ring: Tailwind `ring-2 ring-primary ring-offset-2` (shadcn default)
143
+ - Every form input paired with `<Label htmlFor="...">`
144
+ - Icon-only buttons: `aria-label` required
145
+ - Color not used as the only differentiator (always pair color with shape/text)