gps-denied-onboard/.cursor/skills/decompose/SKILL.md

name, description, disable-model-invocation

name	description	disable-model-invocation
decompose	Decompose planned components into atomic implementable tasks with bootstrap structure plan. 3-step workflow: bootstrap structure plan, task decomposition with inline Jira ticket creation, and cross-task verification. Supports full decomposition (_docs/ structure) and single component mode. Trigger phrases: - "decompose", "decompose features", "feature decomposition" - "task decomposition", "break down components" - "prepare for implementation"	true

Task Decomposition

Decompose planned components into atomic, implementable task specs with a bootstrap structure plan through a systematic workflow. All tasks are named with their Jira ticket ID prefix in a flat directory.

Core Principles

• Atomic tasks: each task does one thing; if it exceeds 5 complexity points, split it
• Behavioral specs, not implementation plans: describe what the system should do, not how to build it
• Flat structure: all tasks are Jira-ID-prefixed files in TASKS_DIR — no component subdirectories
• Save immediately: write artifacts to disk after each task; never accumulate unsaved work
• Jira inline: create Jira ticket immediately after writing each task file
• Ask, don't assume: when requirements are ambiguous, ask the user before proceeding
• Plan, don't code: this workflow produces documents and Jira tasks, never implementation code

Context Resolution

Determine the operating mode based on invocation before any other logic runs.

Default (no explicit input file provided):

• PLANS_DIR: _docs/02_plans/
• TASKS_DIR: _docs/02_tasks/
• Reads from: _docs/00_problem/, _docs/01_solution/, PLANS_DIR
• Runs Step 1 (bootstrap) + Step 2 (all components) + Step 3 (cross-verification)

Single component mode (provided file is within _docs/02_plans/ and inside a components/ subdirectory):

• PLANS_DIR: _docs/02_plans/
• TASKS_DIR: _docs/02_tasks/
• Derive component number and component name from the file path
• Ask user for the parent Epic ID
• Runs Step 2 (that component only, appending to existing task numbering)

Announce the detected mode and resolved paths to the user before proceeding.

Input Specification

Required Files

Default:

File	Purpose
_docs/00_problem/problem.md	Problem description and context
_docs/00_problem/restrictions.md	Constraints and limitations
_docs/00_problem/acceptance_criteria.md	Measurable acceptance criteria
_docs/01_solution/solution.md	Finalized solution
PLANS_DIR/architecture.md	Architecture from plan skill
PLANS_DIR/system-flows.md	System flows from plan skill
PLANS_DIR/components/[##]_[name]/description.md	Component specs from plan skill

Single component mode:

File	Purpose
The provided component description.md	Component spec to decompose
Corresponding tests.md in the same directory (if available)	Test specs for context

Prerequisite Checks (BLOCKING)

Default:

1. PLANS_DIR contains architecture.md and components/ — STOP if missing
2. Create TASKS_DIR if it does not exist
3. If TASKS_DIR already contains task files, ask user: resume from last checkpoint or start fresh?

Single component mode:

1. The provided component file exists and is non-empty — STOP if missing

Artifact Management

Directory Structure

TASKS_DIR/
├── [JIRA-ID]_initial_structure.md
├── [JIRA-ID]_[short_name].md
├── [JIRA-ID]_[short_name].md
├── ...
└── _dependencies_table.md

Naming convention: Each task file is initially saved with a temporary numeric prefix ([##]_[short_name].md). After creating the Jira ticket, rename the file to use the Jira ticket ID as prefix ([JIRA-ID]_[short_name].md). For example: 01_initial_structure.md → AZ-42_initial_structure.md.

Save Timing

Step	Save immediately after	Filename
Step 1	Bootstrap structure plan complete + Jira ticket created + file renamed	[JIRA-ID]_initial_structure.md
Step 2	Each task decomposed + Jira ticket created + file renamed	[JIRA-ID]_[short_name].md
Step 3	Cross-task verification complete	_dependencies_table.md

Resumability

If TASKS_DIR already contains task files:

1. List existing *_*.md files (excluding _dependencies_table.md) and count them
2. Resume numbering from the next number (for temporary numeric prefix before Jira rename)
3. Inform the user which tasks already exist and are being skipped

Progress Tracking

At the start of execution, create a TodoWrite with all applicable steps. Update status as each step/component completes.

Workflow

Step 1: Bootstrap Structure Plan (default mode only)

Role: Professional software architect Goal: Produce 01_initial_structure.md — the first task describing the project skeleton Constraints: This is a plan document, not code. The /implement skill executes it.

1. Read architecture.md, all component specs, and system-flows.md from PLANS_DIR
2. Read problem, solution, and restrictions from _docs/00_problem/ and _docs/01_solution/
3. Research best implementation patterns for the identified tech stack
4. Document the structure plan using templates/initial-structure-task.md

Self-verification:

• All components have corresponding folders in the layout
• All inter-component interfaces have DTOs defined
• CI/CD stages cover build, lint, test, security, deploy
• Environment strategy covers dev, staging, production
• Test structure includes unit and integration test locations

Save action: Write 01_initial_structure.md (temporary numeric name)

Jira action: Create a Jira ticket for this task under the "Bootstrap & Initial Structure" epic. Write the Jira ticket ID and Epic ID back into the task header.

Rename action: Rename the file from 01_initial_structure.md to [JIRA-ID]_initial_structure.md (e.g., AZ-42_initial_structure.md). Update the Task field inside the file to match the new filename.

BLOCKING: Present structure plan summary to user. Do NOT proceed until user confirms.

---

Step 2: Task Decomposition (all modes)

Role: Professional software architect Goal: Decompose each component into atomic, implementable task specs — numbered sequentially starting from 02 Constraints: Behavioral specs only — describe what, not how. No implementation code.

Numbering: Tasks are numbered sequentially across all components in dependency order. Start from 02 (01 is initial_structure). In single component mode, start from the next available number in TASKS_DIR.

Component ordering: Process components in dependency order — foundational components first (shared models, database), then components that depend on them.

For each component (or the single provided component):

1. Read the component's description.md and tests.md (if available)
2. Decompose into atomic tasks; create only 1 task if the component is simple or atomic
3. Split into multiple tasks only when it is necessary and would be easier to implement
4. Do not create tasks for other components — only tasks for the current component
5. Each task should be atomic, containing 0 APIs or a list of semantically connected APIs
6. Write each task spec using templates/task.md
7. Estimate complexity per task (1, 2, 3, 5 points); no task should exceed 5 points — split if it does
8. Note task dependencies (referencing Jira IDs of already-created dependency tasks, e.g., AZ-42_initial_structure)
9. Immediately after writing each task file: create a Jira ticket, link it to the component's epic, write the Jira ticket ID and Epic ID back into the task header, then rename the file from [##]_[short_name].md to [JIRA-ID]_[short_name].md.

Self-verification (per component):

• Every task is atomic (single concern)
• No task exceeds 5 complexity points
• Task dependencies reference correct Jira IDs
• Tasks cover all interfaces defined in the component spec
• No tasks duplicate work from other components
• Every task has a Jira ticket linked to the correct epic

Save action: Write each [##]_[short_name].md (temporary numeric name), create Jira ticket inline, then rename the file to [JIRA-ID]_[short_name].md. Update the Task field inside the file to match the new filename. Update Dependencies references in the file to use Jira IDs of the dependency tasks.

---

Step 3: Cross-Task Verification (default mode only)

Role: Professional software architect and analyst Goal: Verify task consistency and produce _dependencies_table.md Constraints: Review step — fix gaps found, do not add new tasks

1. Verify task dependencies across all tasks are consistent
2. Check no gaps: every interface in architecture.md has tasks covering it
3. Check no overlaps: tasks don't duplicate work across components
4. Check no circular dependencies in the task graph
5. Produce _dependencies_table.md using templates/dependencies-table.md

Self-verification:

• Every architecture interface is covered by at least one task
• No circular dependencies in the task graph
• Cross-component dependencies are explicitly noted in affected task specs
• _dependencies_table.md contains every task with correct dependencies

Save action: Write _dependencies_table.md

BLOCKING: Present dependency summary to user. Do NOT proceed until user confirms.

---

Common Mistakes

• Coding during decomposition: this workflow produces specs, never code
• Over-splitting: don't create many tasks if the component is simple — 1 task is fine
• Tasks exceeding 5 points: split them; no task should be too complex for a single implementer
• Cross-component tasks: each task belongs to exactly one component
• Skipping BLOCKING gates: never proceed past a BLOCKING marker without user confirmation
• Creating git branches: branch creation is an implementation concern, not a decomposition one
• Creating component subdirectories: all tasks go flat in TASKS_DIR
• Forgetting Jira: every task must have a Jira ticket created inline — do not defer to a separate step
• Forgetting to rename: after Jira ticket creation, always rename the file from numeric prefix to Jira ID prefix

Escalation Rules

Situation	Action
Ambiguous component boundaries	ASK user
Task complexity exceeds 5 points after splitting	ASK user
Missing component specs in PLANS_DIR	ASK user
Cross-component dependency conflict	ASK user
Jira epic not found for a component	ASK user for Epic ID
Task naming	PROCEED, confirm at next BLOCKING gate

Methodology Quick Reference

┌────────────────────────────────────────────────────────────────┐
│          Task Decomposition (3-Step Method)                     │
├────────────────────────────────────────────────────────────────┤
│ CONTEXT: Resolve mode (default / single component)             │
│ 1. Bootstrap Structure  → [JIRA-ID]_initial_structure.md       │
│    [BLOCKING: user confirms structure]                         │
│ 2. Task Decompose       → [JIRA-ID]_[short_name].md each      │
│ 3. Cross-Verification   → _dependencies_table.md              │
│    [BLOCKING: user confirms dependencies]                      │
├────────────────────────────────────────────────────────────────┤
│ Principles: Atomic tasks · Behavioral specs · Flat structure   │
│   Jira inline · Rename to Jira ID · Save now · Ask don't assume│
└────────────────────────────────────────────────────────────────┘