mcpField
C
complete-task

complete-task

github.com/driangleProductivity7636 installsUpdated 4w ago
Repository

About complete-task

complete-task is a skill for completing tasks with the taskmd CLI, for workflows that require checking task contents and acceptance criteria before changing status. It reviews subtasks, optional worklogs, and workflow mode, while emphasizing that writes must run in the current working directory.

Key features

  1. 01Read task details and acceptance criteria
  2. 02Verify and check off completed subtasks
  3. 03Append a completion worklog when configured
  4. 04Update status according to workflow mode
  5. 05Keep writes in the current working directory

Use cases

  1. 01Complete a taskmd task after verifying its scope
  2. 02Pause completion when criteria remain unmet
  3. 03Set a task to in-review in PR review mode

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/driangle/taskmd --skill complete-task

After installing, type/complete-taskin Claude Code to confirm it loaded.

Details

From the project README

Complete Task

Mark a task as completed using the taskmd CLI.

Instructions

The user's query is in $ARGUMENTS (a task ID like 077). If $ARGUMENTS is empty or does not contain a task ID, infer the task from conversation context (e.g., the task currently being worked on). If the task cannot be determined, ask the user which task to complete.

⚠️ Worktree safety — never cd before a taskmd write. Run every taskmd set … command (including --verify and the in-review branch) from your current working directory. Do not prepend cd /path/to/repo or cd into a "primary working directory" first: inside a git worktree that path is a different checkout on a different branch. Unlike the Edit/Write tools (which the harness's worktree isolation guards), a shell taskmd write is not isolated — after such a cd it will silently flip the status in the wrong checkout. taskmd resolves its task directory from the current directory, so running in place is what keeps the write in this worktree. (Outside a git repo, running in place is already correct.)

The CLI backs this up: in a multi-worktree repo, taskmd set refuses to write when the task exists only in a sibling worktree (task <id> exists only in worktree <path> …; run taskmd there). If you hit that error, you are in the wrong checkout — do not work around it by cd-ing; run the command from the worktree that owns the task.

  1. Read the task file to understand the full task scope:

    • Run taskmd get <ID> to get the task contents
    • Identify all subtask checklists (- [ ] / - [x] items) in the task body
    • Identify any acceptance criteria section
  2. Verify subtasks and acceptance criteria are met:

    • Review each subtask checklist item — confirm the work has been done
    • Review each acceptance criterion — confirm it is satisfied
    • Check off (- [x]) any items that are complete but not yet checked off by editing the task file
    • If any items are genuinely incomplete, report them to the user and ask how to proceed — do NOT mark the task as completed
  3. Add a final worklog entry (if worklogs are enabled):

    • Check .taskmd.yaml for worklogs: true -- worklogs are opt-in, so skip this step unless the key is explicitly set to true
    • Otherwise, find the worklog file at tasks/<group>/.worklogs/<ID>.md (or tasks/.worklogs/<ID>.md)
    • If a worklog exists, append a timestamped completion summary
  4. Check the workflow mode in .taskmd.yaml (run these taskmd set commands from the current working directory — do not cd elsewhere first, see the ⚠️ note above):

    • If workflow: pr-review is set, use taskmd set $ARGUMENTS --status in-review instead of completed (note: in pr-review mode, tasks are completed by merging the PR, not by setting status directly)
    • Otherwise (default solo mode), run taskmd set $ARGUMENTS --status completed --verify
    • The --verify flag runs any verification checks defined in the task before applying the status change
    • If verification fails, report the failures to the user
  5. Confirm the status change to the user

Comments

Markdown supported