Ask Matt은(는) 무엇을 하나요?
모든 스킬을 기억할 필요는 없습니다. 물어보세요.
스킬이 무엇을 하는지 설명하거나 단계를 건너뛰도록 권장하기 전에, 해당 스킬의 SKILL.md를 읽으십시오: 여기 있는 요약은 방향 참고용일 뿐입니다.
플로우는 스킬을 통과하는 경로입니다. 대부분의 경로는 하나의 메인 플로우를 따라 진행되며, 두 개의 온-램프가 그 위로 합류합니다. 나머지는 독립 실행형이거나, 그 아래에서 실행되는 용어 레이어입니다.
메인 플로우: 아이디어 → 출시
대부분의 작업이 거치는 경로입니다. 아이디어를 만들고 싶습니다.
-
/grill-with-docs인터뷰를 통해 아이디어를 다듬습니다. 작업 디렉토리 안에서 작업 중일 때 여기서 시작하십시오: 상태를 유지하며GLOSSARY.md및 ADR에 학습한 내용을 보존합니다. (작업 디렉토리가 없나요? 대신/grill-me를 사용하세요. 독립 실행형에 설명되어 있습니다. 둘 다 동일한/grilling프리미티브를 실행합니다;grill-with-docs는 문서화 기록을 남기는 버전이므로, 리포지토리가 있을 때는 항상 더 나은 선택입니다.) -
분기: 대화로 모든 질문을 해결할 수 있습니까? 질문에 실행 가능한 답변(상태, 비즈니스 로직, 직접 봐야 하는 UI)이 필요한 경우, 프로토타입을 통해 우회하고 양방향으로 **
/handoff**로 연결하십시오 (프로토타입은 자체 디렉토리에 있으며, 이것이 바로/handoff의 용도입니다. 단계 경계 참조):/handoff아웃시켜 해당 파일에 대해 새 세션을 열고,/prototype으로 일회성 코드로 질문에 답한 후,/handoff백으로 배운 내용을 반영하고 원래 아이디어 스레드에서 참조합니다.
-
분기: 여러 세션에 걸친 빌드입니까?
- 예 →
/to-spec(스레드를 스펙으로 전환), 그런 다음/to-tickets로 이를 추적자-탄환 티켓으로 분할하고 각 티켓은 블로킹 엣지를 선언합니다. 그런 다음 티켓을 다음 두 가지 방법 중 하나로 작업합니다:- 티켓당
/implement를 수행하고, 각 티켓 사이에/clear로 컨텍스트를 정리합니다. 로컬 트래커에서는.scratch/<feature>/issues/아래에 티켓당 하나의 파일로, 블로커 먼저 수동으로 작업합니다; 실제 트래커에서는 엣지가 네이티브 블로킹 링크가 되므로, 블로커가 완료된 티켓은 잡을 수 있습니다. 각 티켓은 독립적이므로 마지막 티켓의 컨텍스트는 폐기 가능합니다. - 전체 스펙을 한 번에 실행하는
/implement-spec을 사용합니다. 티켓을 작업 그래프로 읽고, 준비된 프론티어에서 구현자 서브 에이전트를 병렬로 실행하며 모든 것을 하나의 통합 브랜치에 안착시킵니다. 각 티켓을 직접 구동하기보다 빌드를 조율하고 싶을 때 사용하십시오.
- 티켓당
- 아니오 → 바로 여기, 동일한 컨텍스트 윈도우에서
/implement를 실행합니다.
어느 쪽이든, 코드는
/tdd(한 번에 하나의 레드-그린 슬라이스)를 구동하여 빌드되고/code-review로 마무리되며, diff에 대한 2축 검토(표준 + 스펙)를 수행합니다./implement는 티켓당 두 가지를 모두 실행합니다;/implement-spec의 구현자는 각각/tdd를 구동하고 통합 브랜치에 대해 한 번의/code-review를 실행합니다. 전체 스펙 없이 테스트 우선으로 특정 동작을 빌드하고 싶다면/tdd를 단독으로, 고정된 지점에 대해 브랜치나 PR을 검토하고 싶다면/code-review를 단독으로 사용하십시오.작업이 풀 리퀘스트로 올라가면
/pr이 본문을 구성합니다: 변경 사항을 보여주는 가장 작은 시각 자료, 작동을 증명하는 전/후 증거, 단방향 또는 양방향 결정 호출입니다. 모델이 호출하므로 에이전트가 PR을 작성할 때마다 이를 사용합니다. - 예 →
-
/retro는 루프를 닫습니다. 빌드 후, 특히 잘못된 방향으로 갔던 빌드 후에 세션을 되돌아보고 코드가 아닌 에이전트의 환경에 대한 변경 사항(탐색 포인터, 자동화된 검사,/code-review가 적용하는 코딩 표준, 스티어링 파일, 도구)을 제안합니다. 기계적 실수는 결정론적 검사가 되고; 판단 호출은 코딩 표준이 됩니다. 다음 빌드는 더 나은 환경에서 시작됩니다.
컨텍스트 위생
1~3단계를 중단되지 않은 하나의 컨텍스트 윈도우에 유지하십시오 (/to-tickets 이후까지 압축하거나 정리하지 마십시오). 그래야 그릴링, 스펙, 티켓이 모두 동일한 사고를 바탕으로 구축됩니다. 각 /implement는 티켓에서 작업하여 새로 시작합니다. /retro는 되돌아보는 세션에서, 정리하기 전에 실행하십시오; 정리한 후에는 대신 해당 세션의 로그를 가리키십시오.
이에 대한 한계는 스마트 존 입니다: 모델이 여전히 날카롭게 추론하는 윈도우(최신 모델의 경우 ~150k 토큰)입니다. 세션이 /to-tickets 전에 이에 도달하면, 저하된 상태에서 밀어붙이지 말고 가장 가까운 단계 경계에서 /compact 를 실행하고 계속 진행하십시오 (단계 경계 참조).
온-램프
작업을 생성한 후 메인 플로우로 합류하는 시작 상황입니다.
-
버그 및 요청이 쌓이고 있음 →
/triage. 트라이지 역할을 통해 이슈를 이동시키고 에이전트가 처리할 수 있는 이슈를 생성하며, 이후/implement가 이를 처리합니다.트라이지는 사용자가 생성하지 않은 이슈(버그 신고, 들어오는 기능 요청, 원시 형태로 도착하는 모든 것)에만 해당됩니다.
/to-tickets이 생성한 티켓은 이미 에이전트가 처리할 수 있으므로 트라이지하지 마십시오. -
무언가 고장 났음 →
/diagnosing-bugs. 까다로운 버그용: 한눈에 저항하는 버그, 간헐적인 불안정, 두 개의 알려진 정상 상태 사이에 스며든 회귀. 빠른 피드백 루프(이 버그에 대해 이미 레드가 되는 하나의 명령)를 가질 때까지 이론화를 거부한 다음, 회귀 테스트와 함께 수정합니다. 수정이 완료되면 동일한 세션에서/retro를 실행하여 무엇이 버그를 방지했을지 질문하십시오; 실제 발견이 버그를 잠글 좋은 지점이 없다는 것이라면, 그것은/improve-codebase-architecture의 작업입니다. -
거대하고 안개 낀 노력: 그린필드 프로젝트 또는 하나의 세션에 너무 큰 대규모 기능 빌드 →
/wayfinder, 여기서 가장 인지적으로 까다로운 플로우입니다. 현재 위치에서 목적지까지의 길이 아직 보이지 않을 때, 이슈 트래커에 결정 티켓의 공유 맵을 그리고 안개가 밀려나고 길이 명확해질 때까지 하나씩 해결하여 산출물이 아닌 결정을 생성합니다./grill-with-docs가 하나의 세션에 담을 수 있는 아이디어를 다듬는 반면, wayfinder는 담을 수 없는 아이디어를 위한 것이며 더 느리고 밀도가 높으므로, 정확히 그 경우에만 사용하고 잘 정의된 기능에는 절대 사용하지 마십시오.맵이 명확해지면 빌드하지 않고 핸드오프합니다: 메인 플로우의
/to-spec에 합류하십시오. 이는 맵의 연결된 결정을 실행 가능한 계획으로 축소한 다음, 평소처럼/to-tickets및/implement로 진행합니다. 맵을 바로/implement로 연결하면 해당 축소를 건너뛰고 연결된 세부 사항을 버리므로, 노력이 진정으로 작은 것으로 판명된 경우에만/implement로 바로 가십시오.
코드베이스 건강
기능 작업이 아닌 유지 관리입니다.
/improve-codebase-architecture는 에이전트가 작동하기 좋은 코드베이스를 유지하기 위해 여유 시간이 있을 때마다 실행합니다. 심화 기회를 표면화합니다. 하나를 선택하면 메인 플로우의/grill-with-docs에서 가져갈 수 있는 _아이디어를 생성_합니다. 후보자를 찾는 조사이며;/codebase-design(아래)은 선택한 대상을 설계하는 벤치입니다.
아래에 있는 용어
다른 스킬 아래에서 실행되는 두 개의 모델 호출 참조이며, 각각 해당 용어의 단일 진실 공급원입니다. 단어가 문제일 때 직접 사용하십시오; 또는 위의 스킬이 이를 가져오도록 두십시오.
/domain-modeling: 프로젝트의 도메인 언어를 다듬습니다: 모호한 용어에 이의를 제기하고, 과부하된 단어를 해결하며(