Add "Go to task" to the Today's 5 pinned-task options sheet

.claude/skills/debug-build/SKILL.md

@@ -21,14 +21,32 @@ Build a debug APK and sideload it onto the connected Android device.
 
 Always recommend wireless debugging over USB when a device connection is needed.
 
-To connect wirelessly:
-1. On the phone: Settings → Developer Options → Wireless debugging → Enable it.
-2. Tap "Pair device with pairing code" to get the IP, port, and pairing code.
-3. Run `adb pair <ip>:<pairing-port>` and enter the pairing code.
-4. Then run `adb connect <ip>:<connect-port>` (the port shown on the Wireless debugging main screen, NOT the pairing port).
-5. Verify with `adb devices`.
-
-If the device was previously paired, `adb connect <ip>:<port>` alone should reconnect (no re-pairing needed), as long as both devices are on the same network.
+**Ask about pairing status FIRST — don't assume either way.** Before giving any
+connect instructions, have the user open **Settings → Developer Options →
+Wireless debugging** on the phone. That screen shows, top to bottom: a
+**"Use wireless debugging"** toggle, **"Device name"**, **"IP address and
+port"** (e.g. `192.168.1.5:42173`), then **"Pair device with QR code"**,
+**"Pair device with pairing code"**, and finally a **"Paired devices"** section
+at the bottom listing this machine by its hostname (e.g.
+`soham@soham-Dell-...`), with **"Currently connected"** underneath when a live
+connection exists.
+
+Ask in ONE message for both: (a) whether this machine is listed under **"Paired
+devices"**, and (b) the **"IP address and port"** — the user may answer with the
+full `<ip>:<port>` or just the port, whichever is easier; the port rotates every
+session while the IP usually doesn't, so a bare port is a perfectly normal
+answer. Pair it with the last known IP from memory, and only ask for the IP
+explicitly if there's no saved one or the connect fails. Then branch:
+
+**Already paired** — no re-pairing needed:
+1. Run `adb connect <ip>:<port>` with the "IP address and port" value (the port changes every session; the IP usually doesn't).
+2. Verify with `adb devices`.
+
+**Not paired** (or the connect above fails):
+1. On the phone, tap **"Pair device with pairing code"** — it opens a dialog with its own IP, a *pairing* port, and a 6-digit code.
+2. Run `adb pair <ip>:<pairing-port>` and enter the pairing code.
+3. Then run `adb connect <ip>:<connect-port>` using the **"IP address and port"** value from the main screen — NOT the pairing port (they differ).
+4. Verify with `adb devices`.
 
 When no device is connected, check your memory for the last known IP. Try `adb connect <saved-ip>:<port>` with the user-provided port. If the connection fails, ask the user to verify the IP hasn't changed. When a connection succeeds, save the IP to memory for next time.
 

.claude/skills/manual-test/SKILL.md

@@ -36,6 +36,7 @@ Generate a checklist of manual tests the user should run for recent changes.
    - **Each section must be self-contained, with its OWN setup.** Tests within a section can build on each other, but a new section/subheading must never assume state from a previous section — including the shared "Setup" block, which only bootstraps the FIRST section. Every section that needs a precondition MUST carry its own setup steps (a per-section "Setup" sub-block, or fold the steps into the section) that create/guarantee that precondition from scratch. Walk each section as if the user jumped straight to it: if it needs a **free Today's 5 slot**, a **non-leaf task to drill into**, an **existing dependency**, an **unpinned leaf**, etc., spell out how to reach that state right there. Do not make the user hunt through their existing data for a task in the right shape, and do not make them undo leftover state from an earlier section (e.g. "you had to unpin an already-pinned task") — the section's own setup owns that.
    - **Every test case must name the screen/tab** where the action starts (e.g. "On Today's 5 tab, tap..." not just "Tap..."). Never assume the user knows which screen you mean from context.
    - **Name every control by its exact label/icon — never a pronoun.** Do not write "tap it", "select that", or "confirm it" — even when you named the control earlier in the same line. Re-state the literal label or icon the user must tap (e.g. "tap **'Remove from Today's 5'**", not "tap it"). A pronoun forces the user to guess which of several controls you mean.
+   - **Never name an icon by its code identifier alone — describe it the way the user sees it.** The tester is looking at the screen, not the source: `open_in_new`, `Icons.today`, `archiveIcon` mean nothing to them. Always lead with a **plain-language description of the icon's appearance and/or purpose**, and append the code name in parentheses only when it adds clarity for a control that's otherwise hard to pin down. Write "the **open-in-new-window icon** (a small box with an arrow leaving it)" or "the **'Go to task' arrow icon**" — NOT "the `open_in_new` icon". Same for any other identifier that only exists in code (widget class names, constants, callback names): if it isn't visible on screen, it can't be the primary way you point at something.
    - **State-dependent steps must guarantee the precondition, not assume it.** When a step needs a task to be *unpinned* (or pinned, leaf, empty, etc.), do not name a specific task that an earlier step or the user's existing data may have already moved out of that state. Either use a dedicated fixture created in Setup for exactly this state, or phrase it state-relative — e.g. "pick **any task not currently in Today's 5**" instead of "tap into `Bravo leaf`". Trace cumulative state through all prior steps before naming a task in a precondition.
    - **One test = one flow.** Each test case should verify a single behavior. Don't combine multiple if-else outcomes into one test (e.g. "should show X if Y, otherwise Z"). Split into separate tests with clear preconditions.
    - **Account for state consumed by prior tests.** If test 1 uses a task with a deadline and removes it, test 2 can't reuse that same task for a "keep deadline" test. Either specify separate tasks in the setup, or tell the user to undo/re-add state between tests. **This includes structural state:** if a test relies on a task being a *leaf* (childless), *non-leaf*, *pinned*, *empty*, etc., do NOT reuse a task that an earlier test mutates out of that state (e.g. a "leaf" test must not use a task that an earlier test added a child to). Use a **dedicated fixture task per structural precondition**, named so it's obvious (e.g. "Solo leaf task — never gets children"), and trace the cumulative state through every prior step before asserting a precondition.