loader/.cursor/skills/new-task/SKILL.md

name, description, category, tags, disable-model-invocation

name	description	category	tags	disable-model-invocation
new-task	Interactive skill for adding new functionality to an existing codebase. Guides the user through describing the feature, assessing complexity, optionally running research, analyzing the codebase for insertion points, validating assumptions with the user, and producing a task spec with Jira ticket. Supports a loop — the user can add multiple tasks in one session. Trigger phrases: - "new task", "add feature", "new functionality" - "I want to add", "new component", "extend"	build	task feature interactive planning jira	true

New Task (Interactive Feature Planning)

Guide the user through defining new functionality for an existing codebase. Produces one or more task specifications with Jira tickets, optionally running deep research for complex features.

Core Principles

• User-driven: every task starts with the user's description; never invent requirements
• Right-size research: only invoke the research skill when the change is big enough to warrant it
• Validate before committing: surface all assumptions and uncertainties to the user before writing the task file
• Save immediately: write task files to disk as soon as they are ready; never accumulate unsaved work
• Ask, don't assume: when scope, insertion point, or approach is unclear, STOP and ask the user

Context Resolution

Fixed paths:

• TASKS_DIR: _docs/02_tasks/
• PLANS_DIR: _docs/02_task_plans/
• DOCUMENT_DIR: _docs/02_document/
• DEPENDENCIES_TABLE: _docs/02_tasks/_dependencies_table.md

Create TASKS_DIR and PLANS_DIR if they don't exist.

If TASKS_DIR already contains task files, scan them to determine the next numeric prefix for temporary file naming.

Workflow

The skill runs as a loop. Each iteration produces one task. After each task the user chooses to add another or finish.

---

Step 1: Gather Feature Description

Role: Product analyst Goal: Get a clear, detailed description of the new functionality from the user.

Ask the user:

══════════════════════════════════════
 NEW TASK: Describe the functionality
══════════════════════════════════════
 Please describe in detail the new functionality you want to add:
 - What should it do?
 - Who is it for?
 - Any specific requirements or constraints?
══════════════════════════════════════

BLOCKING: Do NOT proceed until the user provides a description.

Record the description verbatim for use in subsequent steps.

---

Step 2: Analyze Complexity

Role: Technical analyst Goal: Determine whether deep research is needed.

Read the user's description and the existing codebase documentation from DOCUMENT_DIR (architecture.md, components/, system-flows.md).

Assess the change along these dimensions:

• Scope: how many components/files are affected?
• Novelty: does it involve libraries, protocols, or patterns not already in the codebase?
• Risk: could it break existing functionality or require architectural changes?

Classification:

Category	Criteria	Action
Needs research	New libraries/frameworks, unfamiliar protocols, significant architectural change, multiple unknowns	Proceed to Step 3 (Research)
Skip research	Extends existing functionality, uses patterns already in codebase, straightforward new component with known tech	Skip to Step 4 (Codebase Analysis)

Present the assessment to the user:

══════════════════════════════════════
 COMPLEXITY ASSESSMENT
══════════════════════════════════════
 Scope:   [low / medium / high]
 Novelty: [low / medium / high]
 Risk:    [low / medium / high]
══════════════════════════════════════
 Recommendation: [Research needed / Skip research]
 Reason: [one-line justification]
══════════════════════════════════════

BLOCKING: Ask the user to confirm or override the recommendation before proceeding.

---

Step 3: Research (conditional)

Role: Researcher Goal: Investigate unknowns before task specification.

This step only runs if Step 2 determined research is needed.

1. Create a problem description file at PLANS_DIR/<task_slug>/problem.md summarizing the feature request and the specific unknowns to investigate
2. Invoke .cursor/skills/research/SKILL.md in standalone mode:
   • INPUT_FILE: PLANS_DIR/<task_slug>/problem.md
   • BASE_DIR: PLANS_DIR/<task_slug>/
3. After research completes, read the solution draft from PLANS_DIR/<task_slug>/01_solution/solution_draft01.md
4. Extract the key findings relevant to the task specification

The <task_slug> is a short kebab-case name derived from the feature description (e.g., auth-provider-integration, real-time-notifications).

---

Step 4: Codebase Analysis

Role: Software architect Goal: Determine where and how to insert the new functionality.

1. Read the codebase documentation from DOCUMENT_DIR:
   • architecture.md — overall structure
   • components/ — component specs
   • system-flows.md — data flows (if exists)
   • data_model.md — data model (if exists)
2. If research was performed (Step 3), incorporate findings
3. Analyze and determine:
   • Which existing components are affected
   • Where new code should be inserted (which layers, modules, files)
   • What interfaces need to change
   • What new interfaces or models are needed
   • How data flows through the change
4. If the change is complex enough, read the actual source files (not just docs) to verify insertion points

Present the analysis:

══════════════════════════════════════
 CODEBASE ANALYSIS
══════════════════════════════════════
 Affected components: [list]
 Insertion points:    [list of modules/layers]
 Interface changes:   [list or "None"]
 New interfaces:      [list or "None"]
 Data flow impact:    [summary]
══════════════════════════════════════

---

Step 5: Validate Assumptions

Role: Quality gate Goal: Surface every uncertainty and get user confirmation.

Review all decisions and assumptions made in Steps 2–4. For each uncertainty:

1. State the assumption clearly
2. Propose a solution or approach
3. List alternatives if they exist

Present using the Choose format for each decision that has meaningful alternatives:

══════════════════════════════════════
 ASSUMPTION VALIDATION
══════════════════════════════════════
 1. [Assumption]: [proposed approach]
    Alternative: [other option, if any]
 2. [Assumption]: [proposed approach]
    Alternative: [other option, if any]
 ...
══════════════════════════════════════
 Please confirm or correct these assumptions.
══════════════════════════════════════

BLOCKING: Do NOT proceed until the user confirms or corrects all assumptions.

---

Step 6: Create Task

Role: Technical writer Goal: Produce the task specification file.

1. Determine the next numeric prefix by scanning TASKS_DIR for existing files
2. Write the task file using .cursor/skills/decompose/templates/task.md:
   • Fill all fields from the gathered information
   • Set Complexity based on the assessment from Step 2
   • Set Dependencies by cross-referencing existing tasks in TASKS_DIR
   • Set Jira and Epic to pending (filled in Step 7)
3. Save as TASKS_DIR/[##]_[short_name].md

Self-verification:

• Problem section clearly describes the user need
• Acceptance criteria are testable (Gherkin format)
• Scope boundaries are explicit
• Complexity points match the assessment
• Dependencies reference existing task Jira IDs where applicable
• No implementation details leaked into the spec

---

Step 7: Work Item Ticket

Role: Project coordinator Goal: Create a work item ticket and link it to the task file.

1. Create a ticket via the configured work item tracker (Jira MCP or Azure DevOps MCP — see autopilot/protocols.md for detection):
   • Summary: the task's Name field
   • Description: the task's Problem and Acceptance Criteria sections
   • Story points: the task's Complexity value
   • Link to the appropriate epic (ask user if unclear which epic)
2. Write the ticket ID and Epic ID back into the task file header:
   • Update Task field: [TICKET-ID]_[short_name]
   • Update Jira field: [TICKET-ID]
   • Update Epic field: [EPIC-ID]
3. Rename the file from [##]_[short_name].md to [TICKET-ID]_[short_name].md

If the work item tracker is not authenticated or unavailable (tracker: local):

• Keep the numeric prefix
• Set Jira to pending
• Set Epic to pending
• The task is still valid and can be implemented; tracker sync happens later

---

Step 8: Loop Gate

Ask the user:

══════════════════════════════════════
 Task created: [JIRA-ID or ##] — [task name]
══════════════════════════════════════
 A) Add another task
 B) Done — finish and update dependencies
══════════════════════════════════════

• If A → loop back to Step 1
• If B → proceed to Finalize

---

Finalize

After the user chooses Done:

1. Update (or create) TASKS_DIR/_dependencies_table.md — add all newly created tasks to the dependencies table
2. Present a summary of all tasks created in this session:

══════════════════════════════════════
 NEW TASK SUMMARY
══════════════════════════════════════
 Tasks created: N
 Total complexity: M points
 ─────────────────────────────────────
 [JIRA-ID] [name] ([complexity] pts)
 [JIRA-ID] [name] ([complexity] pts)
 ...
══════════════════════════════════════

Escalation Rules

Situation	Action
User description is vague or incomplete	ASK for more detail — do not guess
Unclear which epic to link to	ASK user for the epic
Research skill hits a blocker	Follow research skill's own escalation rules
Codebase analysis reveals conflicting architectures	ASK user which pattern to follow
Complexity exceeds 5 points	WARN user and suggest splitting into multiple tasks
Jira MCP unavailable	WARN, continue with local-only task files

Trigger Conditions

When the user wants to:

• Add new functionality to an existing codebase
• Plan a new feature or component
• Create task specifications for upcoming work

Keywords: "new task", "add feature", "new functionality", "extend", "I want to add"

Differentiation:

• User wants to decompose an existing plan into tasks → use /decompose
• User wants to research a topic without creating tasks → use /research
• User wants to refactor existing code → use /refactor
• User wants to define and plan a new feature → use this skill