Skill Factory - Task Decomposition Engine

intent

skill factory takes a complex user task and breaks it down into 3-6 independent, executable sub-skills with no cross-dependencies. use this when an orchestrator needs to modularize a task before execution, or when you receive a structured input containing a user task, recommended role, and critic insight. the skill does decomposition only, it doesn't schedule, execute, or fix errors in the resulting modules.

inputs

required structured input (must include all fields):

• user_task (string): the complex task to decompose
• context.previous_output.recommended_role (string): role classification from prior analyzer step (e.g. "career-advisor", "data-processor")
• context.previous_output.task_insight (string): summary of task scope and requirements
• context.critic_insight.content (string): optional feedback or recommendations from a critic stage
• context.critic_insight.confidence (float 0-1): weight to apply to critic feedback
• meta.source (string): expected value "orchestrator"
• meta.retry_count (int): counter for retry loops

external connections / setup: none required. this skill is stateless and has no API dependencies.

edge cases to handle:

• missing recommended_role field → trigger need_retry, do not guess
• missing task_insight field → trigger need_retry, do not guess
• critic_insight.confidence below 0.5 → deprioritize critic suggestions but still consider them
• empty or null user_task → return error with clear reason
• retry_count exceeds 2 → return error, escalate to orchestrator
• network timeout (if any logging/telemetry is used) → log and continue; decomposition is local

procedure

1. parse and validate input

   • input: raw request containing user_task and context
   • output: validated JSON object or error response
   • action: check that user_task, recommended_role, and task_insight are present and non-empty. if any are missing, return need_retry status with missing_fields array. if meta.retry_count > 2, return error with reason "max retries exceeded".

2. assess task decomposability

   • input: validated user_task string
   • output: boolean flag (decomposable=true/false) plus reasoning
   • action: determine if the task is complex enough to warrant decomposition. simple tasks (e.g. "fetch user name from database") should return error with reason "task too simple, decomposition not needed". tasks that cannot be split (e.g. "sign this contract") return error with reason "task is atomic, cannot decompose into independent sub-skills".

3. select decomposition strategy based on recommended_role

   • input: recommended_role string and task_insight
   • output: decomposition strategy name (e.g. "data-pipeline", "functional-modules", "sequential-stages")
   • action: map the role to a known decomposition pattern. for "career-advisor" use "sequential-stages" (collect data, analyze, generate output). for "data-processor" use "data-pipeline" (extract, transform, load). for "content-creator" use "functional-modules" (research, draft, edit, publish). if role is unknown, use "functional-modules" as default.

4. generate 3-6 independent sub-skills

   • input: decomposition strategy, task_insight, critic_insight
   • output: array of skill objects, each with name, description, input_example, output_example
   • action: generate sub-skills that align with the selected strategy. each sub-skill must have a single responsibility, clear input/output contracts, and no data dependencies on other sub-skills. if critic_insight.confidence > 0.7, incorporate critic suggestions into naming or descriptions. aim for 3-6 skills; fewer than 3 suggests the task should not be decomposed, more than 6 suggests over-granularity.

5. validate decomposition structure

   • input: array of generated sub-skills
   • output: validation report (valid=true/false, issues array)
   • action: check for duplicates (same name or overlapping descriptions), check for implicit dependencies (skill A's output_example matches skill B's input_example), check for coverage (union of sub-skill responsibilities covers original user_task). if any issue found, return error with reason and list of specific issues.

6. format and output result

   • input: validated sub-skills array, strategy used, validation report
   • output: JSON response with status, skills array, reasoning, next_action
   • action: if validation passed, return status "success" with skills array and a brief reasoning statement explaining the decomposition rationale. if validation failed, return status "error" with specific reasons. set next_action to "done" (decomposition is complete, orchestrator handles scheduling).

decision points

• if required fields missing (recommended_role or task_insight): return status "need_retry" with missing_fields array. do not proceed to decomposition.

• if retry_count exceeds 2: return status "error" with reason "max retries exceeded, escalate to orchestrator". stop processing.

• if task_insight indicates task is atomic (cannot split): return status "error" with reason "task is atomic and cannot be decomposed into independent sub-skills".

• if task_insight is too vague (e.g. "user wants something"): return status "need_retry" with reason "task_insight is insufficient; provide concrete task requirements from user".

• if critic_insight.confidence is high (>0.75): incorporate critic suggestions into sub-skill names, descriptions, or decomposition strategy. adjust strategy if critic proposes a different breakdown pattern.

• if critic_insight.confidence is low (<0.5): acknowledge critic feedback in reasoning field but do not let it override the recommended_role-based strategy. proceed with role-aligned decomposition.

• if decomposition produces <3 sub-skills: return status "error" with reason "task does not warrant decomposition; fewer than 3 independent sub-skills can be identified".

• if decomposition produces >6 sub-skills: return status "error" with reason "decomposition is too granular; merge related sub-skills to stay within 3-6 limit".

• if validation detects circular dependencies (skill A depends on skill B, skill B depends on skill A): return status "error" with reason "circular dependency detected in sub-skills; re-decompose".

• if validation detects coverage gap (some aspect of user_task not covered): return status "error" with reason "decomposition does not cover all aspects of user_task; re-decompose".

output contract

on success (status: success):

{
  "stage": "factory",
  "status": "success",
  "skills": [
    {
      "name": "kebab-case-skill-name",
      "description": "one-sentence description of sub-skill function",
      "input_example": "{ JSON object showing expected input shape }",
      "output_example": "{ JSON object showing expected output shape }"
    },
    ...
  ],
  "reasoning": "brief explanation of decomposition strategy and how it aligns with recommended_role and task_insight",
  "next_action": "done"
}

on need_retry (status: need_retry):

{
  "stage": "factory",
  "status": "need_retry",
  "missing_fields": ["field_name", "field_name"],
  "reason": "specific explanation of what is missing or insufficient"
}

on error (status: error):

{
  "stage": "factory",
  "status": "error",
  "reason": "specific reason: task too simple / task is atomic / decomposition too granular / circular dependency / coverage gap / max retries exceeded / other",
  "issues": ["issue 1", "issue 2"]
}

all responses must include stage: "factory" and a status. all timestamps are ISO 8601 if included. no HTML or markdown in output unless specified in sub-skill output_example.

outcome signal

you know the skill worked when:

• the orchestrator receives a success response with a skills array containing 3-6 independent sub-skills
• each sub-skill has a clear, distinct name (kebab-case), non-overlapping description, and well-formed input/output examples
• the reasoning field explains how the decomposition connects to the original recommended_role (e.g. "career-advisor role suggests sequential data collection, analysis, and report generation")
• a human reviewer can map each sub-skill back to the user_task and confirm no skill is redundant or dependent on another
• the orchestrator can take the skills array and schedule execution without hitting circular dependencies or missing required inputs
• if validation fails, the error response is specific enough that the orchestrator (or a human) can understand exactly why decomposition failed and what to fix upstream