Task Generation

SKILL开发
开发 未标注权限 许可证不明确

Generate user-story-organized task lists from implementation plans. Use when plan exists and user is ready for implementation, mentions "create tasks", "break down work", or asks "what tasks are needed" to implement the feature.

一句话选型结论

按资料字段整理

Task Generation是开发类的 Agent Skill,安装方式:GitHub 仓库,权限级别未标注,许可证不明确,没有现成安装命令,需按说明手动放置 SKILL.md。技能本质是给模型读的说明书,效果取决于模型与客户端;装完先用一个小任务验证,再放进正式流程。

分类开发 安装方式GitHub 仓库 权限级别未标注权限 许可证许可证不明确
累计安装 未标注 本周 未标注
GitHub 星标 1 仓库 fine-tuning-exercise-generation
下载量 未标注 技能市场下载数
权限级别 未标注权限 安装前请确认风险范围
许可证 许可证不明确 未说明

安装

GitHub 仓库
在支持 Skills 的客户端里执行,装完问一句「你有哪些技能」验证
  1. 1
    确认客户端支持

    确认你的客户端支持 Skills(Claude、Codex、Cursor 等),并升级到较新的版本。

  2. 2
    拿到技能文件

    按安装说明或仓库 README,把 SKILL.md 放到客户端的 skills 目录(一般一个技能一个文件夹)。

  3. 3
    刷新技能列表

    重新打开客户端,或刷新技能列表,让新放进来的技能被加载。

  4. 4
    验证是否生效

    问一句「你有哪些技能」,确认列表里出现它,再拿一个小任务试跑。

技能档案

开发
字段来自技能仓库与公开索引,中文说明由本站标注
作者 / 维护方yangsi7仓库 fine-tuning-exercise-generation · 版本 未标注
宿主客户端未标注技能可被这些客户端加载
安装方式GitHub 仓库安装包 yangsi7/fine-tuning-exercise-generation
权限级别未标注权限安装前请确认风险范围
许可证未说明许可证不明确,商用前请自行确认条款
仓库可用性available技能仓库当前是否可访问
最近核验未标注上游最后核验时间 · 数据更新 未标注
正文体量14.1 KBSKILL.md 原文大小,越大说明说明书写得越细

典型使用场景

3 类
按分类整理的常见用法,具体以 SKILL.md 为准
写代码与改 bug

按需求补代码、定位并修掉报错。

读仓库与生成改动

让模型读懂项目结构,再给出可落地的改动。

跑测试与排查故障

按现象排查问题,补测试用例并复跑。

选择建议

装之前先看这几条
按条目字段给出的判断,不替你决定用不用

值得选的地方

  • 基础信息齐全,可以先按说明装一个试试。

先想清楚的地方

  • 没有标注权限级别,实际能做什么要装好后确认。
  • 许可证不明确,商用或二次分发前先到仓库确认条款。
  • 没有现成安装命令,要按安装说明或仓库 README 手动放置。
  • 没有做站内核验,内容以作者仓库为准。
  • 技能只是说明书,实际效果取决于模型与客户端,装完先用小任务试一遍。

更适合

  • 需要在开发场景里给模型补一套做法的人。
  • 愿意先读一遍 SKILL.md、确认它会让模型做什么的人。

不太适合

  • 对许可证要求很严、必须明确可商用的人。
  • 只想装完就自动变强、不打算看说明书的人。

同类对比

6 个同类
同分类里挑最接近的几条,字段以各自详情页为准
技能权限级别安装方式累计安装宿主客户端安装命令
Task Generation当前 未标注权限 GitHub 仓库 未标注 未标注 无
技能审查员 浏览器控制 ClawHub 市场 877.9 万 OpenClaw 有
Vercel React 最佳实践 浏览器控制 GitHub 仓库 849.1 万 Codex、Claude、Cursor 有
GitHub 代码协作 联网访问 ClawHub 市场 763.3 万 OpenClaw 有
网页设计指南 联网访问 GitHub 仓库 668.6 万 Codex、Claude、Cursor 有
本体论 只读 ClawHub 市场 663.7 万 OpenClaw 有

SKILL.md 全文

14.1 KB
模型实际读到的说明书原文,来自技能仓库

@.claude/shared-imports/constitution.md
@.claude/templates/tasks.md

Task Generation

Purpose: Transform implementation plans into executable, user-story-organized task breakdowns following Article VII (User-Story-Centric Organization).

Constitutional Authority: Article VII (User-Story-Centric Organization), Article III (Test-First Imperative), Article VIII (Parallelization Markers)


Phase 1: Load Context

Step 1.1: Validate Prerequisites

PreToolUse hook blocks tasks.md without plan.md, but verify:

FEATURE=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "${SPECIFY_FEATURE:-}")

if [[ ! -f "specs/$FEATURE/spec.md" ]]; then
    echo "ERROR: Missing specification (Article IV violation)"
    exit 1
fi

if [[ ! -f "specs/$FEATURE/plan.md" ]]; then
    echo "ERROR: Missing implementation plan (Article IV violation)"
    exit 1
fi

Step 1.2: Load Specification (User Stories)

Read specs/$FEATURE/spec.md

Extract:
- User stories with priorities (P1, P2, P3...)
- Independent test criteria per story
- Functional requirements

Step 1.3: Load Implementation Plan (Tech Details)

Read specs/$FEATURE/plan.md

Extract:
- Tech stack and frameworks
- Component breakdown
- Acceptance criteria (≥2 per story)
- File structure
- Integration points

Step 1.4: Load Supporting Documents (If Available)

Read specs/$FEATURE/data-model.md  # Entity designs
Read specs/$FEATURE/contracts/*.md  # API specifications
Read specs/$FEATURE/quickstart.md  # Test scenarios

Phase 2: Organize Tasks by User Story (Article VII)

CRITICAL: Tasks MUST be grouped by user story, NOT by technical layer.

Phase Structure

Required Phases:
1. Phase 1: Setup - Project initialization, dependencies
2. Phase 2: Foundational - Blocking prerequisites for ALL stories
3. Phase 3+: User Story Phases - One phase per story (P1, P2, P3...)
4. Final Phase: Polish & Cross-Cutting - Documentation, cleanup

Within Each Story Phase:

Phase N: User Story PX - [Title]

Goal: [What user can do after this phase]
Independent Test: [How to validate this story works standalone]

Tasks:
1. Tests (if TDD required)
2. Models needed for this story
3. Services needed for this story
4. Endpoints/UI needed for this story
5. Integration for this story
6. Verification of this story

Phase 3: Generate Tasks

Step 3.1: Phase 1 - Setup Tasks

Purpose: Initialize project structure, install dependencies

Task Format:

- [ ] T001 Create project structure per implementation plan
- [ ] T002 [P] Install dependencies: <list from plan.md>
- [ ] T003 [P] Configure environment variables
- [ ] T004 [P] Set up development database

Parallel Marker [P]: Tasks that can run simultaneously (different files, no dependencies)

Step 3.2: Phase 2 - Foundational Tasks

Purpose: Blocking prerequisites that ALL user stories depend on

Examples:

- [ ] T005 Create base database schema (users table)
- [ ] T006 Set up authentication middleware
- [ ] T007 Configure error handling and logging

NOT user-story-specific: These enable multiple stories.

Step 3.3: Phase 3+ - User Story Tasks

Article VII Mandate: One phase per user story, organized by priority.

Step 3.3.1: Identify Story Components

For each user story from spec.md:

Map to Components (from plan.md):
- Which models does this story need?
- Which services does this story need?
- Which endpoints/UI does this story need?
- Which tests validate this story?

Example: User Story P1 - Email/Password Registration

Components needed:
- Model: User (enhance existing)
- Service: AuthService (new)
- API: POST /register (new)
- UI: RegisterForm (new)
- Tests: Registration flow tests

Step 3.3.2: Generate Tasks with Article III Compliance

Test-First Mandate (Article III): Tests MUST come before implementation.

Task Sequence:

## Phase 3: User Story P1 - Email/Password Registration

**Story Goal**: Users can create accounts with email and password

**Independent Test**: Can register new user, receive session token, login with credentials

**Dependencies**: Phase 2 (foundational) complete

### Tests (Article III: Test-First)
- [ ] T008 [P] [US1] Write test for AC-P1-001 (valid registration) in tests/auth/register.test.ts
- [ ] T009 [P] [US1] Write test for AC-P1-002 (weak password rejection) in tests/auth/register.test.ts

### Implementation
- [ ] T010 [US1] Enhance User model with password_hash field in models/user.ts
- [ ] T011 [US1] Create AuthService.register() method in services/auth-service.ts
- [ ] T012 [US1] Implement POST /api/auth/register endpoint in api/auth/register.ts
- [ ] T013 [US1] Create RegisterForm component in components/auth/RegisterForm.tsx
- [ ] T014 [US1] Integrate RegisterForm with /register route in pages/register.tsx

### Verification
- [ ] T015 [US1] Run AC tests (must pass 100%)
- [ ] T016 [US1] Test registration flow end-to-end with quickstart scenario
- [ ] T017 [US1] Verify story works independently (no other stories required)

Task ID Format: T### (sequential numbering)
Story Label Format: [US#] where # is story number (US1, US2, US3...)
Parallel Marker: [P] for parallelizable tasks

Step 3.3.3: Repeat for All User Stories

Generate phases for:
- Phase 4: User Story P2
- Phase 5: User Story P3
- ...

Each phase:
- Independent test criteria
- Tests before implementation
- Story-specific tasks only
- Verification step

Step 3.4: Final Phase - Polish

Purpose: Cross-cutting concerns, documentation, cleanup

Examples:

## Phase N: Polish & Cross-Cutting Concerns

- [ ] T### [P] Update API documentation
- [ ] T### [P] Run full test suite
- [ ] T### [P] Perform security audit
- [ ] T### Run linter and fix issues
- [ ] T### Build and verify production bundle
- [ ] T### Update changelog

Phase 4: Mark Parallelization (Article VIII)

Criteria for [P] Marker

Task is parallelizable if:
1. Different files: No file conflicts with other parallel tasks
2. No dependencies: Doesn't depend on incomplete tasks
3. Independent: Can run without coordination

Example:

✓ [P] - [ ] T008 [P] [US1] Write test in tests/auth/register.test.ts
✓ [P] - [ ] T009 [P] [US1] Write test in tests/auth/login.test.ts
          (Different files, no dependencies)

✗ NO [P] - [ ] T010 [US1] Enhance User model
✗ NO [P] - [ ] T011 [US1] Create AuthService using User model
          (T011 depends on T010, must be sequential)

Phase 5: Validate Task Completeness

Step 5.1: Check User Story Coverage

For EACH user story, verify:
- ✓ Has ≥2 tests (one per AC minimum)
- ✓ All components identified in plan.md have tasks
- ✓ Has verification task
- ✓ Has independent test criteria

Step 5.2: Check Acceptance Criteria Coverage

For EACH AC (from plan.md), verify:
- ✓ Has corresponding test task
- ✓ Test task comes before implementation tasks
- ✓ AC is verifiable in verification task

Example:

AC-P1-001: User can register with valid credentials
→ T008: Write test for AC-P1-001
→ T010-T014: Implementation
→ T015: Verify AC-P1-001 passes

Step 5.3: Check Dependencies

Verify:
- Phase 1 (Setup) has no dependencies
- Phase 2 (Foundational) depends only on Phase 1
- Each User Story phase depends only on Foundational
- Final Phase depends on all User Story phases

Create dependency graph:

Phase 1 (Setup)
    ↓
Phase 2 (Foundational)
    ↓
Phase 3 (US P1) ←┐
Phase 4 (US P2) ←┼→ Independent (can be done in any order)
Phase 5 (US P3) ←┘
    ↓
Phase 6 (Polish)

Phase 5: Quality Gate Enforcement (Article V)

Constitutional Mandate: Template-Driven Quality requires automatic validation before implementation.

Step 5.1: Invoke /audit Command Automatically

After tasks.md is successfully created, automatically trigger the quality gate.

DO NOT ask user to run /audit manually - this is automatic enforcement.

Instruct Claude:

"Now that tasks.md is complete, run the quality gate validation to verify cross-artifact consistency:

/audit $FEATURE_ID

This command will:
1. Validate Article IV compliance (spec → plan → tasks sequence)
2. Verify Article VII compliance (user-story-centric organization)
3. Check Article III compliance (≥2 ACs per user story)
4. Detect constitution violations (CRITICAL priority)
5. Identify missing requirement coverage
6. Find ambiguities and underspecification

If audit finds CRITICAL issues:
- Implementation is BLOCKED until issues resolved
- Report violations to user
- Provide remediation guidance

If audit passes all checks:
- Report 'Ready for implementation'
- User can proceed with /implement plan.md

The audit report will be saved as: YYYYMMDD-HHMM-audit-$FEATURE_ID.md"

Step 5.2: Handle Audit Results

On CRITICAL failures:

⚠ Quality Gate FAILED - Implementation BLOCKED

Critical Issues Found:
- [List of CRITICAL findings from audit]

Next Actions:
1. Fix CRITICAL issues in spec.md, plan.md, or tasks.md
2. Re-run /tasks to regenerate tasks.md
3. Audit will re-validate automatically

Implementation cannot proceed until audit passes.

On successful audit:

✓ Quality Gate PASSED - Ready for Implementation

All validation checks passed:
- Constitution compliance: ✓
- Requirements coverage: 100%
- User story organization: ✓
- Acceptance criteria: ≥2 per story ✓

Next Step: Run /implement plan.md to begin implementation

Step 5.3: Record Audit Invocation

Log in tasks.md that audit was run:

## Quality Gate

**Status**: Audit ran automatically on task generation
**Report**: YYYYMMDD-HHMM-audit-$FEATURE_ID.md
**Result**: [PASS/FAIL]
**Date**: [YYYY-MM-DD HH:MM]

Phase 6: Generate tasks.md

Step 6.1: Write Using Template

Use @.claude/templates/tasks.md structure:

---
feature: <number>-<name>
created: <YYYY-MM-DD>
plan: specs/<number>-<name>/plan.md
status: Ready for Implementation
total_tasks: <count>
---

Include:
1. Summary: Total tasks, story breakdown
2. Dependencies: Graph showing story order
3. Parallel Opportunities: Count of [P] tasks per phase
4. All Phases: Setup → Foundational → User Stories → Polish
5. Verification Checklist: How to mark each task complete

Save: specs/$FEATURE/tasks.md

Step 6.2: Report Completion

Output:

✓ Task breakdown created: specs/<number>-<name>/tasks.md

Task Summary:
- Total tasks: 45
- Phase 1 (Setup): 4 tasks
- Phase 2 (Foundational): 3 tasks
- Phase 3 (US P1): 10 tasks (2 tests, 5 impl, 3 verify)
- Phase 4 (US P2): 12 tasks (3 tests, 6 impl, 3 verify)
- Phase 5 (US P3): 8 tasks (2 tests, 4 impl, 2 verify)
- Phase 6 (Polish): 8 tasks

Parallel Opportunities:
- Setup: 3 of 4 tasks can run in parallel
- User Story P1: 2 test tasks can run in parallel
- User Story P2: 3 test tasks can run in parallel

Acceptance Criteria Coverage:
- Total ACs: 8
- Tests mapped: 8 (100% coverage)
- Each AC has ≥1 test task

Story Independence:
- ✓ Each story has independent test criteria
- ✓ Stories can be implemented in priority order (P1 → P2 → P3)
- ✓ Each story is demonstrable standalone

Constitutional Compliance:
- ✓ Article III: Tests before implementation (TDD)
- ✓ Article VII: Tasks organized by user story (not layer)
- ✓ Article VIII: Parallel tasks marked [P]

**Automatic Quality Gate**:
Running /audit command now for validation...

[Audit results will appear here]

If audit passes: Next Step: Run /implement plan.md
If audit fails: Fix CRITICAL issues first, then re-run /tasks

Anti-Patterns to Avoid

DO NOT:
- Organize by layer ("All models", "All services", "All UI")
- Create tasks without [US#] story labels
- Skip test tasks (Article III violation)
- Mix multiple stories in one phase
- Create tasks that span stories (violates independence)
- Forget to mark parallelizable tasks with [P]
- Create < 2 tests per user story (Article III violation)

DO:
- Organize by user story (Phase per story)
- Label tasks with [US#] for traceability
- Tests before implementation (TDD)
- Independent test criteria per story
- Mark parallel tasks with [P]
- Map every AC to ≥1 test task
- Verify 100% AC coverage


Example Task Breakdown

Input: Plan with 2 user stories (P1: Register, P2: Login)

Output: tasks.md with 6 phases

## Phase 1: Setup
- [ ] T001 Create project structure
- [ ] T002 [P] Install dependencies
- [ ] T003 [P] Configure environment

## Phase 2: Foundational
- [ ] T004 Create users table schema
- [ ] T005 Set up Supabase client

## Phase 3: User Story P1 - Registration
Independent Test: Can register and login

### Tests
- [ ] T006 [P] [US1] Test AC-P1-001 (valid registration)
- [ ] T007 [P] [US1] Test AC-P1-002 (weak password rejection)

### Implementation
- [ ] T008 [US1] Enhance User model with password_hash
- [ ] T009 [US1] Create AuthService.register()
- [ ] T010 [US1] Implement POST /api/auth/register
- [ ] T011 [US1] Create RegisterForm component

### Verification
- [ ] T012 [US1] Run all US1 tests (must pass)
- [ ] T013 [US1] Test US1 independently

## Phase 4: User Story P2 - Login
Independent Test: Can login with registered credentials

### Tests
- [ ] T014 [P] [US2] Test AC-P2-001 (valid login)
- [ ] T015 [P] [US2] Test AC-P2-002 (invalid credentials)

### Implementation
- [ ] T016 [US2] Create AuthService.login()
- [ ] T017 [US2] Implement POST /api/auth/login
- [ ] T018 [US2] Create LoginForm component

### Verification
- [ ] T019 [US2] Run all US2 tests (must pass)
- [ ] T020 [US2] Test US2 independently

## Phase 5: Polish
- [ ] T021 [P] Update API docs
- [ ] T022 [P] Run full test suite
- [ ] T023 Build production bundle

Result: 23 tasks, organized by story, tests-first, parallelization marked.


Skill Version: 1.0.0
Last Updated: 2025-10-19

常见问题

5 问
答案由本站依据条目字段整理
Task Generation怎么安装?

没有现成安装命令:按安装说明或仓库 README,把 SKILL.md 放进客户端的 skills 目录(一般一个技能一个文件夹)。

Task Generation支持哪些客户端?

资料没有标注宿主客户端,但只要客户端支持 Skills(Claude、Codex、Cursor 等),一般都能加载。

Task Generation权限高吗,安全吗?

权限级别为未标注权限。安装前先看它会读取或写入哪些内容。

Task Generation收费吗?

本站不代收费用,也没有标注具体价格。是否收费取决于技能本身和所用的模型或客户端,正式使用前按作者说明确认。

Task Generation用什么许可证?

许可证标注为 未说明(许可证不明确)。商用或二次分发前请到仓库确认条款原文。

热门专题

按场景挑技能
全部专题 →

技能内容以作者仓库为准;分类、权限级别与许可证状态的中文说明为中文整理,最近核验 未标注。