Speckit Tasks Zh

Name: Speckit Tasks Zh
Author: forztf

forztf/open-skilled-sdd

284 installs
9 repo stars
Updated November 28, 2025
forztf/open-skilled-sdd

Generate and maintain Chinese SpecKit task breakdowns from OpenSpec documents so implementation work is tracked in ordered, agent-friendly work units.

About

Explains Chinese SpecKit task authoring in forztf/open-skilled-sdd, converting OpenSpec requirements into structured, dependency-aware task lists that guide spec-driven builds and give agents clear, verifiable units of work.

Chinese SpecKit task templates tied to OpenSpec
Breaks specs into ordered, verifiable work items
Aligns agent execution with acceptance criteria
Supports dependency-aware implementation planning
Keeps spec-to-task traceability explicit

Speckit Tasks Zh by the numbers

284 all-time installs (skills.sh)
Ranked #920 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
Data as of Jul 24, 2026 (Skillselion catalog sync)

npx skills add https://github.com/forztf/open-skilled-sdd --skill speckit-tasks-zh

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/forztf/open-skilled-sdd/speckit-tasks-zh.svg)](https://skillselion.com/skills/forztf/open-skilled-sdd/speckit-tasks-zh)

Installs	284
repo stars	★ 9
Last updated	November 28, 2025
Repository	forztf/open-skilled-sdd ↗

What it does

Generate and maintain Chinese SpecKit task breakdowns from OpenSpec documents so implementation work is tracked in ordered, agent-friendly work units.

Files

SKILL.mdMarkdownGitHub ↗

用户输入

$ARGUMENTS

您必须在继续之前考虑用户输入（如果不为空）。

大纲

scripts: sh: .specify/scripts/bash/check-prerequisites.sh --json ps: .specify/scripts/powershell/check-prerequisites.ps1 -Json

1. 设置：从仓库根目录运行 {SCRIPT} 并解析 FEATURE_DIR 和 AVAILABLE_DOCS 列表。所有路径必须是绝对的。对于参数中的单引号，如 "I'm Groot"，使用转义语法：例如 'I'\''m Groot'（或者如果可能的话使用双引号："I'm Groot"）。

2. 加载设计文档：从 FEATURE_DIR 读取：

必需：plan.md（技术栈、库、结构），spec.md（带优先级的用户故事）
可选：data-model.md（实体），contracts/（API 端点），research.md（决策），quickstart.md（测试场景）
注意：并非所有项目都有所有文档。根据可用内容生成任务。

3. 执行任务生成工作流程：

加载 plan.md 并提取技术栈、库、项目结构
加载 spec.md 并提取带优先级的用户故事（P1, P2, P3 等）
如果存在 data-model.md：提取实体并映射到用户故事
如果存在 contracts/：将端点映射到用户故事
如果存在 research.md：提取决策用于设置任务
生成按用户故事组织的任务（参见下面的任务生成规则）
生成依赖图显示用户故事完成顺序
为每个用户故事创建并行执行示例
验证任务完整性（每个用户故事都有所需任务，可独立测试）

4. 生成 tasks.md：使用 .specify/templates/tasks-template.md 作为结构，填充：

从 plan.md 获取正确的功能名称
阶段 1：设置任务（项目初始化）
阶段 2：基础任务（所有用户故事的阻塞先决条件）
阶段 3+：按 spec.md 中的优先级顺序排列的每个用户故事一个阶段
每个阶段包括：故事目标、独立测试标准、测试（如果要求）、实现任务
最终阶段：完善和跨领域关注点
所有任务必须遵循严格的检查表格式（参见下面的任务生成规则）
每个任务的明确文件路径
依赖关系部分显示故事完成顺序
每个故事的并行执行示例
实现策略部分（MVP 优先、增量交付）

5. 报告：输出生成的 tasks.md 路径和摘要：

总任务数
每个用户故事的任务数
识别的并行机会
每个故事的独立测试标准
建议的 MVP 范围（通常仅为用户故事 1）
格式验证：确认所有任务都遵循检查表格式（复选框、ID、标签、文件路径）

为任务生成提供上下文：{ARGS}

tasks.md 应该是立即可执行的 - 每个任务必须足够具体，以便 LLM 可以在没有额外上下文的情况下完成它。

任务生成规则

关键：任务必须按用户故事组织，以实现独立实现和测试。

测试是可选的：仅在功能规格中明确要求或用户要求 TDD 方法时才生成测试任务。

检查表格式（必需）

每个任务必须严格遵循此格式：

- [ ] [任务ID] [P?] [故事?] 带文件路径的描述

格式组件：

1. 复选框：始终以 - [ ] 开头（markdown 复选框） 2. 任务 ID：按执行顺序的序列号（T001, T002, T003...） 3. [P] 标记：仅当任务可并行化时包含（不同文件，不依赖未完成任务） 4. [故事] 标签：仅用户故事阶段任务必需

格式：[US1], [US2], [US3], 等（映射到 spec.md 中的用户故事）
设置阶段：无故事标签
基础阶段：无故事标签
用户故事阶段：必须有故事标签
完善阶段：无故事标签

5. 描述：带确切文件路径的明确操作

示例：

✅ 正确：- [ ] T001 根据实现计划创建项目结构
✅ 正确：- [ ] T005 [P] 在 src/middleware/auth.py 中实现认证中间件
✅ 正确：- [ ] T012 [P] [US1] 在 src/models/user.py 中创建用户模型
✅ 正确：- [ ] T014 [US1] 在 src/services/user_service.py 中实现 UserService
❌ 错误：- [ ] 创建用户模型（缺少 ID 和故事标签）
❌ 错误：T001 [US1] 创建模型（缺少复选框）
❌ 错误：- [ ] [US1] 创建用户模型（缺少任务 ID）
❌ 错误：- [ ] T001 [US1] 创建模型（缺少文件路径）

任务组织

1. 来自用户故事（spec.md） - 主要组织：

每个用户故事（P1, P2, P3...）都有自己的阶段
将所有相关组件映射到它们的故事：
该故事需要的模型
该故事需要的服务
该故事需要的端点/UI
如果要求测试：该故事的特定测试
标记故事依赖关系（大多数故事应该是独立的）

2. 来自契约：

将每个契约/端点 → 映射到它服务的用户故事
如果要求测试：每个契约 → 在该故事阶段实现前的契约测试任务 [P]

3. 来自数据模型：

将每个实体映射到需要它的用户故事
如果实体服务于多个故事：放在最早的故事或设置阶段
关系 → 在适当的故事阶段中的服务层任务

4. 来自设置/基础设施：

共享基础设施 → 设置阶段（阶段 1）
基础/阻塞任务 → 基础阶段（阶段 2）
故事特定设置 → 在该故事的阶段内

阶段结构

阶段 1：设置（项目初始化）
阶段 2：基础（阻塞先决条件 - 必须在用户故事前完成）
阶段 3+：按优先级顺序的用户故事（P1, P2, P3...）
在每个故事内：测试（如果要求）→ 模型 → 服务 → 端点 → 集成
每个阶段应该是一个完整的、可独立测试的增量
最终阶段：完善和跨领域关注点

任务格式示例与规范

检查表格式（必需）

每个任务必须严格遵循此格式：

- [ ] [TaskID] [P?] [Story?] 描述与文件路径

格式组件详解

1. 复选框: 始终以 - [ ] 开始（markdown复选框） 2. 任务ID: 顺序编号（T001、T002、T003...）按执行顺序 3. [P]标记: 仅在任务可并行时包含（不同文件，无未完成任务的依赖） 4. [Story]标签: 仅用户故事阶段任务必需

格式: [US1]、[US2]、[US3]等（映射自spec.md的用户故事）
设置阶段: 无故事标签
基础阶段: 无故事标签
用户故事阶段: 必须有故事标签
完善阶段: 无故事标签

5. 描述: 包含确切文件路径的清晰操作

正确示例

✅ 正确: - [ ] T001 按实施计划创建项目结构
✅ 正确: - [ ] T005 [P] 在src/middleware/auth.py中实现认证中间件
✅ 正确: - [ ] T012 [P] [US1] 在src/models/user.py中创建User模型
✅ 正确: - [ ] T014 [US1] 在src/services/user_service.py中实现UserService

错误示例

❌ 错误: - [ ] 创建User模型（缺少ID和Story标签）
❌ 错误: T001 [US1] 创建模型（缺少复选框）
❌ 错误: - [ ] [US1] 创建User模型（缺少TaskID）
❌ 错误: - [ ] T001 [US1] 创建模型（缺少文件路径）

任务组织原则

1. 从用户故事出发（spec.md）- 主要组织方式

每个用户故事（P1、P2、P3...）获得自己的阶段：

将所有相关组件映射到其故事：
该故事所需的模型
该故事所需的服务
该故事所需的端点/UI
如果需要测试: 特定于该故事的测试
标记故事依赖关系（大多数故事应该是独立的）

2. 从合同/端点出发

将每个合同/端点映射到其服务的用户故事
如果需要测试: 每个合同 → 在该故事阶段中实施前的合同测试任务[P]

3. 从数据模型出发

将每个实体映射到需要它的用户故事
如果实体服务多个故事: 放入最早的故事或设置阶段
关系 → 相应故事阶段中的服务层任务

4. 从设置/基础设施出发

共享基础设施 → 设置阶段（阶段1）
基础/阻塞任务 → 基础阶段（阶段2）
故事特定设置 → 在该故事的阶段内

阶段结构

阶段1: 设置（项目初始化）
阶段2: 基础（阻塞先决条件 - 必须在用户故事前完成）
阶段3+: 用户故事按优先级（P1、P2、P3...）
在每个故事内: 测试（如果需要）→ 模型 → 服务 → 端点 → 集成
每个阶段应该是一个完整的、可独立测试的增量
最终阶段: 完善和横切关注点

测试任务指南

测试是可选的: 仅在功能规格中明确要求或用户要求TDD方法时生成测试任务。

当需要测试时：

为每个用户故事创建独立的测试标准
确保测试可以独立运行
在实施任务前包含测试设置任务

Speckit Tasks 工作流详细指南

工作流概述

本工作流用于根据可用设计文档生成可操作的、依赖有序的tasks.md。

详细步骤

1. 设置阶段

运行环境检查脚本：

.speckit/scripts/powershell/check-prerequisites.ps1 -Json

重要注意事项：

所有路径必须是绝对路径
对于参数中的单引号，使用转义语法：例如 I'm Groot 应写为 'I'\''m Groot'
或者尽可能使用双引号："I'm Groot"

2. 文档加载阶段

从FEATURE_DIR读取以下文档：

必需文档

plan.md: 技术栈、库、项目结构
spec.md: 带优先级的用户故事

可选文档

data-model.md: 实体定义
contracts/: API端点定义
research.md: 技术决策
quickstart.md: 测试场景

注意: 并非所有项目都有所有文档，基于可用内容生成任务。

3. 任务生成工作流执行

文档解析步骤

1. 加载plan.md并提取：

技术栈
库依赖
项目结构

2. 加载spec.md并提取：

用户故事及其优先级（P1、P2、P3等）

3. 可选文档处理：

如果data-model.md存在：提取实体并映射到用户故事
如果contracts/存在：映射端点到用户故事
如果research.md存在：提取决策用于设置任务

任务组织生成

1. 按用户故事组织任务（参见任务生成规则） 2. 生成依赖关系图显示用户故事完成顺序 3. 创建并行执行示例（每个用户故事） 4. 验证任务完整性（每个用户故事都有所需任务，可独立测试）

4. tasks.md生成

使用模板结构填充以下内容：

正确的功能名称（来自plan.md）
阶段1: 设置任务（项目初始化）
阶段2: 基础任务（所有用户故事的阻塞先决条件）
阶段3+: 每个用户故事一个阶段（按spec.md中的优先级顺序）
每个阶段包含：
故事目标
独立测试标准
测试（如果需要）
实施任务
最终阶段: 完善和横切关注点
所有任务必须遵循严格的检查表格式
每个任务的清晰文件路径
显示故事完成顺序的依赖关系部分
每个故事的并行执行示例
实施策略部分（MVP优先，增量交付）

5. 报告生成

输出以下内容的摘要：

生成的tasks.md路径
总任务数量
每个用户故事的任务数量
识别的并行机会
每个故事的独立测试标准
建议的MVP范围（通常仅为用户故事1）
格式验证：确认所有任务都遵循检查表格式（复选框、ID、标签、文件路径）

质量要求

tasks.md应立即可执行 - 每个任务必须足够具体，使LLM无需额外上下文即可完成
确保任务间的依赖关系清晰明确
验证每个用户故事的独立可测试性

# Speckit Tasks 前置条件检查脚本
# 用于检查环境和解析FEATURE_DIR及可用文档列表

param(
    [switch]$Json
)

# 设置错误处理
$ErrorActionPreference = "Stop"

# 输出函数
function Write-Output {
    param([string]$Message)
    if ($Json) {
        Write-Host $Message
    } else {
        Write-Host $Message -ForegroundColor Green
    }
}

function Write-Error-Output {
    param([string]$Message)
    if ($Json) {
        Write-Host $Message
    } else {
        Write-Host $Message -ForegroundColor Red
    }
}

# 检查当前目录是否为git仓库
function Test-GitRepository {
    try {
        $gitDir = git rev-parse --git-dir 2>$null
        return $gitDir -ne $null
    } catch {
        return $false
    }
}

# 检查.speckit目录
function Test-SpeckitDirectory {
    $speckitDir = ".speckit"
    return Test-Path $speckitDir -PathType Container
}

# 查找FEATURE_DIR
function Find-FeatureDir {
    # 常见的feature目录位置
    $possiblePaths = @(
        ".speckit/feature",
        ".speckit/features",
        "feature",
        "features",
        ".feature"
    )

    foreach ($path in $possiblePaths) {
        if (Test-Path $path -PathType Container) {
            return (Resolve-Path $path).Path
        }
    }

    return $null
}

# 获取可用文档列表
function Get-AvailableDocs {
    param([string]$FeatureDir)

    $docs = @{
        "plan.md" = $false
        "spec.md" = $false
        "data-model.md" = $false
        "research.md" = $false
        "quickstart.md" = $false
        "contracts" = $false
    }

    if ($FeatureDir -and (Test-Path $FeatureDir)) {
        foreach ($doc in $docs.Keys) {
            $docPath = Join-Path $FeatureDir $doc
            if (Test-Path $docPath) {
                $docs[$doc] = $true
            }
        }
    }

    return $docs
}

# 主执行逻辑
try {
    if (-not (Test-GitRepository)) {
        throw "当前目录不是git仓库"
    }

    if (-not (Test-SpeckitDirectory)) {
        throw "未找到.speckit目录"
    }

    $featureDir = Find-FeatureDir
    if (-not $featureDir) {
        throw "未找到feature目录"
    }

    $availableDocs = Get-AvailableDocs -FeatureDir $featureDir

    # 构建输出对象
    $output = @{
        "FEATURE_DIR" = $featureDir
        "AVAILABLE_DOCS" = $availableDocs
        "REPO_ROOT" = (Get-Location).Path
        "STATUS" = "SUCCESS"
    }

    # 输出结果
    if ($Json) {
        $output | ConvertTo-Json -Depth 3
    } else {
        Write-Output "✅ 环境检查通过"
        Write-Output "FEATURE_DIR: $($output.FEATURE_DIR)"
        Write-Output "可用文档:"
        foreach ($doc in $output.AVAILABLE_DOCS.Keys) {
            $status = if ($output.AVAILABLE_DOCS[$doc]) { "✅" } else { "❌" }
            Write-Output "  $status $doc"
        }
        Write-Output "仓库根目录: $($output.REPO_ROOT)"
    }

} catch {
    $errorOutput = @{
        "STATUS" = "ERROR"
        "ERROR" = $_.Exception.Message
        "FEATURE_DIR" = $null
        "AVAILABLE_DOCS" = @{}
        "REPO_ROOT" = (Get-Location).Path
    }

    if ($Json) {
        $errorOutput | ConvertTo-Json -Depth 3
    } else {
        Write-Error-Output "❌ 错误: $($_.Exception.Message)"
        Write-Error-Output "请确保："
        Write-Error-Output "1. 当前目录是git仓库"
        Write-Error-Output "2. 存在.speckit目录"
        Write-Error-Output "3. 存在feature目录（.speckit/feature、feature等）"
    }
    exit 1
}

Related skills

Grill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.691k196k

Grill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.585k196k

Lark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.493k

Lark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.493k

Lark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).493k

Lark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.493k

Productivity & Planningpmworkflow

About

Speckit Tasks Zh by the numbers

Add your badge

What it does

Files

用户输入

大纲

任务生成规则

检查表格式（必需）

任务组织

阶段结构

任务格式示例与规范

检查表格式（必需）

格式组件详解

正确示例

错误示例

任务组织原则

1. 从用户故事出发（spec.md）- 主要组织方式

2. 从合同/端点出发

3. 从数据模型出发

4. 从设置/基础设施出发

阶段结构

测试任务指南

Tasks Template

{{FEATURE_NAME}} 实施任务

概述

阶段 1: 设置任务（项目初始化）

目标

任务

阶段 2: 基础任务（阻塞先决条件）

目标

任务

阶段 3: 用户故事 1 {{USER_STORY_1_TITLE}}

目标

独立测试标准

任务

阶段 4: 用户故事 2 {{USER_STORY_2_TITLE}}

目标

独立测试标准

任务

{{ADDITIONAL_PHASES}}

最终阶段: 完善和横切关注点

目标

任务

依赖关系

故事完成顺序

并行执行机会

用户故事 1

用户故事 2

实施策略

MVP方法

增量交付

验证检查表

Speckit Tasks 工作流详细指南

工作流概述

详细步骤

1. 设置阶段

2. 文档加载阶段

必需文档

可选文档

3. 任务生成工作流执行

文档解析步骤

任务组织生成

4. tasks.md生成

5. 报告生成

质量要求

Related skills

This week in AI coding