본문으로 건너뛰기
cccskills
무료GitHub에 공개

speckit.tasks

Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(3)

  • SKILL.md3.7 KB
  • templates/tasks-metadata-template.md421 B
  • templates/tasks-module-template.md691 B

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Outline

  1. Locate Feature:

    • Extract the feature name from the branch name or user input like ###-feature-name, e.g., 001-feature-name.
    • Find the most likely feature in the specs directory, i.e., ./specs/[###-feature-name]. The feature id and name must be exact match.
  2. Pre-check:

    • Make sure the feature directory exists, i.e., ./specs/[###-feature-name], otherwise ERROR "Feature directory not found: ./specs/[###-feature-name]".
    • Make sure the spec file exists, i.e., ./specs/[###-feature-name]/spec.md, otherwise ERROR "Spec file not found: ./specs/[###-feature-name]/spec.md".
    • Make sure the plan file exists, i.e., ./specs/[###-feature-name]/plan.md, otherwise ERROR "Plan file not found: ./specs/[###-feature-name]/plan.md".
  3. Execute task generation workflow:

    • Load spec.md and extract modules and components with their priorities (P1, P2, P3, etc.)
    • Load plan.md and extract tech stack, libraries, project structure
    • Generate tasks organized by Module (see Task Generation Rules below)
  4. Generate metadata:

    • Create a new tasks directory in the feature directory, i.e., ./specs/[###-feature-name]/tasks/.
    • Copy the metadata template templates/tasks-metadata-template.md to the tasks directory as specs/[###-feature-name]/tasks/metadata.md
    • Feature name should match spec.md.
    • GitHub Feature Issue is the issue link of the feature issue on the GitHub.
  5. Generate modules:

    • For each module, copy the module template templates/tasks-module-template.md to the module file as specs/[###-feature-name]/tasks/module_i.md.
    • The <i> is the module number, starting from 1.
    • The module ID and name must match the definition in the spec.md.
    • Each module includes: module goal, GitHub information (assignee, label, milestone, project), implementation tasks.
    • Each task includes: task title, description, details
  6. Report: Generate a summary of the tasks:

    • Total task count
    • Task count per module

Context for task generation: $ARGUMENTS

Each task should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.

Task Generation Rules

CRITICAL: Tasks MUST be organized by module and follow the template templates/tasks-metadata-template.md and templates/tasks-module-template.md.

Tests are OPTIONAL: Only generate test tasks if explicitly requested in the feature specification or if user requests TDD approach.

Metadata Rules

Metadata is saved in tasks/metadata.md. Metadata must follow the template including:

  • Feature name
  • Input
  • Prerequisites
  • GitHub Feature Issue
  • List of modules

Module Rules

Modules are saved in tasks/module_i.md (one file per module). Module must follow the template including:

  • Module name
  • Module goal
  • GitHub settings (assignee, label, milestone, project)
  • Details of each task

Task Rules

Each module file includes multiple tasks. Task must follow the template including:

  • [<FeatureID>-<TaskID>]
  • Task Name
  • Description
  • Details

The <FeatureID> is the three-digit feature number at the beginning of the feature directory name, i.e., 001-feature-name, e.g., F001, F002, F003...

The <TaskID> must restart for each module. For example:

  • Module 1: T101, T102, T103...
  • Module 2: T201, T202, T203... ...

The number of tasks is not fixed. You can add more tasks as needed but must match the spec.md.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

codegraph

무료

Analyze indexed codebases via graph database (neug) and vector index (zvec). Covers call graphs, dependencies, dead code, hotspots, module coupling, architecture reports, semantic search, impact analysis, bug root cause from GitHub issues, class diagrams (UML), and PR review (risk scoring, conflict detection, auto-merge candidates, labeling). Also covers creating, inspecting, and repairing a CodeScope index. Use for: code structure, who calls what, why something changed, similar functions, module boundaries, bug tracing, class relationships, PR risk/conflicts, or any question benefiting from a code knowledge graph. Applies when a `.codegraph` index exists in the workspace, or when the user wants to create one.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

alibaba/neug1712026년 10월 22일 업데이트

Submit a new issue to the project.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

alibaba/neug1712026년 10월 22일 업데이트

create-pr

무료

Submit a new Pull Request to the project.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

alibaba/neug1712026년 10월 22일 업데이트

Analyze new commits and generate related test cases.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

alibaba/neug1712026년 10월 22일 업데이트

Vulnerability audit and dataflow analysis built on the neug CPG engine. file_audit (default, recommended): first builds a function-level summary graph (tier1) over the entire project, then incrementally builds detailed CPGs (tier2) on demand for chosen functions; both tiers coexist in a single neug database (unified schema, cross-layer refines edges; C/Java/Python/Rust). All capabilities are exposed as CLI tool subcommands (audit/overview/build/query/methods/paths), so an agent can drive the audit step by step via shell; the audit subcommand can also run the built-in LLM loop. The same tooling also supports a dataflow analysis mode (Workflow C): no vulnerability hunting, only variable-level dataflow tracing for functions of interest, producing dataflow_analysis.json. repo_audit: multi-round LLM/Cypher audit over a full-repo CPG. Use when the user asks to audit a codebase/project for vulnerabilities, scan a project with CPG/neug, run repo_audit/file_audit, find source-to-sink taint paths, or analyze dataflow inside a function. Supports C, Java, Python, and Rust.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

alibaba/neug1712026년 10월 22일 업데이트

Execute the implementation planning workflow using the plan template to generate design artifacts.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

alibaba/neug1712026년 10월 22일 업데이트

alibaba의 스킬 모두 보기

이 스킬의 문제 신고