no-human-ai / file-a-task

File a task into no_human

Use the two MCP tools this plugin exposes — task_add and task_status — to
hand off work that should become a reviewed pull request, instead of making
the change yourself in this conversation.

When to use

• The work is substantial enough to deserve its own branch, its own tests,
  and independent review — not a one-line edit you can just make inline.

• You want no_human to plan, code, test, have the result reviewed by a second
  model, and open a pull request, while you keep doing something else.

• Do not use this for small edits you can make directly in the current
  conversation — that is strictly slower and adds no value.

Prerequisite: the local server must already be running

Both tools call the existing no_human HTTP API at http://127.0.0.1:8420.
The bridge does not retry or fall back if that address is unreachable —
it refuses to start at all (SystemExit, no auto-retry). Before using either
tool, make sure the server is running:

nh start

(The desktop app starts this for you automatically.) If a tool call fails
with a connection error, the fix is to start the server, not to retry the
call.

Tool: task_add

Creates a new no_human task via POST /api/tasks.

Parameters (all required strings):

You do not pass source — the bridge sets it to "mcp" on every call it
makes, server-side, before the request is sent.

Returns: compact JSON with the new task's id and the source the server
actually stored (first-class alongside "board"/"jira"), e.g.:

{"task_id":"task-abc123","source":"mcp"}

Tool: task_status

Fetches a task's current full state via GET /api/tasks/{id}.

Parameters (required string):

Resolution order: first tries the value as a task id (or id prefix); if that
404s, falls back to a client-side scan of GET /api/tasks for a matching
external_id, then re-fetches by the real id. If nothing matches either way,
the call raises — a nonexistent id is an error, not an empty result.

Returns: the complete task object as compact JSON, including at least
id, external_id, source, title, description, status,
created_at, updated_at, e.g.:

{"id":"task-abc123","external_id":null,"source":"mcp","title":"Fix thing","description":"...","status":"in_progress","created_at":"2026-08-20T12:00:00Z","updated_at":"2026-08-20T12:05:00Z"}

task_status is read-only polling — call it again later to check progress;
it never changes the task.

Writing a good ticket

Inline everything the coding agent will need directly into description:
exact file paths, exact acceptance criteria, any commands to run. Do not
reference "the conversation above" or anything in your own context — the
task runs in its own fresh session and cannot see it.

Product boundary — no_human opens a PR and stops

**no_human plans, codes, tests, has the work reviewed by a second model,
opens the pull request, and stops there. Merge is always the human's
action — this skill must never instruct or attempt a merge, an approval, or
a push to a protected branch.** There is no tool exposed here that can merge
or approve anything, and none should be sought or improvised — do not run any
merge or approval command on the agent's behalf. Once task_status reports a
PR link, your job is to report that link back to the human — not to merge it,
approve it, or push further changes to it yourself.