---
name: new-task
description: Scaffold a new ba-auto-daily feature task following this repo's reference-first workflow — inspect the matching ~/repo/baas-reference/module/... file, update ba_auto/reference_notes/mapping.md, and stub ba_auto/tasks/<feature>.py. Use before writing any new task module, or when the user asks to start/port/implement a new feature (group, bounty, commission, arena, or any other daily task not yet migrated).
---

# /new-task

Scaffolds the start of a new feature task, per `CLAUDE.md`'s "Feature
implementation workflow". This is the mechanical setup only (steps 1-6 below)
— it does not write the actual click/detection logic, because that requires
reading the specific reference module and making per-feature judgment calls
the way `mailbox.py`, `cafe.py`, `story_sweep.py`, `shop_*.py`, and
`lesson.py` each did.

Feature name (and optional reference file hint): $ARGUMENTS

## Known backlog features (from `ba_auto/reference_notes/mapping.md`)

| Feature | Reference file |
|---|---|
| group / club | `module/group.py` |
| bounty | `module/rewarded_task.py` |
| commission(s) | `module/clear_special_task_power.py` |
| arena | `module/arena.py` |

If the requested feature isn't one of these, search
`~/repo/baas-reference/module/` (including subdirectories, e.g.
`module/explore_tasks/`, `module/shop/`) for the closest-matching file by
name/content before asking the user to confirm which reference file applies.
Never invent a Bash click sequence in place of a missing reference file —
if nothing matches, say so rather than guessing.

## Steps

1. **Read the reference module.** Open the matching
   `~/repo/baas-reference/module/...` file (read-only — never edit it) and
   identify:
   - the main class/function driving control flow
   - what it uses for state detection (OCR, color probe, template match,
     UI-object query)
   - what it uses for retries/failure handling
   - which parts are Android/uiautomator2/ADB-specific and need a local
     desktop replacement (`xdotool`/`scrot`/OpenCV/OCR via
     `ba_auto/driver.py` / `ba_auto/detector.py`)
   - which parts can be ported as direct Python control flow

2. **Summarize that flow** back to the user in a few sentences before
   writing any code — this is the point where a wrong assumption is
   cheapest to catch.

3. **Update `ba_auto/reference_notes/mapping.md`.** If a row already exists
   for this feature (the four backlog rows above already have placeholder
   rows with "Need to inspect" / "Not started"), fill in the real
   "Reference functions/classes" and "Backend replacements" columns from
   step 1 and set Status to `In progress`. If no row exists, add one in the
   same table format.

4. **Check for missing driver/detector primitives.** Compare what step 1
   needs against what already exists in `ba_auto/driver.py` and
   `ba_auto/detector.py`. Call out anything missing before stubbing the
   task — e.g. a new OCR crop helper, a new template-match wrapper.

5. **Create `ba_auto/tasks/<feature>.py`** with a minimal stub:

   ```python
   from ba_auto import driver, detector, navigation, config


   def run(driver, config):
       """<one-line pointer to the reference file/functions this ports>"""
       raise NotImplementedError("port <module/xxx.py>'s <function> here")
   ```

   Do not fill in the real logic here — that's the next, non-mechanical
   step, and it should follow the reference's actual control flow rather
   than a placeholder guess.

6. **Remind the user of what's still manual**, matching the rest of
   `CLAUDE.md`'s workflow:
   - implement the real logic in the stub, following the reference control
     flow (state detection, retries, and all)
   - add CLI dispatch for the new task in `ba_daily.py`
   - decide whether it belongs in `DEFAULT_ORDER` — only free/reclaim-type
     tasks do; anything that spends AP/credits/tickets/coin must stay
     opt-in, matching `story_sweep`/`shop_common`/`shop_tactical`/`lesson`
   - run the local syntax checks (`bash -n`, `python3 -m py_compile`) —
     covered automatically now by this repo's `PostToolUse` hook, but worth
     running explicitly before deploying
   - deploy via `/deploy-gpu` and test against the live game
   - update `plan.md` with a phase writeup once it's actually working,
     including any real bugs found live — not just "done"