mcpField
P
project-creator

project-creator

github.com/itechmeat开发24110 次安装4 天前更新
代码仓库

关于 project-creator

project-creator 是指导创建和维护 .project/ 项目文档的技能，适用于新项目启动、文档更新和用户故事规划。它通过模板、参考指南和逐步确认流程组织项目资料。

主要功能

  1. 01生成项目概览、规格和架构文档
  2. 02维护项目上下文与用户故事
  3. 03提供文档模板和参考指南
  4. 04按步骤访谈、起草并确认内容

适用场景

  1. 01为新项目建立 .project/ 文档
  2. 02更新现有项目资料并补齐缺项
  3. 03规划并排序产品用户故事

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/itechmeat/llm-code --skill project-creator

安装后在 Claude Code 中输入/project-creator确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

assets/
about-template.md
architecture-template.md
project-context-template.md
specs-template.md
stories-template.md
story-template.md
references/
about-guide.md
architecture-guide.md
context-guide.md
specs-guide.md
stories-guide.md

详细介绍

项目创建器

指导在 .project/ 文件夹中创建和维护项目文档。

快速导航

  • 模板：assets/ 文件夹
  • 指南：references/ 文件夹

适用场景

  • 启动新项目
  • 创建或更新 .project/ 文档
  • 规划用户故事

项目结构

.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

资源（模板）

模板文件用途
关于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单个故事

指南（参考资料）

指南文件用途
关于references/about-guide.md问题与标准
规格references/specs-guide.md问题与标准
架构references/architecture-guide.md问题与标准
上下文references/context-guide.md问题与标准
故事references/stories-guide.md问题与标准

文档依赖关系

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

各文档的工作流

标准流程
  1. 从 references/ 加载指南
  2. 检查文档是否存在——如果存在，则阅读并评估
  3. 使用 assets/ 中的模板创建或更新
  4. 根据指南中的问题采访用户
  5. 根据用户的回答起草内容
  6. 展示草稿并征求反馈
  7. 反复修改，直到用户确认
  8. 继续处理下一份文档
已有文档

如果文档已经存在：

  • 阅读并评估完成情况
  • 询问用户：审核并更新，还是跳过？
  • 在现有内容基础上完善——不要重新创建
  • 标记缺漏或不一致之处

沟通风格

始终做到
  • 一次只询问一个主题
  • 提供 2-3 种表述方案
  • 用简单的方式解释技术概念
  • 起草前总结对需求的理解
  • 进入下一步前先确认
绝不
  • 擅自假设答案
  • 跳过确认步骤
  • 不加解释地使用行话
  • 未经确认就进入下一份文档
  • 未核实最新版本就编写规格

交互示例

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?

关键规则

  • 绝不假设项目详情——务必询问
  • 始终提供不同的表述方案
  • 始终与用户确认理解是否正确
  • 未经用户确认，绝不继续
  • 始终使用 assets/ 中的模板
  • 绝不允许版本降级（只能升级）

示例问题

以下问题仅为示例——请根据每个项目的具体情况调整：

About.md
  • 你能用一句话描述你的项目吗？
  • 这个项目要解决用户的什么困扰？
  • 如果只能开发 3 项功能，它们会是什么？
  • 你如何判断项目是否成功？
  • 这个项目明确不会做什么？
Specs.md
  • 必须支持哪些设备或浏览器？
  • 你预计会有多少并发用户？
  • 是否有需要集成的现有基础设施？
  • 团队对 [technology] 的使用经验如何？
  • 是否有任何合规要求？
Architecture.md
  • 系统有哪些主要部分？
  • 组件之间应如何通信？
  • 存在哪些数据流？
  • 系统将如何扩展？
  • 如何保障系统安全？
Stories
  • 上线时哪些内容绝对不可或缺？
  • 哪些内容可以稍后再做？
  • 功能的合理开发顺序是什么？
  • 功能 X 是否需要先实现功能 Y？

帮助非技术用户

当用户缺乏技术知识时：

  1. 用简单的方式说明选项
  • “React 非常适合构建交互式 UI，Vue 更容易上手”
  • “PostgreSQL 适合可靠地存储结构化数据，MongoDB 适合灵活的架构”
  1. 使用类比
  • “API 就像服务员，负责把订单送到厨房”
  • “数据库就像一个文件柜”
  • “缓存就像一张方便快速查找的便签”
  1. 给出建议并说明理由
  • “根据您预计的用户数量，我建议……”
  • “由于您需要实时更新，这种模式……”
  1. 说明权衡
  • 性能与简洁性
  • 功能丰富度与学习曲线
  • 成本与可扩展性

链接

评论

支持 Markdown