스킬 저장소 v1.1 — 리네임·grill 픽스·Wayfinder로 완성한 개발 생명주기

생각 덩어리

버전 1.1과 두 개의 리네임 — 가장 거슬릴 변경부터

Let's start with the two that are probably going to be most annoying for you, and the most like, why did he do this? And there is a very specific reason that I did it, which is that two skills have been renamed.

spec이 맞는 말 — PRD는 더 좁다

A product requirements document kind of describes more things about the actual product itself, whereas we were allowing things to leak into the PRD that weren't necessarily PRDs.

Specification is a much broader term that actually entails what we were building.

tickets — GitHub·Linear 편향을 걷어내다

...it was biased towards GitHub and linear that use issues, but really we want this to be tickets. You have a spec, and then underneath the spec you have the tickets that are the journey that you take to actually enact the spec and create it.

grill 버그 픽스 — 한 번에 여러 질문은 bewildering

I've sharpened up this line here saying asking multiple questions at once is bewildering.

We've also added a confirmation gate on the end. Do not enact the plan until I confirm we've reached a shared understanding.

Lots of people on different models were reporting that the grilling session would just end and then it would just go straight into implementation.

facts와 decisions의 구분 — 스스로를 grill하던 문제

Finally, on some situations, it would just grill itself, which is very, very odd.

...I've decided to make a distinction between facts, so facts that are things you find yourself by exploring the code base, and decisions. So, decisions are needed to be made by the user.

메인 플로우 = 소프트웨어 개발 생명주기 — spec·tickets·implement

That spec kind of defines the destination, where you're going. Then, you turn that spec into individual tickets so you can spread the development of it out over multiple agent sessions.

Implement the work described by the user in the spec or tickets. Use TDD where possible at pre-agreed seams. ... And run type checking regularly, single test files regularly, and full test suite once at the end. Once done, use code review to review the work, and then commit your work to the current branch.

code review — Fowler의 코드 스멜을 priors에서 소환

The theory of the code review skill is that it reviews code on two axes. So, it does a sub agent for each one of these. The first one is the standards axis. Does the code conform to this repo's documented coding standards?

...mysterious name or duplicated code or feature envy, data clumps, primitive obsession, repeated switches, divergent change, speculative generality, message chains. You see what I mean? Like, these are all deep in the agent's kind of knowledge base, and all we got to do is just really describe them in a sentence.

So, I tested this for a couple of weeks and it was outrageously useful. It was really, really nice at improving the quality of my code...

Wayfinder — 안개 속 큰 계획을 이슈 트래커 지도로

A loose idea has arrived, too big for one agent session and wrapped in fog. The way from here to the destination isn't visible yet. This skill charts the way as a shared map on the repo's issue tracker, then works its tickets one at a time until the route is clear.

With Wayfinder, it's kind of all managed for me. I just get to close a session, open up the next Wayfinder ticket. It's all saved in GitHub, so it's collaborative. You can share it across your team.

prototype·research·TDD — 나머지 스킬의 조정

The idea is you raise the fidelity of the discussion by making a cheap, rough, concrete artifact to react to.

Spins up a background agent to do the research so you keep working while it reads. Investigate the question against primary sources, write the findings to a simple markdown file...

I tend to think that putting the refactoring in the code review part is a lot more productive because then you don't overload the implementation.