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

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.

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.