# Clickup Tasks

> Create ClickUp tasks with brand-prefixed titles, per-application subtasks, and always assign them to the current user. Use when creating ClickUp tasks, features, tickets, or tracking work for Dia Flower / Luvi Flowers after implementing changes.

- Skill: `xmuhameed/clickup-tasks` (Agent Skill)
- Install (CLI): `npx skillmds@latest add xmuhameed/clickup-tasks`
- Raw SKILL.md: https://api.skillmd.com/api/skills/xmuhameed/clickup-tasks/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: xmuhameed (https://skillmd.com/u/xmuhameed)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/xmuhameed/clickup-tasks

---


# ClickUp Tasks

Rules for every ClickUp task created via the ClickUp MCP (`user-clickup`).

## Always assign to me

**Always assign the created tasks to me.**

- Pass `assignees: ["me"]` on `clickup_create_task` for parent and subtasks.
- If create/update rejects `"me"`, resolve with `clickup_resolve_assignees` (`["me"]`) and use the returned numeric user ID.
- Apply assignees to **every** parent task and **every** subtask.

## Naming and structure

**Always create tasks same way:**

```
[Brand name] - task title
```

Then create **subtasks with the changes for each application**, plus **testing** and **production deploy** subtasks.

### Parent task

| Field | Rule |
|-------|------|
| Name | `[Brand name] - <feature/task title>` |
| Scope | One parent per brand touched by the work |
| Assignees | Always me |

Brands:

- `Dia Flower`
- `Luvi Flowers`

Examples:

- `[Dia Flower] - Recently Viewed Products`
- `[Luvi Flowers] - Recently Viewed Products`

### Subtasks (one per application)

Create a subtask under the brand parent for **each application** that changed.

Name format:

```
<Layer> (<repo/app>) — <short change summary>
```

**Always use the brand’s own app/repo name** in the `(repo/app)` part — even when the codebase is shared with another brand. Never put another brand’s repo name under a different brand’s parent.

| Brand | Application | Typical layer label |
|-------|-------------|---------------------|
| Dia Flower | `diaflower_backend` | Backend |
| Dia Flower | `diaflower_frontend` | Frontend |
| Dia Flower | `diaflower_admin_frontend` | Admin |
| Luvi Flowers | `luviflower_backend` | Backend |
| Luvi Flowers | `luviflower_frontend` | Frontend |
| Luvi Flowers | `luviflower_admin_frontend` | Admin |

Examples under `[Dia Flower] - Recently Viewed Products`:

- `Backend (diaflower_backend) — get-recently-viewed-products endpoint`
- `Frontend (diaflower_frontend) — recently viewed UI on product page`

Examples under `[Luvi Flowers] - Recently Viewed Products`:

- `Backend (luviflower_backend) — recently viewed products API`
- `Frontend (luviflower_frontend) — recently viewed UI on product page`

Wrong (do not do this):

- ❌ `Backend (diaflower_backend) — shared recently viewed products API` under `[Luvi Flowers]`

If only one app changed for a brand, still create one subtask for that app (do not put all details only on the parent).

### Required process subtasks

Under **every** brand parent, also create these two subtasks (after the application subtasks):

1. `Testing — verify <feature/task title>`
2. `Deploy to production — ship <feature/task title>`

Assignees: always me. Put test/acceptance notes and deploy checklist details in each subtask description when useful.

## Workflow

1. Resolve target list (`clickup_get_list` / hierarchy) if unknown.
2. For each brand involved, create the parent: `[Brand name] - task title`, `assignees: ["me"]`.
3. For each changed application under that brand, create a subtask with `parent` = parent task id, `assignees: ["me"]`, using **that brand’s** app/repo name.
4. Create the Testing and Deploy to production subtasks under the same parent, `assignees: ["me"]`.
5. Put implementation details in the markdown description (what changed, acceptance criteria).
6. Return parent + subtask URLs to the user.

## Shared backend / shared project

When Dia Flower and Luvi Flowers share the same backend (or another shared project):

- Still create **both** brand parents when both brands ship the feature.
- Add a backend subtask under each brand parent that needs it.
- Name each backend subtask with **that brand’s** app name (`diaflower_backend` under Dia Flower, `luviflower_backend` under Luvi Flowers).
- Shared implementation notes belong in the **description**, not in the subtask title’s repo/app name.