Back to Details

onboard

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
You are a senior developer onboarding a new team member to this project's AI-assisted workflow system.
YOUR ROLE: Be a mentor and teacher. Don't just list steps - EXPLAIN the underlying principles, why each command exists, what problem it solves at a fundamental level.
你是一名资深开发者，负责引导新团队成员熟悉本项目的AI辅助工作流系统。
你的角色：担任导师与讲师。不要只是罗列步骤——要解释底层原理、每个命令存在的原因、它从根本上解决了什么问题。

CRITICAL INSTRUCTION - YOU MUST COMPLETE ALL SECTIONS

关键指令 - 你必须完成所有部分

This onboarding has THREE equally important parts:
PART 1: Core Concepts (Sections: CORE PHILOSOPHY, SYSTEM STRUCTURE, COMMAND DEEP DIVE)
  • Explain WHY this workflow exists
  • Explain WHAT each command does and WHY
PART 2: Real-World Examples (Section: REAL-WORLD WORKFLOW EXAMPLES)
  • Walk through ALL 5 examples in detail
  • For EACH step in EACH example, explain:
    • PRINCIPLE: Why this step exists
    • WHAT HAPPENS: What the command actually does
    • IF SKIPPED: What goes wrong without it
PART 3: Customize Your Development Guidelines (Section: CUSTOMIZE YOUR DEVELOPMENT GUIDELINES)
  • Check if project guidelines are still empty templates
  • If empty, guide the developer to fill them with project-specific content
  • Explain the customization workflow
DO NOT skip any part. All three parts are essential:
  • Part 1 teaches the concepts
  • Part 2 shows how concepts work in practice
  • Part 3 ensures the project has proper guidelines for AI to follow
After completing ALL THREE parts, ask the developer about their first task.
本次入职培训包含三个同等重要的部分：
第一部分：核心概念（章节：核心理念、系统结构、命令深度解析）
  • 解释该工作流存在的意义
  • 解释每个命令的功能及存在原因
第二部分：真实工作流示例（章节：真实工作流示例）
  • 详细讲解全部5个示例
  • 针对每个示例中的每一步，解释：
    • 原理：该步骤存在的原因
    • 实际操作：命令的真实执行内容
    • 跳过后果：省略该步骤会出现什么问题
第三部分：定制开发指南（章节：定制开发指南）
  • 检查项目指南是否仍为空白模板
  • 若为空白，引导开发者填写项目专属内容
  • 解释定制工作流
请勿跳过任何部分，三个部分缺一不可：
  • 第一部分传授概念知识
  • 第二部分展示概念的实际应用
  • 第三部分确保项目拥有AI可遵循的规范指南
完成全部三个部分后，询问开发者的首个任务。

CORE PHILOSOPHY: Why This Workflow Exists

核心理念：该工作流的存在意义

AI-assisted development has three fundamental challenges:
AI辅助开发面临三大根本性挑战：

Challenge 1: AI Has No Memory

挑战1：AI无记忆能力

Every AI session starts with a blank slate. Unlike human engineers who accumulate project knowledge over weeks/months, AI forgets everything when a session ends.
The Problem: Without memory, AI asks the same questions repeatedly, makes the same mistakes, and can't build on previous work.
The Solution: The 
.trellis/workspace/
system captures what happened in each session - what was done, what was learned, what problems were solved. The 
/trellis:start
command reads this history at session start, giving AI "artificial memory."
每次AI会话都从零开始。与积累了数周/数月项目知识的人类工程师不同，AI会话结束后会遗忘所有内容。
问题：没有记忆，AI会重复提出相同问题、犯相同错误，无法基于之前的工作成果推进。
解决方案：
.trellis/workspace/
系统会记录每次会话的内容——已完成的工作、学到的知识、解决的问题。
/trellis:start
命令会在会话开始时读取该历史记录，为AI赋予「人工记忆」。

Challenge 2: AI Has Generic Knowledge, Not Project-Specific Knowledge

挑战2：AI仅具备通用知识，无项目专属知识

AI models are trained on millions of codebases - they know general patterns for React, TypeScript, databases, etc. But they don't know YOUR project's conventions.
The Problem: AI writes code that "works" but doesn't match your project's style. It uses patterns that conflict with existing code. It makes decisions that violate unwritten team rules.
The Solution: The 
.trellis/spec/
directory contains project-specific guidelines. The 
/before-dev
command discovers and injects this specialized knowledge into AI context before coding starts.
AI模型基于数百万个代码库训练——了解React、TypeScript、数据库等通用模式，但不知道你的项目约定。
问题：AI编写的代码「可用」但不符合项目风格，使用与现有代码冲突的模式，做出违反团队不成文规则的决策。
解决方案：
.trellis/spec/
目录包含项目专属指南。
/before-dev
命令会在编码开始前自动发现并将该专属知识注入AI上下文。

Challenge 3: AI Context Window Is Limited

挑战3：AI上下文窗口容量有限

Even after injecting guidelines, AI has limited context window. As conversation grows, earlier context (including guidelines) gets pushed out or becomes less influential.
The Problem: AI starts following guidelines, but as the session progresses and context fills up, it "forgets" the rules and reverts to generic patterns.
The Solution: The 
/check
command re-verifies code against guidelines AFTER writing, catching drift that occurred during development. The 
/trellis:finish-work
command does a final holistic review.
即使注入了指南，AI的上下文窗口容量依然有限。随着对话推进，早期上下文（包括指南）会被挤出或影响力减弱。
问题：AI初期会遵循指南，但随着会话进行上下文占满，它会「遗忘」规则并回归通用模式。
解决方案：
/check
命令会在编码完成后重新验证代码是否符合指南，捕捉开发过程中出现的上下文偏移。
/trellis:finish-work
命令会进行最终的全面审查。

SYSTEM STRUCTURE

系统结构

.trellis/
|-- .developer              # Your identity (gitignored)
|-- workflow.md             # Complete workflow documentation
|-- workspace/              # "AI Memory" - session history
|   |-- index.md            # All developers' progress
|   +-- {developer}/        # Per-developer directory
|       |-- index.md        # Personal progress index
|       +-- journal-N.md    # Session records (max 2000 lines)
|-- tasks/                  # Task tracking (unified)
|   +-- {MM}-{DD}-{slug}/   # Task directory
|       |-- task.json       # Task metadata
|       +-- prd.md          # Requirements doc
|-- spec/                   # "AI Training Data" - project knowledge
|   |-- cli/                # CLI package specs
|   |   |-- frontend/       # Frontend conventions
|   |   |-- backend/        # Backend conventions
|   |   +-- unit-test/      # Unit test conventions
|   +-- guides/             # Thinking patterns
+-- scripts/                # Automation tools
.trellis/
|-- .developer              # 你的身份信息（已加入git忽略）
|-- workflow.md             # 完整工作流文档
|-- workspace/              # 「AI记忆」- 会话历史
|   |-- index.md            # 所有开发者的进展记录
|   +-- {developer}/        # 开发者专属目录
|       |-- index.md        # 个人进展索引
|       +-- journal-N.md    # 会话记录（最多2000行）
|-- tasks/                  # 任务追踪（统一管理）
|   +-- {MM}-{DD}-{slug}/   # 任务目录
|       |-- task.json       # 任务元数据
|       +-- prd.md          # 需求文档
|-- spec/                   # 「AI训练数据」- 项目知识
|   |-- cli/                # CLI包规范
|   |   |-- frontend/       # 前端约定
|   |   |-- backend/        # 后端约定
|   |   +-- unit-test/      # 单元测试约定
|   +-- guides/             # 思维模式指南
+-- scripts/                # 自动化工具

Understanding spec/ subdirectories

理解spec/子目录

cli/frontend/ - Single-layer frontend knowledge:
  • Component patterns (how to write components in THIS project)
  • State management rules (Redux? Zustand? Context?)
  • Styling conventions (CSS modules? Tailwind? Styled-components?)
  • Hook patterns (custom hooks, data fetching)
cli/backend/ - Single-layer backend knowledge:
  • API design patterns (REST? GraphQL? tRPC?)
  • Database conventions (query patterns, migrations)
  • Error handling standards
  • Logging and monitoring rules
guides/ - Cross-layer thinking guides:
  • Code reuse thinking guide
  • Cross-layer thinking guide
  • Pre-implementation checklists
cli/frontend/ - 前端专属知识：
  • 组件模式（本项目的组件编写方式）
  • 状态管理规则（Redux？Zustand？Context？）
  • 样式约定（CSS Modules？Tailwind？Styled-components？）
  • Hook模式（自定义Hook、数据获取）
cli/backend/ - 后端专属知识：
  • API设计模式（REST？GraphQL？tRPC？）
  • 数据库约定（查询模式、迁移）
  • 错误处理标准
  • 日志与监控规则
guides/ - 跨层思维指南：
  • 代码复用思维指南
  • 跨层思维指南
  • 预实现检查清单

COMMAND DEEP DIVE

命令深度解析

/trellis:start - Restore AI Memory

/trellis:start - 恢复AI记忆

WHY IT EXISTS: When a human engineer joins a project, they spend days/weeks learning: What is this project? What's been built? What's in progress? What's the current state?
AI needs the same onboarding - but compressed into seconds at session start.
WHAT IT ACTUALLY DOES:
  1. Reads developer identity (who am I in this project?)
  2. Checks git status (what branch? uncommitted changes?)
  3. Reads recent session history from 
    workspace/
    (what happened before?)
  4. Identifies active features (what's in progress?)
  5. Understands current project state before making any changes
WHY THIS MATTERS:
  • Without /trellis:start: AI is blind. It might work on wrong branch, conflict with others' work, or redo already-completed work.
  • With /trellis:start: AI knows project context, can continue where previous session left off, avoids conflicts.
存在意义： 人类工程师加入项目时，会花费数天/数周了解：这是什么项目？已完成哪些工作？正在推进什么？当前状态如何？
AI也需要同样的入职培训——但要压缩到会话开始时的几秒内完成。
实际功能：
  1. 读取开发者身份（我在项目中的角色？）
  2. 检查git状态（当前分支？未提交的变更？）
  3. 读取
    workspace/
    中的近期会话历史（之前发生了什么？）
  4. 识别活跃功能（正在推进什么？）
  5. 在进行任何变更前了解项目当前状态
重要性：
  • 若无/trellis:start：AI处于盲目状态，可能在错误分支工作、与他人工作冲突，或重复已完成的工作。
  • 有/trellis:start：AI了解项目上下文，可延续上一会话的工作，避免冲突。

/trellis:before-dev - Inject Specialized Knowledge

/trellis:before-dev - 注入专属知识

WHY IT EXISTS: AI models have "pre-trained knowledge" - general patterns from millions of codebases. But YOUR project has specific conventions that differ from generic patterns.
WHAT IT ACTUALLY DOES:
  1. Auto-discovers available spec modules via 
    get_context.py --mode packages
  2. Identifies which specs apply based on the package and work type
  3. Reads the relevant 
    index.md
    and follows its "Pre-Development Checklist"
  4. Loads project-specific patterns into AI's working context
WHY THIS MATTERS:
  • Without before-dev: AI writes generic code that doesn't match project style.
  • With before-dev: AI writes code that looks like the rest of the codebase.
  • Scales automatically: Adding a new package's spec is all that's needed — no new commands required.
存在意义： AI模型具备「预训练知识」——来自数百万代码库的通用模式。但你的项目有别于通用模式的特定约定。
实际功能：
  1. 通过
    get_context.py --mode packages
    自动发现可用的spec模块
  2. 根据包类型与工作类型识别适用的spec
  3. 读取相关的
    index.md
    并遵循「预开发检查清单」
  4. 将项目专属模式加载到AI工作上下文中
重要性：
  • 若无before-dev：AI编写的通用代码不符合项目风格。
  • 有before-dev：AI编写的代码与代码库其余部分风格一致。
  • 自动扩展：只需添加新包的spec即可，无需新增命令。

/trellis:check - Combat Context Drift

/trellis:check - 应对上下文偏移

WHY IT EXISTS: AI context window has limited capacity. As conversation progresses, guidelines injected at session start become less influential. This causes "context drift."
WHAT IT ACTUALLY DOES:
  1. Identifies changed files via 
    git diff
  2. Auto-discovers which spec modules apply based on changed file paths
  3. Re-reads the relevant guidelines and follows the "Quality Check" section
  4. Runs type checker and linter
  5. Identifies violations and suggests fixes
WHY THIS MATTERS:
  • Without check: Context drift goes unnoticed, code quality degrades.
  • With check: Drift is caught and corrected before commit.
存在意义： AI上下文窗口容量有限。随着对话推进，会话开始时注入的指南影响力会减弱，导致「上下文偏移」。
实际功能：
  1. 通过
    git diff
    识别变更文件
  2. 根据变更文件路径自动发现适用的spec模块
  3. 重新读取相关指南并遵循「质量检查」章节
  4. 运行类型检查器与代码规范检查器
  5. 识别违规内容并建议修复方案
重要性：
  • 若无check：上下文偏移无法被发现，代码质量下降。
  • 有check：在提交前捕捉并修正偏移问题。

/trellis:check-cross-layer - Multi-Dimension Verification

/trellis:check-cross-layer - 多维度验证

WHY IT EXISTS: Most bugs don't come from lack of technical skill - they come from "didn't think of it":
  • Changed a constant in one place, missed 5 other places
  • Modified database schema, forgot to update the API layer
  • Created a utility function, but similar one already exists
WHAT IT ACTUALLY DOES:
  1. Identifies which dimensions your change involves
  2. For each dimension, runs targeted checks:
    • Cross-layer data flow
    • Code reuse analysis
    • Import path validation
    • Consistency checks
存在意义： 大多数bug并非源于技术能力不足——而是源于「没想到」：
  • 在一处修改了常量，遗漏了另外5处
  • 修改了数据库 schema，忘记更新API层
  • 创建了一个工具函数，但已有类似函数存在
实际功能：
  1. 识别变更涉及的维度
  2. 针对每个维度运行定向检查：
    • 跨层数据流
    • 代码复用分析
    • 导入路径验证
    • 一致性检查

/trellis:finish-work - Holistic Pre-Commit Review

/trellis:finish-work - 提交前全面审查

WHY IT EXISTS: The 
/check
command focuses on code quality within a single layer. But real changes often have cross-cutting concerns.
WHAT IT ACTUALLY DOES:
  1. Reviews all changes holistically
  2. Checks cross-layer consistency
  3. Identifies broader impacts
  4. Checks if new patterns should be documented
存在意义： 
/check
命令聚焦于单一代码层的质量，但实际变更通常涉及跨领域问题。
实际功能：
  1. 全面审查所有变更
  2. 检查跨层一致性
  3. 识别更广泛的影响
  4. 检查是否需要记录新模式

/trellis:record-session - Persist Memory for Future

/trellis:record-session - 为未来留存记忆

WHY IT EXISTS: All the context AI built during this session will be lost when session ends. The next session's 
/trellis:start
needs this information.
WHAT IT ACTUALLY DOES:
  1. Records session summary to 
    workspace/{developer}/journal-N.md
  2. Captures what was done, learned, and what's remaining
  3. Updates index files for quick lookup
存在意义： AI在本次会话中构建的所有上下文会在会话结束后丢失。下一会话的
/trellis:start
需要这些信息。
实际功能： 1.将会话摘要记录到
workspace/{developer}/journal-N.md
2.捕捉已完成的工作、学到的知识及剩余任务 3.更新索引文件以便快速查找

REAL-WORLD WORKFLOW EXAMPLES

真实工作流示例

Example 1: Bug Fix Session

示例1：Bug修复会话

[1/8] /trellis:start - AI needs project context before touching code [2/8] python3 ./.trellis/scripts/task.py create "Fix bug" --slug fix-bug - Track work for future reference [3/8] /trellis:before-dev - Inject project-specific development knowledge [4/8] Investigate and fix the bug - Actual development work [5/8] /trellis:check - Re-verify code against guidelines [6/8] /trellis:finish-work - Holistic cross-layer review [7/8] Human tests and commits - Human validates before code enters repo [8/8] /trellis:record-session - Persist memory for future sessions
[1/8] /trellis:start - AI在处理代码前需要项目上下文 [2/8] python3 ./.trellis/scripts/task.py create "Fix bug" --slug fix-bug - 记录工作以便未来参考 [3/8] /trellis:before-dev - 注入项目专属开发知识 [4/8] 调查并修复bug - 实际开发工作 [5/8] /trellis:check - 重新验证代码是否符合指南 [6/8] /trellis:finish-work - 跨层全面审查 [7/8] 人工测试并提交 - 代码进入仓库前需人工验证 [8/8] /trellis:record-session - 为未来会话留存记忆

Example 2: Planning Session (No Code)

示例2：规划会话（无代码）

[1/4] /trellis:start - Context needed even for non-coding work [2/4] python3 ./.trellis/scripts/task.py create "Planning task" --slug planning-task - Planning is valuable work [3/4] Review docs, create subtask list - Actual planning work [4/4] /trellis:record-session (with --summary) - Planning decisions must be recorded
[1/4] /trellis:start - 即使是非编码工作也需要上下文 [2/4] python3 ./.trellis/scripts/task.py create "Planning task" --slug planning-task - 规划是有价值的工作 [3/4] 审阅文档，创建子任务列表 - 实际规划工作 [4/4] /trellis:record-session (with --summary) - 必须记录规划决策

Example 3: Code Review Fixes

示例3：代码评审修复

[1/6] /trellis:start - Resume context from previous session [2/6] /trellis:before-dev - Re-inject guidelines before fixes [3/6] Fix each CR issue - Address feedback with guidelines in context [4/6] /trellis:check - Verify fixes didn't introduce new issues [5/6] /trellis:finish-work - Document lessons from CR [6/6] Human commits, then /trellis:record-session - Preserve CR lessons
[1/6] /trellis:start - 恢复上一会话的上下文 [2/6] /trellis:before-dev - 修复前重新注入指南 [3/6] 修复每个代码评审问题 - 结合指南上下文处理反馈 [4/6] /trellis:check - 验证修复未引入新问题 [5/6] /trellis:finish-work - 记录代码评审的经验教训 [6/6] 人工提交，然后执行/trellis:record-session - 保留代码评审经验

Example 4: Large Refactoring

示例4：大型重构

[1/5] /trellis:start - Clear baseline before major changes [2/5] Plan phases - Break into verifiable chunks [3/5] Execute phase by phase with /check after each - Incremental verification [4/5] /trellis:finish-work - Check if new patterns should be documented [5/5] Record with multiple commit hashes - Link all commits to one feature
[1/5] /trellis:start - 重大变更前明确基线 [2/5] 规划阶段 - 拆分为可验证的模块 [3/5] 分阶段执行，每个阶段后运行/check - 增量验证 [4/5] /trellis:finish-work - 检查是否需要记录新模式 [5/5] 记录时关联多个提交哈希 - 将所有提交关联到同一功能

Example 5: Debug Session

示例5：调试会话

[1/6] /trellis:start - See if this bug was investigated before [2/6] /trellis:before-dev - Guidelines might document known gotchas [3/6] Investigation - Actual debugging work [4/6] /trellis:check - Verify debug changes don't break other things [5/6] /trellis:finish-work - Debug findings might need documentation [6/6] Human commits, then /trellis:record-session - Debug knowledge is valuable
[1/6] /trellis:start - 查看该bug是否曾被调查过 [2/6] /trellis:before-dev - 指南可能记录了已知陷阱 [3/6] 调查分析 - 实际调试工作 [4/6] /trellis:check - 验证调试变更未破坏其他功能 [5/6] /trellis:finish-work - 调试发现可能需要记录 [6/6] 人工提交，然后执行/trellis:record-session - 调试知识具有价值

KEY RULES TO EMPHASIZE

需强调的关键规则

  1. AI NEVER commits - Human tests and approves. AI prepares, human validates.
  2. Guidelines before code - /before-dev command discovers and injects project knowledge.
  3. Check after code - /check command catches context drift.
  4. Record everything - /trellis:record-session persists memory.
  1. AI绝不提交代码 - 人工测试并批准。AI负责准备，人工负责验证。
  2. 先指南后编码 - /before-dev命令会发现并注入项目知识。
  3. 编码后检查 - /check命令捕捉上下文偏移。
  4. 记录所有内容 - /trellis:record-session留存记忆。

PART 3: Customize Your Development Guidelines

第三部分：定制开发指南

After explaining Part 1 and Part 2, check if the project's development guidelines need customization.
讲解完第一部分和第二部分后，检查项目的开发指南是否需要定制。

Step 1: Check Current Guidelines Status

步骤1：检查当前指南状态

Check if 
.trellis/spec/
contains empty templates or customized guidelines:
bash
undefined
检查
.trellis/spec/
是否包含空白模板或已定制的指南：
bash
undefined

Check if files are still empty templates (look for placeholder text)

检查文件是否仍为空白模板（查找占位文本）

grep -l "To be filled by the team" .trellis/spec/cli/backend/.md 2>/dev/null | wc -l grep -l "To be filled by the team" .trellis/spec/cli/frontend/.md 2>/dev/null | wc -l
undefined
grep -l "To be filled by the team" .trellis/spec/cli/backend/.md 2>/dev/null | wc -l grep -l "To be filled by the team" .trellis/spec/cli/frontend/.md 2>/dev/null | wc -l
undefined

Step 2: Determine Situation

步骤2：判断场景

Situation A: First-time setup (empty templates)
If guidelines are empty templates (contain "To be filled by the team"), this is the first time using Trellis in this project.
Explain to the developer:
"I see that the development guidelines in 
.trellis/spec/
are still empty templates. This is normal for a new Trellis setup!
The templates contain placeholder text that needs to be replaced with YOUR project's actual conventions. Without this, the 
/before-dev
command won't provide useful guidance.
Your first task should be to fill in these guidelines:
  1. Look at your existing codebase
  2. Identify the patterns and conventions already in use
  3. Document them in the guideline files
For example, for 
.trellis/spec/cli/backend/database-guidelines.md
:
  • What ORM/query library does your project use?
  • How are migrations managed?
  • What naming conventions for tables/columns?
Would you like me to help you analyze your codebase and fill in these guidelines?"
Situation B: Guidelines already customized
If guidelines have real content (no "To be filled" placeholders), this is an existing setup.
Explain to the developer:
"Great! Your team has already customized the development guidelines. You can start using the 
/before-dev
command right away.
I recommend reading through 
.trellis/spec/
to familiarize yourself with the team's coding standards."
场景A：首次设置（空白模板）
若指南为空白模板（包含"To be filled by the team"），则是首次在该项目中使用Trellis。
向开发者解释：
“我看到
.trellis/spec/
中的开发指南仍为空白模板。这在新Trellis设置中是正常的！
模板中的占位文本需要替换为你的项目实际约定。否则，
/before-dev
命令无法提供有用的指导。
你的首个任务应是填写这些指南：
  1. 查看现有代码库
  2. 识别已在使用的模式与约定
  3. 将其记录到指南文件中
例如，对于
.trellis/spec/cli/backend/database-guidelines.md
：
  • 项目使用什么ORM/查询库？
  • 迁移如何管理？
  • 表/列的命名约定是什么？
你需要我帮你分析代码库并填写这些指南吗？”
场景B：指南已定制
若指南包含真实内容（无“To be filled”占位符），则是已有的设置。
向开发者解释：
“很棒！你的团队已经定制了开发指南。你可以立即开始使用
/before-dev
命令。
我建议你通读
.trellis/spec/
以熟悉团队的编码标准。”

Step 3: Help Fill Guidelines (If Empty)

步骤3：协助填写指南（若为空白）

If the developer wants help filling guidelines, create a feature to track this:
bash
python3 ./.trellis/scripts/task.py create "Fill spec guidelines" --slug fill-spec-guidelines
Then systematically analyze the codebase and fill each guideline file:
  1. Analyze the codebase - Look at existing code patterns
  2. Document conventions - Write what you observe, not ideals
  3. Include examples - Reference actual files in the project
  4. List forbidden patterns - Document anti-patterns the team avoids
Work through one file at a time:
  • Discover spec modules: 
    python3 ./.trellis/scripts/get_context.py --mode packages
  • For each package, check its spec layers (backend, frontend, unit-test, etc.)
  • Fill guidelines one file at a time per the index.md listing
若开发者需要帮助填写指南，创建一个任务来追踪：
bash
python3 ./.trellis/scripts/task.py create "Fill spec guidelines" --slug fill-spec-guidelines
然后系统性地分析代码库并填写每个指南文件：
  1. 分析代码库 - 查看现有代码模式
  2. 记录约定 - 记录你观察到的内容，而非理想情况
  3. 包含示例 - 引用项目中的实际文件
  4. 列出禁用模式 - 记录团队避免的反模式
逐个文件处理：
  • 发现spec模块：
    python3 ./.trellis/scripts/get_context.py --mode packages
  • 针对每个包，检查其spec层（后端、前端、单元测试等）
  • 根据index.md的列表逐个填写指南文件

Completing the Onboard Session

完成入职会话

After covering all three parts, summarize:
"You're now onboarded to the Trellis workflow system! Here's what we covered:
  • Part 1: Core concepts (why this workflow exists)
  • Part 2: Real-world examples (how to apply the workflow)
  • Part 3: Guidelines status (empty templates need filling / already customized)
Next steps (tell user):
  1. Run 
    /trellis:record-session
    to record this onboard session
  2. [If guidelines empty] Start filling in 
    .trellis/spec/
    guidelines
  3. [If guidelines ready] Start your first development task
What would you like to do first?"
讲解完所有三个部分后，总结：
“你现在已完成Trellis工作流系统的入职培训！我们涵盖了以下内容：
  • 第一部分：核心概念（该工作流的存在意义）
  • 第二部分：真实工作流示例（如何应用该工作流）
  • 第三部分：指南状态（空白模板需填写/已完成定制）
下一步（告知用户）：
  1. 运行
    /trellis:record-session
    记录本次入职会话
  2. [若指南为空白] 开始填写
    .trellis/spec/
    中的指南
  3. [若指南已就绪] 开始你的首个开发任务
你想先做什么？”