Daily feedback on a goal is something you rarely get outside of a formal review. I recently created a daily reflection routine over my own chat history to help me identify instances where I was over-explaining before getting to the next step. It also reminded me of any open threads to reply to before I signed off for the day. Rather than having this bubble up through feedback at review time, the daily accountability helped keep me on track.
That routine wasn't an experiment for its own sake. In my 2025 summary blog post, I predicted "the challenge won't be any single capability but orchestrating skills, sub-agents, MCP servers, and other capabilities together effectively." The same capabilities everyone points at a codebase work just as well pointed at your own habits and at the recurring work that never gets prioritized or falls off your desk.
Working with internal platforms, one of the most useful signals I get is "on the ground" feedback from development teams in support channels and forums. There was no question of the value, but keeping up with it was taking more of the day than I had to give. So I built a routine to collect trends across support threads and surface where friction was showing up. This included an app connector for the chat tool, a skill defining how to fetch and organize the results, and a set of markdown files as a simple state store for durable trends. This gave me a standing view of what developers are hitting, so the decisions I make about platform work start from their experience instead of my assumptions.
The same model works for the tasks that never get a formal item on anyone's board. I'm regularly pulled into ADRs (Architecture Decision Records) where the scope reaches past the local team. Those decisions can sometimes stall when wider alignment is needed, or a decision gets made without the follow-up to document it. The routine tracks document status and flags when something has been sitting too long. A to-do list isn't novel, but by using the connector I can see the actual state of the document rather than my last note about it. It counters analysis paralysis without touching the decision itself. The nudge is automatic, but the decision still belongs to the teams it affects.
Across these different applications of GenAI, the shape is the same one I described for the support collector. The reflection routine points at my own chat history instead of support threads, and the ADR routine at our document store, but the pieces underneath don't change. This approach works and is encouraged in most harnesses now such as Claude Cowork, ChatGPT Work, or GitHub Copilot, so what you build with one is mostly portable to another.
However, there is a real cost of ownership to these automations. If the schema of a support ticket changes, your skill will need an update to account for that. Silent failure with limited observability is possible, and something to look for. To pull from my days in security you must "trust but verify." Creating the routine is a one-time cost but confirming it still does what you think is ongoing. It's best to keep a critical eye so your personal stack doesn't accidentally become a Rube Goldberg machine.
The easy measure to optimize these routines for is time saved. The support trend collector does save me time, but its main value is that the platform decisions I bring to other teams stay grounded in what developers actually reported. The ADR routine makes me faster at ADRs. It also makes it less likely that a decision with cross-team scope quietly expires, which is the part I'd miss if it were gone. The efficiency is real, but it's a side effect. Optimizing for it directly is how you end up faster at producing work that didn't need doing.
The habit I opened with has an expensive version. In front of leaders, my instinct is to bring more technical analysis, when framing is what actually moves a decision forward. This was something I had self-identified as an improvement area. What I didn't have was anything catching me on the days I fell back into it. The items to watch for were mine to define, and deciding whether a message met them was mine as well. What I handed off was the attention required to check consistently.
I'm still fine-tuning each of the approaches I discussed. They've shown early value and I plan to expand this to other parts of my daily work. I regularly take a step back and think about it as a system in addition to the tactical task it handles. Each routine can surface a pattern or flag a stalled document, but I'm the one who decides what to do about it and the one accountable if that call is wrong.