io.github.umitkavala/mindpm

Move low-risk verified tasks to done (or submitted ones in needs_verification, when the project's verification is off), only when the user explicitly asked: act as yourself with on_behalf_of: "human:<their name>". Medium and high risk are refused: they are accepted in the Kanban UI only. You cannot accept work you submitted. Each task is accepted or refused on its own.

Add a note to a project or task. Proactively use this when the user shares context about architecture, bugs, ideas, research findings, or any important information worth remembering. Always specify the project parameter when you know which project is active.

Approve a draft spec so agents can work on its tasks. Medium and high risk need human:*; low risk also allows agent:architect. Moves linked backlog tasks with no open blockers to ready and writes specs/SPEC-<n>.md into the repo (a human commits it).

Executor: take exclusive ownership of a ready task. Returns a claim_token that authorizes every later write, the lease expiry, and the task brief. Heartbeat before the lease runs out or the claim expires and counts as a used attempt.

Create a new project to track. Use this when starting a new project or when a user mentions a project that doesn't exist yet.

Define a spec: the objective, why it matters, the chosen approach, constraints and acceptance criteria an executor agent works against. Created as a draft; approve_spec makes its tasks workable. Architect or human only.

Create a new task in a project. Proactively use this when the user mentions something that needs to be done, a bug to fix, or a feature to build. Link it to a spec (spec_id) to make it executable by an agent: it then starts in backlog until the spec is approved.

End a work session with a summary of what was accomplished and what to do next. Call this when the user is done working.

Executor: stop and ask a human, for example when the spec is ambiguous. Ends the attempt as abandoned (it does not use up an attempt) and moves the task to needs_human with your question attached.

Local verifier: end the run. The server computes the outcome: passed only if every check exited 0 and every criterion is pass (task → verified); otherwise failed (task → ready with findings, attempt used). Pass error_reason when the check itself broke (checkout, timeout, missing report): the task stays in needs_verification and no attempt is used.

Returns the recommended instructions for using mindpm effectively. Call this once if you are unsure how to use mindpm, or share it with the user to paste into other LLM clients.

List all blocked tasks with what's blocking them.

Get context by key or list all context for a project.

DORA-inspired delivery metrics for a project: throughput, lead time, flow efficiency, and performance tier. Use to understand delivery health and trends.

Planning view: what should be worked on next? Returns the highest priority ready or claimed tasks for a project. Executor agents use pick_task instead.

Get a full overview of a project: active tasks, recent decisions, blockers, and last session summary. Great for getting up to speed.

High-level summary of a project: total tasks by status, recent activity, open blockers, and upcoming priorities.

Read-only: what changed since the last session ended — commits, branch and working-tree state, task status changes, new blockers, decisions, and notes. Unlike start_session, this does not open a session or mark one as started.

A spec with its acceptance criteria, linked tasks (status and attempts) and the active decisions that shaped it.

Get full detail for a specific task including sub-tasks, related notes, its spec criteria and its attempts.

Everything needed to execute a task in one read: task, spec and acceptance criteria, project conventions, verification commands, relevant decisions, dependencies and what previous attempts learned.

Executor: extend your lease by its original length and log the phase you are in. If spec_changed comes back true, the spec was revised since you claimed: re-read it with get_task_brief before continuing.

List decisions for a project. Filter by tags to find specific decisions.

List all tracked projects. Filter by status to see active, paused, completed, or archived projects.

List tasks with filters. Defaults to showing non-completed tasks for the most recent active project.

Record a decision with reasoning and alternatives considered. Proactively use this when the user makes a technical decision, chooses between options, or settles a debate.

Verifier: tasks in needs_verification with a submitted commit and no run in progress, in projects your key covers, oldest submission first.

Executor: return the next task to work on: ready, spec approved (or no spec), all blockers done, no live lease. Ordered by priority, then oldest. Does not claim; call claim_task next.

Execute a read-only SQL query against the database. Only SELECT statements are allowed. Use this for custom queries not covered by other tools.

Local verifier: record what was executed in the run. Re-recording a check name replaces it.

Verifier: record a result and evidence for acceptance criteria. test and command criteria need a local key, review criteria a reviewer key. A criterion passes only on positive evidence: a skipped or unmatched test is missing.

Executor: give the task back voluntarily, for example when your run budget is spent. Does not use up an attempt.

Executor: end your attempt as failed, with a root cause and notes the next attempt will see in its brief. spec_gap and design_conflict go to a human. dependency goes to blocked (name the blocking tasks in blocked_by so it unblocks itself). Anything else returns the task to ready, or to a human once attempts are exhausted.

Human only: answer a task waiting in needs_human. requeue returns it to the queue (granting one more attempt if the budget is spent); cancel ends it; revise_spec sends it to backlog and returns its spec to draft until the revised spec is approved again; reverify hands a submission whose verification kept erroring back to the verifier, once the verifier is fixed.

Deprecated: a verifier now checks submitted work (see `mindpm verify`), and a human accepts it. accept behaves like accept_tasks for one task: only verified, low-risk work, never your own submission. reject is no longer possible here: failed verification returns work to the executor, and a human reopens verified work in the Kanban UI.

Full-text search (FTS5, ranked by relevance) across tasks, notes, decisions, specs and attempt root causes for a project.

Full-text search across notes for a project.

Set a key-value context pair for a project (upsert). Proactively use this when the user shares important project context like architecture decisions, config values, conventions, or constraints.

Set the coding conventions and verification commands (build, unit, integration, lint) that go into every task brief for this project. Tasks can override individual commands with their own verification. These are hints for the executor: the verifier never runs them. It runs only the checks a human configures in the Kanban UI (Verifiers tab), which the brief lists as verifier_checks.

Set or update the local git repository path for a project. Required for the session brief to include git activity (commits, branch, working-tree state) since the last session.

Begin a work session for a project. Returns the full project overview including last session's next_steps, active tasks, blockers, and recent decisions. Call this at the start of every conversation. For multi-project conversations, call once per project — after that, pass `project` explicitly on every tool call. IMPORTANT: Always show the kanban_url to the user as a clickable link so they can open the Kanban board.

Local verifier: open a run on a task's submitted head_sha. Returns the run id, the SHA to check out, the checks to run and the criteria to judge. The run lease is 30 minutes; every record_* call extends it. Check out exactly head_sha in a clean worktree, never the executor's working tree.

Executor: hand finished work over for verification. Requires the branch, head commit SHA, files touched, a summary, and a result for every acceptance criterion on the task. Moves the task to needs_verification.

Replace a spec with another one. Cancels the old spec's unfinished tasks; any live claim on them ends.

Edit a spec. Pass the version you read as expected_version; a stale version fails with version_conflict. Editing an approved spec republishes it: the version bumps and agents working on its tasks see spec_changed on their next heartbeat.

Update fields of a task. Proactively use this when priorities shift or new information comes in. Changing status directly is reserved for humans (actor human:*); agents move tasks with claim_task, submit_task, report_failure, escalate and release_task.