Task Decomposition

Break complex tasks into executable, dependency-aware steps.

Security Scan

This instruction-only skill is internally consistent with its stated purpose (breaking tasks into actionable steps) and does not request extra permissions, installs, or network access.

Purpose & Capability

The skill's name, description, and runtime instructions align: it describes and implements task decomposition only. Minor provenance inconsistency: SKILL.md and _meta.json claim a 'RedHat Dev' author/owner while the registry metadata lists a different owner slug/ID (axodus-task-decomposition / kn74114...). This is a metadata integrity issue but does not affect the skill's behavior.

Instruction Scope

SKILL.md contains clear, bounded instructions for decomposing tasks into steps, acceptance criteria, and open questions. It does not instruct the agent to read system files, access environment variables, call external endpoints, or exfiltrate data. It only references an optional 'repo_context' input which must be provided by the user; the skill does not autonomously collect it.

Install Mechanism

No install specification or code files are provided (instruction-only). Nothing is written to disk or downloaded during install, so install-side risk is minimal.

Credentials

The skill requests no environment variables, credentials, or config paths. There are no declared secrets required and the instructions do not access undeclared environment data.

Persistence & Privilege

The skill is not marked 'always: true' and uses normal model invocation (default). It does not request persistent system privileges or modifications to other skills' configurations.

Assessment

This skill appears coherent and minimal: it only contains instructions for turning a user problem into ordered, testable steps. Before installing/use: 1) Verify provenance if the publisher matters to you (metadata shows conflicting owner/author entries). 2) Never paste secrets, credentials, or full repository dumps into the optional 'repo_context' — provide only the minimal paths or descriptions needed. 3) Test the skill on a non-sensitive example task to confirm outputs meet your expectations. 4) If you plan to allow autonomous agent runs, monitor first runs and revoke access if the skill asks for unexpected data or actions.

SKILL: task-decomposition

Purpose

Break a raw task into an ordered, executable, dependency-aware step list with acceptance criteria and explicit open questions.

When to Use

• The request implies multiple files or multiple subsystems.
• The request is vague, inconsistent, or underspecified.
• The request mixes design + implementation + validation.

Inputs

• raw_task_description (required, string): the user request as-is.
• constraints (optional, string[]): non-negotiables (security, time, language, tooling).
• repo_context (optional, string): relevant paths, conventions, or prior decisions.
• risk_level_hint (optional, enum: low|medium|high): if the user already signaled risk.

Steps

1. Restate the task in 1–3 sentences without adding assumptions.
2. Extract deliverables (expected behavior, files to touch, commands to run).
3. Identify unknowns that block execution and convert them into concrete questions.
4. Split work into atomic steps; each step must include:
   • action + target
   • a single primary outcome
   • acceptance criteria (done_when)
5. Order steps by dependency and mark safe parallelization explicitly.
6. Tag each step with:
   • risk (low|medium|high)
   • validation (what will be checked)
7. If unknowns are material, stop and ask only the minimum questions; otherwise proceed with stated assumptions.

Validation

• No step depends on hidden context.
• Every step has measurable acceptance criteria.
• Dependencies are explicit (no “and then it works”).
• No step contains vague verbs (“improve”, “optimize”, “make better”) without a measurable target.

Output

Structured plan (example schema):

summary: "<what will be delivered>"
open_questions:
  - "<question>"
assumptions:
  - "<assumption (only if low risk)>"
steps:
  - id: 1
    action: "<verb phrase>"
    targets: ["<path/system>"]
    risk: low
    validation: "<check to run>"
    done_when: "<observable condition>"

Safety Rules

• Do not invent requirements, APIs, or file paths.
• If a step can be destructive, require explicit confirmation in the plan.
• Prefer the smallest viable step sequence; avoid gold-plating.

Example

Input:

• raw_task_description: “Add a CLI command to export reports.”
• constraints: ["No breaking changes", "Must include tests"]

Output (excerpt):

summary: "Add `report export` command and tests"
open_questions:
  - "What output formats are required (json/csv/pdf)?"
steps:
  - id: 1
    action: "Locate existing CLI entrypoints and command router"
    targets: ["src/cli/*"]
    risk: low
    validation: "CLI help shows existing commands unchanged"
    done_when: "Command dispatch mechanism is identified"