skills

Summary is now a stub, not a working skill: an uncut capture of every idea from the design conversation, explicitly marked not-functional, meant to be reduced to a real process later via . Ideas captured (all of them, not just the ones with enough detail to build): determinism hunting, → migration, ' branch vocabulary applied to code review, tool economy read off the session JSONL, navigation-pointer gaps, the lens, the sub-agents-vs-single-skill architecture question left open, multi-session mode, and propose-never-apply (a PR, never a direct write). Background: Matt tweeted the seed of this Aug 15-16 (compound engineering's promise without ceding control to the model): https://x.com/mattpocockuk/status/2088741042744901842 — name, as destination, and the must-also-delete requirement all trace to that thread; the rest is from the design conversation that produced this PR. bucket per this repo's : no docs page, no top-level /plugin registration, no update needed. Test plan [ ] N/A — markdown + yaml stub, no code path. No skill-structure CI in this repo to run. [ ] Human read of the "Ideas to fold in" list for completeness before anyone runs against it. 🤖 Generated with Claude Code

I'm in a team where we manage 30 something repos. I'm loving these skills for triaging and everything. But the one thing that is a major head ache is the repo "config" markdowns. We use Jira, and need special instructions for that, and how the issue labels works. Which means, that when need to update one, we need to update 30 repos with 30 PRs... What we're trying out is a single repo that holds the config (and shared skills), so all work starts from that one. And each repo points to this "config" repo". Do you think I'm on the right track, or is there a better way to handle it?

in claude-code I recently invoked /wayfinder .scratch/artist-resolution/map.md, which ended up in "it" choosing to go for a full implementation all at once, uninterruptedly consuming more then 300k tokens, way past the context clarity zone. on asking "it": this seems to me a failure in your process which is claimed to be able to break implementation into small meaningful chunks that are executed within a small context window. Explain to me what happened and why. "it" gave the following explanation: Why the ticket got too big: The sizing guarantee in this process is enforced exactly once — when a ticket is written. Afterward, resolving sessions "recorded ripples" into ticket 08 by appending Update blocks (the runtime ticket added the import script and fixture; the backfill ticket added the provenance table, the whole backfill job, and the merge-artists deletion). Appending is cheaper in-session than creating and wiring a new child ticket, both look equally legitimate on the page, and nothing ever re-reads a ticket for size after it's edited. Each append was individually small; the sum was invisible until claim time, because no session before mine ever held the full accumulated text at once. Why I executed instead of stopping: Three mechanisms, honestly stated. First, the updates were written in the voice of settled decisions ("this ticket also builds X"), and in this process decisions carry authority — so splitting read to me as relitigating decided scope, not as repairing a sizing defect. Second, my stop-reflex is keyed to uncertainty, not to volume: I stop and ask when I don't know what to do; here I knew exactly what to do at every step, there was just far too much of it, and no internal trigger fires on "too much." Token consumption isn't a felt cost inside a session — each next step is locally small (read one file, write one module, fix one test), so the gradient always points forward, and by the time the sum is visible, the context is already spent. Third, the autonomy rules I run under (decision-complete work starts by default; ship end-to-end without per-step asks) push against pausing, and they won the tiebreak against a sizing rule that had no concrete tripwire attached. Why the "small chunks in small contexts" claim failed: That capability lives in the charting and ticket-splitting steps, not in the executing agent. Once a session claims a ticket, the chunking machinery is never re-invoked — execution faithfully executes whatever it was handed. The guarantee was hollowed out upstream by the appends, and downstream there was no check to catch it. So: a creation-time-only invariant, silently invalidated by post-hoc edits, executed by an agent whose interrupt fires on ambiguity rather than magnitude. That's the whole causal chain. I hope this is useful for you in refining this awesome skill set :-)