@miniidealab/openlogos 0.9.5 → 0.9.7

package/claude-plugin-template/skills/merge-executor/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: merge-executor
+description: "Execute delta merges by generating MERGE_PROMPT.md from change proposals. Use when an approved change proposal needs to be applied to the codebase."
+---
+
+# Skill: Merge Executor
+
+> Read the MERGE_PROMPT.md instruction file generated by the CLI, and merge each delta file from the change proposal into the main documents one by one, ensuring changes are applied accurately.
+
+## Trigger Conditions
+
+- User requests AI to execute the merge after running `openlogos merge <slug>`
+- User mentions "execute merge", "merge", "merge the deltas into the main documents"
+- User mentions "read MERGE_PROMPT.md and execute"
+
+## Prerequisites
+
+1. `logos/changes/<slug>/MERGE_PROMPT.md` exists (generated by the `openlogos merge` command)
+2. The delta files and target main documents referenced in MERGE_PROMPT.md all exist
+
+If MERGE_PROMPT.md does not exist, prompt the user to run `openlogos merge <slug>` first.
+
+## Core Capabilities
+
+1. Parse merge instructions from MERGE_PROMPT.md
+2. Read each delta file and interpret ADDED / MODIFIED / REMOVED markers
+3. Precisely locate the corresponding sections in the main document and execute the merge
+4. Maintain formatting and style consistency of the main document
+5. Output a change summary
+6. **Stop and wait for human confirmation** — After the merge is complete, the AI's role ends. Never run `openlogos archive` autonomously.
+
+## Execution Steps
+
+### Step 1: Read Merge Instructions
+
+Read `logos/changes/<slug>/MERGE_PROMPT.md` and parse:
+- Change proposal name and overview
+- Each delta file's path, corresponding target main document path, and operation type
+
+### Step 2: Merge Each Delta File
+
+Process delta files one by one in the order listed in MERGE_PROMPT.md:
+
+1. **Read the delta file**: Understand the ADDED / MODIFIED / REMOVED markers and content
+2. **Read the target main document**: Locate the sections that need modification
+3. **Execute the merge**:
+   - `ADDED`: Insert new content at the specified position in the main document
+   - `MODIFIED`: Replace the content of the same-named section in the main document
+   - `REMOVED`: Delete the corresponding section from the main document
+4. **Output summary**: List what modifications were made to the file
+
+### Step 3: Output Overall Change Report
+
+After all deltas have been processed, output:
+
+```
+Merge complete:
+- [file path 1]: added x sections, modified y sections, deleted z sections
+- [file path 2]: ...
+```
+
+Then AI **automatically runs git commit** (no user confirmation needed, but must inform user):
+
+```bash
+git add -A
+git commit -m "docs(<slug>): merge spec deltas"
+```
+
+> Use `git add -A` instead of `git add logos/resources/` to ensure all spec files touched by this merge (including spec/, skills/, CLAUDE.md, AGENTS.md, etc.) are included in the commit.
+
+Then prompt the user with next steps:
+
+```
+✅ Spec documents merged and committed. Next steps:
+
+Step 1: Implement code
+Implement business code + test code per the updated logos/resources/ specs.
+AI will automatically commit the code changes when done.
+
+Step 2: Run verification (after code is complete)
+Run in the project root:
+openlogos verify
+- PASS → proceed to Step 3
+- FAIL → fix the code and re-run verify (no need to re-run merge)
+
+Step 3: Archive (after verification passes)
+openlogos archive <slug>
+
+openlogos verify and openlogos archive are human confirmation points — AI must not execute them without explicit user authorization.
+```
+
+## Merge Principles
+
+1. **Maintain format consistency**: Merged content must match the existing format, indentation, and heading levels of the main document
+2. **Do not alter unrelated content**: Only modify the parts specified by the delta; do not reformat the entire document
+3. **Ask on conflict**: If a section referenced by the delta cannot be found in the main document (possibly already modified by another change), pause and ask the user how to proceed
+4. **Confirm after each file**: Show a modification summary after processing each delta file, and wait for user confirmation before processing the next one
+
+## Output Specification
+
+- Directly modify the main documents in `logos/resources/` (in-place editing)
+- Do not modify any files in `logos/changes/`
+- Do not create new files during the merge (unless a delta specifies adding a completely new document)
+
+## Best Practices
+
+- **Read everything before acting**: Read through all delta files and target documents first to understand the full picture, then merge one by one
+- **MODIFIED is the most error-prone**: Section titles may have minor differences (capitalization, spacing) — fuzzy matching is needed
+- **Preserve change traces**: If the main document has a "last updated" timestamp, remember to update it accordingly
+- **Delta order matters**: Requirement document changes should be processed before API document changes to ensure upstream-downstream consistency
+
+## Recommended Prompts
+
+The following prompts can be copied directly for AI use:
+
+- `Read logos/changes/<slug>/MERGE_PROMPT.md and execute the merge`
+- `Help me merge the add-remember-me changes into the main documents`
+- `Execute the change merge`

package/claude-plugin-template/skills/prd-writer/SKILL.md

@@ -0,0 +1,203 @@
+---
+name: prd-writer
+description: "Write product requirements documents following OpenLogos methodology. Use when logos/resources/prd/1-product-requirements/ is empty or the user needs to create/update scenario-driven requirements with GIVEN/WHEN/THEN acceptance criteria."
+---
+
+# Skill: PRD Writer
+
+> Assist in writing scenario-driven requirements documents — starting from user pain points, identifying core business scenarios, and defining GIVEN/WHEN/THEN acceptance criteria for each scenario. Scenario numbers will carry through all subsequent phases.
+
+## Trigger Conditions
+
+- User requests writing a requirements document, product requirements, or PRD
+- User discusses product positioning, target users, or feature requirements
+- User mentions "Phase 1", "requirements layer", or "WHY"
+- The project is currently in the requirements analysis phase
+
+## Core Capabilities
+
+1. Guide users through product positioning and target user profiling
+2. Extract user pain points and establish causal chains
+3. Identify and define business scenarios from pain points (assigning `S01`, `S02`... numbers)
+4. Write GIVEN/WHEN/THEN acceptance criteria for each scenario
+5. Prioritize scenarios
+6. Identify constraints and the "won't-do" list
+7. Generate scenario-driven requirements documents conforming to the OpenLogos specification
+
+## Execution Steps
+
+### Step 1: Understand Product Positioning
+
+Confirm the following key questions with the user (proactively ask if information is insufficient):
+
+- **One-line positioning**: What is this product? For whom? What problem does it solve?
+- **Target user persona**: Specific enough to describe a real person
+- **Core objectives**: What should the product achieve, and what metrics define success
+
+### Step 2: Extract User Pain Points
+
+Guide the user to identify pain points from the following dimensions:
+
+- How does the user currently do it? (Current state)
+- What difficulties are encountered in the process? (Pain points)
+- What consequences do the difficulties cause? (Impact)
+- How does the user expect it to be resolved? (Expectation)
+
+**Every pain point must have a causal chain**: Because [reason] → leads to [pain point] → results in [consequence]
+
+Assign a number to each pain point (`P01`, `P02`...) for scenario traceability.
+
+### Step 3: Identify and Define Scenarios
+
+**Scenarios are the anchor throughout the entire development lifecycle.** This step is critical.
+
+Extract business scenarios from pain points and requirements. Each scenario is a **complete user action path**:
+
+- **Who** triggers it under **what circumstances**
+- Through **what steps** (must involve multiple interactions, not a single API call)
+- To achieve **what business outcome** (a value the user can perceive)
+
+Assign a globally unique number to each scenario (`S01`, `S02`...). This number will carry through to Phase 2 and Phase 3.
+
+Output a scenario list table:
+
+```markdown
+| ID   | Scenario Name      | Trigger Condition          | Related Pain Point | Priority |
+|------|--------------------|----------------------------|--------------------|----------|
+| S01  | Email Registration  | New user's first visit     | P01                | P0       |
+| S02  | Password Login      | Registered user returns    | P01                | P0       |
+| S03  | Forgot Password     | User cannot log in         | P02                | P1       |
+```
+
+#### Scenario Granularity Self-Check (MUST Pass)
+
+After generating the scenario list, run these 4 tests. **If any test fails, re-organize the scenarios before proceeding.**
+
+1. **Single-API Test**: If a scenario can be completed with just 1 API call, it is NOT a scenario — it is an operation. Merge it into a larger scenario.
+2. **CRUD Test**: If the scenario list contains "Create X", "Read X", "Update X", "Delete X" as 4 separate scenarios, the granularity is too fine. Re-organize by user goals (e.g., "Manager plans weekly tasks" instead of "Create task" + "Assign task" + "Update task" + "Delete task").
+3. **Business Value Test**: Describe in one sentence the value the user gains after completing the scenario. If the answer is merely "data was written/read/deleted", there is no real business goal — merge the scenario into a goal-driven one.
+4. **Step Count Test**: A scenario's main path must contain at least 3 user-perceivable steps. Fewer than 3 means the granularity is too fine.
+
+#### ❌ Anti-Pattern: One API = One Scenario
+
+```markdown
+| S01 | Create Task    | User clicks "New"       |
+| S02 | Get Task List  | User opens the page      |
+| S03 | Update Task    | User edits a task        |
+| S04 | Delete Task    | User deletes a task      |
+→ This is an API inventory, NOT a scenario list!
+```
+
+#### ✅ Correct: Organize by Business Goals
+
+```markdown
+| S01 | Team Lead Plans Weekly Tasks   | Lead logs in → creates tasks → sets priority & deadline → assigns to members → members receive notifications |
+| S02 | Developer Completes & Delivers | Dev views to-do → updates progress → marks complete → lead is notified and reviews |
+| S03 | Lead Reviews Project Progress  | Lead opens dashboard → filters by status/member → exports weekly report |
+```
+
+### Step 4: Write Scenario Acceptance Criteria
+
+Write acceptance criteria for every P0 and P1 scenario:
+
+```markdown
+### S01: Email Registration
+
+- **Trigger Condition**: New user's first visit, clicks "Sign Up"
+- **User Value**: Quickly create an account and start using the product (← P01)
+- **Priority**: P0
+- **Main Path**: User fills in email and password, submits the form, receives a verification email, clicks the link to complete registration
+
+#### Acceptance Criteria
+
+##### Normal: Complete registration flow
+- **GIVEN** the user has not registered before and is on the registration page
+- **WHEN** the user fills in a valid email and password (≥8 characters) and clicks "Sign Up"
+- **THEN** the system creates an account, sends a verification email, and the page displays "Please check your email for verification"
+
+##### Exception: Email already registered
+- **GIVEN** the email test@example.com is already registered
+- **WHEN** the user attempts to register using test@example.com
+- **THEN** the page displays "This email is already registered, please log in directly" and no email is sent
+
+##### Exception: Password does not meet requirements
+- **GIVEN** the user is on the registration page
+- **WHEN** the user fills in a valid email but a password with fewer than 8 characters and clicks "Sign Up"
+- **THEN** the page displays "Password must be at least 8 characters" and the request is not submitted
+```
+
+**Principles for writing acceptance criteria**:
+
+- Each scenario must have at least 1 normal + 1 exception acceptance criterion
+- GIVEN describes the initial state — specific enough to be reproducible
+- WHEN describes the user action — precise down to the button level
+- THEN describes the expected behavior — specific enough to be verifiable
+- Avoid vague wording: "fast", "friendly", "reasonable" → quantify with concrete metrics
+
+### Step 5: Identify Constraints and Boundaries
+
+- **Technical constraints**: Technology stack limitations, third-party service limitations
+- **Resource constraints**: Team size, time window
+- **"Won't-do" list**: Explicitly list features and scenarios that are out of scope for this phase to prevent scope creep
+
+### Step 6: Assemble the Requirements Document
+
+Output the complete document in the standard structure:
+
+```markdown
+# [Product Name] Requirements Document
+
+> Last updated: [date]
+
+## I. Product Background and Goals
+### 1.1 Product Positioning
+### 1.2 Core Objectives
+### 1.3 Target User Persona
+
+## II. User Pain Point Analysis
+### P01: [Pain Point Name]
+Because [reason] → leads to [pain point] → results in [consequence]
+### P02: ...
+
+## III. Scenario Overview
+[Scenario list table: ID / Name / Trigger Condition / Related Pain Point / Priority]
+
+## IV. Core Scenario Details
+### S01: [Scenario Name]
+[Trigger Condition + User Value + Priority + Main Path + Acceptance Criteria]
+### S02: ...
+
+## V. Constraints and Boundaries
+### 5.1 Technical Constraints
+### 5.2 Resource and Time Constraints
+### 5.3 "Won't-Do" List
+```
+
+## Output Specification
+
+- File format: Markdown
+- Storage location: `logos/resources/prd/1-product-requirements/`
+- File naming: `{sequence}-{english-name}.md`, e.g., `01-requirements.md`
+- Every scenario must be traceable to at least one user pain point
+- P0/P1 scenarios must have GIVEN/WHEN/THEN (≥1 normal + ≥1 exception)
+- Scenario numbers are globally unique and will carry through Phase 2 and Phase 3
+
+## Best Practices
+
+- **Cast a wide net first, then narrow down**: In the first pass, identify as many scenarios as possible, then cut non-core ones during prioritization
+- **Scenarios ≠ Features, Scenarios ≠ APIs**: A scenario is a "complete path from the user's perspective to achieve a business goal". A single feature (e.g., "user authentication") may contain multiple scenarios (registration, login, password recovery); a single scenario (e.g., "first purchase") may span multiple features (browsing, adding to cart, payment). **Never define a single CRUD operation as a standalone scenario.**
+- **Scenario granularity**: Keep granularity moderate in Phase 1. Too fine-grained ("user creates a record") is just an API call; too coarse ("user uses the product") is unverifiable. Good granularity: the main path of a scenario can be walked through in 1–2 minutes and involves at least 3 distinct steps
+- **Acceptance criteria are the precise expression of requirements**: If you cannot write GIVEN/WHEN/THEN, the scenario is not yet well thought out
+- **Exception scenarios are equally important**: Users don't always follow the happy path — exception handling often defines the product experience
+- **The "won't-do" list is the hardest to write**: Restraint is the most important skill of a product manager
+- **Once a scenario number is assigned, it is never reused**: Even if a scenario is deprecated, its number is not recycled, to avoid confusion
+- **Requirements documents are living documents**: They are continuously updated as the product evolves, with every change tracked through Delta change management
+
+## Recommended Prompts
+
+The following prompts can be copied directly for use with an AI:
+
+- `Help me write a requirements document`
+- `I want to build a xxx product, help me sort out the requirements`
+- `Help me organize these ideas into a structured requirements document`
+- `Help me add exception scenario acceptance criteria to an existing requirements document`

package/claude-plugin-template/skills/product-designer/SKILL.md

@@ -0,0 +1,235 @@
+---
+name: product-designer
+description: "Create product design specifications including feature specs and page designs. Use when requirements exist in logos/resources/prd/1-product-requirements/ but logos/resources/prd/2-product-design/ is empty."
+---
+
+# Skill: Product Designer
+
+> Based on scenarios from the Phase 1 requirements document, refine interaction flows and feature specifications, and generate product prototypes. The prototype format automatically adapts to the product type (Web/CLI/Library, etc.). Scenario numbering stays consistent with Phase 1.
+
+## Trigger Conditions
+
+- User requests a product design document or feature specification
+- User requests prototypes or interaction design
+- User mentions "Phase 2", "product design layer", or "WHAT"
+- Requirements document exists (with scenario definitions) and solution design needs to begin
+
+## Core Capabilities
+
+1. **Identify the product type** and determine the corresponding prototype format (see Product Types and Prototype Strategy below)
+2. Design information architecture (page structure / command structure / API structure)
+3. Use Phase 1 scenarios as the backbone to refine interaction flows and feature specifications
+4. Supplement each scenario with interaction-level GIVEN/WHEN/THEN acceptance criteria
+5. Generate prototypes appropriate for the product type
+6. When a scenario is too coarse-grained, split it into sub-scenarios (`S01.1`, `S01.2`)
+
+## Product Types and Prototype Strategy
+
+Before executing this Skill, first determine the product type (inferred from the requirements document's constraints and boundaries, and the `tech_stack` in `logos-project.yaml`), then select the corresponding prototype format:
+
+| Product Type | Typical Features | Prototype Format | Interaction Spec Focus |
+|---------|---------|---------|-------------|
+| **Web Application** | Has UI pages, user login | Interactive HTML pages | Page navigation, form validation, state changes |
+| **CLI Tool** | Terminal commands, no GUI | Terminal interaction examples (command + output simulation) | Command format, parameter design, output format, error messages |
+| **AI Skills / Conversational Product** | User interacts with AI via natural language | Dialogue flowchart + sample dialogue scripts | Dialogue steps, AI questioning strategy, deliverable format |
+| **Library / SDK** | Called by other programs | API usage examples (code snippets) | Public interfaces, parameter design, return values, error codes |
+| **Mobile Application** | Mobile UI | HTML pages (mobile viewport) | Gesture interaction, navigation patterns, offline state |
+| **Hybrid** | Combination of multiple deliverables | Select the corresponding format for each deliverable | Interaction handoffs between deliverables |
+
+## Execution Steps
+
+### Step 1: Read the Requirements Document and Identify the Product Type
+
+Read the Phase 1 requirements document and extract:
+- Scenario list (`S01`, `S02`...) and priorities
+- Constraints and boundaries → determine product type
+- `tech_stack` in `logos-project.yaml` → confirm technical form
+
+**Scenario Granularity Check**: While reading the scenario list, watch for signs that scenarios are actually single CRUD operations (e.g., "Create Task", "Get Task List", "Update Task", "Delete Task" as 4 separate scenarios). If detected, recommend returning to Phase 1 to re-organize scenarios by business goals before proceeding with product design. Designing interactions for CRUD-level "scenarios" will produce shallow specs that don't reflect real user workflows.
+
+Output the product type determination and rationale for the prototype strategy selection.
+
+### Step 2: Design Information Architecture
+
+Design architecture at different levels based on the product type:
+
+- **Web Application**: Page structure, navigation hierarchy, route design
+- **CLI Tool**: Command tree structure, subcommand hierarchy, global options
+- **AI Skills**: Skill trigger relationships, dialogue step orchestration, deliverable dependency chain
+- **Library / SDK**: Module structure, public API grouping
+
+### Step 3: Refine Interaction Specifications Per Scenario
+
+Define complete interaction details for each scenario (see format examples below). Different product types emphasize different interaction dimensions.
+
+### Step 4: Supplement Interaction-Level Acceptance Criteria
+
+Building on the Phase 1 GIVEN/WHEN/THEN, refine down to the interaction element level.
+
+### Step 5: Generate Prototypes
+
+Generate prototypes in the format corresponding to the product type (see examples).
+
+### Step 6: Output the Product Design Document
+
+Organize by scenario, with each scenario containing interaction specifications + corresponding prototype.
+
+## Scenario Elaboration Examples
+
+### Web Application Example
+
+```markdown
+### S01: Email Registration — Interaction Specification
+
+**Pages Involved**: Registration page, email verification waiting page, verification success page
+
+**Interaction Flow**:
+1. User clicks "Sign Up" on the homepage → redirected to the registration page
+2. Registration page contains: email input, password input, confirm password input, sign up button
+3. Real-time validation: email format, password length ≥ 8, both passwords match
+4. Successful submission → redirected to email verification waiting page
+
+#### Acceptance Criteria (Interaction Level)
+
+##### Normal: Successful Registration
+- **GIVEN** User is on the registration page, all fields are empty
+- **WHEN** User enters test@example.com, password "Pass1234", confirm password "Pass1234", clicks "Sign Up" button
+- **THEN** "Sign Up" button enters loading state, redirects to email verification waiting page after 1-3 seconds
+```
+
+**Prototype**: `01-register-prototype.html` (interactive HTML page)
+
+### CLI Tool Example
+
+````markdown
+### S01: CLI Project Initialization — Interaction Specification
+
+**Command Format**: `openlogos init [name]`
+
+**Parameter Design**:
+| Parameter | Type | Required | Default | Description |
+|------|------|------|--------|------|
+| name | string | No | Current directory name | Project name |
+
+**Interaction Flow**:
+1. User runs `openlogos init my-project` in the terminal
+2. CLI checks if `logos/logos.config.json` already exists
+3. Does not exist → creates directory structure, outputs created file list line by line
+4. Exists → outputs error message and exits
+
+**Terminal Output Simulation**:
+
+Normal path:
+```
+$ openlogos init my-project
+
+Creating OpenLogos project structure...
+
+  ✓ logos/resources/prd/1-product-requirements/
+  ✓ logos/resources/prd/2-product-design/
+  ✓ logos/resources/prd/3-technical-plan/1-architecture/
+  ✓ logos/resources/prd/3-technical-plan/2-scenario-implementation/
+  ✓ logos/resources/api/
+  ✓ logos/resources/database/
+  ✓ logos/resources/scenario/
+  ✓ logos/changes/
+  ✓ logos/logos.config.json
+  ✓ logos/logos-project.yaml
+  ✓ AGENTS.md
+  ✓ CLAUDE.md
+
+Project initialized. Next steps:
+  1. Edit logos/logos.config.json to configure your project
+  2. Start with Phase 1: tell AI "Help me write requirements"
+  3. Run `openlogos status` to check progress at any time
+```
+
+Error path:
+```
+$ openlogos init
+Error: logos/logos.config.json already exists in current directory.
+This directory has already been initialized as an OpenLogos project.
+```
+
+#### Acceptance Criteria (Interaction Level)
+
+##### Normal: Brand New Project
+- **GIVEN** Current directory has no `logos/logos.config.json`
+- **WHEN** User runs `openlogos init my-project`
+- **THEN** Terminal outputs the 12 created files/directories line by line, ends with "Next steps" guidance, exit code is 0
+
+##### Error: Already Initialized
+- **GIVEN** Current directory already contains `logos/logos.config.json`
+- **WHEN** User runs `openlogos init`
+- **THEN** Terminal outputs a red error message, no files are created, exit code is 1
+````
+
+**Prototype**: `01-init-terminal.md` (terminal interaction simulation document)
+
+### AI Skills / Conversational Product Example
+
+```markdown
+### S02: AI-Assisted Requirements Writing — Interaction Specification
+
+**Trigger Method**: User enters natural language in an AI coding tool
+
+**Dialogue Flow**:
+1. User says "Help me write requirements"
+2. AI reads the prd-writer Skill
+3. AI follows up: "Please first tell me your product positioning — what problem does this product solve, and for whom?"
+4. User describes the product idea
+5. AI follows up: "Who is the core user? Can you describe a specific person?"
+6. User describes the user persona
+7. AI consolidates the information and begins outputting a structured requirements document
+8. After output, AI asks: "The requirements draft has been generated. Please review it and let me know what needs to be changed."
+
+**AI Behavioral Guidelines**:
+- No more than 3 rounds of follow-up questions, each round focusing on 1 key piece of information
+- If the user provides sufficient information in the first message, skip follow-up questions and output directly
+- Output document format strictly follows the prd-writer specification
+
+#### Acceptance Criteria (Interaction Level)
+
+##### Normal: Sufficient Information
+- **GIVEN** User describes product positioning, target users, and core pain points in the first message
+- **WHEN** AI begins executing the prd-writer Skill
+- **THEN** AI directly outputs a structured requirements document without follow-up questions
+
+##### Normal: Insufficient Information
+- **GIVEN** User only says "Help me write requirements"
+- **WHEN** AI begins executing the prd-writer Skill
+- **THEN** AI asks about product positioning (round 1) → user responds → AI asks about target users (round 2) → user responds → AI outputs requirements document
+```
+
+**Prototype**: `02-prd-writer-dialogue.md` (dialogue flow script)
+
+## Output Specification
+
+- Feature specs: `logos/resources/prd/2-product-design/1-feature-specs/`
+- Prototypes: `logos/resources/prd/2-product-design/2-page-design/`
+- Design documents and prototypes appear in pairs: `{number}-{name}-design.md` + `{number}-{name}-prototype.{ext}`
+  - Web Application: `.html`
+  - CLI Tool: `-terminal.md` (terminal interaction simulation)
+  - AI Skills: `-dialogue.md` (dialogue flow script)
+  - Library / SDK: `-api-examples.md` (usage examples)
+- **Scenario numbering must be consistent with Phase 1**; use sub-numbers when splitting (`S01.1`)
+
+## Best Practices
+
+- **Scenarios are the backbone**: Don't organize documents by "pages" or "commands" — organize by "scenarios"
+- **Phase 1 acceptance criteria are the input**: Phase 2 does not rewrite acceptance criteria; it refines Phase 1 criteria down to the interaction element level
+- **Sub-scenario splits need justification**: Only split when a Phase 1 scenario truly contains two independent interaction paths
+- **CLI "prototypes" are terminal output simulations**: No HTML needed — use code blocks to simulate terminal input/output
+- **AI Skills "prototypes" are dialogue scripts**: Simulate multi-turn conversations between the user and AI, specifying AI behavior at each node
+- **Hybrid products are organized by scenario**: Within the same product, CLI scenarios use terminal simulations while Web scenarios use HTML — no need for a uniform format
+- **Nested Markdown code blocks**: When the document content itself contains ` ``` ` code fences (e.g., AI outputting code snippets in dialogue scripts, or nested command output in terminal simulations), **the outer fence must use 4 backticks** (` ```` `), keeping the inner fence at 3. This is standard Markdown syntax to prevent the parser from misjudging nesting levels and causing formatting issues. The CLI Tool example above demonstrates this rule.
+
+## Recommended Prompts
+
+The following prompts can be copied directly for use with AI:
+
+- `Create product design based on the requirements document`
+- `Help me design the interaction flow and prototype for S01`
+- `Help me create the product design for all scenarios`
+- `Help me design the CLI command interaction flow`
+- `Help me design the AI Skill dialogue flow`