@miniidealab/openlogos 0.2.0 → 0.3.1

package/skills/product-designer/SKILL.en.md

@@ -0,0 +1,228 @@
+# 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
+
+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`

package/skills/product-designer/SKILL.md

@@ -0,0 +1,228 @@
+# Skill: Product Designer
+
+> 基于 Phase 1 需求文档中的场景，细化交互流程和功能规格，生成产品原型。原型形式根据产品类型自动适配（Web/CLI/Library 等）。场景编号与 Phase 1 保持一致。
+
+## 触发条件
+
+- 用户要求写产品设计文档或功能规格
+- 用户要求画原型或设计交互
+- 用户提到 "Phase 2"、"产品设计层"、"WHAT"
+- 已有需求文档（含场景定义），需要开始设计解决方案
+
+## 核心能力
+
+1. **识别产品类型**，确定对应的原型形式（见下方产品类型与原型策略）
+2. 设计信息架构（页面结构 / 命令结构 / API 结构）
+3. 以 Phase 1 场景为骨架，细化交互流程和功能规格
+4. 为每个场景补充交互级 GIVEN/WHEN/THEN 验收条件
+5. 生成适合产品类型的原型
+6. 当场景粒度过大时，拆分为子场景（`S01.1`, `S01.2`）
+
+## 产品类型与原型策略
+
+执行本 Skill 前，先判断产品类型（可从需求文档的约束与边界、`logos-project.yaml` 的 `tech_stack` 推断），选择对应的原型形式：
+
+| 产品类型 | 典型特征 | 原型形式 | 交互规格重点 |
+|---------|---------|---------|-------------|
+| **Web 应用** | 有 UI 页面、用户登录 | HTML 可交互页面 | 页面流转、表单校验、状态变化 |
+| **CLI 工具** | 终端命令、无 GUI | 终端交互示例（命令 + 输出模拟） | 命令格式、参数设计、输出格式、错误提示 |
+| **AI Skills / 对话式产品** | 用户通过自然语言与 AI 交互 | 对话流程图 + 示例对话脚本 | 对话步骤、AI 提问策略、产出物格式 |
+| **库 / SDK** | 被其他程序调用 | API 使用示例（代码片段） | 公开接口、参数设计、返回值、错误码 |
+| **移动应用** | 手机端 UI | HTML 页面（移动视口） | 手势交互、导航模式、离线状态 |
+| **混合型** | 多种交付物组合 | 按交付物分别选择对应形式 | 各交付物间的交互衔接 |
+
+## 执行步骤
+
+### Step 1: 读取需求文档，识别产品类型
+
+读取 Phase 1 需求文档，提取：
+- 场景清单（`S01`, `S02`...）及优先级
+- 约束与边界 → 判断产品类型
+- `logos-project.yaml` 的 `tech_stack` → 确认技术形态
+
+输出产品类型判断和原型策略选择理由。
+
+### Step 2: 设计信息架构
+
+根据产品类型设计不同层面的架构：
+
+- **Web 应用**：页面结构、导航层级、路由设计
+- **CLI 工具**：命令树结构、子命令层级、全局选项
+- **AI Skills**：Skill 触发关系、对话步骤编排、产出物依赖链
+- **库 / SDK**：模块结构、公开 API 分组
+
+### Step 3: 逐场景细化交互规格
+
+为每个场景定义完整的交互细节（格式见下方示例）。不同产品类型侧重不同的交互维度。
+
+### Step 4: 补充交互级验收条件
+
+在 Phase 1 的 GIVEN/WHEN/THEN 基础上，细化到交互元素级别。
+
+### Step 5: 生成原型
+
+根据产品类型生成对应形式的原型（见示例）。
+
+### Step 6: 输出产品设计文档
+
+按场景组织，每个场景包含交互规格 + 对应原型。
+
+## 场景展开示例
+
+### Web 应用示例
+
+```markdown
+### S01: 邮箱注册 — 交互规格
+
+**涉及页面**：注册页、邮件验证等待页、验证成功页
+
+**交互流程**：
+1. 用户在首页点击「注册」→ 跳转注册页
+2. 注册页包含：邮箱输入框、密码输入框、确认密码输入框、注册按钮
+3. 实时校验：邮箱格式、密码长度 ≥ 8、两次密码一致
+4. 提交成功 → 跳转邮件验证等待页
+
+#### 验收条件（交互级）
+
+##### 正常：成功注册
+- **GIVEN** 用户在注册页面，所有字段为空
+- **WHEN** 用户填写 test@example.com、密码 "Pass1234"、确认密码 "Pass1234"，点击「注册」按钮
+- **THEN** 「注册」按钮变为 loading 状态，1-3 秒后跳转到邮件验证等待页
+```
+
+**原型**：`01-register-prototype.html`（可交互的 HTML 页面）
+
+### CLI 工具示例
+
+````markdown
+### S01: CLI 初始化项目 — 交互规格
+
+**命令格式**：`openlogos init [name]`
+
+**参数设计**：
+| 参数 | 类型 | 必填 | 默认值 | 说明 |
+|------|------|------|--------|------|
+| name | string | 否 | 当前目录名 | 项目名称 |
+
+**交互流程**：
+1. 用户在终端运行 `openlogos init my-project`
+2. CLI 检查 `logos/logos.config.json` 是否已存在
+3. 不存在 → 创建目录结构，逐行输出创建的文件清单
+4. 存在 → 输出错误提示并退出
+
+**终端输出模拟**：
+
+正常路径：
+```
+$ 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 "帮我写需求文档"
+  3. Run `openlogos status` to check progress at any time
+```
+
+错误路径：
+```
+$ openlogos init
+Error: logos/logos.config.json already exists in current directory.
+This directory has already been initialized as an OpenLogos project.
+```
+
+#### 验收条件（交互级）
+
+##### 正常：全新项目
+- **GIVEN** 当前目录无 `logos/logos.config.json`
+- **WHEN** 用户运行 `openlogos init my-project`
+- **THEN** 终端逐行输出创建的 12 个文件/目录，最后输出 "Next steps" 引导，退出码为 0
+
+##### 异常：已初始化
+- **GIVEN** 当前目录已存在 `logos/logos.config.json`
+- **WHEN** 用户运行 `openlogos init`
+- **THEN** 终端输出红色错误提示，不创建任何文件，退出码为 1
+````
+
+**原型**：`01-init-terminal.md`（终端交互模拟文档）
+
+### AI Skills / 对话式产品示例
+
+```markdown
+### S02: AI 辅助写需求文档 — 交互规格
+
+**触发方式**：用户在 AI 编程工具中输入自然语言
+
+**对话流程**：
+1. 用户说「帮我写需求文档」
+2. AI 读取 prd-writer Skill
+3. AI 追问：「请先告诉我你的产品定位——这个产品要解决什么人的什么问题？」
+4. 用户描述产品想法
+5. AI 追问：「核心用户是谁？能描述一个具体的人吗？」
+6. 用户描述用户画像
+7. AI 汇总信息，开始输出结构化需求文档
+8. AI 输出后询问：「需求文档初稿已生成，请 review 后告诉我需要修改的地方」
+
+**AI 行为规范**：
+- 追问不超过 3 轮，每轮聚焦 1 个关键信息
+- 如果用户在第一条消息中提供了充分信息，跳过追问直接输出
+- 输出的文档格式严格遵循 prd-writer 规范
+
+#### 验收条件（交互级）
+
+##### 正常：信息充分
+- **GIVEN** 用户在第一条消息中描述了产品定位、目标用户和核心痛点
+- **WHEN** AI 开始执行 prd-writer Skill
+- **THEN** AI 直接输出结构化需求文档，不进行追问
+
+##### 正常：信息不足
+- **GIVEN** 用户只说了「帮我写需求文档」
+- **WHEN** AI 开始执行 prd-writer Skill
+- **THEN** AI 追问产品定位（第 1 轮）→ 用户回答 → AI 追问目标用户（第 2 轮）→ 用户回答 → AI 输出需求文档
+```
+
+**原型**：`02-prd-writer-dialogue.md`（对话流程脚本）
+
+## 输出规范
+
+- 功能规格：`logos/resources/prd/2-product-design/1-feature-specs/`
+- 原型：`logos/resources/prd/2-product-design/2-page-design/`
+- 设计文档与原型成对出现：`{序号}-{名称}-design.md` + `{序号}-{名称}-prototype.{ext}`
+  - Web 应用：`.html`
+  - CLI 工具：`-terminal.md`（终端交互模拟）
+  - AI Skills：`-dialogue.md`（对话流程脚本）
+  - 库 / SDK：`-api-examples.md`（使用示例）
+- **场景编号必须与 Phase 1 一致**，如需拆分使用子编号（`S01.1`）
+
+## 实践经验
+
+- **场景是骨架**：不要按"页面"或"命令"组织文档，按"场景"组织
+- **Phase 1 的验收条件是输入**：Phase 2 不是重写验收条件，而是在 Phase 1 的基础上细化到交互元素级别
+- **子场景拆分要有理由**：只在 Phase 1 的场景确实包含两条独立的交互路径时才拆分
+- **CLI 的"原型"是终端输出模拟**：不需要 HTML，用代码块模拟终端的输入输出即可
+- **AI Skills 的"原型"是对话脚本**：模拟用户和 AI 的多轮对话，明确 AI 在每个节点的行为
+- **混合型产品按场景分**：同一个产品中 CLI 场景用终端模拟、Web 场景用 HTML，不需要统一形式
+- **Markdown 嵌套代码块**：当文档内容本身包含 ` ``` ` 代码围栏时（如对话脚本中 AI 输出代码片段、终端模拟中嵌套命令输出），**外层围栏必须使用 4 个反引号**（` ```` `），内层保持 3 个。这是 Markdown 标准语法，避免解析器误判层级导致格式错乱。上方 CLI 工具示例已体现此规则
+
+## 推荐提示词
+
+以下提示词可以直接复制给 AI 使用：
+
+- `基于需求文档做产品设计`
+- `帮我设计 S01 的交互流程和原型`
+- `帮我把所有场景的产品设计做出来`
+- `帮我设计 CLI 命令的交互流程`
+- `帮我设计 AI Skill 的对话流程`

package/skills/project-init/SKILL.en.md

@@ -0,0 +1,163 @@
+# Skill: Project Init
+
+> Initialize a project structure following the OpenLogos methodology, generating configuration files, AI instruction files, and standard directories.
+
+## Trigger Conditions
+
+- User requests creating a new project or initializing a project structure
+- User mentions "openlogos init" or "initialize project"
+- No `logos/logos.config.json` exists in the current directory
+
+## Core Capabilities
+
+1. Create the `logos/` directory and its standard substructure
+2. Generate the `logos/logos.config.json` configuration file
+3. Generate the `logos/logos-project.yaml` AI collaboration index
+4. Generate `AGENTS.md` / `CLAUDE.md` AI instruction files (in the root directory)
+5. Create the `logos/changes/` change management directory
+
+## Execution Steps
+
+### Step 1: Gather Project Information
+
+Confirm the following information with the user:
+
+- **Project name**: Used for the `name` field in `logos/logos.config.json`
+- **Project description**: A one-sentence description
+- **Tech stack**: Main framework, language, database, deployment platform
+- **Document modules**: Whether additional modules are needed beyond the default prd/api/scenario/database
+
+If the user does not provide these, use reasonable defaults.
+
+### Step 2: Create Directory Structure
+
+```
+project-root/
+└── logos/
+    ├── resources/
+    │   ├── prd/
+    │   │   ├── 1-product-requirements/
+    │   │   ├── 2-product-design/
+    │   │   │   ├── 1-feature-specs/
+    │   │   │   └── 2-page-design/
+    │   │   └── 3-technical-plan/
+    │   │       ├── 1-architecture/
+    │   │       └── 2-scenario-implementation/
+    │   ├── api/
+    │   ├── database/
+    │   └── scenario/
+    └── changes/
+```
+
+### Step 3: Generate logos/logos.config.json
+
+```json
+{
+  "name": "{project name}",
+  "description": "{project description}",
+  "documents": {
+    "prd": {
+      "label": { "en": "Product Docs", "zh": "产品文档" },
+      "path": "./resources/prd",
+      "pattern": "**/*.{md,html,htm,pdf}"
+    },
+    "api": {
+      "label": { "en": "API Docs", "zh": "API 文档" },
+      "path": "./resources/api",
+      "pattern": "**/*.{yaml,yml,json}"
+    },
+    "scenario": {
+      "label": { "en": "Scenarios", "zh": "业务场景" },
+      "path": "./resources/scenario",
+      "pattern": "**/*.json"
+    },
+    "database": {
+      "label": { "en": "Database", "zh": "数据库" },
+      "path": "./resources/database",
+      "pattern": "**/*.sql"
+    }
+  }
+}
+```
+
+> The `path` field is relative to the directory where `logos.config.json` itself resides (i.e., `logos/`), so `./resources/prd` points to `logos/resources/prd`.
+
+### Step 4: Generate logos/logos-project.yaml
+
+```yaml
+project:
+  name: "{project name}"
+  description: "{project description}"
+  methodology: "OpenLogos"
+
+tech_stack:
+  framework: "{framework provided by user}"
+  language: "{language provided by user}"
+  # ... populate based on user-provided information
+
+resource_index: []
+  # Initially empty; entries are added incrementally as documents are produced
+
+conventions:
+  - "Follow the OpenLogos three-layer progression model (Why → What → How)"
+  - "Every change must first create a change proposal in logos/changes/"
+```
+
+### Step 5: Generate AGENTS.md (Root Directory)
+
+Generate AGENTS.md based on the content from Step 3 and Step 4, placed in the **project root directory**:
+
+```markdown
+# AI Assistant Instructions
+
+This project follows the **OpenLogos** methodology.
+Read `logos/logos-project.yaml` first to understand the project resource index.
+
+## Project Context
+- Config: `logos/logos.config.json`
+- Resource Index: `logos/logos-project.yaml`
+- Tech Stack: {extracted from logos-project.yaml}
+
+## Methodology Rules
+1. Never write code without first completing the design documents
+2. Follow the Why → What → How progression
+3. All API designs must originate from scenario sequence diagrams
+4. All code changes must have corresponding API orchestration tests
+5. Use the Delta change workflow for iterations (see logos/changes/ directory)
+
+## Conventions
+{extracted from conventions in logos-project.yaml}
+```
+
+Also generate `CLAUDE.md` with identical content to AGENTS.md.
+
+### Step 6: Output Initialization Report
+
+Report to the user which files and directories were created, and provide next-step suggestions:
+
+1. Edit `logos/logos.config.json` to refine the project configuration
+2. Start with Phase 1: Write the requirements document
+3. Use the `prd-writer` Skill to assist with writing
+
+## Output Specification
+
+- `logos/logos.config.json`: Valid JSON, conforming to `spec/logos.config.schema.json`
+- `logos/logos-project.yaml`: Valid YAML
+- `AGENTS.md` / `CLAUDE.md`: Markdown format, located in the project root directory
+- All directories under `logos/` are created; empty directories contain `.gitkeep`
+
+## Best Practices
+
+- **Don't over-configure**: Keep configuration minimal during initialization; let users refine it gradually during use
+- **resource_index starts empty**: Add entries as documents are produced, avoiding meaningless placeholder content
+- **Keep AGENTS.md concise**: Only include project-specific information; use fixed templates for universal methodology rules
+- **Prioritize creating the directory structure**: The `logos/` directory structure is the first step in adopting the methodology — more important than any document
+- **Low intrusiveness**: All methodology assets are contained within `logos/`, keeping the project's own structure clean
+
+## Recommended Prompts
+
+The following prompts can be copied directly for use with AI:
+
+- `Help me initialize an OpenLogos project`
+- `Initialize this project with OpenLogos, the project name is xxx`
+- `Help me integrate OpenLogos into an existing project`