/create-tasks

name: create-tasks
description: >
  Creates Jira tasks from meeting notes, specs, or feature descriptions.
  Supports both iOS (Swift/SwiftUI) and Backend (Node.js/TypeScript) platforms.
  Use this skill whenever a user pastes meeting notes, a spec, a feature request, or any description of work to be planned.
  Triggers on: "create tasks", "break this into tickets", "plan this feature", "create Jira tickets", "turn this into tasks",
  or when a user pastes meeting notes or a feature spec and asks what to do with it. Always use this skill for task
  planning — even if the user doesn't say "Jira" or "tickets" explicitly.

> **Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase search for flag/font files), or ask if they cannot be inferred. This plugin ships no per-project config.

Create Tasks from Meeting Notes / Specs

Take meeting notes, specs, or a feature description as input. Detect the platform, explore the codebase, plan the implementation, and create Jira tickets.

Usage

/create-tasks <description or paste meeting notes>

• `$ARGUMENTS` — Feature description, meeting notes, specs, or any context about work to be planned

---

Platform Detection

Detect the platform automatically from the current repository:

| Signal | Platform | |--------|----------| | `Package.swift`, `*.xcodeproj`, `Tuist/`, `*.swift` files | **iOS** | | `package.json`, `tsconfig.json`, `src/api/`, `serverless.yml` | **Backend** |

If ambiguous (e.g., meeting notes mention both platforms), ask the user which platform to create tasks for — or create tasks for both if explicitly requested.

---

Jira Configuration (Shared)

• **Project:** <JIRA_KEY>
• **Issue type:** Task
• **Story points field:** `customfield_10034`
• **Allowed story point values:** 1, 2, 3 only
• **Board:** https://<jira-host>/jira/software/c/projects/<JIRA_KEY>/boards/<jira-board-id>/backlog
• **Epic:** Link tasks to an epic via `"parent": "<EPIC-KEY>"` in `additional_fields`. Ask the user which epic to use if not specified.
• **Assignee:** Ask the user who to assign tasks to before creating tickets. Use email or display name for the `assignee` field.
• **Sprint:** Default to the current active sprint. Fetch via `mcp__mcp-atlassian__jira_get_sprints_from_board` (board ID `<jira-board-id>`, state `active`). Set via `"customfield_10020": <sprint_id>` in `additional_fields`. If no active sprint or the user specifies a different one, ask for input.
• **Next sprint (for feature flag cleanup tickets):** Fetch via `mcp__mcp-atlassian__jira_get_sprints_from_board` (board ID `<jira-board-id>`, state `future`) and take the first result. If no future sprint exists yet, ask the user whether to create the cleanup ticket in the backlog (omit `customfield_10020`) or wait.

---

Platform-Specific Configuration

iOS

• **Labels:** Apply all relevant labels per task:
• **Team:** `frontend`
• **Module:** e.g., `explore`, `feed`, `plan-tab`
• **Report:** exactly one of `report-feature`, `report-improvement-fix`, `report-tech-improvement`, `report-analytics-fix`
• **Story Point Scale:**

| Points | Scope | Examples | |--------|-------|----------| | **1** | Trivial / mechanical change, < 1 hour | Rename a file/struct, add a field to a model, update a CodingKeys enum, delete dead code | | **2** | Moderate change, 1–3 hours | Update a query + response models, create a simple view, wire a new case into an existing switch | | **3** | Significant change, 3–6 hours | Create a new UI component from Figma, build a new repository layer end-to-end, refactor a view model with new data flow |

Backend

• **Labels:** `["backend"]`
• **Story Point Scale:**

| Points | Time estimate | Scope | |--------|--------------|-------| | **1** | ~1–4 hours | Small, focused change — add a field to a Mongoose model, update a GraphQL type, minor refactor, add a DataLoader | | **2** | ~5–8 hours | Moderate — new service method + tests, new repository query, wiring a new GraphQL resolver with validation and permissions | | **3** | ~9–16 hours | Significant — new domain module end-to-end, complex data pipeline, new Lambda function, major refactor across multiple layers | **Hard rule (both platforms):** If a task would exceed 3 points, split it. No task should be larger than 3 story points.

**Trivial task rule (both platforms):** If a task is purely mechanical and small enough to be part of another task (e.g., adding a feature flag, adding a constant, updating an env variable), fold it into the most relevant adjacent task. No standalone tickets for these.

**Feature flag cleanup rule (both platforms):** Whenever any task in the plan introduces a new feature flag (A/B test, experiment, gradual rollout, kill switch), pair it with a mandatory cleanup ticket scheduled in the **next sprint**. See [Feature Flag Cleanup](#feature-flag-cleanup-both-platforms) below for the full rule. Folding the flag *creation* into an adjacent task (trivial task rule above) does not exempt you from creating the *cleanup* ticket.

---

Workflow

Phase 1: Understand the Request

1. Parse `$ARGUMENTS` to extract:

• What is being built or changed
• Any GraphQL queries/mutations or API contracts provided
• UI/UX requirements or Figma references (iOS)
• Which modules/domains are affected
• Any explicit non-goals or out-of-scope items

2. **Extract only tasks for the detected platform.** Ignore:

• Tasks for the other platform (unless explicitly requested)
• Process or organizational discussions
• Non-engineering items

3. If the scope is ambiguous, note open questions and ask before proceeding.

Phase 2: Explore the Codebase

4. Launch up to **3 parallel explore agents** to understand the current i