用户输入 在继续之前，您 必须 考虑用户输入（如果不为空）。 大纲 您正在更新位于 的项目章程。此文件源自一个模板assets/constitution-template.md，包含方括号中的占位符令牌（例如 、 ）。您的工作是：(a) 收集/推导具体值，(b) 精确填充模板，以及 (c) 在依赖工件中传播任何修订。 遵循此执行流程： 1. 将 所有文件（包括子目录）按原目录结构复制到仓库根目录下的 目录，跳过已有文件， 不能覆盖原有同名文件 。cp命令的 -n（--no-clobber）选项可以防止覆盖已存在的文件。 在此阶段，您的项目文件夹内容应类似于以下内容： 2. 加载位于相对仓库根目录 的现有章程模板。 - 识别形式为 的每个占位符令牌。 重要 ：用户可能需要比模板中使用的更少或更多的原则。如果指定了数量，请遵守该数量 - 遵循通用模板。您将相应地更新文档。 3. 收集/推导占位符的值： - 如果用户输入（对话）提供了值，则使用它。 - 否则从现有仓库上下文推断（README、文档、嵌入的先前章程版本）。 - 对于治理日期： 是原始采用日期（如果未知则询问或标记 TODO），如果有更改则 是今天，否则保持之前的日期。 - 必须根据语义版本规则递增： - 主版本：向后不兼容的治理/原则删除或重新定义。 - 次版本：添加新原则/章节或实质性扩展指导。 - 补丁：澄清、措辞、…

| head -3 | tr '\\n' '-' | sed 's/-$//'\n fi\n}\n\n# 生成分支名\nif [ -n \"$SHORT_NAME\" ]; then\n # 使用提供的短名，并进行清理\n BRANCH_SUFFIX=$(echo \"$SHORT_NAME\" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/-\\+/-/g' | sed 's/^-//' | sed 's/-$//')\nelse\n # 基于描述生成短名（智能过滤）\n BRANCH_SUFFIX=$(generate_branch_name \"$FEATURE_DESCRIPTION\")\nfi\n\n# 确定分支编号\nif [ -z \"$BRANCH_NUMBER\" ]; then\n if [ \"$HAS_GIT\" = true ]; then\n # 检查远端现有分支\n BRANCH_NUMBER=$(check_existing_branches \"$BRANCH_SUFFIX\")\n else\n # 回退到本地目录检查\n HIGHEST=0\n if [ -d \"$SPECS_DIR\" ]; then\n for dir in \"$SPECS_DIR\"/*; do\n [ -d \"$dir\" ] || continue\n dirname=$(basename \"$dir\")\n number=$(echo \"$dirname\" | grep -o '^[0-9]\\+' || echo \"0\")\n number=$((10#$number))\n if [ \"$number\" -gt \"$HIGHEST\" ]; then HIGHEST=$number; fi\n done\n fi\n BRANCH_NUMBER=$((HIGHEST + 1))\n fi\nfi\n\nFEATURE_NUM=$(printf \"%03d\" \"$BRANCH_NUMBER\")\nBRANCH_NAME=\"${FEATURE_NUM}-${BRANCH_SUFFIX}\"\n\n# GitHub 对分支名有 244 字节限制\n# 如超限则进行校验与截断\nMAX_BRANCH_LENGTH=244\nif [ ${#BRANCH_NAME} -gt $MAX_BRANCH_LENGTH ]; then\n # 计算需要从后缀截取的长度（特性编号 3 + 连字符 1 = 4）\n MAX_SUFFIX_LENGTH=$((MAX_BRANCH_LENGTH - 4))\n \n # 尽可能在词边界进行截断\n TRUNCATED_SUFFIX=$(echo \"$BRANCH_SUFFIX\" | cut -c1-$MAX_SUFFIX_LENGTH)\n # 若截断产生尾部连字符则移除\n TRUNCATED_SUFFIX=$(echo \"$TRUNCATED_SUFFIX\" | sed 's/-$//')\n \n ORIGINAL_BRANCH_NAME=\"$BRANCH_NAME\"\n BRANCH_NAME=\"${FEATURE_NUM}-${TRUNCATED_SUFFIX}\"\n \n >&2 echo \"[specify] 警告: 分支名称超过 GitHub 的 244 字节限制\"\n >&2 echo \"[specify] 原始: $ORIGINAL_BRANCH_NAME (${#ORIGINAL_BRANCH_NAME} 字节)\"\n >&2 echo \"[specify] 已截断为: $BRANCH_NAME (${#BRANCH_NAME} 字节)\"\nfi\n\nif [ \"$HAS_GIT\" = true ]; then\n git checkout -b \"$BRANCH_NAME\"\nelse\n >&2 echo \"[specify] 警告: 未检测到 Git 仓库；已跳过分支创建: $BRANCH_NAME\"\nfi\n\nFEATURE_DIR=\"$SPECS_DIR/$BRANCH_NAME\"\nmkdir -p \"$FEATURE_DIR\"\n\nTEMPLATE=\"$REPO_ROOT/.specify/templates/spec-template.md\"\nSPEC_FILE=\"$FEATURE_DIR/spec.md\"\nif [ -f \"$TEMPLATE\" ]; then cp \"$TEMPLATE\" \"$SPEC_FILE\"; else touch \"$SPEC_FILE\"; fi\n\n# 为当前会话设置 SPECIFY_FEATURE 环境变量\nexport SPECIFY_FEATURE=\"$BRANCH_NAME\"\n\nif $JSON_MODE; then\n printf '{\"BRANCH_NAME\":\"%s\",\"SPEC_FILE\":\"%s\",\"FEATURE_NUM\":\"%s\"}\\n' \"$BRANCH_NAME\" \"$SPEC_FILE\" \"$FEATURE_NUM\"\nelse\n echo \"分支名称: $BRANCH_NAME\"\n echo \"规格文件: $SPEC_FILE\"\n echo \"特性编号: $FEATURE_NUM\"\n echo \"已设置 SPECIFY_FEATURE 环境变量为: $BRANCH_NAME\"\nfi\n","content_type":"application/x-sh; charset=utf-8","language":"bash","size":9081,"content_sha256":"d3857ee792cb3a5ea18a5b6ce9a12a0fa6e4f763ced58eeb63abaed7687adb25"},{"filename":"assets/specify/scripts/bash/setup-plan.sh","content":"#!/usr/bin/env bash\n\nset -e\n\n# 解析命令行参数\nJSON_MODE=false\nARGS=()\n\nfor arg in \"$@\"; do\n case \"$arg\" in\n --json) \n JSON_MODE=true \n ;;\n --help|-h) \n echo \"用法: $0 [--json]\"\n echo \" --json 以 JSON 格式输出结果\"\n echo \" --help 显示此帮助信息\"\n exit 0 \n ;;\n *) \n ARGS+=(\"$arg\") \n ;;\n esac\ndone\n\n# 获取脚本目录并加载通用函数\nSCRIPT_DIR=\"$(cd \"$(dirname \"${BASH_SOURCE[0]}\")\" && pwd)\"\nsource \"$SCRIPT_DIR/common.sh\"\n\n# 从通用函数获取所有路径与变量\neval $(get_feature_paths)\n\n# 检查当前是否在正确的特性分支（仅在 Git 仓库中校验）\ncheck_feature_branch \"$CURRENT_BRANCH\" \"$HAS_GIT\" || exit 1\n\n# 确保特性目录存在\nmkdir -p \"$FEATURE_DIR\"\n\n# 若存在计划模板则复制\nTEMPLATE=\"$REPO_ROOT/.specify/templates/plan-template.md\"\nif [[ -f \"$TEMPLATE\" ]]; then\n cp \"$TEMPLATE\" \"$IMPL_PLAN\"\n echo \"已复制计划模板到 $IMPL_PLAN\"\nelse\n echo \"警告: 未在 $TEMPLATE 找到计划模板\"\n # 若模板不存在则创建一个基础计划文件\n touch \"$IMPL_PLAN\"\nfi\n\n# 输出结果\nif $JSON_MODE; then\n printf '{\"FEATURE_SPEC\":\"%s\",\"IMPL_PLAN\":\"%s\",\"SPECS_DIR\":\"%s\",\"BRANCH\":\"%s\",\"HAS_GIT\":\"%s\"}\\n' \\\n \"$FEATURE_SPEC\" \"$IMPL_PLAN\" \"$FEATURE_DIR\" \"$CURRENT_BRANCH\" \"$HAS_GIT\"\nelse\n echo \"规格文件: $FEATURE_SPEC\"\n echo \"实现计划: $IMPL_PLAN\" \n echo \"规格目录: $FEATURE_DIR\"\n echo \"当前分支: $CURRENT_BRANCH\"\n echo \"是否有 Git: $HAS_GIT\"\nfi\n","content_type":"application/x-sh; charset=utf-8","language":"bash","size":1609,"content_sha256":"521a1ab39ac9b0ac29baa1d6e0f1159d2808baba9e4c79b955857a01abe6396f"},{"filename":"assets/specify/scripts/bash/update-agent-context.sh","content":"#!/usr/bin/env bash\n\n# 基于 plan.md 更新代理上下文文件\n#\n# 本脚本通过解析特性规格，维护各 AI 代理的上下文文件，\n# 并将项目信息同步到对应的代理配置文件中。\n#\n# 主要功能：\n# 1. 环境校验\n# - 校验 Git 仓库结构与分支信息\n# - 检查必要的 plan.md 与模板文件\n# - 验证文件权限与可访问性\n#\n# 2. 计划数据解析\n# - 解析 plan.md 提取项目元数据\n# - 识别语言/版本、框架、数据库、项目类型\n# - 友好处理缺失或不完整的规格数据\n#\n# 3. 代理文件管理\n# - 需要时从模板创建新的代理上下文文件\n# - 将新增项目信息写入已有代理文件\n# - 保留手动添加的内容与自定义配置\n# - 支持多种代理文件路径与目录结构\n#\n# 4. 内容生成\n# - 生成语言对应的构建/测试命令\n# - 创建合理的项目目录结构示例\n# - 更新技术栈与最近变更章节\n# - 保持一致的格式与时间戳\n#\n# 5. 多代理支持\n# - 处理不同代理的文件路径与命名约定\n# - 支持：Claude、Gemini、Copilot、Cursor、Qwen、opencode、Codex、Windsurf、Kilo Code、Auggie CLI、Roo Code、CodeBuddy CLI、Amp、Amazon Q Developer CLI\n# - 可选择单个代理或更新所有已存在的代理文件\n# - 若不存在代理文件，则默认创建 Claude 文件\n#\n# 用法: ./update-agent-context.sh [agent_type]\n# 支持的代理类型: claude|gemini|copilot|cursor-agent|qwen|opencode|codex|windsurf|kilocode|auggie|q\n# 留空则更新所有已存在的代理文件\n\nset -e\n\n# 启用严格错误处理\nset -u\nset -o pipefail\n\n#==============================================================================\n# 配置与全局变量\n#==============================================================================\n\n# 获取脚本目录并加载通用函数\nSCRIPT_DIR=\"$(cd \"$(dirname \"${BASH_SOURCE[0]}\")\" && pwd)\"\nsource \"$SCRIPT_DIR/common.sh\"\n\n# 从通用函数获取所有路径与变量\neval $(get_feature_paths)\n\nNEW_PLAN=\"$IMPL_PLAN\" # Alias for compatibility with existing code\nAGENT_TYPE=\"${1:-}\"\n\n# 各代理的文件路径 \nCLAUDE_FILE=\"$REPO_ROOT/CLAUDE.md\"\nGEMINI_FILE=\"$REPO_ROOT/GEMINI.md\"\nCOPILOT_FILE=\"$REPO_ROOT/.github/copilot-instructions.md\"\nCURSOR_FILE=\"$REPO_ROOT/.cursor/rules/specify-rules.mdc\"\nQWEN_FILE=\"$REPO_ROOT/QWEN.md\"\nAGENTS_FILE=\"$REPO_ROOT/AGENTS.md\"\nWINDSURF_FILE=\"$REPO_ROOT/.windsurf/rules/specify-rules.md\"\nKILOCODE_FILE=\"$REPO_ROOT/.kilocode/rules/specify-rules.md\"\nAUGGIE_FILE=\"$REPO_ROOT/.augment/rules/specify-rules.md\"\nROO_FILE=\"$REPO_ROOT/.roo/rules/specify-rules.md\"\nCODEBUDDY_FILE=\"$REPO_ROOT/CODEBUDDY.md\"\nAMP_FILE=\"$REPO_ROOT/AGENTS.md\"\nQ_FILE=\"$REPO_ROOT/AGENTS.md\"\n\n# 模板文件\nTEMPLATE_FILE=\"$REPO_ROOT/.specify/templates/agent-file-template.md\"\n\n# 解析后的计划数据的全局变量\nNEW_LANG=\"\"\nNEW_FRAMEWORK=\"\"\nNEW_DB=\"\"\nNEW_PROJECT_TYPE=\"\"\n\n#==============================================================================\n# 工具函数\n#==============================================================================\n\nlog_info() {\n echo \"信息: $1\"\n}\n\nlog_success() {\n echo \"✓ $1\"\n}\n\nlog_error() {\n echo \"错误: $1\" >&2\n}\n\nlog_warning() {\n echo \"警告: $1\" >&2\n}\n\n# 清理临时文件函数\ncleanup() {\n local exit_code=$?\n rm -f /tmp/agent_update_*_$\n rm -f /tmp/manual_additions_$\n exit $exit_code\n}\n\n# 设置清理钩子\ntrap cleanup EXIT INT TERM\n\n#==============================================================================\n# 校验函数\n#==============================================================================\n\nvalidate_environment() {\n # Check if we have a current branch/feature (git or non-git)\n if [[ -z \"$CURRENT_BRANCH\" ]]; then\n log_error \"无法确定当前特性\"\n if [[ \"$HAS_GIT\" == \"true\" ]]; then\n log_info \"请确保当前处于特性分支\"\n else\n log_info \"请设置 SPECIFY_FEATURE 环境变量或先创建特性\"\n fi\n exit 1\n fi\n \n # Check if plan.md exists\n if [[ ! -f \"$NEW_PLAN\" ]]; then\n log_error \"未在 $NEW_PLAN 发现 plan.md\"\n log_info \"请确保正在处理具有对应规格目录的特性\"\n if [[ \"$HAS_GIT\" != \"true\" ]]; then\n log_info \"使用: export SPECIFY_FEATURE=your-feature-name 或先创建新特性\"\n fi\n exit 1\n fi\n \n # Check if template exists (needed for new files)\n if [[ ! -f \"$TEMPLATE_FILE\" ]]; then\n log_warning \"未在 $TEMPLATE_FILE 找到模板文件\"\n log_warning \"创建新的代理文件将失败\"\n fi\n}\n\n#==============================================================================\n# 计划解析函数\n#==============================================================================\n\nextract_plan_field() {\n local field_pattern=\"$1\"\n local plan_file=\"$2\"\n \n grep \"^\\*\\*${field_pattern}\\*\\*: \" \"$plan_file\" 2>/dev/null | \\\n head -1 | \\\n sed \"s|^\\*\\*${field_pattern}\\*\\*: ||\" | \\\n sed 's/^[ \\t]*//;s/[ \\t]*$//' | \\\n grep -v \"NEEDS CLARIFICATION\" | \\\n grep -v \"^N/A$\" || echo \"\"\n}\n\nparse_plan_data() {\n local plan_file=\"$1\"\n \n if [[ ! -f \"$plan_file\" ]]; then\n log_error \"未找到计划文件: $plan_file\"\n return 1\n fi\n \n if [[ ! -r \"$plan_file\" ]]; then\n log_error \"计划文件不可读: $plan_file\"\n return 1\n fi\n \n log_info \"正在解析计划数据: $plan_file\"\n \n NEW_LANG=$(extract_plan_field \"Language/Version\" \"$plan_file\")\n NEW_FRAMEWORK=$(extract_plan_field \"Primary Dependencies\" \"$plan_file\")\n NEW_DB=$(extract_plan_field \"Storage\" \"$plan_file\")\n NEW_PROJECT_TYPE=$(extract_plan_field \"Project Type\" \"$plan_file\")\n \n # Log what we found\n if [[ -n \"$NEW_LANG\" ]]; then\n log_info \"发现语言: $NEW_LANG\"\n else\n log_warning \"在计划中未找到语言信息\"\n fi\n \n if [[ -n \"$NEW_FRAMEWORK\" ]]; then\n log_info \"发现框架: $NEW_FRAMEWORK\"\n fi\n \n if [[ -n \"$NEW_DB\" ]] && [[ \"$NEW_DB\" != \"N/A\" ]]; then\n log_info \"发现数据库: $NEW_DB\"\n fi\n \n if [[ -n \"$NEW_PROJECT_TYPE\" ]]; then\n log_info \"发现项目类型: $NEW_PROJECT_TYPE\"\n fi\n}\n\nformat_technology_stack() {\n local lang=\"$1\"\n local framework=\"$2\"\n local parts=()\n \n # Add non-empty parts\n [[ -n \"$lang\" && \"$lang\" != \"NEEDS CLARIFICATION\" ]] && parts+=(\"$lang\")\n [[ -n \"$framework\" && \"$framework\" != \"NEEDS CLARIFICATION\" && \"$framework\" != \"N/A\" ]] && parts+=(\"$framework\")\n \n # Join with proper formatting\n if [[ ${#parts[@]} -eq 0 ]]; then\n echo \"\"\n elif [[ ${#parts[@]} -eq 1 ]]; then\n echo \"${parts[0]}\"\n else\n # Join multiple parts with \" + \"\n local result=\"${parts[0]}\"\n for ((i=1; i\u003c${#parts[@]}; i++)); do\n result=\"$result + ${parts[i]}\"\n done\n echo \"$result\"\n fi\n}\n\n#==============================================================================\n# 模板与内容生成函数\n#==============================================================================\n\nget_project_structure() {\n local project_type=\"$1\"\n \n if [[ \"$project_type\" == *\"web\"* ]]; then\n echo \"backend/\\\\nfrontend/\\\\ntests/\"\n else\n echo \"src/\\\\ntests/\"\n fi\n}\n\nget_commands_for_language() {\n local lang=\"$1\"\n \n case \"$lang\" in\n *\"Python\"*)\n echo \"cd src && pytest && ruff check .\"\n ;;\n *\"Rust\"*)\n echo \"cargo test && cargo clippy\"\n ;;\n *\"JavaScript\"*|*\"TypeScript\"*)\n echo \"npm test \\\\&\\\\& npm run lint\"\n ;;\n *)\n echo \"# 为 $lang 添加命令\"\n ;;\n esac\n}\n\nget_language_conventions() {\n local lang=\"$1\"\n echo \"$lang: 遵循标准约定\"\n}\n\ncreate_new_agent_file() {\n local target_file=\"$1\"\n local temp_file=\"$2\"\n local project_name=\"$3\"\n local current_date=\"$4\"\n \n if [[ ! -f \"$TEMPLATE_FILE\" ]]; then\n log_error \"Template not found at $TEMPLATE_FILE\"\n return 1\n fi\n \n if [[ ! -r \"$TEMPLATE_FILE\" ]]; then\n log_error \"Template file is not readable: $TEMPLATE_FILE\"\n return 1\n fi\n \n log_info \"正在从模板创建新的代理上下文文件...\"\n \n if ! cp \"$TEMPLATE_FILE\" \"$temp_file\"; then\n log_error \"复制模板文件失败\"\n return 1\n fi\n \n # 替换模板占位符\n local project_structure\n project_structure=$(get_project_structure \"$NEW_PROJECT_TYPE\")\n \n local commands\n commands=$(get_commands_for_language \"$NEW_LANG\")\n \n local language_conventions\n language_conventions=$(get_language_conventions \"$NEW_LANG\")\n \n # 执行占位符替换（带错误检查，使用更安全方式）\n # 通过选择不同分隔符或转义来处理 sed 的特殊字符\n local escaped_lang=$(printf '%s\\n' \"$NEW_LANG\" | sed 's/[\\[\\.*^$()+{}|]/\\\\&/g')\n local escaped_framework=$(printf '%s\\n' \"$NEW_FRAMEWORK\" | sed 's/[\\[\\.*^$()+{}|]/\\\\&/g')\n local escaped_branch=$(printf '%s\\n' \"$CURRENT_BRANCH\" | sed 's/[\\[\\.*^$()+{}|]/\\\\&/g')\n \n # 根据条件构建技术栈与“最近变更”字符串\n local tech_stack\n if [[ -n \"$escaped_lang\" && -n \"$escaped_framework\" ]]; then\n tech_stack=\"- $escaped_lang + $escaped_framework ($escaped_branch)\"\n elif [[ -n \"$escaped_lang\" ]]; then\n tech_stack=\"- $escaped_lang ($escaped_branch)\"\n elif [[ -n \"$escaped_framework\" ]]; then\n tech_stack=\"- $escaped_framework ($escaped_branch)\"\n else\n tech_stack=\"- ($escaped_branch)\"\n fi\n\n local recent_change\n if [[ -n \"$escaped_lang\" && -n \"$escaped_framework\" ]]; then\n recent_change=\"- $escaped_branch: Added $escaped_lang + $escaped_framework\"\n elif [[ -n \"$escaped_lang\" ]]; then\n recent_change=\"- $escaped_branch: Added $escaped_lang\"\n elif [[ -n \"$escaped_framework\" ]]; then\n recent_change=\"- $escaped_branch: Added $escaped_framework\"\n else\n recent_change=\"- $escaped_branch: Added\"\n fi\n\n local substitutions=(\n \"s|\\[PROJECT NAME\\]|$project_name|\"\n \"s|\\[DATE\\]|$current_date|\"\n \"s|\\[EXTRACTED FROM ALL PLAN.MD FILES\\]|$tech_stack|\"\n \"s|\\[ACTUAL STRUCTURE FROM PLANS\\]|$project_structure|g\"\n \"s|\\[ONLY COMMANDS FOR ACTIVE TECHNOLOGIES\\]|$commands|\"\n \"s|\\[LANGUAGE-SPECIFIC, ONLY FOR LANGUAGES IN USE\\]|$language_conventions|\"\n \"s|\\[LAST 3 FEATURES AND WHAT THEY ADDED\\]|$recent_change|\"\n )\n \n for substitution in \"${substitutions[@]}\"; do\n if ! sed -i.bak -e \"$substitution\" \"$temp_file\"; then\n log_error \"占位符替换失败: $substitution\"\n rm -f \"$temp_file\" \"$temp_file.bak\"\n return 1\n fi\n done\n \n # 将 \\n 序列转换为实际换行\n newline=$(printf '\\n')\n sed -i.bak2 \"s/\\\\\\\\n/${newline}/g\" \"$temp_file\"\n \n # 清理备份文件\n rm -f \"$temp_file.bak\" \"$temp_file.bak2\"\n \n return 0\n}\n\n\n\n\nupdate_existing_agent_file() {\n local target_file=\"$1\"\n local current_date=\"$2\"\n \n log_info \"正在更新现有代理上下文文件...\"\n \n # 使用单个临时文件以保证原子更新\n local temp_file\n temp_file=$(mktemp) || {\n log_error \"创建临时文件失败\"\n return 1\n }\n \n # 单次遍历处理文件\n local tech_stack=$(format_technology_stack \"$NEW_LANG\" \"$NEW_FRAMEWORK\")\n local new_tech_entries=()\n local new_change_entry=\"\"\n \n # 准备新的技术栈条目\n if [[ -n \"$tech_stack\" ]] && ! grep -q \"$tech_stack\" \"$target_file\"; then\n new_tech_entries+=(\"- $tech_stack ($CURRENT_BRANCH)\")\n fi\n \n if [[ -n \"$NEW_DB\" ]] && [[ \"$NEW_DB\" != \"N/A\" ]] && [[ \"$NEW_DB\" != \"NEEDS CLARIFICATION\" ]] && ! grep -q \"$NEW_DB\" \"$target_file\"; then\n new_tech_entries+=(\"- $NEW_DB ($CURRENT_BRANCH)\")\n fi\n \n # 准备新的“最近变更”条目\n if [[ -n \"$tech_stack\" ]]; then\n new_change_entry=\"- $CURRENT_BRANCH: 新增 $tech_stack\"\n elif [[ -n \"$NEW_DB\" ]] && [[ \"$NEW_DB\" != \"N/A\" ]] && [[ \"$NEW_DB\" != \"NEEDS CLARIFICATION\" ]]; then\n new_change_entry=\"- $CURRENT_BRANCH: 新增 $NEW_DB\"\n fi\n \n # 检查文件中是否存在相应章节\n local has_active_technologies=0\n local has_recent_changes=0\n \n if grep -q \"^## Active Technologies\" \"$target_file\" 2>/dev/null; then\n has_active_technologies=1\n fi\n \n if grep -q \"^## Recent Changes\" \"$target_file\" 2>/dev/null; then\n has_recent_changes=1\n fi\n \n # 按行处理文件\n local in_tech_section=false\n local in_changes_section=false\n local tech_entries_added=false\n local changes_entries_added=false\n local existing_changes_count=0\n local file_ended=false\n \n while IFS= read -r line || [[ -n \"$line\" ]]; do\n # 处理 Active Technologies 章节\n if [[ \"$line\" == \"## Active Technologies\" ]]; then\n echo \"$line\" >> \"$temp_file\"\n in_tech_section=true\n continue\n elif [[ $in_tech_section == true ]] && [[ \"$line\" =~ ^##[[:space:]] ]]; then\n # 在章节结束前追加新的技术栈条目\n if [[ $tech_entries_added == false ]] && [[ ${#new_tech_entries[@]} -gt 0 ]]; then\n printf '%s\\n' \"${new_tech_entries[@]}\" >> \"$temp_file\"\n tech_entries_added=true\n fi\n echo \"$line\" >> \"$temp_file\"\n in_tech_section=false\n continue\n elif [[ $in_tech_section == true ]] && [[ -z \"$line\" ]]; then\n # 在技术栈章节的空行前追加新条目\n if [[ $tech_entries_added == false ]] && [[ ${#new_tech_entries[@]} -gt 0 ]]; then\n printf '%s\\n' \"${new_tech_entries[@]}\" >> \"$temp_file\"\n tech_entries_added=true\n fi\n echo \"$line\" >> \"$temp_file\"\n continue\n fi\n \n # 处理 Recent Changes 章节\n if [[ \"$line\" == \"## Recent Changes\" ]]; then\n echo \"$line\" >> \"$temp_file\"\n # 在章节标题后立即追加新的变更条目\n if [[ -n \"$new_change_entry\" ]]; then\n echo \"$new_change_entry\" >> \"$temp_file\"\n fi\n in_changes_section=true\n changes_entries_added=true\n continue\n elif [[ $in_changes_section == true ]] && [[ \"$line\" =~ ^##[[:space:]] ]]; then\n echo \"$line\" >> \"$temp_file\"\n in_changes_section=false\n continue\n elif [[ $in_changes_section == true ]] && [[ \"$line\" == \"- \"* ]]; then\n # 仅保留前 2 条已有的变更记录\n if [[ $existing_changes_count -lt 2 ]]; then\n echo \"$line\" >> \"$temp_file\"\n ((existing_changes_count++))\n fi\n continue\n fi\n \n # 更新时间戳\n if [[ \"$line\" =~ \\*\\*Last\\ updated\\*\\*:.*[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] ]]; then\n echo \"$line\" | sed \"s/[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]/$current_date/\" >> \"$temp_file\"\n else\n echo \"$line\" >> \"$temp_file\"\n fi\n done \u003c \"$target_file\"\n \n # 遍历结束后的检查：若仍在技术栈章节且尚未追加新条目\n if [[ $in_tech_section == true ]] && [[ $tech_entries_added == false ]] && [[ ${#new_tech_entries[@]} -gt 0 ]]; then\n printf '%s\\n' \"${new_tech_entries[@]}\" >> \"$temp_file\"\n tech_entries_added=true\n fi\n \n # 若章节不存在，则在文件结尾追加该章节\n if [[ $has_active_technologies -eq 0 ]] && [[ ${#new_tech_entries[@]} -gt 0 ]]; then\n echo \"\" >> \"$temp_file\"\n echo \"## Active Technologies\" >> \"$temp_file\"\n printf '%s\\n' \"${new_tech_entries[@]}\" >> \"$temp_file\"\n tech_entries_added=true\n fi\n \n if [[ $has_recent_changes -eq 0 ]] && [[ -n \"$new_change_entry\" ]]; then\n echo \"\" >> \"$temp_file\"\n echo \"## Recent Changes\" >> \"$temp_file\"\n echo \"$new_change_entry\" >> \"$temp_file\"\n changes_entries_added=true\n fi\n \n # 原子性地将临时文件移动到目标文件\n if ! mv \"$temp_file\" \"$target_file\"; then\n log_error \"Failed to update target file\"\n rm -f \"$temp_file\"\n return 1\n fi\n \n return 0\n}\n#==============================================================================\n# 代理文件更新主函数\n#==============================================================================\n\nupdate_agent_file() {\n local target_file=\"$1\"\n local agent_name=\"$2\"\n \n if [[ -z \"$target_file\" ]] || [[ -z \"$agent_name\" ]]; then\n log_error \"update_agent_file 需要 target_file 和 agent_name 参数\"\n return 1\n fi\n \n log_info \"正在更新 $agent_name 上下文文件: $target_file\"\n \n local project_name\n project_name=$(basename \"$REPO_ROOT\")\n local current_date\n current_date=$(date +%Y-%m-%d)\n \n # Create directory if it doesn't exist\n local target_dir\n target_dir=$(dirname \"$target_file\")\n if [[ ! -d \"$target_dir\" ]]; then\n if ! mkdir -p \"$target_dir\"; then\n log_error \"创建目录失败: $target_dir\"\n return 1\n fi\n fi\n \n if [[ ! -f \"$target_file\" ]]; then\n # Create new file from template\n local temp_file\n temp_file=$(mktemp) || {\n log_error \"Failed to create temporary file\"\n return 1\n }\n \n if create_new_agent_file \"$target_file\" \"$temp_file\" \"$project_name\" \"$current_date\"; then\n if mv \"$temp_file\" \"$target_file\"; then\n log_success \"已创建新的 $agent_name 上下文文件\"\n else\n log_error \"移动临时文件到 $target_file 失败\"\n rm -f \"$temp_file\"\n return 1\n fi\n else\n log_error \"创建新的代理文件失败\"\n rm -f \"$temp_file\"\n return 1\n fi\n else\n # Update existing file\n if [[ ! -r \"$target_file\" ]]; then\n log_error \"无法读取现有文件: $target_file\"\n return 1\n fi\n \n if [[ ! -w \"$target_file\" ]]; then\n log_error \"无法写入现有文件: $target_file\"\n return 1\n fi\n \n if update_existing_agent_file \"$target_file\" \"$current_date\"; then\n log_success \"已更新现有的 $agent_name 上下文文件\"\n else\n log_error \"更新现有代理文件失败\"\n return 1\n fi\n fi\n \n return 0\n}\n\n#==============================================================================\n# 代理类型选择与处理\n#==============================================================================\n\nupdate_specific_agent() {\n local agent_type=\"$1\"\n \n case \"$agent_type\" in\n claude)\n update_agent_file \"$CLAUDE_FILE\" \"Claude Code\"\n ;;\n gemini)\n update_agent_file \"$GEMINI_FILE\" \"Gemini CLI\"\n ;;\n copilot)\n update_agent_file \"$COPILOT_FILE\" \"GitHub Copilot\"\n ;;\n cursor-agent)\n update_agent_file \"$CURSOR_FILE\" \"Cursor IDE\"\n ;;\n qwen)\n update_agent_file \"$QWEN_FILE\" \"Qwen Code\"\n ;;\n opencode)\n update_agent_file \"$AGENTS_FILE\" \"opencode\"\n ;;\n codex)\n update_agent_file \"$AGENTS_FILE\" \"Codex CLI\"\n ;;\n windsurf)\n update_agent_file \"$WINDSURF_FILE\" \"Windsurf\"\n ;;\n kilocode)\n update_agent_file \"$KILOCODE_FILE\" \"Kilo Code\"\n ;;\n auggie)\n update_agent_file \"$AUGGIE_FILE\" \"Auggie CLI\"\n ;;\n roo)\n update_agent_file \"$ROO_FILE\" \"Roo Code\"\n ;;\n codebuddy)\n update_agent_file \"$CODEBUDDY_FILE\" \"CodeBuddy CLI\"\n ;;\n amp)\n update_agent_file \"$AMP_FILE\" \"Amp\"\n ;;\n q)\n update_agent_file \"$Q_FILE\" \"Amazon Q Developer CLI\"\n ;;\n *)\n log_error \"未知代理类型 '$agent_type'\"\n log_error \"期望: claude|gemini|copilot|cursor-agent|qwen|opencode|codex|windsurf|kilocode|auggie|roo|amp|q\"\n exit 1\n ;;\n esac\n}\n\nupdate_all_existing_agents() {\n local found_agent=false\n \n # Check each possible agent file and update if it exists\n if [[ -f \"$CLAUDE_FILE\" ]]; then\n update_agent_file \"$CLAUDE_FILE\" \"Claude Code\"\n found_agent=true\n fi\n \n if [[ -f \"$GEMINI_FILE\" ]]; then\n update_agent_file \"$GEMINI_FILE\" \"Gemini CLI\"\n found_agent=true\n fi\n \n if [[ -f \"$COPILOT_FILE\" ]]; then\n update_agent_file \"$COPILOT_FILE\" \"GitHub Copilot\"\n found_agent=true\n fi\n \n if [[ -f \"$CURSOR_FILE\" ]]; then\n update_agent_file \"$CURSOR_FILE\" \"Cursor IDE\"\n found_agent=true\n fi\n \n if [[ -f \"$QWEN_FILE\" ]]; then\n update_agent_file \"$QWEN_FILE\" \"Qwen Code\"\n found_agent=true\n fi\n \n if [[ -f \"$AGENTS_FILE\" ]]; then\n update_agent_file \"$AGENTS_FILE\" \"Codex/opencode\"\n found_agent=true\n fi\n \n if [[ -f \"$WINDSURF_FILE\" ]]; then\n update_agent_file \"$WINDSURF_FILE\" \"Windsurf\"\n found_agent=true\n fi\n \n if [[ -f \"$KILOCODE_FILE\" ]]; then\n update_agent_file \"$KILOCODE_FILE\" \"Kilo Code\"\n found_agent=true\n fi\n\n if [[ -f \"$AUGGIE_FILE\" ]]; then\n update_agent_file \"$AUGGIE_FILE\" \"Auggie CLI\"\n found_agent=true\n fi\n \n if [[ -f \"$ROO_FILE\" ]]; then\n update_agent_file \"$ROO_FILE\" \"Roo Code\"\n found_agent=true\n fi\n\n if [[ -f \"$CODEBUDDY_FILE\" ]]; then\n update_agent_file \"$CODEBUDDY_FILE\" \"CodeBuddy CLI\"\n found_agent=true\n fi\n\n if [[ -f \"$Q_FILE\" ]]; then\n update_agent_file \"$Q_FILE\" \"Amazon Q Developer CLI\"\n found_agent=true\n fi\n \n # If no agent files exist, create a default Claude file\n if [[ \"$found_agent\" == false ]]; then\n log_info \"未发现现有代理文件，正在创建默认的 Claude 文件...\"\n update_agent_file \"$CLAUDE_FILE\" \"Claude Code\"\n fi\n}\nprint_summary() {\n echo\n log_info \"变更摘要:\"\n \n if [[ -n \"$NEW_LANG\" ]]; then\n echo \" - 新增语言: $NEW_LANG\"\n fi\n \n if [[ -n \"$NEW_FRAMEWORK\" ]]; then\n echo \" - 新增框架: $NEW_FRAMEWORK\"\n fi\n \n if [[ -n \"$NEW_DB\" ]] && [[ \"$NEW_DB\" != \"N/A\" ]]; then\n echo \" - 新增数据库: $NEW_DB\"\n fi\n \n echo\n\n log_info \"用法: $0 [claude|gemini|copilot|cursor-agent|qwen|opencode|codex|windsurf|kilocode|auggie|codebuddy|q]\"\n}\n\n#==============================================================================\n# 主流程执行\n#==============================================================================\n\nmain() {\n # Validate environment before proceeding\n validate_environment\n \n log_info \"=== 正在为特性 $CURRENT_BRANCH 更新代理上下文文件 ===\"\n \n # Parse the plan file to extract project information\n if ! parse_plan_data \"$NEW_PLAN\"; then\n log_error \"解析计划数据失败\"\n exit 1\n fi\n \n # Process based on agent type argument\n local success=true\n \n if [[ -z \"$AGENT_TYPE\" ]]; then\n # No specific agent provided - update all existing agent files\n log_info \"未指定代理类型，更新所有现有代理文件...\"\n if ! update_all_existing_agents; then\n success=false\n fi\n else\n # Specific agent provided - update only that agent\n log_info \"正在更新指定代理: $AGENT_TYPE\"\n if ! update_specific_agent \"$AGENT_TYPE\"; then\n success=false\n fi\n fi\n \n # Print summary\n print_summary\n \n if [[ \"$success\" == true ]]; then\n log_success \"代理上下文更新成功完成\"\n exit 0\n else\n log_error \"代理上下文更新完成但存在错误\"\n exit 1\n fi\n}\n\n# Execute main function if script is run directly\nif [[ \"${BASH_SOURCE[0]}\" == \"${0}\" ]]; then\n main \"$@\"\nfi\n","content_type":"application/x-sh; charset=utf-8","language":"bash","size":24368,"content_sha256":"49e339c0527bb469f21ee125d95d0a7eb59fd8cab99bf02ddb5805261b86cff9"},{"filename":"assets/specify/templates/agent-file-template.md","content":"# [项目名称] 开发指南\n\n自动生成自所有功能计划。最后更新：[日期]\n\n## 活动技术\n\n[从所有计划文件中提取]\n\n## 项目结构\n\n```text\n[来自计划的实际结构]\n```\n\n## 命令\n\n[仅限活动技术的命令]\n\n## 代码风格\n\n[特定语言的规范，仅适用于正在使用的语言]\n\n## 最近变更\n\n[最近3个功能及其添加内容]\n\n\u003c!-- 手动添加开始 -->\n\u003c!-- 手动添加结束 -->","content_type":"text/markdown; charset=utf-8","language":"markdown","size":433,"content_sha256":"a4c5cf54255f8497516475b2a453f6a74a65ee4d949db8532609bc31239fe9c3"},{"filename":"assets/specify/templates/checklist-template.md","content":"# [检查表类型] 检查表：[功能名称]\n\n**目的**：[此检查表涵盖内容的简要描述]\n**创建时间**：[日期]\n**功能**：[链接到 spec.md 或相关文档]\n\n**注意**：此检查表由 `/speckit.checklist` 命令根据功能上下文和要求生成。\n\n\u003c!-- \n ============================================================================\n 重要提示：下面的检查表项目仅为示例项目，仅用于说明。\n\n /speckit.checklist 命令必须根据以下内容替换这些项目：\n - 用户的具体检查表请求\n - 来自 spec.md 的功能要求\n - 来自 plan.md 的技术上下文\n - 来自 tasks.md 的实现细节\n \n 不要在生成的检查表文件中保留这些示例项目。\n ============================================================================\n-->\n\n## [类别 1]\n\n- [ ] CHK001 第一个检查表项目，带有明确的操作\n- [ ] CHK002 第二个检查表项目\n- [ ] CHK003 第三个检查表项目\n\n## [类别 2]\n\n- [ ] CHK004 另一个类别的项目\n- [ ] CHK005 带有特定标准的项目\n- [ ] CHK006 此类别中的最后一个项目\n\n## 备注\n\n- 完成后勾选项目：`[x]`\n- 在线添加评论或发现\n- 链接到相关资源或文档\n- 项目按顺序编号以便于参考","content_type":"text/markdown; charset=utf-8","language":"markdown","size":1255,"content_sha256":"b8bdb728b5b5e08682c5c1750ada615cdc04264c234a9d0a266cde840434781f"},{"filename":"assets/specify/templates/commands/analyze.md","content":"---\ndescription: 在任务生成后，对 spec.md、plan.md 和 tasks.md 进行非破坏性的跨工件一致性和质量分析。\nscripts:\n sh: scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks\n ps: scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks\n---\n\n## 用户输入\n\n```text\n$ARGUMENTS\n```\n\n您**必须**在继续之前考虑用户输入（如果不为空）。\n\n## 目标\n\n在实现之前，识别三个核心工件（`spec.md`、`plan.md`、`tasks.md`）之间的不一致、重复、歧义和未充分说明的项目。此命令必须仅在 `/speckit.tasks` 成功生成完整的 `tasks.md` 后运行。\n\n## 操作约束\n\n**严格只读**：**不要**修改任何文件。输出结构化分析报告。提供可选的补救计划（用户必须明确批准后才能手动调用任何后续编辑命令）。\n\n**宪章权威性**：项目宪章（`/memory/constitution.md`）在此分析范围内是**不可协商的**。宪章冲突自动为关键级别，需要调整规格、计划或任务——而不是稀释、重新解释或默默忽略原则。如果原则本身需要更改，必须在 `/speckit.analyze` 之外的单独、明确的宪章更新中进行。\n\n## 执行步骤\n\n### 1. 初始化分析上下文\n\n从仓库根目录运行一次 `{SCRIPT}` 并解析 JSON 以获取 FEATURE_DIR 和 AVAILABLE_DOCS。推导绝对路径：\n\n- SPEC = FEATURE_DIR/spec.md\n- PLAN = FEATURE_DIR/plan.md\n- TASKS = FEATURE_DIR/tasks.md\n\n如果缺少任何必需文件，则中止并显示错误消息（指示用户运行缺少的先决条件命令）。\n对于参数中的单引号，如 \"I'm Groot\"，使用转义语法：例如 'I'\\''m Groot'（或者如果可能的话使用双引号：\"I'm Groot\"）。\n\n### 2. 加载工件（渐进式披露）\n\n仅加载每个工件的最小必要上下文：\n\n**来自 spec.md：**\n\n- 概述/上下文\n- 功能要求\n- 非功能要求\n- 用户故事\n- 边缘情况（如果存在）\n\n**来自 plan.md：**\n\n- 架构/技术栈选择\n- 数据模型引用\n- 阶段\n- 技术约束\n\n**来自 tasks.md：**\n\n- 任务 ID\n- 描述\n- 阶段分组\n- 并行标记 [P]\n- 引用的文件路径\n\n**来自 constitution：**\n\n- 加载 `/memory/constitution.md` 用于原则验证\n\n### 3. 构建语义模型\n\n创建内部表示（不要在输出中包含原始工件）：\n\n- **要求清单**：每个功能+非功能要求带有一个稳定键（根据祈使句派生 slug；例如，\"用户可以上传文件\" → `user-can-upload-file`）\n- **用户故事/动作清单**：具有验收标准的离散用户动作\n- **任务覆盖映射**：将每个任务映射到一个或多个要求或故事（通过关键词/显式引用模式如 ID 或关键词进行推断）\n- **宪章规则集**：提取原则名称和 MUST/SHOULD 规范性陈述\n\n### 4. 检测过程（高效令牌分析）\n\n专注于高信号发现。限制总数为 50 个发现；在溢出摘要中聚合其余发现。\n\n#### A. 重复检测\n\n- 识别近似重复的要求\n- 标记质量较低的措辞以进行合并\n\n#### B. 歧义检测\n\n- 标记缺乏可测量标准的模糊形容词（快速、可扩展、安全、直观、健壮）\n- 标记未解决的占位符（TODO、TKTK、???、`\u003cplaceholder>` 等）\n\n#### C. 未充分说明\n\n- 有动词但缺少对象或可测量结果的要求\n- 缺少验收标准对齐的用户故事\n- 引用在规格/计划中未定义的文件或组件的任务\n\n#### D. 宪章对齐\n\n- 任何与 MUST 原则冲突的要求或计划元素\n- 缺少宪章中规定的章节或质量门\n\n#### E. 覆盖差距\n\n- 没有关联任务的要求\n- 没有映射要求/故事的任务\n- 未在任务中体现的非功能要求（例如，性能、安全性）\n\n#### F. 不一致\n\n- 术语漂移（同一概念在不同文件中有不同名称）\n- 计划中引用但在规格中缺失的数据实体（反之亦然）\n- 任务排序矛盾（例如，集成任务在基础设置任务之前但没有依赖注释）\n- 冲突的要求（例如，一个要求 Next.js 而另一个指定 Vue）\n\n### 5. 严重性分配\n\n使用此启发式方法来优先处理发现：\n\n- **关键**：违反宪章 MUST、缺少核心规格工件，或阻塞基本功能的零覆盖要求\n- **高**：重复或冲突的要求、模糊的安全/性能属性、不可测试的验收标准\n- **中**：术语漂移、缺少非功能任务覆盖、未充分说明的边缘情况\n- **低**：样式/措辞改进、不影响执行顺序的次要冗余\n\n### 6. 生成紧凑分析报告\n\n输出一个 Markdown 报告（不写入文件）具有以下结构：\n\n## 规格分析报告\n\n| ID | 类别 | 严重性 | 位置 | 摘要 | 建议 |\n|----|----------|----------|-------------|---------|----------------|\n| A1 | 重复 | 高 | spec.md:L120-134 | 两个相似的要求 ... | 合并措辞；保留更清晰的版本 |\n\n（每项发现添加一行；生成以类别首字母为前缀的稳定 ID。）\n\n**覆盖摘要表：**\n\n| 要求键 | 有任务？ | 任务 ID | 备注 |\n|-----------------|-----------|----------|-------|\n\n**宪章对齐问题：**（如果有）\n\n**未映射的任务：**（如果有）\n\n**指标：**\n\n- 总要求\n- 总任务\n- 覆盖率%（有>=1个任务的要求）\n- 歧义计数\n- 重复计数\n- 关键问题计数\n\n### 7. 提供下一步行动\n\n在报告末尾，输出一个简洁的下一步行动块：\n\n- 如果存在关键问题：建议在 `/speckit.implement` 之前解决\n- 如果只有低/中等：用户可以继续，但提供改进建议\n- 提供明确的命令建议：例如，\"使用改进运行 /speckit.specify\"，\"运行 /speckit.plan 调整架构\"，\"手动编辑 tasks.md 添加 'performance-metrics' 的覆盖\"\n\n### 8. 提供补救措施\n\n询问用户：\"您希望我为前 N 个问题建议具体的补救编辑吗？\"（不要自动应用它们。）\n\n## 操作原则\n\n### 上下文效率\n\n- **最小高信号令牌**：专注于可操作的发现，而不是详尽的文档\n- **渐进式披露**：增量加载工件；不要将所有内容倒入分析\n- **高效令牌输出**：限制发现表为 50 行；总结溢出\n- **确定性结果**：在没有更改的情况下重新运行应产生一致的 ID 和计数\n\n### 分析指南\n\n- **永不修改文件**（这是只读分析）\n- **永不虚构缺失部分**（如果缺失，准确报告）\n- **优先处理宪章违规**（这些总是关键的）\n- **使用示例而非详尽规则**（引用具体实例，而非通用模式）\n- **优雅报告零问题**（发出带有覆盖统计的成功报告）\n\n## 上下文\n\n{ARGS}","content_type":"text/markdown; charset=utf-8","language":"markdown","size":6582,"content_sha256":"b66e323bd961a173d29b8b083a511c56343a593f149f2f3941f8223db5ef8f5b"},{"filename":"assets/specify/templates/commands/checklist.md","content":"---\ndescription: 根据用户要求为当前功能生成自定义检查表。\nscripts:\n sh: scripts/bash/check-prerequisites.sh --json\n ps: scripts/powershell/check-prerequisites.ps1 -Json\n---\n\n## 检查表目的：\"中文的单元测试\"\n\n**关键概念**：检查表是**要求编写的单元测试** - 它们验证特定领域中要求的质量、清晰度和完整性。\n\n**不用于验证/测试**：\n\n- ❌ 不是\"验证按钮正确点击\"\n- ❌ 不是\"测试错误处理是否有效\"\n- ❌ 不是\"确认 API 返回 200\"\n- ❌ 不是检查代码/实现是否符合规格\n\n**用于要求质量验证**：\n\n- ✅ \"是否为所有卡片类型定义了视觉层次要求？\"（完整性）\n- ✅ \"是否用特定的尺寸/定位量化了'显著显示'？\"（清晰度）\n- ✅ \"所有交互元素的悬停状态要求是否一致？\"（一致性）\n- ✅ \"是否为键盘导航定义了可访问性要求？\"（覆盖范围）\n- ✅ \"规格是否定义了徽标图像加载失败时的情况？\"（边缘情况）\n\n**比喻**：如果您的规格是用英语编写的代码，那么检查表就是它的单元测试套件。您正在测试要求是否编写良好、完整、明确并准备好实施 - 而不是测试实现是否有效。\n\n## 用户输入\n\n```text\n$ARGUMENTS\n```\n\n您**必须**在继续之前考虑用户输入（如果不为空）。\n\n## 执行步骤\n\n1. **设置**：从仓库根目录运行 `{SCRIPT}` 并解析 JSON 以获取 FEATURE_DIR 和 AVAILABLE_DOCS 列表。\n - 所有文件路径必须是绝对的。\n - 对于参数中的单引号，如 \"I'm Groot\"，使用转义语法：例如 'I'\\''m Groot'（或者如果可能的话使用双引号：\"I'm Groot\"）。\n\n2. **澄清意图（动态）**：推导出最多三个初始上下文澄清问题（无预设目录）。它们必须：\n - 从用户的措辞 + 从规格/计划/任务中提取的信号生成\n - 仅询问会实质性改变检查表内容的信息\n - 如果在 `$ARGUMENTS` 中已经明确，则单独跳过\n - 优先考虑精确性而非广度\n\n 生成算法：\n 1. 提取信号：功能领域关键词（例如，auth, latency, UX, API），风险指标（\"critical\", \"must\", \"compliance\"），利益相关者提示（\"QA\", \"review\", \"security team\"）和明确的交付物（\"a11y\", \"rollback\", \"contracts\"）。\n 2. 将信号聚类到候选关注领域（最多 4 个）按相关性排序。\n 3. 识别可能的受众和时机（作者、审阅者、QA、发布）如果不明确。\n 4. 检测缺失的维度：范围广度、深度/严谨性、风险重点、排除边界、可测量的验收标准。\n 5. 从这些原型中制定问题：\n - 范围细化（例如，\"这应该包括与 X 和 Y 的集成接触点还是仅限于本地模块正确性？\"）\n - 风险优先级（例如，\"这些潜在风险领域中哪些应该接受强制门控检查？\"）\n - 深度校准（例如，\"这是一个轻量级的预提交健全性列表还是正式的发布门？\"）\n - 受众框架（例如，\"这将仅由作者使用还是在 PR 审阅期间由同行使用？\"）\n - 边界排除（例如，\"我们应该明确排除本轮的性能调优项目吗？\"）\n - 场景类别差距（例如，\"未检测到恢复流程——回滚/部分故障路径是否在范围内？\"）\n\n 问题格式规则：\n - 如果提供选项，生成一个紧凑的表格，列：选项 | 候选 | 重要性原因\n - 限制最多 A-E 个选项；如果自由形式答案更清晰则省略表格\n - 永远不要要求用户重述他们已经说过的话\n - 避免推测性类别（无幻觉）。如果不确定，明确询问：\"确认 X 是否在范围内。\"\n\n 无法交互时的默认值：\n - 深度：标准\n - 受众：如果与代码相关则为审阅者（PR）；否则为作者\n - 关注：前 2 个相关性聚类\n\n 输出问题（标记 Q1/Q2/Q3）。回答后：如果≥2 个场景类别（替代/异常/恢复/非功能性领域）仍不清楚，您可以要求最多两个更有针对性的后续问题（Q4/Q5），每个问题附带一行理由（例如，\"未解决的恢复路径风险\"）。不要超过五个总问题。如果用户明确拒绝更多问题则跳过升级。\n\n3. **理解用户请求**：结合 `$ARGUMENTS` + 澄清答案：\n - 推导检查表主题（例如，安全、审阅、部署、用户体验）\n - 整合用户提到的明确必备项目\n - 将焦点选择映射到类别脚手架\n - 从规格/计划/任务中推断任何缺失的上下文（不要幻觉）\n\n4. **加载功能上下文**：从 FEATURE_DIR 读取：\n - spec.md：功能要求和范围\n - plan.md（如果存在）：技术细节、依赖关系\n - tasks.md（如果存在）：实施任务\n\n **上下文加载策略**：\n - 仅加载与活跃关注领域相关的必要部分（避免完整文件转储）\n - 更喜欢将长段落总结为简洁的场景/要求要点\n - 使用渐进式披露：仅在检测到差距时添加后续检索\n - 如果源文档很大，生成中间摘要项目而不是嵌入原始文本\n\n5. **生成检查表** - 创建\"要求的单元测试\"：\n - 如果不存在则创建 `FEATURE_DIR/checklists/` 目录\n - 生成唯一的检查表文件名：\n - 使用基于领域的简短描述性名称（例如，`ux.md`, `api.md`, `security.md`）\n - 格式：`[domain].md`\n - 如果文件存在，则追加到现有文件\n - 从 CHK001 开始顺序编号项目\n - 每个 `/speckit.checklist` 运行创建一个新文件（从不覆盖现有检查表）\n\n **核心原则 - 测试要求，而不是实现**：\n 每个检查表项目必须评估要求本身：\n - **完整性**：所有必要的要求是否存在？\n - **清晰度**：要求是否明确且具体？\n - **一致性**：要求是否相互对齐？\n - **可测量性**：要求是否可以客观验证？\n - **覆盖范围**：是否解决了所有场景/边缘情况？\n\n **类别结构** - 按要求质量维度分组项目：\n - **要求完整性**（是否记录了所有必要的要求？）\n - **要求清晰度**（要求是否具体且明确？）\n - **要求一致性**（要求是否对齐而无冲突？）\n - **验收标准质量**（成功标准是否可测量？）\n - **场景覆盖**（是否解决了所有流程/案例？）\n - **边缘情况覆盖**（是否定义了边界条件？）\n - **非功能性要求**（性能、安全性、可访问性等 - 是否指定？）\n - **依赖关系和假设**（是否记录和验证？）\n - **歧义和冲突**（需要澄清什么？）\n\n **如何编写检查表项目 - \"英语的单元测试\"**：\n\n ❌ **错误**（测试实现）：\n - \"验证着陆页显示 3 个剧集卡片\"\n - \"测试桌面端悬停状态是否有效\"\n - \"确认徽标点击导航到主页\"\n\n ✅ **正确**（测试要求质量）：\n - \"是否明确指定了特色剧集的确切数量和布局？\" [完整性]\n - \"是否用特定的尺寸/定位量化了'显著显示'？\" [清晰度]\n - \"所有交互元素的悬停状态要求是否一致？\" [一致性]\n - \"是否为所有交互式 UI 定义了键盘导航要求？\" [覆盖范围]\n - \"当徽标图像加载失败时是否指定了回退行为？\" [边缘情况]\n - \"是否为异步剧集数据定义了加载状态？\" [完整性]\n - \"规格是否定义了竞争 UI 元素的视觉层次？\" [清晰度]\n\n **项目结构**：\n 每个项目应遵循此模式：\n - 询问要求质量的问题格式\n - 关注规格/计划中编写（或未编写）的内容\n - 包括质量维度在括号中 [完整性/清晰度/一致性等]\n - 检查现有要求时引用规格部分 `[Spec §X.Y]`\n - 使用 `[Gap]` 标记检查缺失的要求\n\n **按质量维度的示例**：\n\n 完整性：\n - \"是否为所有 API 故障模式定义了错误处理要求？ [Gap]\"\n - \"是否为所有交互元素指定了可访问性要求？ [完整性]\"\n - \"是否为响应式布局定义了移动断点要求？ [Gap]\"\n\n 清晰度：\n - \"是否用特定的时间阈值量化了'快速加载'？ [清晰度, Spec §NFR-2]\"\n - \"是否明确定义了'相关剧集'的选择标准？ [清晰度, Spec §FR-5]\"\n - \"是否用可测量的视觉属性定义了'显著'？ [歧义, Spec §FR-4]\"\n\n 一致性：\n - \"所有页面的导航要求是否对齐？ [一致性, Spec §FR-10]\"\n - \"着陆页和详情页的卡片组件要求是否一致？ [一致性]\"\n\n 覆盖范围：\n - \"是否为零状态场景（无剧集）定义了要求？ [覆盖范围, 边缘情况]\"\n - \"是否解决了并发用户交互场景？ [覆盖范围, Gap]\"\n - \"是否为部分数据加载失败指定了要求？ [覆盖范围, 异常流程]\"\n\n 可测量性：\n - \"视觉层次要求是否可测量/可测试？ [验收标准, Spec §FR-1]\"\n - \"是否可以客观验证'平衡的视觉权重'？ [可测量性, Spec §FR-2]\"\n\n **场景分类和覆盖**（要求质量重点）：\n - 检查是否存在要求：主要、替代、异常/错误、恢复、非功能性场景\n - 对于每个场景类别，询问：\"[场景类型] 要求是否完整、清晰且一致？\"\n - 如果场景类别缺失：\"[场景类型] 要求是故意排除还是缺失？ [Gap]\"\n - 包括状态变更时的弹性/回滚：\"是否为迁移失败定义了回滚要求？ [Gap]\"\n\n **可追溯性要求**：\n - 最低要求：≥80% 的项目必须至少包含一个可追溯性引用\n - 每个项目应引用：规格部分 `[Spec §X.Y]`，或使用标记：`[Gap]`、`[Ambiguity]`、`[Conflict]`、`[Assumption]`\n - 如果不存在 ID 系统：\"是否建立了要求和验收标准 ID 方案？ [可追溯性]\"\n\n **表面和解决问题**（要求质量问题）：\n 询问有关要求本身的问题：\n - 歧义：\"'快速' 一词是否用具体指标量化？ [歧义, Spec §NFR-1]\"\n - 冲突：\"§FR-10 和 §FR-10a 中的导航要求是否冲突？ [冲突]\"\n - 假设：\"'始终可用的播客 API' 假设是否已验证？ [假设]\"\n - 依赖关系：\"是否记录了外部播客 API 要求？ [依赖关系, Gap]\"\n - 缺失定义：\"是否用可测量的标准定义了'视觉层次'？ [Gap]\"\n\n **内容整合**：\n - 软上限：如果原始候选项目 > 40，按风险/影响优先排序\n - 合并检查相同要求方面的近似重复项\n - 如果 >5 个低影响边缘情况，创建一个项目：\"边缘情况 X、Y、Z 是否在要求中解决？ [覆盖范围]\"\n\n **🚫 绝对禁止** - 这些使其成为实现测试，而不是要求测试：\n - ❌ 任何以\"验证\"、\"测试\"、\"确认\"、\"检查\" + 实现行为开头的项目\n - ❌ 引用代码执行、用户操作、系统行为\n - ❌ \"正确显示\"、\"正常工作\"、\"按预期功能\"\n - ❌ \"点击\"、\"导航\"、\"渲染\"、\"加载\"、\"执行\"\n - ❌ 测试用例、测试计划、QA 程序\n - ❌ 实现细节（框架、API、算法）\n\n **✅ 必需模式** - 这些测试要求质量：\n - ✅ \"是否为 [场景] 定义/指定/记录了 [要求类型]？\"\n - ✅ \"是否用具体标准量化/澄清了 [模糊术语]？\"\n - ✅ \"[部分 A] 和 [部分 B] 的要求是否一致？\"\n - ✅ \"是否可以客观测量/验证 [要求]？\"\n - ✅ \"要求中是否解决了 [边缘情况/场景]？\"\n - ✅ \"规格是否定义了 [缺失方面]？\"\n\n6. **结构参考**：按照 `templates/checklist-template.md` 中的规范模板生成检查表，包括标题、元部分、类别标题和 ID 格式。如果模板不可用，使用：H1 标题、目的/创建的元行、包含 `- [ ] CHK### \u003c要求项目>` 行的 `##` 类别部分，全局递增 ID 从 CHK001 开始。\n\n7. **报告**：输出创建的检查表的完整路径、项目计数，并提醒用户每次运行都会创建一个新文件。总结：\n - 选择的关注领域\n - 深度级别\n - 参与者/时机\n - 任何包含的用户明确指定的必备项目\n\n**重要**：每个 `/speckit.checklist` 命令调用都使用简短的描述性名称创建检查表文件，除非文件已存在。这允许：\n\n- 不同类型的多个检查表（例如，`ux.md`, `test.md`, `security.md`）\n- 简单、易记的文件名，指示检查表目的\n- 在 `checklists/` 文件夹中轻松识别和导航\n\n为避免混乱，使用描述性类型并在完成后清理过时的检查表。\n\n## 示例检查表类型和示例项目\n\n**用户体验要求质量：** `ux.md`\n\n示例项目（测试要求，而不是实现）：\n\n- \"是否用可测量的标准定义了视觉层次要求？ [清晰度, Spec §FR-1]\"\n- \"是否明确定义了 UI 元素的数量和定位？ [完整性, Spec §FR-1]\"\n- \"交互状态要求（悬停、焦点、活动）是否一致定义？ [一致性]\"\n- \"是否为所有交互元素指定了可访问性要求？ [覆盖范围, Gap]\"\n- \"图像加载失败时是否定义了回退行为？ [边缘情况, Gap]\"\n- \"是否可以客观测量'显著显示'？ [可测量性, Spec §FR-4]\"\n\n**API 要求质量：** `api.md`\n\n示例项目：\n\n- \"是否为所有故障场景指定了错误响应格式？ [完整性]\"\n- \"是否用具体阈值量化了速率限制要求？ [清晰度]\"\n- \"所有端点的身份验证要求是否一致？ [一致性]\"\n- \"是否为外部依赖关系定义了重试/超时要求？ [覆盖范围, Gap]\"\n- \"版本控制策略是否在要求中记录？ [Gap]\"\n\n**性能要求质量：** `performance.md`\n\n示例项目：\n\n- \"是否用具体指标量化了性能要求？ [清晰度]\"\n- \"是否为所有关键用户旅程定义了性能目标？ [覆盖范围]\"\n- \"是否为不同负载条件指定了性能要求？ [完整性]\"\n- \"是否可以客观测量性能要求？ [可测量性]\"\n- \"是否为高负载场景定义了降级要求？ [边缘情况, Gap]\"\n\n**安全要求质量：** `security.md`\n\n示例项目：\n\n- \"是否为所有受保护资源指定了身份验证要求？ [覆盖范围]\"\n- \"是否为敏感信息定义了数据保护要求？ [完整性]\"\n- \"威胁模型是否记录并与要求对齐？ [可追溯性]\"\n- \"安全要求是否与合规义务一致？ [一致性]\"\n- \"是否定义了安全故障/违规响应要求？ [Gap, 异常流程]\"\n\n## 反例：不要做的事情\n\n**❌ 错误 - 这些测试实现，而不是要求：**\n\n```markdown\n- [ ] CHK001 - 验证着陆页显示 3 个剧集卡片 [Spec §FR-001]\n- [ ] CHK002 - 测试桌面端悬停状态是否正确工作 [Spec §FR-003]\n- [ ] CHK003 - 确认徽标点击导航到主页 [Spec §FR-010]\n- [ ] CHK004 - 检查相关剧集部分显示 3-5 个项目 [Spec §FR-005]\n```\n\n**✅ 正确 - 这些测试要求质量：**\n\n```markdown\n- [ ] CHK001 - 是否明确定义了特色剧集的数量和布局？ [完整性, Spec §FR-001]\n- [ ] CHK002 - 是否为所有交互元素一致定义了悬停状态要求？ [一致性, Spec §FR-003]\n- [ ] CHK003 - 是否为所有可点击品牌元素明确了导航要求？ [清晰度, Spec §FR-010]\n- [ ] CHK004 - 是否记录了相关剧集的选择标准？ [Gap, Spec §FR-005]\n- [ ] CHK005 - 是否为异步剧集数据定义了加载状态要求？ [Gap]\n- [ ] CHK006 - 是否可以客观测量\"视觉层次\"要求？ [可测量性, Spec §FR-001]\n```\n\n**主要区别：**\n\n- 错误：测试系统是否正常工作\n- 正确：测试要求是否编写正确\n- 错误：行为验证\n- 正确：要求质量验证\n- 错误：\"它是否做 X？\"\n- 正确：\"X 是否明确定义？\"","content_type":"text/markdown; charset=utf-8","language":"markdown","size":15507,"content_sha256":"8a0f209a6469a25e2fbd92aa7505d15843fea7d0d469a55db904edfbea50891b"},{"filename":"assets/specify/templates/commands/clarify.md","content":"---\ndescription: 通过提出最多 5 个高度针对性的澄清问题并将其答案编码回规格中，识别当前功能规格中未充分说明的领域。\nscripts:\n sh: scripts/bash/check-prerequisites.sh --json --paths-only\n ps: scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly\n---\n\n## 用户输入\n\n```text\n$ARGUMENTS\n```\n\n您**必须**在继续之前考虑用户输入（如果不为空）。\n\n## 大纲\n\n目标：检测并减少活动功能规格中的歧义或缺失决策点，并将澄清直接记录在规格文件中。\n\n注意：此澄清工作流程预计在调用 `/speckit.plan` 之前运行（并完成）。如果用户明确表示他们正在跳过澄清（例如，探索性刺探），您可以继续，但必须警告下游返工风险会增加。\n\n执行步骤：\n\n1. 从仓库根目录运行一次 `{SCRIPT}`（组合 `--json --paths-only` 模式 / `-Json -PathsOnly`）。解析最小 JSON 负载字段：\n - `FEATURE_DIR`\n - `FEATURE_SPEC`\n - （可选捕获 `IMPL_PLAN`, `TASKS` 用于未来的链式流程。）\n - 如果 JSON 解析失败，则中止并指示用户重新运行 `/speckit.specify` 或验证功能分支环境。\n - 对于参数中的单引号，如 \"I'm Groot\"，使用转义语法：例如 'I'\\''m Groot'（或者如果可能的话使用双引号：\"I'm Groot\"）。\n\n2. 加载当前规格文件。使用此分类法执行结构化歧义和覆盖扫描。对于每个类别，标记状态：清晰 / 部分 / 缺失。生成用于优先级排序的内部覆盖图（除非不问问题，否则不要输出原始图）。\n\n 功能范围和行为：\n - 核心用户目标和成功标准\n - 明确的范围外声明\n - 用户角色 / 人物区分\n\n 领域和数据模型：\n - 实体、属性、关系\n - 身份和唯一性规则\n - 生命周期/状态转换\n - 数据量 / 规模假设\n\n 交互和用户体验流程：\n - 关键用户旅程 / 序列\n - 错误/空/加载状态\n - 可访问性或本地化注释\n\n 非功能性质量属性：\n - 性能（延迟、吞吐量目标）\n - 可扩展性（水平/垂直、限制）\n - 可靠性和可用性（正常运行时间、恢复期望）\n - 可观察性（日志、指标、跟踪信号）\n - 安全性和隐私（认证/授权、数据保护、威胁假设）\n - 合规性 / 监管约束（如果有）\n\n 集成和外部依赖：\n - 外部服务/API 和故障模式\n - 数据导入/导出格式\n - 协议/版本假设\n\n 边缘情况和故障处理：\n - 负面场景\n - 速率限制 / 节流\n - 冲突解决（例如，并发编辑）\n\n 约束和权衡：\n - 技术约束（语言、存储、托管）\n - 明确的权衡或被拒绝的替代方案\n\n 术语和一致性：\n - 规范术语表\n - 避免的同义词 / 废弃术语\n\n 完成信号：\n - 验收标准可测试性\n - 可测量的完成定义风格指标\n\n 杂项 / 占位符：\n - TODO 标记 / 未解决的决策\n - 缺乏量化的模糊形容词（\"健壮的\"、\"直观的\"）\n\n 对于状态为部分或缺失的每个类别，添加一个候选问题机会，除非：\n - 澄清不会实质性改变实施或验证策略\n - 信息最好推迟到规划阶段（内部记录）\n\n3. 生成（内部）优先级候选澄清问题队列（最多 5 个）。不要一次性输出所有问题。应用这些约束：\n - 整个会话最多 10 个问题。\n - 每个问题必须可以通过以下方式回答：\n - 短的多项选择（2-5 个不同的、互斥的选项），或\n - 一个单词 / 短语答案（明确约束：\"答案 \u003c=5 个单词\"）。\n - 仅包括其答案实质性影响架构、数据建模、任务分解、测试设计、用户体验行为、运营准备或合规性验证的问题。\n - 确保类别覆盖平衡：尝试首先覆盖最高影响的未解决类别；避免在单个高影响领域（例如，安全态势）未解决时问两个低影响问题。\n - 排除已经回答的问题、琐碎的风格偏好或计划级执行细节（除非阻塞正确性）。\n - 优先考虑减少下游返工风险或防止不一致验收测试的澄清。\n - 如果超过 5 个类别仍未解决，按（影响 * 不确定性）启发式选择前 5 个。\n\n4. 顺序提问循环（交互式）：\n - 一次只提出一个问题。\n - 对于多项选择问题：\n - **分析所有选项**并根据以下确定**最合适的选项**：\n - 项目类型的最佳实践\n - 类似实现中的常见模式\n - 风险降低（安全性、性能、可维护性）\n - 与规格中可见的任何明确项目目标或约束对齐\n - 突出显示您的**推荐选项**在顶部，并提供明确的理由（1-2 句解释为什么这是最佳选择）。\n - 格式为：`**推荐：** 选项 [X] - \u003c理由>`\n - 然后将所有选项呈现为 Markdown 表格：\n\n | 选项 | 描述 |\n |--------|-------------|\n | A | \u003c选项 A 描述> |\n | B | \u003c选项 B 描述> |\n | C | \u003c选项 C 描述>（根据需要添加 D/E 至多 5 个） |\n | 简短 | 提供不同的简短答案（\u003c=5 个单词）（仅在自由形式替代方案适当时包含） |\n\n - 表格后添加：`您可以回复选项字母（例如，\"A\"），通过说\"yes\"或\"recommended\"接受推荐，或提供您自己的简短答案。`\n - 对于简短答案风格（无有意义的离散选项）：\n - 提供您的**建议答案**基于最佳实践和上下文。\n - 格式为：`**建议：** \u003c您的建议答案> - \u003c简要理由>`\n - 然后输出：`格式：简短答案（\u003c=5 个单词）。您可以通过说\"yes\"或\"suggested\"接受建议，或提供您自己的答案。`\n - 用户回答后：\n - 如果用户回复\"yes\"、\"recommended\"或\"suggested\"，使用您之前声明的推荐/建议作为答案。\n - 否则，验证答案映射到一个选项或符合 \u003c=5 个单词的约束。\n - 如果模糊，要求快速澄清（计数仍属于同一问题；不要前进）。\n - 一旦满意，将其记录在工作内存中（尚不写入磁盘）并移至下一个排队问题。\n - 停止进一步提问当：\n - 所有关键歧义提前解决（剩余排队项目变得不必要），或\n - 用户发出完成信号（\"done\"、\"good\"、\"no more\"），或\n - 您达到 5 个已问问题。\n - 永远不要提前透露未来排队的问题。\n - 如果开始时没有有效问题，立即报告没有关键歧义。\n\n5. 每个接受答案后的集成（增量更新方法）：\n - 维护规格的内存表示（启动时加载一次）加上原始文件内容。\n - 对于此会话中的第一个集成答案：\n - 确保存在 `## Clarifications` 部分（如果缺失，则在规格模板中最高级上下文/概述部分之后创建）。\n - 在其下创建（如果不存在）一个 `### Session YYYY-MM-DD` 子标题用于今天。\n - 接受后立即追加一个项目符号行：`- Q: \u003c问题> → A: \u003c最终答案>`。\n - 然后立即将澄清应用到最合适的部分：\n - 功能歧义 → 更新或在功能要求中添加项目符号。\n - 用户交互 / 行为者区分 → 更新用户故事或行为者子部分（如果存在）与澄清的角色、约束或场景。\n - 数据形状 / 实体 → 更新数据模型（添加字段、类型、关系）保持排序；简洁地记录添加的约束。\n - 非功能性约束 → 在非功能性 / 质量属性部分添加/修改可测量标准（将模糊形容词转换为指标或明确目标）。\n - 边缘情况 / 负面流程 → 在边缘情况 / 错误处理下添加新项目符号（或创建此类子部分如果模板提供占位符）。\n - 术语冲突 → 规范化整个规格中的术语；仅在必要时保留原始术语，添加`(以前称为\"X\")`一次。\n - 如果澄清使早期模糊声明无效，则替换该声明而不是重复；不留过时的矛盾文本。\n - 每次集成后保存规格文件以最小化上下文丢失风险（原子覆盖）。\n - 保持格式：不要重新排序无关部分；保持标题层次结构完整。\n - 保持每个插入的澄清最小且可测试（避免叙述性漂移）。\n\n6. 验证（每次写入后执行加上最终通过）：\n - 澄清会话包含每个接受答案的一个项目符号（无重复）。\n - 总问（接受）问题 ≤ 5。\n - 更新部分不包含新的答案应该解决的模糊占位符。\n - 无矛盾的早期声明保留（扫描移除的无效替代选择）。\n - Markdown 结构有效；仅允许新标题：`## Clarifications`, `### Session YYYY-MM-DD`。\n - 术语一致性：所有更新部分使用相同的规范术语。\n\n7. 将更新的规格写回 `FEATURE_SPEC`。\n\n8. 报告完成（提问循环结束或提前终止后）：\n - 问和回答的问题数量。\n - 更新规格的路径。\n - 触及的部分（列出名称）。\n - 覆盖摘要表列出每个分类类别，状态：已解决（之前部分/缺失并已解决）、推迟（超出问题配额或更适合规划）、清晰（已足够）、未解决（仍部分/缺失但影响低）。\n - 如果有任何未解决或推迟的，建议是否继续到 `/speckit.plan` 或稍后再次运行 `/speckit.clarify`。\n - 建议的下一个命令。\n\n行为规则：\n\n- 如果未发现有意义的歧义（或所有潜在问题都是低影响的），回应：\"未检测到值得正式澄清的关键歧义。\"并建议继续。\n- 如果规格文件缺失，指示用户先运行 `/speckit.specify`（不要在此处创建新规格）。\n- 永远不要超过 5 个总问问题（澄清重试单个问题不计入新问题）。\n- 避免推测性技术栈问题，除非缺失会阻塞功能清晰度。\n- 尊重用户提前终止信号（\"stop\"、\"done\"、\"proceed\"）。\n- 如果由于完全覆盖而未问问题，输出紧凑的覆盖摘要（所有类别清晰）然后建议前进。\n- 如果配额达到但仍有未解决的高影响类别，明确标记它们为推迟并附上理由。\n\n优先级上下文：{ARGS}","content_type":"text/markdown; charset=utf-8","language":"markdown","size":10219,"content_sha256":"30a4203d7093d35f5b56cf89d93698d883abc71210037bd2b29cd6130f909efd"},{"filename":"assets/specify/templates/commands/constitution.md","content":"---\ndescription: 根据交互式或提供的原则输入创建或更新项目宪章，确保所有依赖模板保持同步\n---\n\n## 用户输入\n\n```text\n$ARGUMENTS\n```\n\n您**必须**在继续之前考虑用户输入（如果不为空）。\n\n## 大纲\n\n您正在更新位于 `/memory/constitution.md` 的项目宪章。此文件是一个模板，包含方括号中的占位符标记（例如 `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`）。您的工作是 (a) 收集/推导具体值，(b) 精确填充模板，以及 (c) 传播任何修订到依赖工件。\n\n遵循此执行流程：\n\n1. 加载位于 `/memory/constitution.md` 的现有宪章模板。\n - 识别形式为 `[ALL_CAPS_IDENTIFIER]` 的每个占位符标记。\n **重要**：用户可能需要比模板中使用的更少或更多的原则。如果指定了数量，请尊重 - 遵循通用模板。您将相应地更新文档。\n\n2. 收集/推导占位符的值：\n - 如果用户输入（对话）提供了值，则使用它。\n - 否则从现有仓库上下文（README、文档、先前的宪章版本（如果嵌入））推断。\n - 对于治理日期：`RATIFICATION_DATE` 是原始采用日期（如果未知则询问或标记 TODO），`LAST_AMENDED_DATE` 是今天如果进行了更改，否则保持先前日期。\n - `CONSTITUTION_VERSION` 必须根据语义版本规则递增：\n - MAJOR：向后不兼容的治理/原则删除或重新定义。\n - MINOR：添加新原则/部分或实质性扩展指导。\n - PATCH：澄清、措辞、拼写错误修复、非语义性改进。\n - 如果版本提升类型不明确，在最终确定前提出理由。\n\n3. 起草更新的宪章内容：\n - 用具体文本替换每个占位符（除了项目选择尚未定义的故意保留的模板槽位 - 明确说明任何保留的槽位）。\n - 保持标题层次结构，注释可以在替换后删除，除非它们仍然提供澄清指导。\n - 确保每个原则部分：简洁的名称行，段落（或项目符号列表）捕获不可协商的规则，如果不是显而易见则提供明确的理由。\n - 确保治理部分列出修订程序、版本政策和合规性审查期望。\n\n4. 一致性传播检查表（将先前的检查表转换为积极验证）：\n - 读取 `/templates/plan-template.md` 并确保任何\"宪章检查\"或规则与更新的原则对齐。\n - 读取 `/templates/spec-template.md` 以对齐范围/要求 - 如果宪章添加/删除了强制性部分或约束则更新。\n - 读取 `/templates/tasks-template.md` 并确保任务分类反映新增或删除的原则驱动任务类型（例如，可观察性、版本控制、测试纪律）。\n - 读取 `/templates/commands/*.md` 中的每个命令文件（包括此文件）以验证没有过时的引用（仅当需要通用指导时保留特定代理名称如 CLAUDE）。\n - 读取任何运行时指导文档（例如，`README.md`, `docs/quickstart.md`，或特定代理指导文件（如果存在））。更新对更改原则的引用。\n\n5. 生成同步影响报告（在更新后作为 HTML 注释预置在宪章文件顶部）：\n - 版本变更：旧 → 新\n - 修改的原则列表（旧标题 → 新标题如果重命名）\n - 添加的部分\n - 删除的部分\n - 需要更新的模板（✅ 已更新 / ⚠ 待处理）及文件路径\n - 如果有任何占位符故意推迟则列出。\n\n6. 最终输出前的验证：\n - 没有剩余的未解释括号标记。\n - 版本行与报告匹配。\n - 日期为 ISO 格式 YYYY-MM-DD。\n - 原则是陈述性的、可测试的，并且没有模糊语言（\"应该\" → 在适当时替换为 MUST/SHOULD 理由）。\n\n7. 将完成的宪章写回 `/memory/constitution.md`（覆盖）。\n\n8. 向用户输出最终摘要：\n - 新版本和提升理由。\n - 任何标记为手动跟进的文件。\n - 建议的提交消息（例如，`docs: 修订宪章至 vX.Y.Z（原则添加 + 治理更新）`）。\n\n格式和样式要求：\n\n- 完全按照模板中的 Markdown 标题使用（不要降级/升级级别）。\n- 包装长理由行以保持可读性（理想情况下 \u003c100 个字符），但不要用尴尬的断行强制执行。\n- 在部分之间保持单个空行。\n- 避免尾随空格。\n\n如果用户提供部分更新（例如，仅一个原则修订），仍执行验证和版本决策步骤。\n\n如果关键信息缺失（例如，批准日期真正未知），插入 `TODO(\u003cFIELD_NAME>): explanation` 并在同步影响报告的推迟项目下列出。\n\n不要创建新模板；始终在现有的 `/memory/constitution.md` 文件上操作。","content_type":"text/markdown; charset=utf-8","language":"markdown","size":4629,"content_sha256":"c61b8fa30bcd1662c5efadc420cf093a289506a403c27cc0c5ccd75e7f50aab5"},{"filename":"assets/specify/templates/commands/implement.md","content":"---\ndescription: 通过处理和执行 tasks.md 中定义的所有任务来执行实现计划\nscripts:\n sh: scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks\n ps: scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks\n---\n\n## 用户输入\n\n```text\n$ARGUMENTS\n```\n\n您**必须**在继续之前考虑用户输入（如果不为空）。\n\n## 大纲\n\n1. 从仓库根目录运行 `{SCRIPT}` 并解析 FEATURE_DIR 和 AVAILABLE_DOCS 列表。所有路径必须是绝对的。对于参数中的单引号，如 \"I'm Groot\"，使用转义语法：例如 'I'\\''m Groot'（或者如果可能的话使用双引号：\"I'm Groot\"）。\n\n2. **检查检查表状态**（如果 FEATURE_DIR/checklists/ 存在）：\n - 扫描 checklists/ 目录中的所有检查表文件\n - 对于每个检查表，计数：\n - 总项目：所有匹配 `- [ ]` 或 `- [X]` 或 `- [x]` 的行\n - 完成项目：匹配 `- [X]` 或 `- [x]` 的行\n - 未完成项目：匹配 `- [ ]` 的行\n - 创建状态表：\n\n ```text\n | 检查表 | 总计 | 已完成 | 未完成 | 状态 |\n |-----------|-------|-----------|------------|--------|\n | ux.md | 12 | 12 | 0 | ✓ 通过 |\n | test.md | 8 | 5 | 3 | ✗ 失败 |\n | security.md | 6 | 6 | 0 | ✓ 通过 |\n ```\n\n - 计算总体状态：\n - **通过**：所有检查表都有 0 个未完成项目\n - **失败**：一个或多个检查表有未完成项目\n\n - **如果有任何检查表未完成**：\n - 显示包含未完成项目计数的表格\n - **停止**并询问：\"一些检查表未完成。您是否仍要继续执行实现？(yes/no)\"\n - 等待用户响应后再继续\n - 如果用户说\"no\"或\"wait\"或\"stop\"，则停止执行\n - 如果用户说\"yes\"或\"proceed\"或\"continue\"，则继续到步骤 3\n\n - **如果所有检查表都完成**：\n - 显示表格显示所有检查表已通过\n - 自动继续到步骤 3\n\n3. 加载和分析实现上下文：\n - **必需**：读取 tasks.md 以获取完整的任务列表和执行计划\n - **必需**：读取 plan.md 以获取技术栈、架构和文件结构\n - **如果存在**：读取 data-model.md 以获取实体和关系\n - **如果存在**：读取 contracts/ 以获取 API 规范和测试要求\n - **如果存在**：读取 research.md 以获取技术决策和约束\n - **如果存在**：读取 quickstart.md 以获取集成场景\n\n4. **项目设置验证**：\n - **必需**：根据实际项目设置创建/验证忽略文件：\n\n **检测和创建逻辑**：\n - 检查以下命令是否成功以确定仓库是否为 git 仓库（如果是则创建/验证 .gitignore）：\n\n ```sh\n git rev-parse --git-dir 2>/dev/null\n ```\n\n - 检查是否存在 Dockerfile* 或 Docker 在 plan.md 中 → 创建/验证 .dockerignore\n - 检查是否存在 .eslintrc* 或 eslint.config.* → 创建/验证 .eslintignore\n - 检查是否存在 .prettierrc* → 创建/验证 .prettierignore\n - 检查是否存在 .npmrc 或 package.json → 创建/验证 .npmignore（如果发布）\n - 检查是否存在 terraform 文件 (*.tf) → 创建/验证 .terraformignore\n - 检查是否需要 .helmignore（存在 helm 图表）→ 创建/验证 .helmignore\n\n **如果忽略文件已存在**：验证它包含基本模式，仅追加缺失的关键模式\n **如果忽略文件缺失**：创建包含检测技术的完整模式集\n\n **按技术的常见模式**（来自 plan.md 技术栈）：\n - **Node.js/JavaScript/TypeScript**：`node_modules/`, `dist/`, `build/`, `*.log`, `.env*`\n - **Python**：`__pycache__/`, `*.pyc`, `.venv/`, `venv/`, `dist/`, `*.egg-info/`\n - **Java**：`target/`, `*.class`, `*.jar`, `.gradle/`, `build/`\n - **C#/.NET**：`bin/`, `obj/`, `*.user`, `*.suo`, `packages/`\n - **Go**：`*.exe`, `*.test`, `vendor/`, `*.out`\n - **Ruby**：`.bundle/`, `log/`, `tmp/`, `*.gem`, `vendor/bundle/`\n - **PHP**：`vendor/`, `*.log`, `*.cache`, `*.env`\n - **Rust**：`target/`, `debug/`, `release/`, `*.rs.bk`, `*.rlib`, `*.prof*`, `.idea/`, `*.log`, `.env*`\n - **Kotlin**：`build/`, `out/`, `.gradle/`, `.idea/`, `*.class`, `*.jar`, `*.iml`, `*.log`, `.env*`\n - **C++**：`build/`, `bin/`, `obj/`, `out/`, `*.o`, `*.so`, `*.a`, `*.exe`, `*.dll`, `.idea/`, `*.log`, `.env*`\n - **C**：`build/`, `bin/`, `obj/`, `out/`, `*.o`, `*.a`, `*.so`, `*.exe`, `Makefile`, `config.log`, `.idea/`, `*.log`, `.env*`\n - **Swift**：`.build/`, `DerivedData/`, `*.swiftpm/`, `Packages/`\n - **R**：`.Rproj.user/`, `.Rhistory`, `.RData`, `.Ruserdata`, `*.Rproj`, `packrat/`, `renv/`\n - **通用**：`.DS_Store`, `Thumbs.db`, `*.tmp`, `*.swp`, `.vscode/`, `.idea/`\n\n **工具特定模式**：\n - **Docker**：`node_modules/`, `.git/`, `Dockerfile*`, `.dockerignore`, `*.log*`, `.env*`, `coverage/`\n - **ESLint**：`node_modules/`, `dist/`, `build/`, `coverage/`, `*.min.js`\n - **Prettier**：`node_modules/`, `dist/`, `build/`, `coverage/`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`\n - **Terraform**：`.terraform/`, `*.tfstate*`, `*.tfvars`, `.terraform.lock.hcl`\n - **Kubernetes/k8s**：`*.secret.yaml`, `secrets/`, `.kube/`, `kubeconfig*`, `*.key`, `*.crt`\n\n5. 解析 tasks.md 结构并提取：\n - **任务阶段**：设置、测试、核心、集成、完善\n - **任务依赖**：顺序与并行执行规则\n - **任务详情**：ID、描述、文件路径、并行标记 [P]\n - **执行流程**：顺序和依赖要求\n\n6. 按照任务计划执行实现：\n - **阶段执行**：完成每个阶段后再进入下一个\n - **尊重依赖**：按顺序运行顺序任务，并行任务 [P] 可以一起运行 \n - **遵循 TDD 方法**：在相应的实现任务之前执行测试任务\n - **基于文件的协调**：影响相同文件的任务必须顺序运行\n - **验证检查点**：在继续之前验证每个阶段的完成情况\n\n7. 实现执行规则：\n - **首先设置**：初始化项目结构、依赖、配置\n - **测试优先于代码**：如果需要为契约、实体和集成场景编写测试\n - **核心开发**：实现模型、服务、CLI 命令、端点\n - **集成工作**：数据库连接、中间件、日志、外部服务\n - **完善和验证**：单元测试、性能优化、文档\n\n8. 进度跟踪和错误处理：\n - 在每个完成的任务后报告进度\n - 如果任何非并行任务失败则停止执行\n - 对于并行任务 [P]，继续执行成功的任务，报告失败的任务\n - 提供清晰的错误消息和调试上下文\n - 如果实现无法继续则建议下一步\n - **重要** 对于完成的任务，确保在任务文件中标记为 [X]。\n\n9. 完成验证：\n - 验证所有必需任务已完成\n - 检查实现的功能是否与原始规格匹配\n - 验证测试通过且覆盖率符合要求\n - 确认实现遵循技术计划\n - 报告最终状态和已完成工作的摘要\n\n注意：此命令假设 tasks.md 中存在完整的任务分解。如果任务不完整或缺失，建议首先运行 `/speckit.tasks` 以重新生成任务列表。","content_type":"text/markdown; charset=utf-8","language":"markdown","size":7211,"content_sha256":"8167950f72c1157924af06038f8b3e47b7507931cd5b36487451960b2056b3d4"},{"filename":"assets/specify/templates/commands/plan.md","content":"---\ndescription: 使用计划模板执行实现规划工作流程以生成设计工件。\nscripts:\n sh: scripts/bash/setup-plan.sh --json\n ps: scripts/powershell/setup-plan.ps1 -Json\nagent_scripts:\n sh: scripts/bash/update-agent-context.sh __AGENT__\n ps: scripts/powershell/update-agent-context.ps1 -AgentType __AGENT__\n---\n\n## 用户输入\n\n```text\n$ARGUMENTS\n```\n\n您**必须**在继续之前考虑用户输入（如果不为空）。\n\n## 大纲\n\n1. **设置**：从仓库根目录运行 `{SCRIPT}` 并解析 JSON 以获取 FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH。对于参数中的单引号，如 \"I'm Groot\"，使用转义语法：例如 'I'\\''m Groot'（或者如果可能的话使用双引号：\"I'm Groot\"）。\n\n2. **加载上下文**：读取 FEATURE_SPEC 和 `/memory/constitution.md`。加载 IMPL_PLAN 模板（已复制）。\n\n3. **执行计划工作流程**：按照 IMPL_PLAN 模板中的结构：\n - 填写技术上下文（将未知标记为\"需要澄清\"）\n - 从宪章填写宪章检查部分\n - 评估门（如果违规未经证明则报错）\n - 阶段 0：生成 research.md（解决所有\"需要澄清\"）\n - 阶段 1：生成 data-model.md, contracts/, quickstart.md\n - 阶段 1：通过运行代理脚本更新代理上下文\n - 设计后重新评估宪章检查\n\n4. **停止并报告**：命令在阶段 2 规划后结束。报告分支、IMPL_PLAN 路径和生成的工件。\n\n## 阶段\n\n### 阶段 0：大纲和研究\n\n1. **从上面的技术上下文中提取未知项**：\n - 对于每个\"需要澄清\" → 研究任务\n - 对于每个依赖项 → 最佳实践任务\n - 对于每个集成 → 模式任务\n\n2. **生成和派遣研究代理**：\n\n ```text\n 对于技术上下文中的每个未知项：\n 任务：\"研究 {未知项} 用于 {功能上下文}\"\n 对于每个技术选择：\n 任务：\"查找 {技术} 在 {领域} 中的最佳实践\"\n ```\n\n3. **在 `research.md` 中整合发现**，使用格式：\n - 决策：[选择了什么]\n - 理由：[为什么选择]\n - 考虑的替代方案：[评估了什么其他选项]\n\n**输出**：research.md，解决所有\"需要澄清\"\n\n### 阶段 1：设计和契约\n\n**先决条件**：`research.md` 完成\n\n1. **从功能规格中提取实体** → `data-model.md`：\n - 实体名称、字段、关系\n - 来自要求的验证规则\n - 如适用的状态转换\n\n2. **从功能要求生成 API 契约**：\n - 对于每个用户操作 → 端点\n - 使用标准 REST/GraphQL 模式\n - 将 OpenAPI/GraphQL 模式输出到 `/contracts/`\n\n3. **代理上下文更新**：\n - 运行 `{AGENT_SCRIPT}`\n - 这些脚本检测使用中的 AI 代理\n - 更新适当的代理特定上下文文件\n - 仅添加当前计划中的新技术\n - 保留标记之间的手动添加\n\n**输出**：data-model.md, /contracts/*, quickstart.md, 代理特定文件\n\n## 关键规则\n\n- 使用绝对路径\n- 门失败或未解决的澄清时报错","content_type":"text/markdown; charset=utf-8","language":"markdown","size":2973,"content_sha256":"936eb547e4720a687b934d5b3315a6924f0b3064119f1a4c04476aeda83cbb96"},{"filename":"assets/specify/templates/commands/specify.md","content":"---\ndescription: 根据自然语言功能描述创建或更新功能规格。\nscripts:\n sh: scripts/bash/create-new-feature.sh --json \"{ARGS}\"\n ps: scripts/powershell/create-new-feature.ps1 -Json \"{ARGS}\"\n---\n\n## 用户输入\n\n```text\n$ARGUMENTS\n```\n\n您**必须**在继续之前考虑用户输入（如果不为空）。\n\n## 大纲\n\n用户在触发消息中输入 `/speckit.specify` 后的文本**就是**功能描述。假设您在此对话中始终可以使用它，即使下面出现 `{ARGS}` 字面意思。除非用户提供了空命令，否则不要要求用户重复。\n\n根据该功能描述，执行以下操作：\n\n1. **生成简洁的短名称**（2-4 个单词）用于分支：\n - 分析功能描述并提取最有意义的关键词\n - 创建一个 2-4 个单词的短名称，捕捉功能的本质\n - 尽可能使用动作-名词格式（例如，\"add-user-auth\"，\"fix-payment-bug\"）\n - 保留技术术语和缩写（OAuth2, API, JWT 等）\n - 保持简洁但描述性足够，一眼就能理解功能\n - 示例：\n - \"我想添加用户认证\" → \"user-auth\"\n - \"为 API 实现 OAuth2 集成\" → \"oauth2-api-integration\"\n - \"创建分析仪表板\" → \"analytics-dashboard\"\n - \"修复支付处理超时错误\" → \"fix-payment-timeout\"\n\n2. **在创建新分支前检查现有分支**：\n \n a. 首先，获取所有远程分支以确保我们有最新信息：\n ```bash\n git fetch --all --prune\n ```\n \n b. 查找短名称的最高功能编号：\n - 远程分支：`git ls-remote --heads origin | grep -E 'refs/heads/[0-9]+-\u003cshort-name>

用户输入 在继续之前，您 必须 考虑用户输入（如果不为空）。 大纲 您正在更新位于 的项目章程。此文件源自一个模板assets/constitution-template.md，包含方括号中的占位符令牌（例如 、 ）。您的工作是：(a) 收集/推导具体值，(b) 精确填充模板，以及 (c) 在依赖工件中传播任何修订。 遵循此执行流程： 1. 将 所有文件（包括子目录）按原目录结构复制到仓库根目录下的 目录，跳过已有文件， 不能覆盖原有同名文件 。cp命令的 -n（--no-clobber）选项可以防止覆盖已存在的文件。 在此阶段，您的项目文件夹内容应类似于以下内容： 2. 加载位于相对仓库根目录 的现有章程模板。 - 识别形式为 的每个占位符令牌。 重要 ：用户可能需要比模板中使用的更少或更多的原则。如果指定了数量，请遵守该数量 - 遵循通用模板。您将相应地更新文档。 3. 收集/推导占位符的值： - 如果用户输入（对话）提供了值，则使用它。 - 否则从现有仓库上下文推断（README、文档、嵌入的先前章程版本）。 - 对于治理日期： 是原始采用日期（如果未知则询问或标记 TODO），如果有更改则 是今天，否则保持之前的日期。 - 必须根据语义版本规则递增： - 主版本：向后不兼容的治理/原则删除或重新定义。 - 次版本：添加新原则/章节或实质性扩展指导。 - 补丁：澄清、措辞、…

`\n - 本地分支：`git branch | grep -E '^[* ]*[0-9]+-\u003cshort-name>

用户输入 在继续之前，您 必须 考虑用户输入（如果不为空）。 大纲 您正在更新位于 的项目章程。此文件源自一个模板assets/constitution-template.md，包含方括号中的占位符令牌（例如 、 ）。您的工作是：(a) 收集/推导具体值，(b) 精确填充模板，以及 (c) 在依赖工件中传播任何修订。 遵循此执行流程： 1. 将 所有文件（包括子目录）按原目录结构复制到仓库根目录下的 目录，跳过已有文件， 不能覆盖原有同名文件 。cp命令的 -n（--no-clobber）选项可以防止覆盖已存在的文件。 在此阶段，您的项目文件夹内容应类似于以下内容： 2. 加载位于相对仓库根目录 的现有章程模板。 - 识别形式为 的每个占位符令牌。 重要 ：用户可能需要比模板中使用的更少或更多的原则。如果指定了数量，请遵守该数量 - 遵循通用模板。您将相应地更新文档。 3. 收集/推导占位符的值： - 如果用户输入（对话）提供了值，则使用它。 - 否则从现有仓库上下文推断（README、文档、嵌入的先前章程版本）。 - 对于治理日期： 是原始采用日期（如果未知则询问或标记 TODO），如果有更改则 是今天，否则保持之前的日期。 - 必须根据语义版本规则递增： - 主版本：向后不兼容的治理/原则删除或重新定义。 - 次版本：添加新原则/章节或实质性扩展指导。 - 补丁：澄清、措辞、…

`\n - 规格目录：检查匹配 `specs/[0-9]+-\u003cshort-name>` 的目录\n \n c. 确定下一个可用编号：\n - 从所有三个来源提取所有编号\n - 找到最高编号 N\n - 使用 N+1 作为新分支编号\n \n d. 使用计算出的编号和短名称运行脚本 `{SCRIPT}`：\n - 传递 `--number N+1` 和 `--short-name \"your-short-name\"` 以及功能描述\n - Bash 示例：`{SCRIPT} --json --number 5 --short-name \"user-auth\" \"添加用户认证\"`\n - PowerShell 示例：`{SCRIPT} -Json -Number 5 -ShortName \"user-auth\" \"添加用户认证\"`\n \n **重要**：\n - 检查所有三个来源（远程分支、本地分支、规格目录）以找到最高编号\n - 仅匹配具有确切短名称模式的分支/目录\n - 如果未找到具有此短名称的现有分支/目录，则从编号 1 开始\n - 每个功能只能运行此脚本一次\n - JSON 在终端中作为输出提供 - 始终参考它以获取您要查找的实际内容\n - JSON 输出将包含 BRANCH_NAME 和 SPEC_FILE 路径\n - 对于参数中的单引号，如 \"I'm Groot\"，使用转义语法：例如 'I'\\''m Groot'（或者如果可能的话使用双引号：\"I'm Groot\"）\n\n3. 加载 `templates/spec-template.md` 以了解必需部分。\n\n4. 遵循此执行流程：\n\n 1. 从输入解析用户描述\n 如果为空：错误 \"未提供功能描述\"\n 2. 从描述中提取关键概念\n 识别：参与者、动作、数据、约束\n 3. 对于不清楚的方面：\n - 基于上下文和行业标准做出有根据的猜测\n - 仅在以下情况下标记 [需要澄清：具体问题]：\n - 选择显著影响功能范围或用户体验\n - 存在多种合理解释且有不同的含义\n - 没有合理的默认值\n - **限制：最多 3 个 [需要澄清] 标记**\n - 按影响优先级排序：范围 > 安全/隐私 > 用户体验 > 技术细节\n 4. 填写用户场景和测试部分\n 如果没有明确的用户流程：错误 \"无法确定用户场景\"\n 5. 生成功能要求\n 每个要求必须可测试\n 为未指定的细节使用合理的默认值（在假设部分记录假设）\n 6. 定义成功标准\n 创建可测量的、技术无关的结果\n 包括定量指标（时间、性能、数量）和定性措施（用户满意度、任务完成）\n 每个标准必须在没有实现细节的情况下可验证\n 7. 识别关键实体（如果涉及数据）\n 8. 返回：成功（规格已准备好规划）\n\n5. 使用模板结构将规格写入 SPEC_FILE，将占位符替换为从功能描述（参数）中得出的具体细节，同时保持部分顺序和标题。\n\n6. **规格质量验证**：在编写初始规格后，根据质量标准进行验证：\n\n a. **创建规格质量检查表**：在 `FEATURE_DIR/checklists/requirements.md` 生成检查表文件，使用检查表模板结构和这些验证项目：\n\n ```markdown\n # 规格质量检查表：[功能名称]\n \n **目的**：在继续规划之前验证规格完整性和质量\n **创建时间**：[日期]\n **功能**：[链接到 spec.md]\n \n ## 内容质量\n \n - [ ] 无实现细节（语言、框架、API）\n - [ ] 专注于用户价值和业务需求\n - [ ] 为非技术利益相关者编写\n - [ ] 所有必需部分已完成\n \n ## 要求完整性\n \n - [ ] 无 [需要澄清] 标记\n - [ ] 要求可测试且明确\n - [ ] 成功标准可测量\n - [ ] 成功标准技术无关（无实现细节）\n - [ ] 所有验收场景已定义\n - [ ] 边缘情况已识别\n - [ ] 范围明确界定\n - [ ] 依赖关系和假设已识别\n \n ## 功能准备度\n \n - [ ] 所有功能要求都有明确的验收标准\n - [ ] 用户场景涵盖主要流程\n - [ ] 功能满足成功标准中定义的可测量结果\n - [ ] 无实现细节泄露到规格中\n \n ## 备注\n \n - 标记为不完整的项目需要在 `/speckit.clarify` 或 `/speckit.plan` 之前更新规格\n ```\n\n b. **运行验证检查**：根据每个检查表项目审查规格：\n - 对于每个项目，确定它是通过还是失败\n - 记录发现的具体问题（引用相关规格部分）\n\n c. **处理验证结果**：\n\n - **如果所有项目都通过**：标记检查表完成并继续到步骤 6\n\n - **如果项目失败（不包括 [需要澄清]）**：\n 1. 列出失败的项目和具体问题\n 2. 更新规格以解决每个问题\n 3. 重新运行验证直到所有项目通过（最多 3 次迭代）\n 4. 如果 3 次迭代后仍失败，将剩余问题记录在检查表备注中并警告用户\n\n - **如果 [需要澄清] 标记仍然存在**：\n 1. 从规格中提取所有 [需要澄清：...] 标记\n 2. **限制检查**：如果标记超过 3 个，仅保留 3 个最关键（按范围/安全/用户体验影响）并为其余标记做出有根据的猜测\n 3. 对于每个需要的澄清（最多 3 个），以以下格式向用户呈现选项：\n\n ```markdown\n ## 问题 [N]：[主题]\n \n **上下文**：[引用相关规格部分]\n \n **我们需要知道**：[来自需要澄清标记的具体问题]\n \n **建议答案**：\n \n | 选项 | 答案 | 影响 |\n |--------|--------|--------------|\n | A | [第一个建议答案] | [这对功能意味着什么] |\n | B | [第二个建议答案] | [这对功能意味着什么] |\n | C | [第三个建议答案] | [这对功能意味着什么] |\n | 自定义 | 提供您自己的答案 | [解释如何提供自定义输入] |\n \n **您的选择**：_[等待用户响应]_\n ```\n\n 4. **关键 - 表格格式**：确保 markdown 表格格式正确：\n - 使用一致的间距，管道对齐\n - 每个单元格应有内容周围的空格：`| 内容 |` 而不是 `|内容|`\n - 标题分隔符必须至少有 3 个破折号：`|--------|`\n - 测试表格在 markdown 预览中正确渲染\n 5. 顺序编号问题（Q1, Q2, Q3 - 最多 3 个总计）\n 6. 在等待响应之前一起呈现所有问题\n 7. 等待用户响应他们对所有问题的选择（例如，\"Q1: A, Q2: 自定义 - [详情], Q3: B\"）\n 8. 通过将每个 [需要澄清] 标记替换为用户选择或提供的答案来更新规格\n 9. 在所有澄清解决后重新运行验证\n\n d. **更新检查表**：在每次验证迭代后，使用当前通过/失败状态更新检查表文件\n\n7. 报告完成情况，包括分支名称、规格文件路径、检查表结果和下一阶段的准备情况（`/speckit.clarify` 或 `/speckit.plan`）。\n\n**注意**：脚本创建并检出新分支并在写入前初始化规格文件。\n\n## 一般指南\n\n## 快速指南\n\n- 专注于用户需要**什么**和**为什么**。\n- 避免如何实现（无技术栈、API、代码结构）。\n- 为业务利益相关者编写，而不是开发人员。\n- 不要创建嵌入在规格中的任何检查表。那将是单独的命令。\n\n### 部分要求\n\n- **必需部分**：每个功能必须完成\n- **可选部分**：仅在与功能相关时包含\n- 当部分不适用时，完全删除（不要留作\"N/A\"）\n\n### 对于 AI 生成\n\n从用户提示创建此规格时：\n\n1. **做出有根据的猜测**：使用上下文、行业标准和常见模式填补空白\n2. **记录假设**：在假设部分记录合理的默认值\n3. **限制澄清**：最多 3 个 [需要澄清] 标记 - 仅用于关键决策：\n - 显著影响功能范围或用户体验\n - 有多种合理解释且有不同的含义\n - 没有合理的默认值\n4. **优先级澄清**：范围 > 安全/隐私 > 用户体验 > 技术细节\n5. **像测试人员一样思考**：每个模糊要求都应无法通过\"可测试和明确\"检查表项目\n6. **需要澄清的常见领域**（如果没有合理的默认值）：\n - 功能范围和边界（包括/排除特定用例）\n - 用户类型和权限（如果存在多个冲突解释）\n - 安全/合规要求（当法律/财务重要时）\n\n**合理默认值示例**（不要询问这些）：\n\n- 数据保留：该领域的行业标准实践\n- 性能目标：标准网络/移动应用期望（除非指定）\n- 错误处理：用户友好的消息和适当的回退\n- 认证方法：标准基于会话或 OAuth2 用于 Web 应用\n- 集成模式：RESTful API（除非另有说明）\n\n### 成功标准指南\n\n成功标准必须：\n\n1. **可测量**：包括具体指标（时间、百分比、数量、比率）\n2. **技术无关**：不提及框架、语言、数据库或工具\n3. **用户导向**：从用户/业务角度描述结果，而不是系统内部\n4. **可验证**：可以在不知道实现细节的情况下测试/验证\n\n**好示例**：\n\n- \"用户可以在 3 分钟内完成结账\"\n- \"系统支持 10,000 个并发用户\"\n- \"95% 的搜索在 1 秒内返回结果\"\n- \"任务完成率提高 40%\"\n\n**坏示例**（实现导向）：\n\n- \"API 响应时间低于 200ms\"（太技术性，使用\"用户立即看到结果\"）\n- \"数据库可以处理 1000 TPS\"（实现细节，使用面向用户的指标）\n- \"React 组件高效渲染\"（框架特定）\n- \"Redis 缓存命中率高于 80%\"（技术特定）","content_type":"text/markdown; charset=utf-8","language":"markdown","size":11279,"content_sha256":"1b8204a71906cf5f1d51f540f6f1d51b88183320eb0661e13514dfd2dfd5b3d0"},{"filename":"assets/specify/templates/commands/tasks.md","content":"---\ndescription: 基于可用设计工件为功能生成可操作的、按依赖顺序排列的 tasks.md。\nscripts:\n sh: scripts/bash/check-prerequisites.sh --json\n ps: scripts/powershell/check-prerequisites.ps1 -Json\n---\n\n## 用户输入\n\n```text\n$ARGUMENTS\n```\n\n您**必须**在继续之前考虑用户输入（如果不为空）。\n\n## 大纲\n\n1. **设置**：从仓库根目录运行 `{SCRIPT}` 并解析 FEATURE_DIR 和 AVAILABLE_DOCS 列表。所有路径必须是绝对的。对于参数中的单引号，如 \"I'm Groot\"，使用转义语法：例如 'I'\\''m Groot'（或者如果可能的话使用双引号：\"I'm Groot\"）。\n\n2. **加载设计文档**：从 FEATURE_DIR 读取：\n - **必需**：plan.md（技术栈、库、结构），spec.md（带优先级的用户故事）\n - **可选**：data-model.md（实体），contracts/（API 端点），research.md（决策），quickstart.md（测试场景）\n - 注意：并非所有项目都有所有文档。根据可用内容生成任务。\n\n3. **执行任务生成工作流程**：\n - 加载 plan.md 并提取技术栈、库、项目结构\n - 加载 spec.md 并提取带优先级的用户故事（P1, P2, P3 等）\n - 如果存在 data-model.md：提取实体并映射到用户故事\n - 如果存在 contracts/：将端点映射到用户故事\n - 如果存在 research.md：提取决策用于设置任务\n - 生成按用户故事组织的任务（参见下面的任务生成规则）\n - 生成依赖图显示用户故事完成顺序\n - 为每个用户故事创建并行执行示例\n - 验证任务完整性（每个用户故事都有所需任务，可独立测试）\n\n4. **生成 tasks.md**：使用 `.specify/templates/tasks-template.md` 作为结构，填充：\n - 从 plan.md 获取正确的功能名称\n - 阶段 1：设置任务（项目初始化）\n - 阶段 2：基础任务（所有用户故事的阻塞先决条件）\n - 阶段 3+：按 spec.md 中的优先级顺序排列的每个用户故事一个阶段\n - 每个阶段包括：故事目标、独立测试标准、测试（如果要求）、实现任务\n - 最终阶段：完善和跨领域关注点\n - 所有任务必须遵循严格的检查表格式（参见下面的任务生成规则）\n - 每个任务的明确文件路径\n - 依赖关系部分显示故事完成顺序\n - 每个故事的并行执行示例\n - 实现策略部分（MVP 优先、增量交付）\n\n5. **报告**：输出生成的 tasks.md 路径和摘要：\n - 总任务数\n - 每个用户故事的任务数\n - 识别的并行机会\n - 每个故事的独立测试标准\n - 建议的 MVP 范围（通常仅为用户故事 1）\n - 格式验证：确认所有任务都遵循检查表格式（复选框、ID、标签、文件路径）\n\n为任务生成提供上下文：{ARGS}\n\ntasks.md 应该是立即可执行的 - 每个任务必须足够具体，以便 LLM 可以在没有额外上下文的情况下完成它。\n\n## 任务生成规则\n\n**关键**：任务必须按用户故事组织，以实现独立实现和测试。\n\n**测试是可选的**：仅在功能规格中明确要求或用户要求 TDD 方法时才生成测试任务。\n\n### 检查表格式（必需）\n\n每个任务必须严格遵循此格式：\n\n```text\n- [ ] [任务ID] [P?] [故事?] 带文件路径的描述\n```\n\n**格式组件**：\n\n1. **复选框**：始终以 `- [ ]` 开头（markdown 复选框）\n2. **任务 ID**：按执行顺序的序列号（T001, T002, T003...）\n3. **[P] 标记**：仅当任务可并行化时包含（不同文件，不依赖未完成任务）\n4. **[故事] 标签**：仅用户故事阶段任务必需\n - 格式：[US1], [US2], [US3], 等（映射到 spec.md 中的用户故事）\n - 设置阶段：无故事标签\n - 基础阶段：无故事标签 \n - 用户故事阶段：必须有故事标签\n - 完善阶段：无故事标签\n5. **描述**：带确切文件路径的明确操作\n\n**示例**：\n\n- ✅ 正确：`- [ ] T001 根据实现计划创建项目结构`\n- ✅ 正确：`- [ ] T005 [P] 在 src/middleware/auth.py 中实现认证中间件`\n- ✅ 正确：`- [ ] T012 [P] [US1] 在 src/models/user.py 中创建用户模型`\n- ✅ 正确：`- [ ] T014 [US1] 在 src/services/user_service.py 中实现 UserService`\n- ❌ 错误：`- [ ] 创建用户模型`（缺少 ID 和故事标签）\n- ❌ 错误：`T001 [US1] 创建模型`（缺少复选框）\n- ❌ 错误：`- [ ] [US1] 创建用户模型`（缺少任务 ID）\n- ❌ 错误：`- [ ] T001 [US1] 创建模型`（缺少文件路径）\n\n### 任务组织\n\n1. **来自用户故事（spec.md）** - 主要组织：\n - 每个用户故事（P1, P2, P3...）都有自己的阶段\n - 将所有相关组件映射到它们的故事：\n - 该故事需要的模型\n - 该故事需要的服务\n - 该故事需要的端点/UI\n - 如果要求测试：该故事的特定测试\n - 标记故事依赖关系（大多数故事应该是独立的）\n\n2. **来自契约**：\n - 将每个契约/端点 → 映射到它服务的用户故事\n - 如果要求测试：每个契约 → 在该故事阶段实现前的契约测试任务 [P]\n\n3. **来自数据模型**：\n - 将每个实体映射到需要它的用户故事\n - 如果实体服务于多个故事：放在最早的故事或设置阶段\n - 关系 → 在适当的故事阶段中的服务层任务\n\n4. **来自设置/基础设施**：\n - 共享基础设施 → 设置阶段（阶段 1）\n - 基础/阻塞任务 → 基础阶段（阶段 2）\n - 故事特定设置 → 在该故事的阶段内\n\n### 阶段结构\n\n- **阶段 1**：设置（项目初始化）\n- **阶段 2**：基础（阻塞先决条件 - 必须在用户故事前完成）\n- **阶段 3+**：按优先级顺序的用户故事（P1, P2, P3...）\n - 在每个故事内：测试（如果要求）→ 模型 → 服务 → 端点 → 集成\n - 每个阶段应该是一个完整的、可独立测试的增量\n- **最终阶段**：完善和跨领域关注点","content_type":"text/markdown; charset=utf-8","language":"markdown","size":6005,"content_sha256":"ea35392a134918f91fc52effd7109c9efd091948aef3f08d7ac8eed5fc1e1839"},{"filename":"assets/specify/templates/constitution-template.md","content":"# [项目名称] 章程\n\u003c!-- 示例：规范章程，任务流章程等 -->\n\n## 核心原则\n\n### [原则_1_名称]\n\u003c!-- 示例：I. 库优先 -->\n[原则_1_描述]\n\u003c!-- 示例：每个功能都以独立库开始；库必须自包含、可独立测试、有文档；需要明确目的 - 没有仅用于组织的库 -->\n\n### [原则_2_名称]\n\u003c!-- 示例：II. CLI 接口 -->\n[原则_2_描述]\n\u003c!-- 示例：每个库都通过 CLI 暴露功能；文本输入/输出协议：stdin/args → stdout，错误 → stderr；支持 JSON + 人类可读格式 -->\n\n### [原则_3_名称]\n\u003c!-- 示例：III. 测试优先（不可协商） -->\n[原则_3_描述]\n\u003c!-- 示例：TDD 强制：编写测试 → 用户批准 → 测试失败 → 然后实现；严格强制红-绿-重构循环 -->\n\n### [原则_4_名称]\n\u003c!-- 示例：IV. 集成测试 -->\n[原则_4_描述]\n\u003c!-- 示例：需要集成测试的重点领域：新库契约测试、契约变更、服务间通信、共享模式 -->\n\n### [原则_5_名称]\n\u003c!-- 示例：V. 可观察性，VI. 版本控制和破坏性变更，VII. 简单性 -->\n[原则_5_描述]\n\u003c!-- 示例：文本 I/O 确保可调试性；需要结构化日志；或：MAJOR.MINOR.BUILD 格式；或：从简单开始，YAGNI 原则 -->\n\n## [部分_2_名称]\n\u003c!-- 示例：附加约束、安全要求、性能标准等 -->\n\n[部分_2_内容]\n\u003c!-- 示例：技术栈要求、合规标准、部署策略等 -->\n\n## [部分_3_名称]\n\u003c!-- 示例：开发工作流程、审查过程、质量门等 -->\n\n[部分_3_内容]\n\u003c!-- 示例：代码审查要求、测试门、部署批准流程等 -->\n\n## 治理\n\u003c!-- 示例：章程优于所有其他实践；修订需要文档、批准、迁移计划 -->\n\n[治理规则]\n\u003c!-- 示例：所有 PR/审查必须验证合规性；复杂性必须有正当理由；使用 [指导文件] 作为运行时开发指导 -->\n\n**版本**：[章程版本] | **批准**：[批准日期] | **最后修订**：[最后修订日期]\n\u003c!-- 示例：版本：2.1.1 | 批准：2025-06-13 | 最后修订：2025-07-16 -->","content_type":"text/markdown; charset=utf-8","language":"markdown","size":2047,"content_sha256":"3d034f400b5f866e2488b00712f1772898e57d40165953749f7d5872de66a198"},{"filename":"assets/specify/templates/plan-template.md","content":"# 实现计划：[功能]\n\n**分支**：`[###-feature-name]` | **日期**：[日期] | **规格**：[链接]\n**输入**：来自 `/specs/[###-feature-name]/spec.md` 的功能规格\n\n**注意**：此模板由 `/speckit.plan` 命令填写。请参见 `.specify/templates/commands/plan.md` 了解执行工作流程。\n\n## 概要\n\n[从功能规格中提取：主要需求 + 研究中的技术方法]\n\n## 技术背景\n\n\u003c!--\n 需要操作：用该项目的技术细节替换本节内容。\n 此处提供的结构是为了指导迭代过程而提供的建议性框架。\n-->\n\n**语言/版本**：[例如，Python 3.11, Swift 5.9, Rust 1.75 或需要澄清] \n**主要依赖项**：[例如，FastAPI, UIKit, LLVM 或需要澄清] \n**存储**：[如果适用，例如，PostgreSQL, CoreData, 文件 或不适用] \n**测试**：[例如，pytest, XCTest, cargo test 或需要澄清] \n**目标平台**：[例如，Linux 服务器, iOS 15+, WASM 或需要澄清]\n**项目类型**：[单体/网页/移动端 - 决定源码结构] \n**性能目标**：[领域特定，例如，1000 请求/秒, 10k 行/秒, 60 帧/秒 或需要澄清] \n**约束条件**：[领域特定，例如，\u003c200ms p95, \u003c100MB 内存, 支持离线 或需要澄清] \n**规模/范围**：[领域特定，例如，10k 用户, 1M LOC, 50 屏幕 或需要澄清]\n\n## 宪章检查\n\n*关卡：必须在第 0 阶段研究前通过。在第 1 阶段设计后重新检查。*\n\n[基于宪章文件确定的关卡]\n\n## 项目结构\n\n### 文档（此功能）\n\n```text\nspecs/[###-feature]/\n├── plan.md # 本文件（/speckit.plan 命令输出）\n├── research.md # 第 0 阶段输出（/speckit.plan 命令）\n├── data-model.md # 第 1 阶段输出（/speckit.plan 命令）\n├── quickstart.md # 第 1 阶段输出（/speckit.plan 命令）\n├── contracts/ # 第 1 阶段输出（/speckit.plan 命令）\n└── tasks.md # 第 2 阶段输出（/speckit.tasks 命令 - 不由 /speckit.plan 创建）\n```\n\n### 源代码（仓库根目录）\n\u003c!--\n 需要操作：用此功能的具体布局替换下面的占位符树。\n 删除未使用的选项，并使用真实路径扩展所选结构（例如，apps/admin, packages/something）。\n 提供的计划不得包含选项标签。\n-->\n\n```text\n# [如果未使用则删除] 选项 1：单一项目（默认）\nsrc/\n├── models/\n├── services/\n├── cli/\n└── lib/\n\ntests/\n├── contract/\n├── integration/\n└── unit/\n\n# [如果未使用则删除] 选项 2：Web 应用程序（当检测到 \"frontend\" + \"backend\" 时）\nbackend/\n├── src/\n│ ├── models/\n│ ├── services/\n│ └── api/\n└── tests/\n\nfrontend/\n├── src/\n│ ├── components/\n│ ├── pages/\n│ └── services/\n└── tests/\n\n# [如果未使用则删除] 选项 3：移动端 + API（当检测到 \"iOS/Android\" 时）\napi/\n└── [与后端相同]\n\nios/ 或 android/\n└── [平台特定结构：功能模块、UI 流程、平台测试]\n```\n\n**结构决策**：[记录选择的结构并引用上面捕获的真实目录]\n\n## 复杂度跟踪\n\n> **仅当宪章检查存在必须证明合理性的违规情况时才填写**\n\n| 违规情况 | 为何需要 | 被拒绝的更简单替代方案原因 |\n|-----------|------------|-------------------------------------|\n| [例如，第 4 个项目] | [当前需求] | [为什么 3 个项目不够] |\n| [例如，仓储模式] | [具体问题] | [为什么直接数据库访问不够] |","content_type":"text/markdown; charset=utf-8","language":"markdown","size":3579,"content_sha256":"4e86cc6b346c5a2c72e30abcf796214159a063eb4aa6f74ab88bddf84d281a4c"},{"filename":"assets/specify/templates/spec-template.md","content":"# 功能规格：[功能名称]\n\n**功能分支**：`[###-feature-name]` \n**创建时间**：[日期] \n**状态**：草案 \n**输入**：用户描述：\"$ARGUMENTS\"\n\n## 用户场景与测试 *(必填)*\n\n\u003c!--\n 重要：用户故事应按照重要性排序为用户旅程。\n 每个用户故事/旅程必须是独立可测试的 - 这意味着如果您只实现其中一个，\n 您仍应拥有一个可交付价值的可行MVP（最小可行产品）。\n \n 为每个故事分配优先级（P1, P2, P3等），其中P1是最重要的。\n 将每个故事视为可以：\n - 独立开发\n - 独立测试\n - 独立部署\n - 独立向用户展示\n-->\n\n### 用户故事 1 - [简要标题] (优先级: P1)\n\n[用通俗语言描述此用户旅程]\n\n**为何此优先级**：[解释价值以及为何具有此优先级]\n\n**独立测试**：[描述如何独立测试 - 例如，\"可以通过[具体操作]完全测试，并交付[具体价值]\"]\n\n**验收场景**：\n\n1. **给定** [初始状态]，**当** [操作]，**则** [预期结果]\n2. **给定** [初始状态]，**当** [操作]，**则** [预期结果]\n\n---\n\n### 用户故事 2 - [简要标题] (优先级: P2)\n\n[用通俗语言描述此用户旅程]\n\n**为何此优先级**：[解释价值以及为何具有此优先级]\n\n**独立测试**：[描述如何独立测试]\n\n**验收场景**：\n\n1. **给定** [初始状态]，**当** [操作]，**则** [预期结果]\n\n---\n\n### 用户故事 3 - [简要标题] (优先级: P3)\n\n[用通俗语言描述此用户旅程]\n\n**为何此优先级**：[解释价值以及为何具有此优先级]\n\n**独立测试**：[描述如何独立测试]\n\n**验收场景**：\n\n1. **给定** [初始状态]，**当** [操作]，**则** [预期结果]\n\n---\n\n[根据需要添加更多用户故事，每个都有分配的优先级]\n\n### 边缘情况\n\n\u003c!--\n 需要操作：本节中的内容是占位符。\n 用正确的边缘情况填充它们。\n-->\n\n- 当[边界条件]发生时会怎样？\n- 系统如何处理[错误场景]？\n\n## 要求 *(必填)*\n\n\u003c!--\n 需要操作：本节中的内容是占位符。\n 用正确的功能要求填充它们。\n-->\n\n### 功能要求\n\n- **FR-001**：系统必须[具体能力，例如，\"允许用户创建账户\"]\n- **FR-002**：系统必须[具体能力，例如，\"验证电子邮件地址\"] \n- **FR-003**：用户必须能够[关键交互，例如，\"重置密码\"]\n- **FR-004**：系统必须[数据要求，例如，\"持久化用户偏好设置\"]\n- **FR-005**：系统必须[行为，例如，\"记录所有安全事件\"]\n\n*标记不明确要求的示例：*\n\n- **FR-006**：系统必须通过[需要澄清：未指定认证方法 - 电子邮件/密码、SSO、OAuth？]\n- **FR-007**：系统必须保留用户数据[需要澄清：未指定保留期]\n\n### 关键实体 *(如果功能涉及数据则包含)*\n\n- **[实体 1]**：[它代表什么，关键属性（无实现细节）]\n- **[实体 2]**：[它代表什么，与其他实体的关系]\n\n## 成功标准 *(必填)*\n\n\u003c!--\n 需要操作：定义可衡量的成功标准。\n 这些必须是技术无关且可衡量的。\n-->\n\n### 可衡量的结果\n\n- **SC-001**：[可衡量的指标，例如，\"用户可以在2分钟内完成账户创建\"]\n- **SC-002**：[可衡量的指标，例如，\"系统在无降级情况下处理1000个并发用户\"]\n- **SC-003**：[用户满意度指标，例如，\"90%的用户首次尝试即可成功完成主要任务\"]\n- **SC-004**：[业务指标，例如，\"将与[X]相关的支持工单减少50%\"]","content_type":"text/markdown; charset=utf-8","language":"markdown","size":3521,"content_sha256":"333070a573eae88cd1152289e4ecb20f07352e5e3c9d229b5c91bb4f7c391259"},{"filename":"assets/specify/templates/tasks-template.md","content":"---\ndescription: \"功能实现的任务列表模板\"\n---\n\n# 任务：[功能名称]\n\n**输入**：来自 `/specs/[###-功能名称]/` 的设计文档\n**先决条件**：plan.md（必需），spec.md（用户故事必需），research.md，data-model.md，contracts/\n\n**测试**：下面的示例包含测试任务。测试是可选的 - 仅在功能规格中明确要求时才包含它们。\n\n**组织**：任务按用户故事分组，以实现每个故事的独立实现和测试。\n\n## 格式：`[ID] [P?] [故事] 描述`\n\n- **[P]**：可以并行运行（不同文件，无依赖关系）\n- **[故事]**：此任务属于哪个用户故事（例如，US1, US2, US3）\n- 在描述中包含确切的文件路径\n\n## 路径约定\n\n- **单一项目**：`src/`, `tests/` 在仓库根目录\n- **Web 应用**：`backend/src/`, `frontend/src/`\n- **移动端**：`api/src/`, `ios/src/` 或 `android/src/`\n- 下面显示的路径假设为单一项目 - 根据 plan.md 结构进行调整\n\n\u003c!-- \n ============================================================================\n 重要提示：下面的任务仅为示例任务，仅用于说明目的。\n \n /speckit.tasks 命令必须根据以下内容替换这些任务：\n - 来自 spec.md 的用户故事（及其优先级 P1, P2, P3...）\n - 来自 plan.md 的功能要求\n - 来自 data-model.md 的实体\n - 来自 contracts/ 的端点\n \n 任务必须按用户故事组织，以便每个故事可以：\n - 独立实现\n - 独立测试\n - 作为 MVP 增量交付\n \n 不要在生成的 tasks.md 文件中保留这些示例任务。\n ============================================================================\n-->\n\n## 阶段 1：设置（共享基础设施）\n\n**目的**：项目初始化和基本结构\n\n- [ ] T001 根据实现计划创建项目结构\n- [ ] T002 使用 [框架] 依赖项初始化 [语言] 项目\n- [ ] T003 [P] 配置代码检查和格式化工具\n\n---\n\n## 阶段 2：基础（阻塞先决条件）\n\n**目的**：必须在任何用户故事实现之前完成的核心基础设施\n\n**⚠️ 关键**：在本阶段完成之前，任何用户故事工作都不能开始\n\n基础任务示例（根据您的项目进行调整）：\n\n- [ ] T004 设置数据库模式和迁移框架\n- [ ] T005 [P] 实现认证/授权框架\n- [ ] T006 [P] 设置 API 路由和中间件结构\n- [ ] T007 创建所有故事都依赖的基础模型/实体\n- [ ] T008 配置错误处理和日志基础设施\n- [ ] T009 设置环境配置管理\n\n**检查点**：基础就绪 - 用户故事实现现在可以并行开始\n\n---\n\n## 阶段 3：用户故事 1 - [标题] (优先级: P1) 🎯 MVP\n\n**目标**：[对此故事交付内容的简要描述]\n\n**独立测试**：[如何验证此故事独立工作]\n\n### 用户故事 1 的测试（可选 - 仅在要求测试时）⚠️\n\n> **注意：首先编写这些测试，确保在实现之前它们失败**\n\n- [ ] T010 [P] [US1] tests/contract/test_[name].py 中 [端点] 的契约测试\n- [ ] T011 [P] [US1] tests/integration/test_[name].py 中 [用户旅程] 的集成测试\n\n### 用户故事 1 的实现\n\n- [ ] T012 [P] [US1] 在 src/models/[entity1].py 中创建 [Entity1] 模型\n- [ ] T013 [P] [US1] 在 src/models/[entity2].py 中创建 [Entity2] 模型\n- [ ] T014 [US1] 在 src/services/[service].py 中实现 [服务]（依赖于 T012, T013）\n- [ ] T015 [US1] 在 src/[location]/[file].py 中实现 [端点/功能]\n- [ ] T016 [US1] 添加验证和错误处理\n- [ ] T017 [US1] 为用户故事 1 操作添加日志\n\n**检查点**：此时，用户故事 1 应该完全功能化并可独立测试\n\n---\n\n## 阶段 4：用户故事 2 - [标题] (优先级: P2)\n\n**目标**：[对此故事交付内容的简要描述]\n\n**独立测试**：[如何验证此故事独立工作]\n\n### 用户故事 2 的测试（可选 - 仅在要求测试时）⚠️\n\n- [ ] T018 [P] [US2] tests/contract/test_[name].py 中 [端点] 的契约测试\n- [ ] T019 [P] [US2] tests/integration/test_[name].py 中 [用户旅程] 的集成测试\n\n### 用户故事 2 的实现\n\n- [ ] T020 [P] [US2] 在 src/models/[entity].py 中创建 [实体] 模型\n- [ ] T021 [US2] 在 src/services/[service].py 中实现 [服务]\n- [ ] T022 [US2] 在 src/[location]/[file].py 中实现 [端点/功能]\n- [ ] T023 [US2] 与用户故事 1 组件集成（如果需要）\n\n**检查点**：此时，用户故事 1 和 2 都应该独立工作\n\n---\n\n## 阶段 5：用户故事 3 - [标题] (优先级: P3)\n\n**目标**：[对此故事交付内容的简要描述]\n\n**独立测试**：[如何验证此故事独立工作]\n\n### 用户故事 3 的测试（可选 - 仅在要求测试时）⚠️\n\n- [ ] T024 [P] [US3] tests/contract/test_[name].py 中 [端点] 的契约测试\n- [ ] T025 [P] [US3] tests/integration/test_[name].py 中 [用户旅程] 的集成测试\n\n### 用户故事 3 的实现\n\n- [ ] T026 [P] [US3] 在 src/models/[entity].py 中创建 [实体] 模型\n- [ ] T027 [US3] 在 src/services/[service].py 中实现 [服务]\n- [ ] T028 [US3] 在 src/[location]/[file].py 中实现 [端点/功能]\n\n**检查点**：所有用户故事现在都应该独立功能化\n\n---\n\n[根据需要添加更多用户故事阶段，遵循相同模式]\n\n---\n\n## 阶段 N：完善和跨领域关注点\n\n**目的**：影响多个用户故事的改进\n\n- [ ] TXXX [P] docs/ 中的文档更新\n- [ ] TXXX 代码清理和重构\n- [ ] TXXX 跨所有故事的性能优化\n- [ ] TXXX [P] 附加单元测试（如果要求）在 tests/unit/ 中\n- [ ] TXXX 安全加固\n- [ ] TXXX 运行 quickstart.md 验证\n\n---\n\n## 依赖关系和执行顺序\n\n### 阶段依赖关系\n\n- **设置（阶段 1）**：无依赖关系 - 可立即开始\n- **基础（阶段 2）**：依赖于设置完成 - 阻塞所有用户故事\n- **用户故事（阶段 3+）**：都依赖于基础阶段完成\n - 用户故事然后可以并行进行（如果有人员）\n - 或按优先级顺序依次进行（P1 → P2 → P3）\n- **完善（最终阶段）**：依赖于所有所需用户故事完成\n\n### 用户故事依赖关系\n\n- **用户故事 1 (P1)**：可在基础阶段完成后开始 - 无其他故事依赖\n- **用户故事 2 (P2)**：可在基础阶段完成后开始 - 可能与 US1 集成但应独立可测试\n- **用户故事 3 (P3)**：可在基础阶段完成后开始 - 可能与 US1/US2 集成但应独立可测试\n\n### 每个用户故事内部\n\n- 测试（如果包含）必须在实现之前编写并失败\n- 模型在服务之前\n- 服务在端点之前\n- 核心实现在集成之前\n- 故事完成后才进入下一个优先级\n\n### 并行机会\n\n- 所有标记为 [P] 的设置任务可以并行运行\n- 所有标记为 [P] 的基础任务可以并行运行（在阶段 2 内）\n- 一旦基础阶段完成，所有用户故事可以并行开始（如果团队容量允许）\n- 标记为 [P] 的用户故事的所有测试可以并行运行\n- 标记为 [P] 的故事内的模型可以并行运行\n- 不同的用户故事可以由不同团队成员并行处理\n\n---\n\n## 并行示例：用户故事 1\n\n```bash\n# 一起启动用户故事 1 的所有测试（如果要求测试）：\n任务：\"tests/contract/test_[name].py 中 [端点] 的契约测试\"\n任务：\"tests/integration/test_[name].py 中 [用户旅程] 的集成测试\"\n\n# 一起启动用户故事 1 的所有模型：\n任务：\"在 src/models/[entity1].py 中创建 [Entity1] 模型\"\n任务：\"在 src/models/[entity2].py 中创建 [Entity2] 模型\"\n```\n\n---\n\n## 实现策略\n\n### MVP 优先（仅用户故事 1）\n\n1. 完成阶段 1：设置\n2. 完成阶段 2：基础（关键 - 阻塞所有故事）\n3. 完成阶段 3：用户故事 1\n4. **停止并验证**：独立测试用户故事 1\n5. 如果准备就绪则部署/演示\n\n### 增量交付\n\n1. 完成设置 + 基础 → 基础就绪\n2. 添加用户故事 1 → 独立测试 → 部署/演示（MVP！）\n3. 添加用户故事 2 → 独立测试 → 部署/演示\n4. 添加用户故事 3 → 独立测试 → 部署/演示\n5. 每个故事在不破坏之前故事的情况下增加价值\n\n### 并行团队策略\n\n多个开发人员时：\n\n1. 团队一起完成设置 + 基础\n2. 一旦基础完成：\n - 开发人员 A：用户故事 1\n - 开发人员 B：用户故事 2\n - 开发人员 C：用户故事 3\n3. 故事独立完成和集成\n\n---\n\n## 备注\n\n- [P] 任务 = 不同文件，无依赖关系\n- [故事] 标签将任务映射到特定用户故事以实现可追溯性\n- 每个用户故事应该是独立可完成和可测试的\n- 在实现之前验证测试失败\n- 每个任务或逻辑组之后提交\n- 在任何检查点停止以独立验证故事\n- 避免：模糊任务、相同文件冲突、破坏独立性的跨故事依赖","content_type":"text/markdown; charset=utf-8","language":"markdown","size":8682,"content_sha256":"f3dbdad15a3c18454bed485bbb421ac14ed62ccd098b1d3c663ddf89125e4fdf"}],"content_json":{"type":"doc","content":[{"type":"heading","attrs":{"level":2},"content":[{"text":"用户输入","type":"text"}]},{"type":"code_block","attrs":{"wrap":false,"language":"text"},"content":[{"text":"$ARGUMENTS","type":"text"}]},{"type":"paragraph","content":[{"text":"在继续之前，您","type":"text"},{"text":"必须","type":"text","marks":[{"type":"strong"}]},{"text":"考虑用户输入（如果不为空）。","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"大纲","type":"text"}]},{"type":"paragraph","content":[{"text":"您正在更新位于 ","type":"text"},{"text":".specify/memory/constitution.md","type":"text","marks":[{"type":"code_inline"}]},{"text":" 的项目章程。此文件源自一个模板","type":"text"},{"text":"assets/constitution-template.md","type":"text","marks":[{"type":"link","attrs":{"href":"assets/constitution-template.md","title":null}}]},{"text":"，包含方括号中的占位符令牌（例如 ","type":"text"},{"text":"[项目名称]","type":"text","marks":[{"type":"code_inline"}]},{"text":"、","type":"text"},{"text":"[原则_1_名称]","type":"text","marks":[{"type":"code_inline"}]},{"text":"）。您的工作是：(a) 收集/推导具体值，(b) 精确填充模板，以及 (c) 在依赖工件中传播任何修订。","type":"text"}]},{"type":"paragraph","content":[{"text":"遵循此执行流程：","type":"text"}]},{"type":"ordered_list","attrs":{"order":1,"listStyle":"number"},"content":[{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"将 ","type":"text"},{"text":"assets/specify/","type":"text","marks":[{"type":"code_inline"}]},{"text":" 所有文件（包括子目录）按原目录结构复制到仓库根目录下的","type":"text"},{"text":".specify","type":"text","marks":[{"type":"code_inline"}]},{"text":" 目录，跳过已有文件，","type":"text"},{"text":"不能覆盖原有同名文件","type":"text","marks":[{"type":"strong"}]},{"text":"。cp命令的 -n（--no-clobber）选项可以防止覆盖已存在的文件。 在此阶段，您的项目文件夹内容应类似于以下内容：","type":"text"}]}]}]},{"type":"code_block","attrs":{"wrap":false,"language":"text"},"content":[{"text":"仓库根目录\n└── .specify\n ├── memory\n │ └── constitution.md\n ├── scripts\n │ ├──bash \n │ │ ├── check-prerequisites.sh\n │ │ ├── common.sh\n │ │ ├── create-new-feature.sh\n │ │ ├── setup-plan.sh\n │ │ └── update-claude-md.sh\n │ ├──powershell \n │ │ ├── check-prerequisites.ps1\n │ │ ├── common.ps1\n │ │ ├── create-new-feature.ps1\n │ │ ├── setup-plan.ps1\n │ │ └── update-claude-md.ps1 \n ├── specs\n │ └── 001-create-taskify\n │ └── spec.md\n └── templates\n ├── plan-template.md\n ├── spec-template.md\n └── tasks-template.md","type":"text"}]},{"type":"ordered_list","attrs":{"order":2,"listStyle":"number"},"content":[{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"加载位于相对仓库根目录 ","type":"text"},{"text":".specify/memory/constitution.md","type":"text","marks":[{"type":"code_inline"}]},{"text":" 的现有章程模板。","type":"text"}]},{"type":"bullet_list","content":[{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"识别形式为 ","type":"text"},{"text":"[ALL_CAPS_IDENTIFIER]","type":"text","marks":[{"type":"code_inline"}]},{"text":" 的每个占位符令牌。 ","type":"text"},{"text":"重要","type":"text","marks":[{"type":"strong"}]},{"text":"：用户可能需要比模板中使用的更少或更多的原则。如果指定了数量，请遵守该数量 - 遵循通用模板。您将相应地更新文档。","type":"text"}]}]}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"收集/推导占位符的值：","type":"text"}]},{"type":"bullet_list","content":[{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"如果用户输入（对话）提供了值，则使用它。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"否则从现有仓库上下文推断（README、文档、嵌入的先前章程版本）。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"对于治理日期：","type":"text"},{"text":"批准日期","type":"text","marks":[{"type":"code_inline"}]},{"text":" 是原始采用日期（如果未知则询问或标记 TODO），如果有更改则 ","type":"text"},{"text":"最后修订日期","type":"text","marks":[{"type":"code_inline"}]},{"text":" 是今天，否则保持之前的日期。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"章程版本","type":"text","marks":[{"type":"code_inline"}]},{"text":" 必须根据语义版本规则递增：","type":"text"}]},{"type":"bullet_list","content":[{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"主版本：向后不兼容的治理/原则删除或重新定义。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"次版本：添加新原则/章节或实质性扩展指导。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"补丁：澄清、措辞、拼写错误修复、非语义性优化。","type":"text"}]}]}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"如果版本升级类型不明确，在最终确定前提出理由。","type":"text"}]}]}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"起草更新的章程内容：","type":"text"}]},{"type":"bullet_list","content":[{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"用具体文本替换每个占位符（除了项目选择尚未定义而有意保留的模板槽位——明确说明任何剩余的占位符）。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"保留标题层次结构，一旦替换可以移除注释，除非它们仍然提供澄清指导。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"确保每个原则部分：简洁的名称行，段落（或项目符号列表）捕捉不可协商的规则，如果不是显而易见则提供明确的理由。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"确保治理部分列出修订程序、版本策略和合规审查期望。","type":"text"}]}]}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"一致性传播检查清单（将先前检查清单转换为积极验证）：","type":"text"}]},{"type":"bullet_list","content":[{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"读取 ","type":"text"},{"text":".specify/templates/plan-template.md","type":"text","marks":[{"type":"code_inline"}]},{"text":" 并确保任何\"章程检查\"或规则与更新的原则一致。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"读取 ","type":"text"},{"text":".specify/templates/spec-template.md","type":"text","marks":[{"type":"code_inline"}]},{"text":" 以对齐范围/要求——如果章程添加/删除强制性章节或约束则更新。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"读取 ","type":"text"},{"text":".specify/templates/tasks-template.md","type":"text","marks":[{"type":"code_inline"}]},{"text":" 并确保任务分类反映新增或删除的原则驱动任务类型（例如，可观察性、版本控制、测试纪律）。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"读取任何运行时指导文档（例如 ","type":"text"},{"text":"README.md","type":"text","marks":[{"type":"code_inline"}]},{"text":"、","type":"text"},{"text":"docs/quickstart.md","type":"text","marks":[{"type":"code_inline"}]},{"text":" 或存在的特定代理指导文件）。更新对已更改原则的引用。","type":"text"}]}]}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"生成同步影响报告（在更新后作为 HTML 注释预置在章程文件顶部）：","type":"text"}]},{"type":"bullet_list","content":[{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"版本变更：旧 → 新","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"修改的原则列表（旧标题 → 新标题如果重命名）","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"新增章节","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"删除章节","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"需要更新的模板（✅ 已更新 / ⚠ 待处理）及文件路径","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"如果有任何占位符被故意推迟，则列出后续待办事项。","type":"text"}]}]}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"最终输出前的验证：","type":"text"}]},{"type":"bullet_list","content":[{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"没有剩余未解释的括号令牌。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"版本行与报告匹配。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"日期为 ISO 格式 YYYY-MM-DD。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"原则是陈述性的、可测试的，并且没有模糊语言（\"应该\" → 在适当地方替换为 MUST/SHOULD 理由）。","type":"text"}]}]}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"将完成的章程写回到 ","type":"text"},{"text":".specify/memory/constitution.md","type":"text","marks":[{"type":"code_inline"}]},{"text":"（覆盖）。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"向用户输出最终摘要：","type":"text"}]}]}]},{"type":"bullet_list","content":[{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"新版本和升级理由。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"任何标记为手动跟进的文件。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"建议的提交消息（例如，","type":"text"},{"text":"docs: 修订章程至 vX.Y.Z（原则添加 + 治理更新）","type":"text","marks":[{"type":"code_inline"}]},{"text":"）。","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"格式化和样式要求：","type":"text"}]},{"type":"bullet_list","content":[{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"完全按照模板中的 Markdown 标题使用（不要降级/升级级别）。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"包装长理由行以保持可读性（理想情况下 \u003c100 个字符），但不要用生硬的断行强制执行。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"在章节之间保持单个空行。","type":"text"}]}]},{"type":"list_item","content":[{"type":"paragraph","content":[{"text":"避免尾随空白。","type":"text"}]}]}]},{"type":"paragraph","content":[{"text":"如果用户提供部分更新（例如，仅修订一个原则），仍需执行验证和版本决策步骤。","type":"text"}]},{"type":"paragraph","content":[{"text":"如果关键信息缺失（例如，批准日期确实未知），插入 ","type":"text"},{"text":"TODO(\u003cFIELD_NAME>): explanation","type":"text","marks":[{"type":"code_inline"}]},{"text":" 并在同步影响报告的延期项目下包含。","type":"text"}]},{"type":"heading","attrs":{"level":2},"content":[{"text":"不要创建新模板；始终在现有的 ","type":"text"},{"text":".specify/memory/constitution.md","type":"text","marks":[{"type":"code_inline"}]},{"text":" 文件上操作。","type":"text"}]}]},"metadata":{"date":"2026-06-05","name":"speckit-constitution-zh","author":"@skillopedia","source":{"stars":9,"repo_name":"open-skilled-sdd","origin_url":"https://github.com/forztf/open-skilled-sdd/blob/HEAD/skills/speckit-constitution-zh/SKILL.md","repo_owner":"forztf","body_sha256":"c8a29413b6a4b7b194401f2106df4ce0001fd506cb6d36992d33103ba7610529","cluster_key":"fa72db7ab26f8ddc46c54ca195283664f20a94dbfd57ff9d91bec267eca08771","clean_bundle":{"format":"clean-skill-bundle-v1","source":"forztf/open-skilled-sdd/skills/speckit-constitution-zh/SKILL.md","attachments":[{"id":"605dcea7-4ce4-52b6-9ebd-6db634da15ae","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/605dcea7-4ce4-52b6-9ebd-6db634da15ae/attachment.md","path":"assets/specify/memory/constitution.md","size":2047,"sha256":"3d034f400b5f866e2488b00712f1772898e57d40165953749f7d5872de66a198","contentType":"text/markdown; charset=utf-8"},{"id":"77dc270f-5188-59bf-b520-539da34079f4","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/77dc270f-5188-59bf-b520-539da34079f4/attachment.sh","path":"assets/specify/scripts/bash/check-prerequisites.sh","size":4888,"sha256":"8c62d6b730416a6cfde7af69cedfbd48d832e7d17b178a8d14d1b53a649678be","contentType":"application/x-sh; charset=utf-8"},{"id":"099ee60b-b836-56e1-8f68-07123ce68c6c","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/099ee60b-b836-56e1-8f68-07123ce68c6c/attachment.sh","path":"assets/specify/scripts/bash/common.sh","size":4909,"sha256":"1104cec784e15345ecb7cfda8d025ac7ac389e864d336793691c78d8b7aa2812","contentType":"application/x-sh; charset=utf-8"},{"id":"0ba42acb-5352-5c66-91df-18f88106e28d","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/0ba42acb-5352-5c66-91df-18f88106e28d/attachment.sh","path":"assets/specify/scripts/bash/create-new-feature.sh","size":9081,"sha256":"d3857ee792cb3a5ea18a5b6ce9a12a0fa6e4f763ced58eeb63abaed7687adb25","contentType":"application/x-sh; charset=utf-8"},{"id":"335131d3-960d-51a9-b77d-d25eee84eb78","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/335131d3-960d-51a9-b77d-d25eee84eb78/attachment.sh","path":"assets/specify/scripts/bash/setup-plan.sh","size":1609,"sha256":"521a1ab39ac9b0ac29baa1d6e0f1159d2808baba9e4c79b955857a01abe6396f","contentType":"application/x-sh; charset=utf-8"},{"id":"16888eaf-32e2-526d-a94d-15762665ed78","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/16888eaf-32e2-526d-a94d-15762665ed78/attachment.sh","path":"assets/specify/scripts/bash/update-agent-context.sh","size":24368,"sha256":"49e339c0527bb469f21ee125d95d0a7eb59fd8cab99bf02ddb5805261b86cff9","contentType":"application/x-sh; charset=utf-8"},{"id":"c1482e69-f4d1-5dcd-b37f-185232d7bdb0","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/c1482e69-f4d1-5dcd-b37f-185232d7bdb0/attachment.ps1","path":"assets/specify/scripts/powershell/check-prerequisites.ps1","size":4746,"sha256":"93abaf536c75d83b6f2c8612564f7c3b4a7d829a81c91b380a4eb474a199f941","contentType":"text/plain; charset=utf-8"},{"id":"54d01b86-cd0b-5023-a9bf-28d0402b7c23","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/54d01b86-cd0b-5023-a9bf-28d0402b7c23/attachment.ps1","path":"assets/specify/scripts/powershell/common.ps1","size":3854,"sha256":"38e74324798ca647c474dd23f4722dfb6657c2b5685a8737d95916fd45cf31e0","contentType":"text/plain; charset=utf-8"},{"id":"2ed1eb7f-1809-5e5f-949f-18fe1e463a64","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/2ed1eb7f-1809-5e5f-949f-18fe1e463a64/attachment.ps1","path":"assets/specify/scripts/powershell/create-new-feature.ps1","size":9623,"sha256":"9ce0454c39d5a20a63d0a4591d823d202bff8b8a6198d60dce8df640528c8eca","contentType":"text/plain; charset=utf-8"},{"id":"16486460-4293-553d-92ff-e5473fddee7b","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/16486460-4293-553d-92ff-e5473fddee7b/attachment.ps1","path":"assets/specify/scripts/powershell/setup-plan.ps1","size":1889,"sha256":"6078598d72b6e94f8379b033d4739bdc573db507d916077f84a1c5ec770163bc","contentType":"text/plain; charset=utf-8"},{"id":"acd59cd4-8579-5bea-80b5-9f33bfa9ab16","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/acd59cd4-8579-5bea-80b5-9f33bfa9ab16/attachment.ps1","path":"assets/specify/scripts/powershell/update-agent-context.ps1","size":19295,"sha256":"8441b2e33c273c81328bee0adcc45423df12114826f4483a5c79b0ac505641b4","contentType":"text/plain; charset=utf-8"},{"id":"8cead816-cdef-5710-b941-e2dc8a1a9cf3","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/8cead816-cdef-5710-b941-e2dc8a1a9cf3/attachment.md","path":"assets/specify/templates/agent-file-template.md","size":433,"sha256":"a4c5cf54255f8497516475b2a453f6a74a65ee4d949db8532609bc31239fe9c3","contentType":"text/markdown; charset=utf-8"},{"id":"a41a45c2-415c-5390-a928-5f991484f696","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/a41a45c2-415c-5390-a928-5f991484f696/attachment.md","path":"assets/specify/templates/checklist-template.md","size":1255,"sha256":"b8bdb728b5b5e08682c5c1750ada615cdc04264c234a9d0a266cde840434781f","contentType":"text/markdown; charset=utf-8"},{"id":"6b147cdc-a907-5c32-b95b-441f367d46a2","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/6b147cdc-a907-5c32-b95b-441f367d46a2/attachment.md","path":"assets/specify/templates/commands/analyze.md","size":6582,"sha256":"b66e323bd961a173d29b8b083a511c56343a593f149f2f3941f8223db5ef8f5b","contentType":"text/markdown; charset=utf-8"},{"id":"85b299d8-557e-5265-a720-1f8a2e95bf62","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/85b299d8-557e-5265-a720-1f8a2e95bf62/attachment.md","path":"assets/specify/templates/commands/checklist.md","size":15507,"sha256":"8a0f209a6469a25e2fbd92aa7505d15843fea7d0d469a55db904edfbea50891b","contentType":"text/markdown; charset=utf-8"},{"id":"09a8fd78-8d8e-5db2-89f5-3d1682c55f48","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/09a8fd78-8d8e-5db2-89f5-3d1682c55f48/attachment.md","path":"assets/specify/templates/commands/clarify.md","size":10219,"sha256":"30a4203d7093d35f5b56cf89d93698d883abc71210037bd2b29cd6130f909efd","contentType":"text/markdown; charset=utf-8"},{"id":"6d2b26cc-83ea-50a2-950b-d076a01d5c7c","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/6d2b26cc-83ea-50a2-950b-d076a01d5c7c/attachment.md","path":"assets/specify/templates/commands/constitution.md","size":4629,"sha256":"c61b8fa30bcd1662c5efadc420cf093a289506a403c27cc0c5ccd75e7f50aab5","contentType":"text/markdown; charset=utf-8"},{"id":"9e0c80cd-c4dc-5275-8d91-00f3ed1037ac","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/9e0c80cd-c4dc-5275-8d91-00f3ed1037ac/attachment.md","path":"assets/specify/templates/commands/implement.md","size":7211,"sha256":"8167950f72c1157924af06038f8b3e47b7507931cd5b36487451960b2056b3d4","contentType":"text/markdown; charset=utf-8"},{"id":"faae4633-fba4-5fad-a873-1499581ad09e","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/faae4633-fba4-5fad-a873-1499581ad09e/attachment.md","path":"assets/specify/templates/commands/plan.md","size":2973,"sha256":"936eb547e4720a687b934d5b3315a6924f0b3064119f1a4c04476aeda83cbb96","contentType":"text/markdown; charset=utf-8"},{"id":"d1201c18-3cf7-577b-8403-440b8c37a138","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/d1201c18-3cf7-577b-8403-440b8c37a138/attachment.md","path":"assets/specify/templates/commands/specify.md","size":11279,"sha256":"1b8204a71906cf5f1d51f540f6f1d51b88183320eb0661e13514dfd2dfd5b3d0","contentType":"text/markdown; charset=utf-8"},{"id":"79a06b90-924e-5e62-b5cc-0111ba8e6aa3","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/79a06b90-924e-5e62-b5cc-0111ba8e6aa3/attachment.md","path":"assets/specify/templates/commands/tasks.md","size":6005,"sha256":"ea35392a134918f91fc52effd7109c9efd091948aef3f08d7ac8eed5fc1e1839","contentType":"text/markdown; charset=utf-8"},{"id":"11940c32-925c-526a-a5f4-772ffbb43e7e","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/11940c32-925c-526a-a5f4-772ffbb43e7e/attachment.md","path":"assets/specify/templates/constitution-template.md","size":2047,"sha256":"3d034f400b5f866e2488b00712f1772898e57d40165953749f7d5872de66a198","contentType":"text/markdown; charset=utf-8"},{"id":"0d82dbcc-f6f4-5e76-980b-e8a271adecd5","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/0d82dbcc-f6f4-5e76-980b-e8a271adecd5/attachment.md","path":"assets/specify/templates/plan-template.md","size":3579,"sha256":"4e86cc6b346c5a2c72e30abcf796214159a063eb4aa6f74ab88bddf84d281a4c","contentType":"text/markdown; charset=utf-8"},{"id":"4b9a5fb0-d122-5d24-acc6-2ea6307a6638","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/4b9a5fb0-d122-5d24-acc6-2ea6307a6638/attachment.md","path":"assets/specify/templates/spec-template.md","size":3521,"sha256":"333070a573eae88cd1152289e4ecb20f07352e5e3c9d229b5c91bb4f7c391259","contentType":"text/markdown; charset=utf-8"},{"id":"5e981d8d-e61a-5e2d-a859-4f83ab58cb8d","key":"uploads/10433ee7-ad12-4ae0-b34e-97553e46c6c8/5e981d8d-e61a-5e2d-a859-4f83ab58cb8d/attachment.md","path":"assets/specify/templates/tasks-template.md","size":8682,"sha256":"f3dbdad15a3c18454bed485bbb421ac14ed62ccd098b1d3c663ddf89125e4fdf","contentType":"text/markdown; charset=utf-8"}],"bundle_sha256":"4dc98ad3413ba5351cd07351611c7aaac371b214c8557a6bfcde341dba5727b9","attachment_count":25,"text_attachments":20,"attachment_storage":"skillopedia-attachments-v1","binary_attachments":5,"excluded_attachments":[]},"cluster_size":1,"skill_md_path":"skills/speckit-constitution-zh/SKILL.md","import_metadata":{"date":"2026-06-05","author":"@skillopedia","version":"v1","category":"general","category_label":"General"},"exact_dupes_collapsed_into_this":0},"version":"v1","category":"general","import_tag":"clean-skills-v1","description":"从交互式或提供的原则输入创建或更新项目章程，确保所有依赖模板保持同步。用于项目管理、规范制定、章程维护和团队协作场景。触发词包括 \"speckit章程\"、\"创建章程\"、\"更新章程\"、\"项目章程\"、\"制定规范\"、\"团队章程\"。"}},"renderedAt":1782988437358}

用户输入 在继续之前，您 必须 考虑用户输入（如果不为空）。 大纲 您正在更新位于 的项目章程。此文件源自一个模板assets/constitution-template.md，包含方括号中的占位符令牌（例如 、 ）。您的工作是：(a) 收集/推导具体值，(b) 精确填充模板，以及 (c) 在依赖工件中传播任何修订。 遵循此执行流程： 1. 将 所有文件（包括子目录）按原目录结构复制到仓库根目录下的 目录，跳过已有文件， 不能覆盖原有同名文件 。cp命令的 -n（--no-clobber）选项可以防止覆盖已存在的文件。 在此阶段，您的项目文件夹内容应类似于以下内容： 2. 加载位于相对仓库根目录 的现有章程模板。 - 识别形式为 的每个占位符令牌。 重要 ：用户可能需要比模板中使用的更少或更多的原则。如果指定了数量，请遵守该数量 - 遵循通用模板。您将相应地更新文档。 3. 收集/推导占位符的值： - 如果用户输入（对话）提供了值，则使用它。 - 否则从现有仓库上下文推断（README、文档、嵌入的先前章程版本）。 - 对于治理日期： 是原始采用日期（如果未知则询问或标记 TODO），如果有更改则 是今天，否则保持之前的日期。 - 必须根据语义版本规则递增： - 主版本：向后不兼容的治理/原则删除或重新定义。 - 次版本：添加新原则/章节或实质性扩展指导。 - 补丁：澄清、措辞、…