92 lines
4.3 KiB
Markdown

---
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"