Skip to main content

ClickUp Automations

When a ClickUp list is connected to a GitHub repository, Alakai watches for tasks that move into the "Alakai Ready" status. Moving a task there is what triggers Alakai — not creating it. This lets us write and refine a task freely, and only hand it off once it's actually ready.

Two custom fields on the task control what Alakai does:

  • Platform — which application/repository the task targets (only needed when one list feeds several repos).
  • Alakai stage — whether Alakai should generate a prompt PR for review (Prompting) or implement the task directly (Implementation).

The trigger: "Alakai Ready"

Alakai only acts when a task transitions into the Alakai Ready status. Any other status change is ignored. So the workflow is:

  1. Create the task and fill in a clear title and description.
  2. Set the Platform field (if the list serves more than one repo) and the Alakai stage field.
  3. Move the task to Alakai Ready.

If we later want Alakai to run again — for example after editing the description — we move the task out of Alakai Ready and back into it.

Choosing the target repository — the Platform field

Some ClickUp lists map to a single repository; others are shared across several. When a list is shared, the Platform dropdown tells Alakai which repository a task belongs to.

  • List → one repo: the Platform field is not required. Tasks always route to that repo.
  • List → several repos: set the Platform field (e.g. Backend, iOS, Web). Alakai routes the task to the repository mapped to that value.
  • Shared list, Platform left empty: Alakai falls back to the list's default repository if one is configured; otherwise it does nothing and the task is skipped.

The exact Platform options and which repo each one maps to are configured per list by our Alakai administrator.

Choosing what Alakai does — the Alakai stage field

The Alakai stage dropdown picks the mode:

Prompting (default)

If Alakai stage is set to Prompting — or left empty — Alakai runs the prompt-PR flow:

  1. It reads the task name and description.
  2. It generates prompt markdown and opens a pull request titled docs(prompts): clickup-<taskId> in the target repository.
  3. It comments on the task with the PR link and prompt file path.

We review the prompt PR, adjust it if needed, and merge it. Merging it triggers the implementation agent, which opens a second PR with the actual code changes — the same pipeline used for any docs(prompts): PR. See GitHub Automations.

Implementation

If Alakai stage is set to Implementation, Alakai skips the prompt PR entirely and implements the task directly from its description:

  1. It comments on the task to confirm implementation has started.
  2. It launches the implementation agent using the task description as the spec.
  3. When the agent finishes, the resulting PR link is posted back on the task.

For this mode the task description is the spec, so it must be filled in:

  • No description → Alakai will not run. It comments asking us to add a specification and move the task back to Alakai Ready.
  • Description too large → Alakai comments asking us to trim it, then move the task back to Alakai Ready.

Naming conventions

For the Prompting flow, Alakai names everything from the ClickUp task ID:

ArtifactPatternExample
PR titledocs(prompts): clickup-<taskId>docs(prompts): clickup-abc123
PR branchdocs-prompts/clickup-<taskId>docs-prompts/clickup-abc123
Prompt fileprompts/docs-prompts__clickup-<taskId>.mdprompts/docs-prompts__clickup-abc123.md

Tips for better results

The quality of the output depends directly on the task title and description:

  • Be specific in the title — "Add exponential backoff to outbound HTTP calls" beats "Fix retries".
  • Treat the description as a spec — include context, acceptance criteria, and constraints. This matters most for the Implementation stage, where the description is all the agent has.
  • For Prompting, edit before merging — if the generated prompt misses something, adjust the .md file on the PR before merging it.

How it compares to the GitHub Issues flow

Both flows produce the same docs(prompts): PRs (in Prompting mode) and feed the same downstream implementation pipeline. They differ only in the entry point:

GitHub IssuesClickUp Tasks
TriggerOpen an issueMove a task to Alakai Ready
Target repoThe issue's repoResolved from the list (and Platform field)
Comment posted toGitHub issueClickUp task
Direct implementationNoYes — via the Implementation stage

Setup

Connecting a ClickUp list to a repository — including the Platform options and the Alakai stage field — is a one-time setup done by our Alakai administrator. See the admin guide: ClickUp Integration. If a list isn't connected yet, ask them to set it up.