new-feature

name	new-feature
description	Start a piece of work on main (trunk — the DEFAULT path). Loads the plan / 100days item, checks recent history, agrees a plan, and records the task. No branch, no worktree, no env setup. For work that needs an isolated live environment, use /new-branch instead.
disable-model-invocation	true
user-invocable	true
allowed-tools	Bash, Read, Edit, Glob, Grep

Start work on main for the task described in $ARGUMENTS.

This is the default way to start work: trunk. You stay on main, in the env that's already built, and commit liberally as you go. Reach for /new-branch only when two envs must be live at once, the work is multi-day and main must stay shippable meanwhile, or it's a throwaway spike.

Instrumentation: every step calls the shared logger so the run is observable. Set BRISTLENOSE_WORKFLOW_DEBUG=1 for verbose step-by-step echo to stderr. The log lands at .claude/workflow-log.jsonl. Call shape: bash .claude/skills/_shared/wflog.sh new-feature <step> "<detail>".

Failure policy: Step 1 (location) is critical — stop on failure. The rest are about loading context and recording state; warn and continue.

Step 1: Confirm trunk + log start

export PATH="/usr/bin:/bin:/usr/sbin:/sbin:/opt/homebrew/bin:$PATH"; hash -r 2>/dev/null || true
bash .claude/skills/_shared/wflog.sh new-feature start
git branch --show-current
git status --short

If the current branch is not main, you're likely already inside a worktree. This is the forgiving case — don't fail hard:

"You're on <branch>, not main. If you meant to start isolated work, you're already in the right place — just work here and /close-branch when done. To start trunk work, cd /Users/cassio/Code/bristlenose first, then re-run /new-feature."

Then stop. On main, continue.

Step 2: Load the plan context

• If $ARGUMENTS names or matches a docs/private/100days.md item, read that entry, note its sprint tag, and find any linked board card.
• If a handoff exists at docs/private/handoffs/<slug>.md, read it as the starting brief — don't synthesise from scratch.
• Handoffs aren't specs. Run git log -3 -p on the files the task/handoff names and grep commit bodies for decision-shapes ("not Y", "deferred to", "rejected", "chose X over Y", "post-TF", "status-only"). If a recent commit contradicts the plan, raise it as a question BEFORE planning. Recent commits win unless the user overrides.

bash .claude/skills/_shared/wflog.sh new-feature context "<what was loaded>"

Step 3: Plan — or skip it for a one-liner

If you could describe the diff in one sentence (typo, log line, rename, one-line copy fix), skip planning — just do the work. Otherwise draft a short bullet plan and get the user's nod. For anything structural or convention-touching, offer /usual-suspects on the plan first.

bash .claude/skills/_shared/wflog.sh new-feature plan "<skipped|drafted: N bullets>"

Step 4: Record the task

Write .claude/current-task.json (per-working-dir, gitignored). Get the timestamp from bash (date -u +%Y-%m-%dT%H:%M:%SZ):

{
  "route": "main",
  "task": "<one line>",
  "source": "<100days line / board card / freeform>",
  "plan": ["<bullet>", "..."],
  "started": "<UTC now>",
  "changelog_needed": false
}

Set changelog_needed true only if the work is user-facing (ships in the wheel / changes the app). Then:

bash .claude/skills/_shared/wflog.sh new-feature state-written main

Step 5: Hand back

Tell the user: "On main, task recorded. Build away — I'll commit at every green checkpoint. Run /close-feature when done."

bash .claude/skills/_shared/wflog.sh new-feature ready

During implementation (your behaviour — not a step the user runs)

Commit liberally — at every green checkpoint — with real messages. Each commit is a labelled rollback point: git log --oneline is the menu, git reset --hard <sha> returns to a named state. That is the whole safety net; no hooks, no wip refs. Reflog is the last-ditch backstop, not the plan.