skeeper: Skill for Claude Code

Create Tasks

Decompose requirements into detailed, actionable task files with codebase-informed enrichment.

Required Inputs

• Feature name identifying the .compozy/tasks/<name>/ directory.
• At minimum, _prd.md or _techspec.md in that directory.

Workflow

1. Load type registry.

   • Read .compozy/config.toml.
   • If it contains [tasks].types, use that list as the allowed type values.
   • Otherwise use the built-in defaults: frontend, backend, docs, test, infra, refactor, chore, bugfix.

2. Load context.

   • Read _prd.md and _techspec.md from .compozy/tasks/<name>/.
   • Read existing ADRs from .compozy/tasks/<name>/adrs/ to understand the decision context behind requirements and design choices.
   • If _techspec.md is missing:
     • Warn the user that tasks will be higher-level without TechSpec implementation guidance.
     • Derive tasks from PRD functional requirements and user stories instead of TechSpec implementation sections.
     • During enrichment, rely more heavily on codebase exploration to fill ## Implementation Details, ### Relevant Files, and ### Dependent Files.
     • Mark <requirements> with PRD-derived behavioral requirements instead of TechSpec-derived technical requirements.
     • Explicitly call out missing implementation detail gaps in the task body instead of inventing specifics.
   • If both _prd.md and _techspec.md are missing, stop and ask the user to create at least one first.
   • Spawn an Agent tool call to explore the codebase for files to create or modify, test patterns, and coding conventions.

3. Break down into tasks.

   • Decompose implementation sections from the TechSpec into granular, independently implementable tasks.
   • Each task MUST be independently implementable when all of its declared dependencies are met. No task may require undeclared work from another task. If two tasks share a tight coupling, either merge them or extract the shared piece into a dependency task.
   • No circular dependencies. If task A depends on task B, task B must NOT depend on task A (directly or transitively).
   • Each task must have: title, type, complexity, and dependencies.
   • Assign complexity using these criteria:
     • low: Single file change, no new interfaces, no concurrency, straightforward logic.
     • medium: 2-4 files, may introduce a new interface or struct, limited integration points.
     • high: 5+ files, new subsystem or significant refactor, multiple integration points, concurrency involved.
     • critical: Cross-cutting change affecting many packages, high risk of regression, requires coordination with other tasks.
   • When a task directly implements or is constrained by a specific ADR, include the ADR reference in the task's "Related ADRs" section under Implementation Details.
   • Embed test requirements in every task. Never create separate tasks dedicated solely to testing.
   • Follow the structure defined in references/task-template.md.
   • Refer to references/task-context-schema.md for metadata field definitions.