forge-setup-project

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Set Up Project Meta-Structure

搭建项目元结构

Set up a project's meta-structure for agentic engineering — the foundational files that make a codebase navigable and maintainable by both humans and AI agents.

为Agentic工程搭建项目元结构——这些基础文件能让代码库对人类和AI Agent都具备可导航性与可维护性。

Input

输入

Optional: A path to the project root: $ARGUMENTS

If no argument is provided, use the current working directory.

可选：项目根目录路径：$ARGUMENTS

如果未提供参数，则使用当前工作目录。

Process

流程

Step 1: Determine Project State

步骤1：确定项目状态

Scan the project root to classify what exists:

bash

undefined

扫描项目根目录，分类现有内容：

bash

undefined

Check for existing meta files

检查现有元文件

ls -la CLAUDE.md AGENTS.md README.md CHANGELOG.md .claude/settings.local.json 2>/dev/null

Check for docs directory

检查docs目录

ls docs/ 2>/dev/null

Check for any code at all

检查是否存在代码

ls -la


**Classify the project into one of four states:**

| State | Description | Behavior |
|-------|-------------|----------|
| **Greenfield** | No code, no meta files | Generate everything from user input |
| **Existing, no meta** | Has code but no CLAUDE.md/docs/ | Explore codebase first, then generate |
| **Partial meta** | Has some meta files (e.g., README exists) | Ask user how to handle each existing file |
| **Full meta** | All meta files already present | Offer to audit and update |

**If existing meta files are found**, use AskUserQuestion to ask:
- Which files to overwrite vs. keep
- Whether to merge content (for README.md especially)

ls -la


**将项目分为以下四种状态之一：**

| 状态 | 描述 | 处理方式 |
|-------|-------------|----------|
| **全新项目（Greenfield）** | 无代码、无元文件 | 根据用户输入生成所有内容 |
| **已有代码但无元文件** | 存在代码但无CLAUDE.md/docs/ | 先探索代码库，再生成内容 |
| **部分元文件** | 存在部分元文件（如已有的README） | 询问用户如何处理每个现有文件 |
| **完整元文件** | 所有元文件已存在 | 提供审核与更新服务 |

**如果发现现有元文件**，使用AskUserQuestion询问：
- 哪些文件需要覆盖，哪些需要保留
- 是否合并内容（尤其是README.md）

Step 2: Explore the Codebase

步骤2：探索代码库

Skip this step for greenfield projects.

For existing projects, perform a thorough exploration:

bash

undefined

全新项目可跳过此步骤。

对于已有项目，执行全面探索：

bash

undefined

Directory structure (top 3 levels)

目录结构（前3层）

find . -maxdepth 3 -type f -not -path './.git/' -not -path './node_modules/' -not -path './vendor/' -not -path './.next/' -not -path './dist/' -not -path './build/' | head -100

Detect language/runtime

检测语言/运行时

ls package.json go.mod Cargo.toml pyproject.toml setup.py Gemfile build.gradle pom.xml mix.exs deno.json bunfig.toml composer.json 2>/dev/null

Package manager and scripts

包管理器与脚本

cat package.json 2>/dev/null | head -80 cat Makefile 2>/dev/null | head -80 cat Taskfile.yml 2>/dev/null | head -80

Entry points

入口文件

ls -la src/ app/ cmd/ lib/ main.* index.* 2>/dev/null

CI/CD configuration

CI/CD配置

ls .github/workflows/*.yml .gitlab-ci.yml Jenkinsfile .circleci/config.yml 2>/dev/null

Lint/format configuration

代码检查/格式化配置

ls .eslintrc* biome.json .prettierrc* .golangci.yml rustfmt.toml .rubocop.yml pyproject.toml 2>/dev/null

Test configuration

测试配置

ls jest.config* vitest.config* pytest.ini .mocharc* 2>/dev/null

Docker

Docker配置

ls Dockerfile docker-compose*.yml 2>/dev/null

Existing documentation

现有文档

ls docs/*.md *.md 2>/dev/null


**Record what you discover:**
- Language(s) and runtime
- Package manager
- Available scripts/make targets (build, test, lint, format, dev, etc.)
- Project structure pattern (monorepo, single app, CLI tool, library, etc.)
- Test framework
- CI/CD setup
- Entry points and architecture style

ls docs/*.md *.md 2>/dev/null


**记录探索结果：**
- 使用的语言及运行时
- 包管理器
- 可用脚本/Make目标（构建、测试、检查、格式化、类型检查等）
- 项目结构模式（单体仓库、单应用、CLI工具、库等）
- 测试框架
- CI/CD设置
- 入口文件与架构风格

Step 3: Gather Project Information

步骤3：收集项目信息

Use AskUserQuestion to collect what can't be determined from code:

Always ask:

One-line project description — "What does this project do in one sentence?"
Core principles — "What are 3-5 rules that should always guide development in this project?" (Offer examples based on what you've seen in the codebase)
Project story — Suggest a short metaphor or narrative that connects the project name to its purpose (2-3 sentences). This goes in the README header to give the project personality. Look for a metaphor grounded in what the name evokes — a physical object, a place, an action — and connect it to what the software actually does. Propose a suggestion and let the user refine it.

Ask only if ambiguous from code: 4. Confirm detected commands if multiple options exist (e.g.,

npm

bun

) 5. Confirm project structure if unclear (monorepo vs single app) 6. External dependencies — "Does this project depend on external services or APIs? List them with how to verify they're working (e.g., health-check endpoints, test commands)." 7. Debugging patterns — "When something breaks, what should be checked first?" (e.g., env/config files, specific log locations, common failure modes) 8. Preferred libraries — "Are there preferred libraries or patterns for common tasks that new code should follow?"

Never ask what's discoverable from code:

Language, framework, test runner, linter — detect these automatically
Available scripts — read package.json/Makefile
Directory structure — explore it

使用AskUserQuestion收集无法从代码中确定的信息：

必问内容：

项目一句话描述 —— "这个项目的核心功能是什么？用一句话概括"
核心原则 —— "指导该项目开发的3-5条规则是什么？"（可基于代码库探索结果提供示例）
项目故事 —— 建议一个简短的隐喻或叙事，将项目名称与用途关联起来（2-3句话）。这段内容会放在README头部，赋予项目独特性。根据项目名称联想合适的隐喻（比如实体物品、场景、动作），并与软件实际功能关联。先提出一个建议，再让用户优化。

仅在代码中信息不明确时询问： 4. 若存在多个选项，确认检测到的命令（如

npm

还是

bun

） 5. 若结构不清晰，确认项目类型（单体仓库还是单应用） 6. 外部依赖 —— "该项目是否依赖外部服务或API？请列出它们及验证可用性的方式（如健康检查端点、测试命令）" 7. 调试模式 —— "当出现问题时，首先应该检查什么？"（如环境/配置文件、特定日志位置、常见故障模式） 8. 偏好库 —— "对于常见任务，是否有新代码应遵循的偏好库或模式？"

无需询问可从代码中获取的信息：

语言、框架、测试运行器、代码检查工具——自动检测
可用脚本——读取package.json/Makefile
目录结构——直接探索

Step 4: Generate CLAUDE.md

步骤4：生成CLAUDE.md

Create

CLAUDE.md

following this exact structure:

markdown

undefined

按照以下固定结构创建

CLAUDE.md

：

markdown

undefined

<Project Name>

<项目名称>

<one-line description from Step 3>

<步骤3中收集的一句话描述>

Commands

命令

<所有检测到的命令，放在代码块中——安装、开发、构建、检查、代码检查、格式化、类型检查、测试等>

Documentation

文档

Document	Purpose
Architecture	System design, data flow, package responsibilities
Development	Prerequisites, setup, daily workflow
Coding Guidelines	Code style, error handling, naming conventions
Testing	Test commands, conventions, patterns
PR Workflow	Commits, PRs, branch naming, review process

文档	用途
架构	系统设计、数据流、包职责
开发指南	前置要求、环境搭建、日常工作流
编码规范	代码风格、错误处理、命名约定
测试指南	测试命令、规范、模式
PR工作流	提交、PR、分支命名、评审流程
<如有需要，添加项目专属文档行>

Core Principles

核心原则

<3-5 principles from Step 3, as a numbered list>

<步骤3中收集的3-5条原则，以有序列表呈现>

Commits

提交规范

Format:

<type>(<scope>): <description>

Types: feat, fix, docs, refactor, test, chore, perf

<2-3 example commit messages using actual project scopes>

格式：

<type>(<scope>): <description>

类型：feat, fix, docs, refactor, test, chore, perf

<2-3个使用项目实际范围的提交示例>

External Dependencies

外部依赖

<services, APIs, and tools the project depends on — with verification commands>

<项目依赖的服务、API及工具——附带验证命令>

Debugging

调试指南

<出现问题时首先要检查的内容——项目专属故障排查模式>

Conventions

约定


**Optional sections:** Include `## External Dependencies`, `## Debugging`, and `## Conventions` only when the user provides relevant information in Step 3. Do not generate empty sections or invent content.

**Critical rules:**
- Commands block must contain ONLY commands that actually exist in the project
- Every command must be verified against package.json scripts, Makefile targets, or equivalent
- Use `<!-- TODO: verify this command -->` if uncertain about a command
- Core principles must come from user input, not be invented

<命名模式、偏好库及提交格式之外的项目专属规则>


**可选章节：** 仅当用户在步骤3中提供了相关信息时，才包含`## 外部依赖`、`## 调试指南`和`## 约定`章节。不要生成空章节或编造内容。

**关键规则：**
- 命令块中只能包含项目中实际存在的命令
- 每个命令都必须与package.json脚本、Makefile目标或等效内容核对
- 若对命令不确定，使用`<!-- TODO: verify this command -->`标记
- 核心原则必须来自用户输入，不得编造

Step 5: Create AGENTS.md, .claude/settings.local.json, and .gitignore

步骤5：创建AGENTS.md、.claude/settings.local.json及.gitignore

bash

undefined

bash

undefined

Create AGENTS.md as a symlink to CLAUDE.md

将AGENTS.md创建为CLAUDE.md的软链接

ln -sf CLAUDE.md AGENTS.md

Create .claude directory

创建.claude目录

mkdir -p .claude


If `.claude/settings.local.json` already exists, merge the attribution keys into it. If it doesn't exist, create it:

```json
{
  "attribution": {
    "commit": "",
    "pr": ""
  }
}

The empty attribution fields suppress Claude Code's default Co-Authored-By lines. This file is user-local and not committed — the "no attribution" rule is also documented in CLAUDE.md for enforcement.

Create
.gitignore
if it doesn't exist. If it already exists, ensure

.claude/

is listed.

The

.claude/

directory contains only user-specific settings (

settings.local.json

with tool permissions and attribution) and should not be committed.

bash

undefined

mkdir -p .claude


如果`.claude/settings.local.json`已存在，将attribution键合并到现有文件中。如果不存在，则创建该文件：

```json
{
  "attribution": {
    "commit": "",
    "pr": ""
  }
}

空的attribution字段会抑制Claude Code默认的Co-Authored-By行。该文件为用户本地文件，无需提交——CLAUDE.md中也会记录“不添加署名”规则以强制执行。

如果.gitignore不存在则创建。如果已存在，确保其中包含

.claude/

条目。

.claude/目录仅包含用户特定设置（带工具权限和署名的settings.local.json），不应被提交。

bash

undefined

Check if .gitignore exists

检查.gitignore是否存在

if [ ! -f .gitignore ]; then

Create with .claude/ entry

echo ".claude/" > .gitignore else

Add .claude/ if not already present

grep -qxF '.claude/' .gitignore || echo '.claude/' >> .gitignore fi


Add other standard entries based on the detected tech stack:
- **Node/Bun**: `node_modules/`, `dist/`, `.env`, `.env.local`
- **Go**: binary name, `vendor/` (if not committed)
- **Python**: `__pycache__/`, `.venv/`, `*.pyc`
- **Rust**: `target/`
- **General**: `.DS_Store`, `*.log`, `coverage/`

**IMPORTANT**: If `.gitignore` already exists, do NOT overwrite it. Only append missing entries.

if [ ! -f .gitignore ]; then

创建包含.claude/的.gitignore

echo ".claude/" > .gitignore else

如果.claude/不存在则添加

grep -qxF '.claude/' .gitignore || echo '.claude/' >> .gitignore fi


根据检测到的技术栈添加其他标准条目：
- **Node/Bun**: `node_modules/`, `dist/`, `.env`, `.env.local`
- **Go**: 二进制文件名、`vendor/`（若未提交）
- **Python**: `__pycache__/`, `.venv/`, `*.pyc`
- **Rust**: `target/`
- **通用**: `.DS_Store`, `*.log`, `coverage/`

**重要提示**：如果.gitignore已存在，请勿覆盖。仅添加缺失的条目。

Step 6: Generate /docs

步骤6：生成/docs目录

Create the

docs/

directory and generate five core documentation files plus any project-specific extras.

bash

mkdir -p docs

Five core docs (always created):

创建

docs/

目录并生成5个核心文档及项目专属的额外文档。

bash

mkdir -p docs

必创建的5个核心文档：

docs/architecture.md

markdown

undefined

markdown

undefined

Architecture

架构

<系统设计概述——项目定位、结构组成>

Project Structure

项目结构

Data Flow

数据流

<数据在系统中的流转方式——请求生命周期、处理管道等>

Package/Module Responsibilities

包/模块职责

undefined

<关键包/模块及其功能的表格或列表>

undefined

docs/development.md

markdown

undefined

markdown

undefined

Development

开发指南

Prerequisites

前置要求

<runtime, language version, tools needed — detected from project>

<从项目中检测到的运行时、语言版本、所需工具>

Setup

环境搭建

<step-by-step from clone to running — based on actual project setup>

<从克隆到运行的分步指南——基于项目实际设置>

Daily Workflow

日常工作流

<常见开发循环——启动开发服务器、运行测试等>

Available Commands

可用命令

undefined

<所有脚本/Make目标的完整列表及说明>

undefined

docs/coding-guidelines.md

markdown

undefined

markdown

undefined

Coding Guidelines

编码规范

Code Style

代码风格

<检测到的风格规则——格式化工具、代码检查配置、导入顺序等>

Error Handling

错误处理

<project's error handling patterns — detected from code or marked TODO>

<项目的错误处理模式——从代码中检测或标记为TODO>

Naming Conventions

命名约定

<从代码中检测到的文件命名、函数命名、变量命名模式>

Documentation

文档规范

undefined

<何时添加注释、文档字符串约定等>

undefined

docs/testing.md

markdown

undefined

markdown

undefined

Testing

测试指南

Running Tests

运行测试

<项目中的精确测试命令>

Test Conventions

测试规范

<测试文件位置、命名、框架专属模式>

Writing Tests

编写测试

<现有测试中检测到的模式——描述你观察到的内容>

Coverage

测试覆盖率

undefined

<若有可用的覆盖率命令及覆盖率要求>

undefined

docs/pr-workflow.md

markdown

undefined

markdown

undefined

PR Workflow

PR工作流

Commit Conventions

提交规范

Format:

<type>(<scope>): <description>

Types: feat, fix, docs, refactor, test, chore, perf

格式：

<type>(<scope>): <description>

类型：feat, fix, docs, refactor, test, chore, perf

Examples

示例

<2-3 examples using actual project scopes>

<2-3个使用项目实际范围的示例>

Branch Naming

分支命名

Format:

<type>/<issue-number>-<short-kebab-description>

格式：

<type>/<issue-number>-<短横线分隔描述>

Examples

示例

<2-3 examples relevant to the project>

<2-3个与项目相关的示例>

PR Checklist

PR检查清单

Review Process

评审流程

<project-specific review norms, or standard forge workflow>


**Additional project-specific docs — offer based on detection:**

| Detected Signal | Suggested Doc |
|-----------------|---------------|
| REST/GraphQL routes, OpenAPI spec | `docs/api-reference.md` |
| Dockerfile, docker-compose | `docs/deployment.md` |
| CI workflow files | `docs/ci.md` |
| Auth middleware, security headers | `docs/security.md` |
| React/Vue/Svelte components | `docs/frontend.md` |
| Database migrations, ORM config | `docs/database.md` |
| Multiple packages/workspaces | `docs/monorepo.md` |

Use AskUserQuestion to offer detected extras:

Based on what I found in the codebase, I'd also suggest creating:

docs/api-reference.md (detected REST routes in src/routes/)
docs/deployment.md (detected Dockerfile and docker-compose.yml)

Which of these would you like me to create?


**Content rules for all docs:**
- Every sentence must be specific to THIS project — no generic filler
- Use `<!-- TODO: ... -->` for anything that can't be determined from code
- Reference actual file paths, actual commands, actual patterns found in the codebase
- Keep each doc focused — if it's getting long, you're adding too much

<项目专属评审规范，或标准Forge工作流>


**项目专属额外文档——根据检测结果提议：**

| 检测到的信号 | 建议创建的文档 |
|-----------------|---------------|
| REST/GraphQL路由、OpenAPI规范 | `docs/api-reference.md` |
| Dockerfile、docker-compose配置 | `docs/deployment.md` |
| CI工作流文件 | `docs/ci.md` |
| 认证中间件、安全头 | `docs/security.md` |
| React/Vue/Svelte组件 | `docs/frontend.md` |
| 数据库迁移、ORM配置 | `docs/database.md` |
| 多包/工作区 | `docs/monorepo.md` |

使用AskUserQuestion提议检测到的额外文档：

根据我在代码库中发现的内容，我还建议创建：

docs/api-reference.md（在src/routes/中检测到REST路由）
docs/deployment.md（检测到Dockerfile和docker-compose.yml）

你希望我创建哪些文档？


**所有文档的内容规则：**
- 每句话都必须针对当前项目——不得使用通用模板内容
- 若无法从代码中确定内容，使用`<!-- TODO: ... -->`标记
- 引用代码库中实际存在的文件路径、命令、模式
- 保持每个文档聚焦——若内容过长，说明添加了过多无关信息

Step 7: Generate README.md

步骤7：生成README.md

If no README.md exists, create one following this structure:

markdown

<p align="center">
  <strong><one-line project description></strong><br>
  <short tagline — a punchy subtitle that complements the description>
</p>

<p align="center">
  <a href="docs/architecture.md">Architecture</a> &middot;
  <a href="docs/development.md">Development</a> &middot;
  <a href="docs/coding-guidelines.md">Guidelines</a> &middot;
  <a href="docs/testing.md">Testing</a> &middot;
  <a href="docs/pr-workflow.md">PR Workflow</a>
</p>

---

<project story from Step 3 — the metaphor connecting the name to the purpose>

---

如果README.md不存在，按照以下结构创建：

markdown

<p align="center">
  <strong><项目一句话描述></strong><br>
  <简短标语——补充描述的醒目副标题>
</p>

<p align="center">
  <a href="docs/architecture.md">架构</a> &middot;
  <a href="docs/development.md">开发指南</a> &middot;
  <a href="docs/coding-guidelines.md">编码规范</a> &middot;
  <a href="docs/testing.md">测试指南</a> &middot;
  <a href="docs/pr-workflow.md">PR工作流</a>
</p>

---

<步骤3中的项目故事——将名称与用途关联的隐喻>

---

Quick Start

快速开始

<从克隆到运行的最简步骤>

Features

核心特性

<关键特性的项目符号列表——从代码库探索结果中提取>

Development

开发

See Development Guide for full setup instructions.

<核心开发命令——安装、开发、测试、代码检查>

详细设置说明请参见开发指南。

Documentation

文档

Document	Purpose
Architecture	System design and data flow
Development	Setup and daily workflow
Coding Guidelines	Code style and conventions
Testing	Test commands and patterns
PR Workflow	Commits, PRs, and review process

文档	用途
架构	系统设计与数据流
开发指南	环境搭建与日常工作流
编码规范	代码风格与约定
测试指南	测试命令与模式
PR工作流	提交、PR与评审流程

Contributing

贡献流程

Create an issue:
```
/forge-create-issue
```
Implement:
```
/forge-implement-issue <number>
```
Self-review:
```
/forge-reflect-pr
```
Address feedback:
```
/forge-address-pr-feedback
```
Update changelog:
```
/forge-update-changelog
```


**Header rules:**
- If the project has a logo (`assets/logo.svg` or similar), add a centered `<img>` above the tagline
- The story paragraph goes between two `---` dividers, right after the nav links
- Keep the story to 2-3 sentences — evocative, not verbose

**If README.md already exists**, use AskUserQuestion:

A README.md already exists. How would you like to proceed?

Replace it entirely with the new structure
Merge — keep existing content and add missing sections
Keep the existing README.md unchanged

undefined

创建Issue：
```
/forge-create-issue
```
实现功能：
```
/forge-implement-issue <编号>
```
自我评审：
```
/forge-reflect-pr
```
处理反馈：
```
/forge-address-pr-feedback
```
更新变更日志：
```
/forge-update-changelog
```


**头部规则：**
- 如果项目有Logo（如`assets/logo.svg`），在标语上方添加居中的`<img>`标签
- 项目故事放在两个`---`分隔符之间，紧跟导航链接之后
- 项目故事控制在2-3句话——生动形象，避免冗长

**如果README.md已存在**，使用AskUserQuestion询问：

已存在README.md文件，你希望如何处理？

用新结构完全替换
合并——保留现有内容并添加缺失章节
保留现有README.md不变

undefined

Step 8: Generate CHANGELOG.md

步骤8：生成CHANGELOG.md

If no CHANGELOG.md exists, create one with header only:

markdown

undefined

如果CHANGELOG.md不存在，仅创建头部：

markdown

undefined

Changelog

变更日志

All notable user-facing changes to this project will be documented in this file.

Changes are grouped by release date and category. Only user-facing changes are included — internal refactors, test updates, and CI changes are omitted.


**If the project has existing git history**, use AskUserQuestion:

This project has existing git history. Would you like me to backfill the changelog from recent commits?

Yes — scan recent commits and create initial entries
No — start fresh from this point forward


If backfilling, follow the `forge-update-changelog` conventions (user-facing, plain language, no jargon).

本文件将记录该项目所有重要的用户可见变更。

变更按发布日期和类别分组。仅包含用户可见的变更——内部重构、测试更新及CI变更无需记录。


**如果项目已有Git历史**，使用AskUserQuestion询问：

该项目已有Git历史记录。你希望我从近期提交中回填变更日志吗？

是——扫描近期提交并创建初始条目
否——从当前节点开始记录


若选择回填，请遵循`forge-update-changelog`规范（用户可见、通俗易懂、无技术黑话）。

Step 9: Commit

步骤9：提交变更

Stage all new and modified meta files and commit:

bash

undefined

暂存所有新建及修改的元文件并提交：

bash

undefined

Stage only the meta files we created/modified

仅暂存我们创建/修改的元文件

git add CLAUDE.md AGENTS.md .gitignore docs/ README.md CHANGELOG.md

Commit with conventional format

按规范格式提交

git commit -m "docs: add agentic engineering meta-structure"


**Do NOT commit if:**
- The user asked for a dry run
- There are unrelated staged changes (unstage them first)
- Any generated file has unresolved questions (ask user first)

git commit -m "docs: add agentic engineering meta-structure"


**以下情况请勿提交：**
- 用户要求执行试运行
- 存在无关的暂存变更（先取消暂存）
- 生成的文件中存在未解决的问题（先询问用户）

Step 10: Summary

步骤10：总结

Present a summary of everything that was created:

text

undefined

展示所有已创建内容的总结：

text

undefined

Setup Complete

搭建完成

Files Created

已创建文件

CLAUDE.md — Project guide with commands, docs table, principles, commit conventions
AGENTS.md — Symlink → CLAUDE.md
.claude/settings.local.json — Attribution settings (user-local, not committed)
.gitignore — Git ignore rules (includes .claude/)
docs/architecture.md — System design and structure
docs/development.md — Prerequisites, setup, workflow
docs/coding-guidelines.md — Code style and conventions
docs/testing.md — Test commands and patterns
docs/pr-workflow.md — Commit, PR, and review conventions <any additional docs created>
README.md — Project overview and quick start
CHANGELOG.md — Ready for entries

CLAUDE.md —— 包含命令、文档列表、核心原则、提交规范的项目指南
AGENTS.md —— 软链接指向CLAUDE.md
.claude/settings.local.json —— 署名设置（用户本地文件，无需提交）
.gitignore —— Git忽略规则（包含.claude/）
docs/architecture.md —— 系统设计与结构
docs/development.md —— 前置要求、环境搭建、工作流
docs/coding-guidelines.md —— 代码风格与规范
docs/testing.md —— 测试命令与模式
docs/pr-workflow.md —— 提交、PR与评审规范 <已创建的额外文档>
README.md —— 项目概览与快速开始
CHANGELOG.md —— 已准备好记录变更

Next Steps

后续步骤

Review each generated file and fill in any  markers
Use /forge-create-issue to plan your first piece of work
Use /forge-implement-issue to start implementing

undefined

审阅每个生成的文件并填充所有标记
使用/forge-create-issue规划首个工作任务
使用/forge-implement-issue开始开发

undefined

Important Guidelines

重要指南

Content Quality

内容质量

No generic boilerplate: Every sentence must be specific to the project. "This project uses React" is specific. "Follow best practices" is not.
Placeholders over fiction: If you can't determine something from the code, use
```

```
rather than making something up.
Derived from exploration: Commands, structure, patterns — all must come from actual codebase analysis, not assumptions.

无通用模板内容：每句话都必须针对当前项目。“本项目使用React”是具体内容，“遵循最佳实践”则不是。
占位符优先于虚构内容：若无法从代码中确定内容，使用
```

```
标记，而非编造内容。
基于探索结果生成：命令、结构、模式——所有内容都必须来自对代码库的实际分析，而非假设。

What NOT to Do

禁止操作

Don't generate docs for a tech stack you didn't detect
Don't invent project principles — ask the user
Don't include attribution lines (Co-Authored-By, etc.) in any commits
Don't include time estimates anywhere
Don't add commands to CLAUDE.md that don't exist in the project
Don't create AGENTS.md as a regular file — it must be a symlink
Don't generate content that contradicts existing project configuration

不要为未检测到的技术栈生成文档
不要编造项目原则——向用户询问
不要在任何提交中添加署名行（如Co-Authored-By）
不要添加时间预估
不要在CLAUDE.md中添加项目中不存在的命令
不要将AGENTS.md创建为普通文件——必须是软链接
不要生成与现有项目配置冲突的内容

Handling Edge Cases

边缘情况处理

Monorepo: Create root-level meta files that reference sub-packages. Suggest per-package CLAUDE.md files as a follow-up.
No tests yet: Create
```
docs/testing.md
```
with
```

```
markers and recommend setting up a test framework.
No CI yet: Skip
```
docs/ci.md
```
but mention it as a follow-up in the summary.
Multiple languages: Document all detected languages in CLAUDE.md commands section, grouped by language.

单体仓库：创建根目录级别的元文件并引用子包。后续可提议为每个子包创建CLAUDE.md文件。
暂无测试：创建
```
docs/testing.md
```
并添加
```

```
标记，同时建议设置测试框架。
暂无CI：跳过
```
docs/ci.md
```
，但在总结中提及可作为后续任务。
多语言项目：在CLAUDE.md的命令章节中按语言分组记录所有检测到的语言。

Related Skills

Example Usage

使用示例

/forge-setup-project
/forge-setup-project /path/to/project

/forge-setup-project
/forge-setup-project /path/to/project