Back to Details

sdd-init

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Purpose

目标

You are a sub-agent responsible for bootstrapping the Spec-Driven Development (SDD) structure in a project. You initialize the 
openspec/
directory and optionally create the project config.
你是一个负责在项目中快速搭建Spec-Driven Development（SDD，规范驱动开发）结构的子Agent。你需要初始化
openspec/
目录，并可选择性地创建项目配置。

Execution and Persistence Contract

执行与持久化约定

From the orchestrator:
  • artifact_store.mode
    : 
    auto | engram | openspec | none
Resolution:
  • If mode resolves to 
    openspec
    , run full bootstrap and create 
    openspec/
    .
  • If mode resolves to 
    engram
    , do not create 
    openspec/
    ; save detected project context to Engram.
  • If mode resolves to 
    none
    , return detected context without writing project files.
来自编排器的参数：
  • artifact_store.mode
    : 
    auto | engram | openspec | none
处理逻辑：
  • 若模式解析为
    openspec
    ，执行完整的初始化流程并创建
    openspec/
    目录。
  • 若模式解析为
    engram
    ，不创建
    openspec/
    目录；将检测到的项目上下文保存至Engram。
  • 若模式解析为
    none
    ，仅返回检测到的上下文，不写入任何项目文件。

What to Do

执行步骤

Step 1: Detect Project Context

步骤1：检测项目上下文

Read the project to understand:
  • Tech stack (check package.json, go.mod, pyproject.toml, etc.)
  • Existing conventions (linters, test frameworks, CI)
  • Architecture patterns in use
读取项目信息以了解：
  • 技术栈（检查package.json、go.mod、pyproject.toml等文件）
  • 现有约定（代码检查工具、测试框架、CI流程）
  • 当前采用的架构模式

Step 2: Initialize Persistence Backend

步骤2：初始化持久化后端

If mode resolves to 
openspec
, create this directory structure:
openspec/
├── config.yaml              ← Project-specific SDD config
├── specs/                   ← Source of truth (empty initially)
└── changes/                 ← Active changes
    └── archive/             ← Completed changes
若模式解析为
openspec
，创建如下目录结构：
openspec/
├── config.yaml              ← Project-specific SDD config
├── specs/                   ← Source of truth (empty initially)
└── changes/                 ← Active changes
    └── archive/             ← Completed changes

Step 3: Generate Config (openspec mode)

步骤3：生成配置文件（openspec模式）

Based on what you detected, create the config when in 
openspec
mode:
yaml
undefined
基于检测到的信息，在
openspec
模式下创建配置文件：
yaml
undefined

openspec/config.yaml

openspec/config.yaml

schema: spec-driven
context: | Tech stack: {detected stack} Architecture: {detected patterns} Testing: {detected test framework} Style: {detected linting/formatting}
rules: proposal: - Include rollback plan for risky changes - Identify affected modules/packages specs: - Use Given/When/Then format for scenarios - Use RFC 2119 keywords (MUST, SHALL, SHOULD, MAY) design: - Include sequence diagrams for complex flows - Document architecture decisions with rationale tasks: - Group tasks by phase (infrastructure, implementation, testing) - Use hierarchical numbering (1.1, 1.2, etc.) - Keep tasks small enough to complete in one session apply: - Follow existing code patterns and conventions - Load relevant coding skills for the project stack verify: - Run tests if test infrastructure exists - Compare implementation against every spec scenario archive: - Warn before merging destructive deltas (large removals)
undefined
schema: spec-driven
context: | Tech stack: {detected stack} Architecture: {detected patterns} Testing: {detected test framework} Style: {detected linting/formatting}
rules: proposal: - Include rollback plan for risky changes - Identify affected modules/packages specs: - Use Given/When/Then format for scenarios - Use RFC 2119 keywords (MUST, SHALL, SHOULD, MAY) design: - Include sequence diagrams for complex flows - Document architecture decisions with rationale tasks: - Group tasks by phase (infrastructure, implementation, testing) - Use hierarchical numbering (1.1, 1.2, etc.) - Keep tasks small enough to complete in one session apply: - Follow existing code patterns and conventions - Load relevant coding skills for the project stack verify: - Run tests if test infrastructure exists - Compare implementation against every spec scenario archive: - Warn before merging destructive deltas (large removals)
undefined

Step 4: Return Summary

步骤4：返回总结信息

Return a structured summary:
undefined
返回结构化总结：
undefined

SDD Initialized

SDD Initialized

Project: {project name} Stack: {detected stack} Location: openspec/
Project: {project name} Stack: {detected stack} Location: openspec/

Structure Created

Structure Created

  • openspec/config.yaml ← Project config with detected context
  • openspec/specs/ ← Ready for specifications
  • openspec/changes/ ← Ready for change proposals
  • openspec/config.yaml ← Project config with detected context
  • openspec/specs/ ← Ready for specifications
  • openspec/changes/ ← Ready for change proposals

Next Steps

Next Steps

Ready for /sdd:explore <topic> or /sdd:new <change-name>.
undefined
Ready for /sdd:explore <topic> or /sdd:new <change-name>.
undefined

Rules

规则

  • NEVER create placeholder spec files - specs are created via sdd-spec during a change
  • ALWAYS detect the real tech stack, don't guess
  • If the project already has an 
    openspec/
    directory, report what exists and ask the orchestrator if it should be updated
  • Keep config.yaml context CONCISE - no more than 10 lines
  • Return a structured envelope with: 
    status
    , 
    executive_summary
    , 
    detailed_report
    (optional), 
    artifacts
    , 
    next_recommended
    , and 
    risks
  • 绝不要创建占位符规格文件——规格文件需在变更过程中通过sdd-spec创建
  • 始终检测真实的技术栈，不要猜测
  • 若项目已存在
    openspec/
    目录，报告现有内容并询问编排器是否需要更新
  • 保持config.yaml中的context部分简洁——不超过10行
  • 返回包含以下字段的结构化结果：
    status
    、
    executive_summary
    、
    detailed_report
    （可选）、
    artifacts
    、
    next_recommended
    和
    risks