mirror of
https://github.com/azaion/detections.git
synced 2026-04-23 00:46:32 +00:00
Add detailed file index and enhance skill documentation for autopilot, decompose, deploy, plan, and research skills. Introduce tests-only mode in decompose skill, clarify required files for deploy and plan skills, and improve prerequisite checks across skills for better user guidance and workflow efficiency.
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 `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: Jira Ticket
|
||||
|
||||
**Role**: Project coordinator
|
||||
**Goal**: Create a Jira ticket and link it to the task file.
|
||||
|
||||
1. Create a Jira ticket for the task:
|
||||
- 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 Jira ticket ID and Epic ID back into the task file header:
|
||||
- Update **Task** field: `[JIRA-ID]_[short_name]`
|
||||
- Update **Jira** field: `[JIRA-ID]`
|
||||
- Update **Epic** field: `[EPIC-ID]`
|
||||
3. Rename the file from `[##]_[short_name].md` to `[JIRA-ID]_[short_name].md`
|
||||
|
||||
If Jira MCP is not authenticated or unavailable:
|
||||
- Keep the numeric prefix
|
||||
- Set **Jira** to `pending`
|
||||
- Set **Epic** to `pending`
|
||||
- The task is still valid and can be implemented; Jira 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,113 @@
|
||||
# Task Specification Template
|
||||
|
||||
Create a focused behavioral specification that describes **what** the system should do, not **how** it should be built.
|
||||
Save as `TASKS_DIR/[##]_[short_name].md` initially, then rename to `TASKS_DIR/[JIRA-ID]_[short_name].md` after Jira ticket creation.
|
||||
|
||||
---
|
||||
|
||||
```markdown
|
||||
# [Feature Name]
|
||||
|
||||
**Task**: [JIRA-ID]_[short_name]
|
||||
**Name**: [short human name]
|
||||
**Description**: [one-line description of what this task delivers]
|
||||
**Complexity**: [1|2|3|5] points
|
||||
**Dependencies**: [AZ-43_shared_models, AZ-44_db_migrations] or "None"
|
||||
**Component**: [component name for context]
|
||||
**Jira**: [TASK-ID]
|
||||
**Epic**: [EPIC-ID]
|
||||
|
||||
## Problem
|
||||
|
||||
Clear, concise statement of the problem users are facing.
|
||||
|
||||
## Outcome
|
||||
|
||||
- Measurable or observable goal 1
|
||||
- Measurable or observable goal 2
|
||||
- ...
|
||||
|
||||
## Scope
|
||||
|
||||
### Included
|
||||
- What's in scope for this task
|
||||
|
||||
### Excluded
|
||||
- Explicitly what's NOT in scope
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
**AC-1: [Title]**
|
||||
Given [precondition]
|
||||
When [action]
|
||||
Then [expected result]
|
||||
|
||||
**AC-2: [Title]**
|
||||
Given [precondition]
|
||||
When [action]
|
||||
Then [expected result]
|
||||
|
||||
## Non-Functional Requirements
|
||||
|
||||
**Performance**
|
||||
- [requirement if relevant]
|
||||
|
||||
**Compatibility**
|
||||
- [requirement if relevant]
|
||||
|
||||
**Reliability**
|
||||
- [requirement if relevant]
|
||||
|
||||
## Unit Tests
|
||||
|
||||
| AC Ref | What to Test | Required Outcome |
|
||||
|--------|-------------|-----------------|
|
||||
| AC-1 | [test subject] | [expected result] |
|
||||
|
||||
## Integration Tests
|
||||
|
||||
| AC Ref | Initial Data/Conditions | What to Test | Expected Behavior | NFR References |
|
||||
|--------|------------------------|-------------|-------------------|----------------|
|
||||
| AC-1 | [setup] | [test subject] | [expected behavior] | [NFR if any] |
|
||||
|
||||
## Constraints
|
||||
|
||||
- [Architectural pattern constraint if critical]
|
||||
- [Technical limitation]
|
||||
- [Integration requirement]
|
||||
|
||||
## Risks & Mitigation
|
||||
|
||||
**Risk 1: [Title]**
|
||||
- *Risk*: [Description]
|
||||
- *Mitigation*: [Approach]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Complexity Points Guide
|
||||
|
||||
- 1 point: Trivial, self-contained, no dependencies
|
||||
- 2 points: Non-trivial, low complexity, minimal coordination
|
||||
- 3 points: Multi-step, moderate complexity, potential alignment needed
|
||||
- 5 points: Difficult, interconnected logic, medium-high risk
|
||||
- 8 points: Too complex — split into smaller tasks
|
||||
|
||||
## Output Guidelines
|
||||
|
||||
**DO:**
|
||||
- Focus on behavior and user experience
|
||||
- Use clear, simple language
|
||||
- Keep acceptance criteria testable (Gherkin format)
|
||||
- Include realistic scope boundaries
|
||||
- Write from the user's perspective
|
||||
- Include complexity estimation
|
||||
- Reference dependencies by Jira ID (e.g., AZ-43_shared_models)
|
||||
|
||||
**DON'T:**
|
||||
- Include implementation details (file paths, classes, methods)
|
||||
- Prescribe technical solutions or libraries
|
||||
- Add architectural diagrams or code examples
|
||||
- Specify exact API endpoints or data structures
|
||||
- Include step-by-step implementation instructions
|
||||
- Add "how to build" guidance
|
||||
Reference in New Issue
Block a user