mirror of
https://github.com/azaion/ui.git
synced 2026-04-22 22:06:35 +00:00
Update Dockerfile to use Bun for package management, remove package-lock.json, and adjust .gitignore to include it.
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -0,0 +1,302 @@
|
||||
---
|
||||
name: new-task
|
||||
description: |
|
||||
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"
|
||||
category: build
|
||||
tags: [task, feature, interactive, planning, jira]
|
||||
disable-model-invocation: 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
|
||||
@@ -0,0 +1,2 @@
|
||||
<!-- This skill uses the shared task template at .cursor/skills/decompose/templates/task.md -->
|
||||
<!-- See that file for the full template structure. -->
|
||||
Reference in New Issue
Block a user