task-decomp

Decompose architecture and UI specifications into implementation tasks with testable acceptance criteria.

133|9|Updated Mar 26, 2026
One-click install
npx skills add https://github.com/lync-cyber/CataForge --skill task-decomp
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: task-decomp
Source: https://github.com/lync-cyber/CataForge/tree/main/.cataforge/skills/task-decomp
Command: npx skills add https://github.com/lync-cyber/CataForge --skill task-decomp

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill breaks completed architecture work into clear, manageable tasks so teams can plan execution without guessing scope, effort, or dependencies.

Core Features & Use Cases

  • Feature-to-task decomposition: Converts ARCH modules, API contracts, and UI specs into task cards with single-purpose scope.
  • TDD-ready acceptance criteria: Defines Given-When-Then acceptance criteria that map directly to testable outcomes.
  • Sprint and dependency planning: Produces sprint groupings, dependency graphs, critical paths, and integration or E2E verification planning.
  • Use Case: After an architecture document is approved, use this Skill to generate implementation tasks, estimate complexity, and identify what must be built first.

Quick Start

Use the task-decomp skill to split this architecture document into task cards with acceptance criteria, dependencies, and sprint recommendations.

Frequently Asked Questions about task-decomp

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decompose architecture specifications into actionable implementation tasks?

Architecture decomposition converts structured ARCH modules, API contracts, and UI specs into single-purpose task cards with complexity ratings, deliverables, and sprint groupings. It requires completed architecture documents to generate testable task breakdowns.

How do I generate task cards with Given-When-Then acceptance criteria for sprint planning?

Sprint planning task cards are generated by mapping UI specs and API contracts to Given-When-Then acceptance criteria. This creates TDD-ready outcomes that map directly to testable results, ensuring each task has single-purpose scope and clear verification.

What is the best way to map dependency graphs and critical paths from an architecture document?

Dependency mapping analyzes approved architecture documents to produce dependency graphs, critical paths, and sprint groupings. It identifies execution order and integration test planning needs, ensuring teams know what must be built first before implementation begins.

Can I use architecture decomposition for E2E and integration test planning?

Architecture decomposition supports E2E and integration test planning by extracting testable acceptance criteria from API contracts and UI specs. It maps dependencies to verification planning, ensuring integration tests align with critical path execution.

Do I need structured ARCH modules before starting task decomposition?

Task decomposition requires structured ARCH modules, API contracts, and UI specs as input. Without completed architecture documents, it cannot produce accurate task cards, complexity ratings, dependency graphs, or sprint recommendations.

Why does task decomposition require architecture approval before generating task cards?

Task decomposition depends on approved architecture documents because it transforms finalized ARCH modules and API contracts into implementation tasks. Unapproved specs risk generating task cards with incorrect scope, missing dependencies, or invalid acceptance criteria.