skills

Hi Matt, Raising my experience with Astra this morning. I'm a huge fan of and using it heavily on and without any problem for weeks now. Really impressive tool. This morning, I started $grill-with-docs conversation with for the first time. I presented with a problem that I want documented, and it begin with the usual QnA. Astra gave me Q1-Q5 questions. I answered it specifically like below. Upon sending, it went on its own for good 30minutes, then I ask a question if its now doing implementation. It answered me with: . Then I ask when did I give approval, and told me it was when I say I was expecting it to realise means Q1-Q5, and not the overall implementation plan. It didn't give written understanding summary, just went ahead and implement. I have no problem on this flow with and . Anyone have similar experience?

Hi! First off, thank you for this skill — it's become a regular part of my workflow and I really appreciate it. I wanted to share a couple of small, entirely take-or-leave suggestions from using it. 1. Where the handoff is saved. The skill currently suggests the OS temp directory rather than the workspace. That works, but for the skill's own goal — a fresh session picking the work back up — I've found temp a little awkward in practice: The paths are long and hard to remember, e.g. . They're ephemeral — gets cleared on reboot, so a handoff can disappear before the next session. Each session gets a new temp dir, so successive handoffs end up scattered across unrelated paths and can't easily reference each other. One option that's worked really well for me: in a git repo, save to and add to . It's stable and easy to reference (), survives reboots, and stays out of version control — with a fallback to OS temp when it isn't a git repo. 2. Cleaning up old handoffs. Since there's no cleanup step today, handoffs can pile up over time. A short note near the top telling the picking-up agent to delete the file once it's no longer needed (the work is done, or a newer handoff supersedes it) keeps things tidy. Completely understand if these don't fit your vision for the skill — just wanted to pass along what's helped me. Happy to open a PR if it'd be useful. Thanks again!

The gap produces code, commits it, and hands off to . What it does not produce is a record of the judgment calls made along the way: where the spec was ambiguous and the agent picked an interpretation, where it deliberately deviated, which alternatives it rejected, and what it still wants the user to confirm. Today that reasoning lives only in the session transcript. Once the context expires (or the user was not watching in real time), the only way to recover it is to reverse-engineer the diff. The commit history shows what changed, not why the spec was read that way. This is the same class of problem as #311 (grill-me has no durable output), just at the implementation stage. Proposal Have maintain a running implementation-notes document while it works, updated as decisions are made rather than in one batch at the end. Concrete change to , inserted between the typechecking line and the handoff: Everything else in the skill stays as is. Why these four sections Design decisions and Deviations are kept separate on purpose. The first is "the spec did not say, so I chose". The second is "the spec said X, I did Y". A reviewer treats those very differently: one is a gap in the spec worth feeding back to , the other is a correctness question for the change itself. Tradeoffs is where the rejected alternatives go. Without it, the next person (or agent) re-derives the same options and may pick the one that was already ruled out for a reason nobody wrote down. Open questions** gives and the user a checklist instead of making them hunt through the diff for things the agent was unsure about. "Update as you go" matters more than the section list. An agent asked to summarize at the end will reconstruct a tidy narrative that omits the moments of doubt; asked to write it down at the moment of decision, it records what actually drove the choice. "Empty section stays in place" is deliberate: an absent section is ambiguous (forgot, or nothing to say?), an empty one is a positive claim. What I have been running I have had this in my local copy of for a while. The notes file has turned out to be the single most useful thing to read before opening the diff, and it makes the step noticeably better because open questions are already enumerated. Happy to send a PR if the direction is acceptable.