---
name: preset-trigger
description: Start Harness Anything task creation by choosing a software/coding preset first. Use when creating or planning a harness task package.
---

# Preset Trigger

## Core Rule

When building a Harness Anything task, choose the preset before creating the task package. Presets are the recommended starting points for task shape, checks, and generated materials.

Use:

```bash
ha task create --title "<title>" --vertical software/coding --preset <id>
```

If unsure, inspect the current list first:

```bash
ha task create --help
ha preset list
ha capabilities preset
```

## Organize Work

A **work** is the only grouping concept: one root task plus the tasks filed under it (its `parentTaskId` subtree). When several tasks serve one goal, group them in a work instead of leaving them flat.

```bash
ha work create --title "<work name>"                      # root task on the create-work preset
ha task create --work <work-id> --title "<title>" --preset <id>
ha work list                                              # open works; --all includes closed ones
ha work show <work-id>                                    # goal, subtree counts, open tasks
ha agenda --work <work-id>                                # the agenda narrowed to one work
```

- Without `--work`, a task stands alone. The create receipt names the task's work, or hints `--work` when open works exist; read that hint before filing the next task.
- `--work` accepts the work root or any task inside the work; the new task becomes that task's child. `ha task list --parent <id> --depth all` reads the whole subtree.
- Close a work with the `work-closeout` preset before completing its root task.

## Available Presets

- `architecture-rot-audit`: Detect structural architecture drift.
- `code-impact-analysis`: Map a proposed change across code, tests, docs, dependencies, and operations.
- `create-work`: The root of a work; its `task_plan.md` is the work map. Start it with `ha work create --title "<name>"`.
- `decision-conformance`: Prove implementation alignment with accepted decisions.
- `docs-task`: Plan design, documentation, or chore work without a code commit.
- `gui-development`: GUI pages, shared components, and GUI acceptance using the existing product design system.
- `github-issue-repair`: Repair an existing GitHub issue with evidence.
- `legacy-migration`: Run generation replay of a previous-generation Harness repository, resolve reported conflicts, and rebuild legacy presets as v3 packages.
- `standard-task`: General implementation or maintenance task; the default starting point.
- `subtask-expansion`: Plan and fan out a parent task into concrete child tasks, each created with `--work <parent-id>`.
- `work-closeout`: Verify a work's criteria, tasks, decisions, and evidence before declaring it closed.
- `worker-dispatch`: Add bounded worker coordination roles and dependencies.

## Guardrails

- Do not hand-create task package directories.
- Do not skip preset selection for software/coding work; use `standard-task` when no narrower preset fits.
- Use `legacy-migration` only for `ha migrate import` generation replay; do not turn it into manual legacy-material classification.
- Create packages through `ha task create`; then edit the generated plan and closeout within the task’s authorized document surface.
- For a small low-risk `standard-task`, select `--profile lightweight` at creation. It uses minimal plan/closeout templates and no review, consent, or Fact requirement; it retains applicable CI. The profile is frozen at creation.
- Group tasks only through works. There is no module, milestone, or epic grouping; do not invent one in task titles or directories.