azaion/gps-denied-onboard
1
0
Fork 0
mirror of https://github.com/azaion/gps-denied-onboard.git synced 2026-04-22 09:26:38 +00:00
Code Issues Packages Projects Releases Wiki Activity

Sync .cursor from detections

Browse Source
This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-04-12 05:05:11 +03:00
parent 531a1301d5
commit fa17185f82
49 changed files with 2119 additions and 1284 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.cursor/skills/new-task/SKILL.md
+40 -21
View File
@@ -4,19 +4,19 @@ 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.
validating assumptions with the user, and producing a task spec with work item 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]
tags: [task, feature, interactive, planning, work-items]
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.
Guide the user through defining new functionality for an existing codebase. Produces one or more task specifications with work item tickets, optionally running deep research for complex features.
## Core Principles
@@ -31,13 +31,14 @@ Guide the user through defining new functionality for an existing codebase. Prod
Fixed paths:
- TASKS_DIR: `_docs/02_tasks/`
- TASKS_TODO: `_docs/02_tasks/todo/`
- 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.
Create TASKS_DIR, TASKS_TODO, 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.
If TASKS_DIR already contains task files (scan `todo/`, `backlog/`, and `done/`), use them to determine the next numeric prefix for temporary file naming.
## Workflow
@@ -118,7 +119,7 @@ This step only runs if Step 2 determined research is needed.
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`
3. After research completes, read the latest solution draft from `PLANS_DIR/<task_slug>/01_solution/` (highest-numbered `solution_draft*.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`).
@@ -128,7 +129,7 @@ The `<task_slug>` is a short kebab-case name derived from the feature descriptio
### Step 4: Codebase Analysis
**Role**: Software architect
**Goal**: Determine where and how to insert the new functionality.
**Goal**: Determine where and how to insert the new functionality, and whether existing tests cover the new requirements.
1. Read the codebase documentation from DOCUMENT_DIR:
- `architecture.md` — overall structure
@@ -143,6 +144,10 @@ The `<task_slug>` is a short kebab-case name derived from the feature descriptio
- 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
5. **Test coverage gap analysis**: Read existing test files that cover the affected components. For each acceptance criterion from Step 1, determine whether an existing test already validates it. Classify each AC as:
- **Covered**: an existing test directly validates this behavior
- **Partially covered**: an existing test exercises the code path but doesn't assert the new requirement
- **Not covered**: no existing test validates this behavior — a new test is required
Present the analysis:
@@ -155,9 +160,22 @@ Present the analysis:
Interface changes: [list or "None"]
New interfaces: [list or "None"]
Data flow impact: [summary]
─────────────────────────────────────
TEST COVERAGE GAP ANALYSIS
─────────────────────────────────────
AC-1: [Covered / Partially covered / Not covered]
[existing test name or "needs new test"]
AC-2: [Covered / Partially covered / Not covered]
[existing test name or "needs new test"]
...
─────────────────────────────────────
New tests needed: [count]
Existing tests to update: [count or "None"]
══════════════════════════════════════
```
When gaps are found, the task spec (Step 6) MUST include the missing tests in the Scope (Included) section and the Unit/Blackbox Tests tables. Tests are not optional — if an AC is not covered by an existing test, the task must deliver a test for it.
---
### Step 5: Validate Assumptions
@@ -195,20 +213,21 @@ Present using the Choose format for each decision that has meaningful alternativ
**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`:
1. Determine the next numeric prefix by scanning all TASKS_DIR subfolders (`todo/`, `backlog/`, `done/`) for existing files
2. If research was performed (Step 3), the research artifacts live in `PLANS_DIR/<task_slug>/` — reference them from the task spec where relevant
3. 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`
- Set **Dependencies** by cross-referencing existing tasks in TASKS_DIR subfolders
- Set **Tracker** and **Epic** to `pending` (filled in Step 7)
3. Save as `TASKS_TODO/[##]_[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
- [ ] Dependencies reference existing task tracker IDs where applicable
- [ ] No implementation details leaked into the spec
---
@@ -218,20 +237,20 @@ Present using the Choose format for each decision that has meaningful alternativ
**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):
1. Create a ticket via the configured work item tracker (see `autopilot/protocols.md` for tracker 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 **Tracker** 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 **Tracker** to `pending`
- Set **Epic** to `pending`
- The task is still valid and can be implemented; tracker sync happens later
@@ -243,7 +262,7 @@ Ask the user:
```
══════════════════════════════════════
Task created: [JIRA-ID or ##] — [task name]
Task created: [TRACKER-ID or ##] — [task name]
══════════════════════════════════════
A) Add another task
B) Done — finish and update dependencies
@@ -259,7 +278,7 @@ Ask the user:
After the user chooses **Done**:
1. Update (or create) `TASKS_DIR/_dependencies_table.md` — add all newly created tasks to the dependencies table
1. Update (or create) `DEPENDENCIES_TABLE` — add all newly created tasks to the dependencies table
2. Present a summary of all tasks created in this session:
```
@@ -269,8 +288,8 @@ After the user chooses **Done**:
Tasks created: N
Total complexity: M points
─────────────────────────────────────
[JIRA-ID] [name] ([complexity] pts)
[JIRA-ID] [name] ([complexity] pts)
[TRACKER-ID] [name] ([complexity] pts)
[TRACKER-ID] [name] ([complexity] pts)
...
══════════════════════════════════════
```
@@ -284,7 +303,7 @@ After the user chooses **Done**:
| 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 |
| Work item tracker MCP unavailable | **WARN**, continue with local-only task files |
## Trigger Conditions