/aitask-pickrem

A mostly autonomous version of /aitask-pick designed for non-interactive environments. It combines task selection and implementation into a single flow with zero AskUserQuestion calls — all decisions are driven by an execution profile. The only interactive step is plan approval, which still requires the user to review and confirm the implementation plan via ExitPlanMode.

Note: This skill requires write access to the task data branch, so it is suited for local Claude Code or CI-like environments. For Claude Code Web (which cannot write to branches other than the code branch), use /aitask-pickweb instead.

Usage:

/aitask-pickrem 42        # Parent task (no children)
/aitask-pickrem 42_2      # Child task

A task ID argument is required — there is no interactive task browsing.

Note: Must be run from the project root directory. See Skills overview for details.

Codex CLI note: In Codex wrappers, after implementation, most of the times you will need to explicitly tell the agent to continue the workflow because request_user_input is only available in plan mode. Example prompts: Good, now finish the workflow or Good, now continue.

Key Differences from /aitask-pick

Step-by-Step

1. Initialize data branch — Ensures aitask-data worktree and symlinks are ready (required when ait setup hasn’t been run). No-op for legacy repos
2. Load execution profile — Auto-selects a profile (prefers one named remote; falls back to first available). Profile is required — aborts if none found
3. Resolve task file — Validates the task ID argument, loads the task file. Parent tasks with children are rejected (must specify a child ID directly)
4. Sync with remote — Best-effort sync to pick up changes from other machines
5. Task status checks — Detects Done-but-unarchived tasks and orphaned parents. Handles them based on profile settings (done_task_action, orphan_parent_action)
6. Assign task — Non-interactive email resolution (from task metadata → userconfig → profile). Claims ownership and acquires lock. Stale locks can be auto-force-unlocked via force_unlock_stale profile setting
7. Environment setup — Always works on the current branch (no worktree/branch management)
8. Create implementation plan — Uses EnterPlanMode/ExitPlanMode for plan creation and user approval (plan approval is always interactive and cannot be skipped by profiles). Can verify existing plans or create new ones. Always implements as single task (no child creation in remote mode)
9. Implement and auto-commit — Follows the approved plan, runs tests and build verification, stages all changes, and commits with the standard <issue_type>: <description> (t<task_id>) format
10. Archive and push — Archives task and plan files, handles linked issues per profile setting, pushes to remote

Abort Handling

If errors occur after claiming the task, the abort procedure releases the lock, reverts task status (configurable via abort_revert_status), and optionally deletes the plan file (abort_plan_action). No user interaction required.

Execution Profiles

Remote mode requires a profile — without one, the skill aborts. The profile pre-answers every decision that /aitask-pick would ask interactively (except plan approval, which always requires user confirmation).

Profiles are YAML files stored in aitasks/metadata/profiles/. The remote profile ships by default:

name: remote
description: Fully autonomous workflow - no interactive prompts except plan approval
skip_task_confirmation: true
default_email: userconfig
force_unlock_stale: true
plan_preference: use_current
post_plan_action: start_implementation
done_task_action: archive
orphan_parent_action: archive
complexity_action: single_task
review_action: commit
issue_action: close_with_notes
abort_plan_action: keep
abort_revert_status: Ready

Standard Profile Fields

These fields are shared with /aitask-pick (see Execution Profiles):

Fields from the standard schema that are ignored in remote mode: run_location, create_worktree, base_branch.

Remote-Specific Profile Fields

These fields are only recognized by /aitask-pickrem:

All fields have sensible defaults — a profile only needs name and description to function, though providing all fields is recommended.

Build Verification

The skill can optionally verify the build after implementation. See Build Verification for configuration details.

Workflows

For a full workflow guide, see Parallel Development.