Takeaway: Next time I'd open with where the extension actually lives (globally installed via npm) instead of assuming it was in the repo - that would have saved several minutes of searching pi-mono source for nothing.
Takeaway: I'd start by asking for the investigation and the two features (row dividers, longest-word minimum width) together, since that's basically what I ended up doing anyway.
Takeaway: I should have just said 'git pull --ff-only on branch X' up front instead of assuming 'ff' was self-explanatory.
Takeaway: Next time I'd start by pointing straight at ~/pi-extensions instead of letting it dig around in pi-mono's source first - that redirect was the correction that actually got it moving in the right direction.
Takeaway: I'd probably skip asking the agent to just review a file this simple next time since it just confirmed what I could see myself.
Takeaway: I never actually got to a real task here - I'd start next time by clearly naming the module and the change I want instead of pasting logs or waiting on a paste that didn't go through.
Takeaway: Next time I'd start by checking upstream/issues for the bug number before spending an hour building a consolidated fix, since the maintainer landed a one-line getExpandedText() fallback for the same bug while I was still refactoring.
Takeaway: I'd keep this prompt as simple next time since it's a one-shot git operation with no ambiguity.
Takeaway: Next time I'd just name the exact skill I installed up front instead of making the agent infer it from context, since it had to ask which item I meant at the end.
Takeaway: I'd just ask for the same repo overview again next time, but maybe point it straight at the README instead of letting it discover the file itself.
Takeaway: I didn't actually give the agent anything to work with, so nothing happened.
Takeaway: I'd start by asking the agent to trace findCutPoint and findTurnStartIndex directly instead of doing broad rg searches first, since that's where the real logic lives.
Takeaway: I'd start by pointing the agent straight at the specific subsystems I care about (permissions, memory/compaction, sub-agents) instead of letting it wander the whole repo tree first — that would have gotten to the comparison faster.
Takeaway: I didn't actually give it a task yet, so nothing got built this session.
Takeaway: I'd start by asking it to trace the footer percentage calculation against the debug log directly instead of reading the code first — that got to the root cause faster.
Takeaway: I didn't actually give the agent a task here, just said hi, so it read the README and asked which package I wanted to work on.
Takeaway: I didn't actually give it a task this time, just said hi to test things out.
Takeaway: I'd start by pointing straight at the powerline-footer extension path instead of letting the agent grep the whole monorepo for 'footer' and 'powerline' first — that exploration ate most of the session.
Takeaway: I'd start by giving the direct PR number instead of the issue link, since it cost a round trip to figure out #603 was the issue and #604 was the actual PR.
Takeaway: I'd give more context upfront about which queue system or module I meant, since 'Queue test' alone wasn't enough for a targeted search.