Back to Details

project-creator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Project Creator

项目文档生成器

Guide creation and maintenance of project documentation in 
.project/
folder.
指导
.project/
文件夹中项目文档的创建与维护。

Quick Navigation

快速导航

  • Templates: 
    assets/
    folder
  • Guides: 
    references/
    folder
  • 模板：
    assets/
    文件夹
  • 指南：
    references/
    文件夹

When to Use

使用场景

  • Starting a new project
  • Creating/updating 
    .project/
    documentation
  • Planning user stories
  • 启动新项目时
  • 创建/更新
    .project/
    下的文档时
  • 规划用户故事时

Project Structure

项目结构

.project/
├── about.md              # Project overview, goals, target audience
├── specs.md              # Technical specifications, versions
├── architecture.md       # System architecture with diagrams
├── project-context.md    # Cumulative decisions (optional)
└── stories/
    ├── stories.md        # Master list
    └── 001-story-name.md # Individual stories
.project/
├── about.md              # 项目概述、目标、目标受众
├── specs.md              # 技术规格、版本信息
├── architecture.md       # 带图表的系统架构
├── project-context.md    # 累积决策记录（可选）
└── stories/
    ├── stories.md        # 主列表
    └── 001-story-name.md # 单个用户故事

Assets (Templates)

资源（模板）

TemplateFilePurpose
About
assets/about-template.md
Project overview
Specs
assets/specs-template.md
Technical specs
Architecture
assets/architecture-template.md
System architecture
Context
assets/project-context-template.md
Project context
Stories List
assets/stories-template.md
Stories master list
Story
assets/story-template.md
Individual story
模板文件用途
项目概述
assets/about-template.md
项目整体介绍
规格说明
assets/specs-template.md
技术规格说明
架构
assets/architecture-template.md
系统架构说明
项目背景
assets/project-context-template.md
项目背景记录
用户故事列表
assets/stories-template.md
用户故事主列表
单个用户故事
assets/story-template.md
单个用户故事模板

Guides (References)

指南（参考资料）

GuideFilePurpose
About
references/about-guide.md
Questions & criteria
Specs
references/specs-guide.md
Questions & criteria
Architecture
references/architecture-guide.md
Questions & criteria
Context
references/context-guide.md
Questions & criteria
Stories
references/stories-guide.md
Questions & criteria
指南文件用途
项目概述
references/about-guide.md
相关问题与标准
规格说明
references/specs-guide.md
相关问题与标准
架构
references/architecture-guide.md
相关问题与标准
项目背景
references/context-guide.md
相关问题与标准
用户故事
references/stories-guide.md
相关问题与标准

Document Dependencies

文档依赖关系

about.md → specs.md → architecture.md → project-context.md → stories/
about.md → specs.md → architecture.md → project-context.md → stories/

Workflow per Document

单文档工作流程

Standard Flow

标准流程

  1. Load guide from 
    references/
  2. Check if document exists — read and assess if yes
  3. Create/update using template from 
    assets/
  4. Interview user with questions from guide
  5. Draft content based on responses
  6. Present draft, ask for feedback
  7. Iterate until user confirms
  8. Move to next document
  1. 从
    references/
    加载对应指南
  2. 检查文档是否存在——若存在则读取并评估内容
  3. 使用
    assets/
    中的模板创建/更新文档
  4. 根据指南中的问题与用户沟通
  5. 根据用户反馈生成草稿内容
  6. 展示草稿并收集反馈
  7. 迭代修改直至用户确认
  8. 进入下一个文档的处理

Existing Documents

已有文档处理方式

When documents already exist:
  • Read and assess completion state
  • Ask user: review/update or skip?
  • Build on existing content — don't recreate
  • Note gaps or inconsistencies
当文档已存在时：
  • 读取并评估文档完成度
  • 询问用户：是审阅/更新还是跳过？
  • 基于现有内容进行补充——不重新创建
  • 记录内容缺口或不一致之处

Communication Style

沟通风格

Always Do

必须遵循

  • Ask one topic at a time
  • Offer 2-3 formulation variants
  • Explain technical concepts simply
  • Summarize understanding before drafting
  • Confirm before moving to next step
  • 一次仅讨论一个主题
  • 提供2-3种表述选项
  • 用简单语言解释技术概念
  • 生成草稿前先总结对需求的理解
  • 进入下一步前需获得用户确认

Never Do

绝对禁止

  • Assume answers
  • Skip confirmation steps
  • Use jargon without explanation
  • Move to next document without confirmation
  • Write specs without verifying latest versions
  • 自行假设项目细节——务必询问用户
  • 跳过确认步骤
  • 使用未解释的专业术语
  • 未获用户确认就进入下一个文档
  • 未核实最新版本就编写规格说明

Example Interaction

交互示例

Agent: Let's start with about.md. Can you describe what this project does in your own words?

User: It's an app for tracking expenses.

Agent: Great start! Here are some formulation options:

  1. "A personal finance app for tracking daily expenses"
  2. "An expense tracker that helps users manage spending"
  3. "A mobile app for recording and categorizing expenses"

  Which resonates most? Or combine elements?

User: Option 2, but for small businesses, not personal.

Agent: Updated formulation:

  "An expense tracker that helps small businesses 
  manage spending and categorize business expenses."

  Does that capture it? Should we add reporting 
  or team features?
Agent: 我们从about.md开始吧。你能用自己的话描述这个项目的功能吗？

用户：这是一个用于追踪开支的应用。

Agent: 很棒的开端！这里有几个表述选项：

  1. "一款用于追踪日常开支的个人理财应用"
  2. "一款帮助用户管理开支的开支追踪工具"
  3. "一款用于记录和分类开支的移动应用"

  你更倾向于哪一个？或者想要组合不同选项的内容？

用户：选项2，但针对小型企业，而非个人。

Agent: 更新后的表述：

  "一款帮助小型企业管理开支并分类业务开支的开支追踪工具。"

  这个表述准确吗？我们需要添加报表或团队功能吗？

Critical Rules

核心规则

  • NEVER assume project details — always ask
  • ALWAYS offer formulation variants
  • ALWAYS validate understanding with user
  • NEVER proceed without user confirmation
  • ALWAYS use templates from 
    assets/
  • NEVER allow version downgrades (only upgrades)
  • 绝对不要自行假设项目细节——务必询问用户
  • 始终提供多种表述选项
  • 始终与用户确认对需求的理解
  • 绝对不要未获用户确认就推进工作
  • 始终使用
    assets/
    中的模板
  • 绝对不要允许版本降级（仅可升级）

Example Questions

示例问题

Questions are examples — adapt to each unique project:
以下问题为示例——需根据每个项目的独特情况调整：

About.md

About.md

  • Can you describe your project in one sentence?
  • What frustration does this solve for users?
  • If you could only build 3 features, what would they be?
  • How will you know if the project is successful?
  • What will this project definitely NOT do?
  • 你能用一句话描述你的项目吗？
  • 这个项目能解决用户的哪些痛点？
  • 如果你只能实现3个功能，会选哪3个？
  • 你如何判断这个项目是否成功？
  • 这个项目绝对不会涉及哪些内容？

Specs.md

Specs.md

  • What devices/browsers must be supported?
  • How many concurrent users do you expect?
  • Is there existing infrastructure to integrate with?
  • What's the team's experience with [technology]?
  • Are there any compliance requirements?
  • 必须支持哪些设备/浏览器？
  • 你预期的并发用户数量是多少？
  • 是否有需要集成的现有基础设施？
  • 团队对[技术栈]的经验如何？
  • 是否有任何合规要求？

Architecture.md

Architecture.md

  • What are the main parts of the system?
  • How should components communicate?
  • What data flows exist?
  • How will it scale?
  • How is it secured?
  • 系统的主要组成部分有哪些？
  • 组件之间应如何通信？
  • 存在哪些数据流？
  • 系统将如何扩展？
  • 系统的安全机制是怎样的？

Stories

Stories

  • What's absolutely essential for launch?
  • What can wait until later?
  • What's the logical order of features?
  • Does feature X need feature Y first?
  • 哪些功能是上线的必备项？
  • 哪些功能可以延后实现？
  • 功能的合理开发顺序是什么？
  • 功能X是否依赖功能Y的完成？

Helping Non-Technical Users

面向非技术用户的沟通技巧

When user lacks technical knowledge:
  1. Explain options simply
  • "React is great for interactive UIs, Vue is simpler to learn"
  • "PostgreSQL is reliable for structured data, MongoDB for flexible schemas"
  1. Use analogies
  • "The API is like a waiter taking orders to the kitchen"
  • "The database is like a filing cabinet"
  • "The cache is like a notepad for quick lookups"
  1. Make recommendations with reasoning
  • "Given your expected user count, I recommend..."
  • "Since you need real-time updates, this pattern..."
  1. Explain trade-offs
  • Performance vs. simplicity
  • Feature richness vs. learning curve
  • Cost vs. scalability
当用户缺乏技术知识时：
  1. 用简单语言解释选项
  • "React适合构建交互式UI，Vue则更易于学习"
  • "PostgreSQL是处理结构化数据的可靠选择，MongoDB则适用于灵活的 schema"
  1. 使用类比
  • "API就像将订单传递到厨房的服务员"
  • "数据库就像文件柜"
  • "缓存就用于快速查询的记事本"
  1. 给出带理由的建议
  • "根据你预期的用户数量，我推荐..."
  • "由于你需要实时更新，这种模式..."
  1. 解释取舍关系
  • 性能与简洁性的取舍
  • 功能丰富度与学习曲线的取舍
  • 成本与可扩展性的取舍