start-work

Files (1)

• SKILL.md

SKILL.md (first lines)

Call `health_check` first, loading it and `boulder_write` if needed: `ToolSearch({query: "select:mcp__plugin_oh-my-claudeagent_omca__health_check,mcp__plugin_oh-my-claudeagent_omca__boulder_write", max_results: 2})`. Proceed only when `runtime` is `ok`; otherwise repeat `runtime_reason` to the user, tell them to run `/oh-my-claudeagent:omca-setup`, and stop. If the tool is still missing, say OMCA's server is not connected and stop.

# Plan execution mode: start-work

This command runs in the main session at depth 0. The `Agent` tool is available,
so orchestration is real: parallel fan-out to `executor`, specialist escalation
via `build-fixer`/`explorer`/`researcher` as needed.

The platform's native Workflow tool is not a substitute for this command. A workflow run
is driven by the platform's own runtime, so its agents never call `evidence_log`, never
bind a plan, and OMCA's plan gates never see them. That makes it a separate lane, not a
replacement for plan execution here.

## Refusal clause

This command body runs in the main session at depth 0. If the `Agent` tool is not in
your tool list (a `--tools`, `--disallowedTools`, or deny-rule restriction removed it),
refuse and return.

There is no degraded mode. Do not implement tasks directly.
Do not attempt a partial execution. Emit the refusal message below and return:

```
ERROR: start-work needs the `Agent` tool to delegate plan tasks, and this session
does not have it. There is no degraded-mode fallback.

Run plan execution from a session where the Agent tool is available:
  /oh-my-claudeagent:start-work <plan>
```

## Plan discovery logic (step 0)

### Plan mode handling

When plan mode is active, call `ExitPlanMode` first. Plugin agents cannot set their own
`permissionMode`, so delegated agents inherit plan mode and could not edit.

### Finding the active plan

OMCA tracks several plans at once, and each session is bound to at most one of them.
Plan selection in this step is what binds this session.

1. When the guidance OMCA added to this session carries an `[ACTIVE PLAN] <name>: <path>`
   line, this session is bound to that plan. If the file has unchecked boxes, resume
   it directly (skip steps 2-3); `boulder_progress(plan_name="<name>")` gives the counts.

2. Otherwise, or when that plan is fully checked, build the selection list from two
   sources:
   - The plan `boulder_progress()` returns, labeled `[active]`. With no binding it
     returns the only registered plan or the most recently started one, which may be
     another session's. **Exclude it when its checkboxes are all checked**: completion
     is derived from the plan file's `- [x]` boxes, not a stored flag.
   - Plan files in `<plans-dir>/*.md` and `<project root>/.omca/plans/*.md`, labeled
     `[available]`.

   `<plans-dir>` is the platform's plans directory: the `plansDirectory` setting when
   it is set (a path relative to the project root), otherwise `~/.claude/plans`. Read
   it from settings before globbing; with `plansDirectory` configured, the default
   path holds nothing and a `~/.claude/plans` glob finds no platform-created plan.

3. Merge results, deduplicate by absolute path. When the plan being registered sits outside
   both homes, tell the user its path and that the Plan tab lists the two homes and
   registered plans.

### Decision logic

#### Draft gate (checked before anything is executed)

A plan may carry a `**Status**:` field on its metadata line. Read it before executing,
resuming, or auto-selecting a plan:

- `Status` says `FINAL`: executable.
- No `Status` field anywhere in the plan: executable. A missing field never blocks
  execution.
- `Status` is present but says anything other than `FINAL` (`DRAFT` being the common
  case): REFUSE to execute it. A draft is a plan the user is still being interviewed
  about, and executing one runs work nobody agreed to.

On a refusal, emit this and return without delegating anything:

```
This plan is still a draft (Status: {value}), so start-work will not execute it.

Finish the plan first:
  /oh-my-claudeagent:plan

Once the plan's Status line reads FINAL, re-run:
  /oh-my-claudeagent:start-work {plan path}
```

A refused plan is also excluded from the selection list, so a single draft never
auto-selects. If every candidate is a draft, say so rather than picking one.

- **This session already resolves to a bound plan with unchecked boxes**: append the
  session (re-run `boulder_write`, which is idempotent) and continue work.
- **No bound plan, or the bound plan is complete**: list available plans (per above,
  completed plans excluded).
  - One plan found: auto-select it.
  - Several plans: present the list and ask the user to choose. Selecting a plan calls
    `boulder_write`, which registers the plan and binds this session to it.

### Argument handling

If `[plan file]` argument is provided, use that path directly, skip search.

If `--worktree <path>` is provided:
1. Validate: `git rev-parse --show-toplevel` inside path.
2. If valid, store it in boulder via `boulder_write` and inject worktree instructions
   into ALL delegation prompts (all ops target worktree paths).
3. If invalid, show setup: `git worktree add <path> <branch>`.

Without `--worktree`, run in the current checkout; `boulder_write` keeps a
`worktree_path` stored earlier for the plan.

### Boulder write (before delegating)

After the plan is selected, before any delegation:

```

From UtsavBalar1231/oh-my-claudeagent, MIT.

More from UtsavBalar1231/oh-my-claudeagent