archi

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Archi

Project scaffolding and management for AI-assisted development ("vibe coding").

面向AI辅助开发（“氛围式编码”）的项目脚手架与管理工具。

Workflows

工作流

Command	What it does
`/archi`	Detect context and choose appropriate workflow, or show menu
`/archi init`	Initialize new project with docs structure
`/archi feature`	Manage features (add/start/complete/update)
`/archi status`	Show project overview
`/archi docs`	Sync and update documentation

Users can just run
/archi
- you'll figure out what they need based on context. If it's a new project with no docs structure, offer to initialize. If they're mid-conversation about a feature, offer to track it. When unclear, use AskUserQuestion to let them choose.

Parse

$ARGUMENTS

to route to specific workflows, or detect from context.

命令	功能说明
`/archi`	检测上下文并选择合适的工作流，或显示菜单
`/archi init`	初始化带有文档结构的新项目
`/archi feature`	管理功能（添加/启动/完成/更新）
`/archi status`	显示项目概览
`/archi docs`	同步并更新文档

用户只需运行
/archi
- 系统会根据上下文判断用户需求。如果是无文档结构的新项目，将提供初始化服务；如果用户正在讨论功能相关内容，将提供跟踪服务；若需求不明确，将使用AskUserQuestion让用户选择。

解析

$ARGUMENTS

以路由到特定工作流，或从上下文自动识别。

Initialize Project

初始化项目

Trigger:

/archi init

/archi start

, or when project has no docs structure

Goal: Create SPEC.md and docs folder structure through a conversational interview.

触发条件：

/archi init

、

/archi start

，或项目无文档结构时

目标： 通过交互式对话创建SPEC.md和docs文件夹结构。

Interview the user to understand:

与用户对话以了解以下信息：

Project name (detect from directory/package.json if possible)
What they're building (one sentence)
Who it's for
What problem it solves
Key features (3-5 things it should do)

If there are existing files (README, package.json, etc.), read them to gather context before asking questions. Don't ask permission to read - just read them.

Use AskUserQuestion throughout to gather info interactively. Keep questions simple and beginner-friendly.

项目名称（可从目录/package.json自动识别）
项目定位（一句话描述）
目标用户
解决的问题
核心功能（3-5项）

如果存在现有文件（README、package.json等），请先读取文件以收集上下文信息，无需询问用户许可。

全程使用AskUserQuestion交互式收集信息，问题应简洁易懂，适合新手。

Create this structure:

创建如下结构：

project/
├── SPEC.md
└── docs/
    ├── features/
    │   ├── todo/
    │   ├── doing/
    │   └── done/
    ├── research/
    │   ├── spikes/
    │   └── references/
    └── bugs/

project/
├── SPEC.md
└── docs/
    ├── features/
    │   ├── todo/
    │   ├── doing/
    │   └── done/
    ├── research/
    │   ├── spikes/
    │   └── references/
    └── bugs/

SPEC.md template:

SPEC.md模板：

markdown

undefined

markdown

undefined

{Project Name}

{项目名称}

{One-sentence description}

{一句话描述}

Problem

问题

{What problem does this solve}

{解决的具体问题}

Users

用户

{Who is this for}

{目标用户群体}

Features

功能

{Feature}
{Feature} ...

{功能点}
{功能点} ...

Out of Scope

范围外内容

待确定

Success Criteria

成功标准


After creating, suggest next steps like adding their first feature.

---

待确定


创建完成后，建议用户进行下一步操作，比如添加首个功能。

---

Feature Management

功能管理

Trigger:

/archi feature

, or when user mentions working on/completing something

Goal: Track features through todo → doing → done lifecycle.

触发条件：

/archi feature

，或用户提及正在开发/完成某项功能时

目标： 跟踪功能从todo → doing → done的生命周期。

Capabilities:

功能：

Add new feature → create file in
```
docs/features/todo/
```
Start feature → move from
```
todo/
```
to
```
doing/
```
, add started date
Complete feature → move from
```
doing/
```
to
```
done/
```
, add completed date
Update progress → edit existing feature file

Detect intent from conversation context. If user says "I just finished the auth system", offer to mark it done. If they say "I'm going to work on payments", offer to start that feature or create it if it doesn't exist.

添加新功能 → 在
```
docs/features/todo/
```
中创建文件
启动功能 → 从
```
todo/
```
移动到
```
doing/
```
，添加启动日期
完成功能 → 从
```
doing/
```
移动到
```
done/
```
，添加完成日期
更新进度 → 编辑现有功能文件

从对话上下文识别用户意图。如果用户说“我刚完成了认证系统”，则提供标记为已完成的服务；如果用户说“我要开发支付功能”，则提供启动该功能或创建新功能的服务（若不存在）。

Feature file format:

功能文件格式：

Todo:

yaml

---
title: Feature Name
priority: high | medium | low
---

待办（Todo）：

yaml

---
title: 功能名称
priority: high | medium | low
---

Feature Name

功能名称

Description and requirements...


**Doing:**
```yaml
---
title: Feature Name
priority: high
started: 2026-01-23
---

描述与需求...


**进行中（Doing）：**
```yaml
---
title: 功能名称
priority: high
started: 2026-01-23
---

Feature Name

功能名称

Progress

进度

What's been done
What's next


**Done:**
```yaml
---
title: Feature Name
category: Core | Enhancement | Fix | Infrastructure
completed: 2026-01-23
---

已完成内容
下一步计划


**已完成（Done）：**
```yaml
---
title: 功能名称
category: Core | Enhancement | Fix | Infrastructure
completed: 2026-01-23
---

Feature Name

功能名称

Summary of what was built.


Use kebab-case for filenames: `user-authentication.md`

---

已实现内容总结。


文件名使用kebab-case格式：`user-authentication.md`

---

Project Status

项目状态

Trigger:

/archi status

, or when user asks about project state

Goal: Give a quick overview of where the project stands.

Read the docs structure and summarize:

Features in progress (from
```
doing/
```
)
Backlog count and priorities (from
```
todo/
```
)
Recently completed (from
```
done/
```
)
Any research or bugs

Keep it concise and actionable.

触发条件：

/archi status

，或用户询问项目状态时

目标： 快速概览项目当前进展。

读取文档结构并汇总：

进行中的功能（来自
```
doing/
```
）
待办事项数量及优先级（来自
```
todo/
```
）
近期完成的功能（来自
```
done/
```
）
研究内容或Bug

内容应简洁且具有可操作性。

Documentation Sync

文档同步

Trigger:

/archi docs

, or when docs seem out of sync

Goal: Keep project documentation current.

Check for:

SPEC.md reflects current scope
Features mentioned but not tracked
Stale information

Offer to update what's outdated. Don't over-ask - if something clearly needs updating, just suggest the specific changes.

触发条件：

/archi docs

，或文档看起来已过时

目标： 保持项目文档最新。

检查以下内容：

SPEC.md是否反映当前范围
提及但未跟踪的功能
过时信息

提供更新过时内容的服务。无需过度询问，若明确需要更新，直接建议具体修改内容。

Behavior Guidelines

行为准则

Be contextual - detect what the user needs from conversation flow
Be beginner-friendly - no jargon, explain what's happening
Just do it - read files, check structure, don't ask permission for basic operations
Use AskUserQuestion - for choices and gathering info, not for confirmation of obvious actions

Kebab-case filenames -

user-authentication.md

not

UserAuthentication.md

Date format - YYYY-MM-DD

贴合上下文 - 从对话流程中识别用户需求
对新手友好 - 避免行话，解释操作内容
直接操作 - 读取文件、检查结构等基础操作无需询问用户许可
使用AskUserQuestion - 用于选择和收集信息，而非确认明显的操作

文件名使用kebab-case -

user-authentication.md

而非

UserAuthentication.md

日期格式 - YYYY-MM-DD

Handling Existing Documentation

处理现有文档

IMPORTANT: Never overwrite existing documentation without explicit user permission.

When initializing a project that already has documentation (README.md, docs/, SPEC.md, etc.):

Read existing docs first - understand what's already there
Preserve all content - never summarize or condense existing documentation
Adapt to archi format - restructure into the archi structure while keeping ALL original content
Ask before overwriting - if a file would be replaced, ask the user first
Copy when needed - if existing content fits elsewhere, use
```
cp
```
to preserve it before reorganizing

重要提示： 未经用户明确许可，绝不能覆盖现有文档。

当初始化已有文档的项目（README.md、docs/、SPEC.md等）时：

先读取现有文档 - 了解已有的内容
保留所有内容 - 绝不能总结或压缩现有文档
适配Archi格式 - 重构为Archi结构，同时保留所有原始内容
覆盖前询问用户 - 若文件将被替换，需先询问用户
必要时复制 - 若现有内容适合其他位置，先使用
```
cp
```
命令复制再重组

Migration approach:

迁移方法：

Existing README → Extract relevant sections into SPEC.md, keep README for public-facing info
Existing docs/ folder → Move files into appropriate archi subdirectories (features/, research/, etc.)
Existing feature docs → Adapt to feature file format, preserving full content
Existing specs → Merge into SPEC.md sections, keeping all detail

Never lose user content. If unsure where something belongs, ask. If content is substantial, copy the file rather than moving it until the user confirms the new structure works for them.

现有README → 提取相关部分到SPEC.md，保留README作为对外展示信息
现有docs/文件夹 → 将文件移动到Archi对应的子目录（features/、research/等）
现有功能文档 → 适配为功能文件格式，保留全部内容
现有规格文档 → 合并到SPEC.md的对应章节，保留所有细节

绝不能丢失用户内容。 若不确定内容归属，询问用户；若内容较多，在用户确认新结构可行前，优先复制文件而非移动。