create-tasks

Files (1)

• SKILL.md

SKILL.md (first lines)

> **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 implementation:
   **iOS agents:**
   - Find existing files, models, views, view models, repositories related to the feature
   - Find existing patterns and components that can be reused
   - Understand the data pipeline (query → response model → mapper → repository → use case → view model → view)
   **Backend agents:**
   - **Agent 1 — Domain model:** Find `*.model.ts` and `*.entities.ts` in the relevant domain; check for existing migrations
   - **Agent 2 — API layer:** Find the relevant `src/api/*-api.ts`; identify existing `typeDefs`, resolver signatures, Joi validations, and shield permissions
   - **Agent 3 — Service/repository layer:** Find `*.service.ts` and `*.repository.ts` in the relevant domain; identify methods, patterns, and event bus usage
5. Read the critical files identified to verify details before planning.
6. Specifically look for:
   - **Existing patterns** for similar features — always follow them, never invent new conventions
   - **(iOS)** Reusable UI components, existing design system tokens, AppStrings keys
   - **(Backend)** DataLoaders in `src/dataLoaders/`, feature flag infrastructure in `src/domain/config/`, event bus usage, Lambda functions in `src/functions/`
### Phase 3: Plan the Implementation
 
7. Break the work into **discrete, independently deliverable tasks**. Each task must:
   - Have a single clear concern
   - Be completable in one PR or less
   - Follow natural dependency order
8. **Dependency ordering:**
   - **iOS:** Data layer → domain → presentation (models → repository → view model → view)
   - **Backend:** Schema/model + migrations → repository → service → API resolver → event listeners → cleanup
9. **Per-task detail to include:**
   - Exact file paths to create or modify
   - Existing patterns or utilities to reuse
   - Whether unit tests need to be added or updated
   - **(Backend)** Whether a DataLoader needs to be created or extended
10. Estimate each task using the platform-specific story point scale.
11. **Detect feature flag creation.** Scan the plan for any task that introduces a new feature flag (A/B test, experiment, gradual rollout, kill switch). For each new flag, generate a paired cleanup task per [Feature Flag Cleanup](#feature-flag-cleanup-both-platforms) below. The cleanup task targets the **next sprint**, not the current one.

From carloshpdoc/ios-workflow-claude, Apache-2.0.

More from carloshpdoc/ios-workflow-claude