Menu
Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.
Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/LynnColeArt/ShovelerDB --skill spec-kitty-tasks-outlineLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Basé sur la classification professionnelle SOC
Affichage de SKILL.md
| name | spec-kitty.tasks-outline |
| description | Create a work package manifest |
| user-invocable | true |
Version: 3.2.0
Create wps.yaml — the structured work package manifest that defines WP metadata,
dependencies, and file ownership. tasks.md is generated automatically from this
manifest by finalize-tasks.
⚠️ DO NOT write
tasks.md. The system generates it fromwps.yaml. Writingtasks.mdmanually will have it overwritten byfinalize-tasks.
You are creating the blueprint for implementation. The quality of work packages determines:
QUALITY OVER SPEED: Take your time to understand the full scope deeply, break work into clear pieces, and write detailed guidance.
IMPORTANT: This step works in the repository root checkout. NO worktrees created.
Do NOT cd anywhere. Stay in the repository root checkout.
In repos with multiple missions, always pass --mission <handle> to every spec-kitty command. The can be the mission's (ULID), (first 8 chars of the ULID), or . The resolver disambiguates by and returns a structured error on ambiguity — there is no silent fallback.
<handle>mission_idmid8mission_slugmission_idMISSION_AMBIGUOUS_SELECTORThe content of the user's message that invoked this skill (everything after the skill invocation token, e.g. after /spec-kitty.<command> or $spec-kitty.<command>) is the User Input referenced elsewhere in these instructions.
You MUST consider this user input before proceeding (if not empty).
Before proceeding, resolve canonical command context:
spec-kitty agent context resolve --action tasks_outline --mission <mission-slug> --json
Treat that JSON as canonical for feature slug, feature directory, and target branch. Do not probe git branch state manually inside the prompt.
Run the exact check_prerequisites command returned by the resolver. Capture
feature_dir plus available_docs. All paths must be absolute.
CRITICAL: The command returns JSON with feature_dir as an ABSOLUTE path. YOU MUST USE THIS PATH for ALL subsequent file operations.
Read from feature_dir (only those present):
Scale your effort to the feature: simple UI tweaks deserve lighter coverage, multi-system releases require deeper decomposition.
Create complete list of subtasks with IDs T001, T002, etc.:
[P] means safe to parallelize per file/concern).Group subtasks into work packages (IDs WP01, WP02, ...):
TARGET SIZE: 3-7 subtasks per WP (200-500 line prompts) MAXIMUM: 10 subtasks per WP (700 line prompts) If more than 10 subtasks needed: Create additional WPs, don't pack them in
GROUPING PRINCIPLES:
requirement_refs list referencing IDs from spec.md (FR/NFR/C)wps.yamlWrite to feature_dir/wps.yaml following the schema below. This is the single
authoritative source for WP metadata in the planning pipeline.
Do NOT write tasks.md — it is generated automatically by finalize-tasks from wps.yaml.
Schema:
work_packages:
- id: WP01
title: "Foundation Setup"
dependencies: [] # [] = explicitly no deps (authoritative)
owned_files:
- "src/myapp/core/**"
requirement_refs:
- FR-001
- FR-002
subtasks:
- T001
- T002
- T003
prompt_file: "tasks/WP01-foundation-setup.md"
- id: WP02
title: "API Layer"
dependencies:
- WP01
owned_files:
- "src/myapp/api/**"
requirement_refs:
- FR-003
subtasks:
- T004
- T005
prompt_file: "tasks/WP02-api-layer.md"
- id: WP03
title: "Frontend Integration"
dependencies:
- WP02
owned_files:
- "src/myapp/frontend/**"
requirement_refs:
- FR-004
- NFR-001
subtasks:
- T006
- T007
- T008
prompt_file: "tasks/WP03-frontend-integration.md"
Field semantics:
id: Work package identifier (WP01, WP02, …)title: Short human-readable namedependencies: List of WP IDs this WP depends on. [] = explicitly no deps (authoritative); if the key is absent, tasks-packages may fill it based on analysis.owned_files: Glob patterns for files this WP touches — no two WPs may overlap.requirement_refs: Requirement IDs from spec.md (FR/NFR/C) addressed by this WP.subtasks: Ordered list of subtask IDs included in this WP.prompt_file: Relative path (from feature_dir) to the WP prompt file — set by tasks-packages in the next step.IMPORTANT: Leave prompt_file as null or omit it — tasks-packages fills this field.
Analyze the spec and plan for dependency relationships. Express them in wps.yaml
dependencies fields.
Do NOT include a Dependency Graph section in prose — it is not needed and cannot
be parsed by finalize-tasks.
Rules:
dependencies: []dependencies: [WP01]DO NOT generate WP prompt files in this step. That happens in the next step.
After completing this step:
feature_dir/wps.yaml exists with all work package definitionsid, title, dependencies, owned_files, requirement_refs, subtasksprompt_file fields are absent or null (filled by tasks-packages)Next step: spec-kitty next --agent <name> will advance to work package generation.
Target: 3-7 subtasks per WP → 200-500 line prompts Maximum: 10 subtasks → ~700 line prompts No arbitrary limit on WP count — let complexity dictate
Split if ANY of these are true:
Merge if ALL of these are true:
Context for work-package planning: (refer to the User Input section above)