Slipdock 작업 관리

Slipdock 작업하기

보드는 계획의 기록입니다: 다음에 무엇을 할지, 그리고 발생한 기록이 저장되는 곳입니다. 서버는 자체 규칙을 문서화합니다. 세션당 한 번, 선택하거나 업데이트하기 전에 먼저 읽으십시오:

slipdock guide                    # markdown, GET /api/guide에서

이 시스템에 CLI가 없는 경우(일반적인 경우, CLI는 Elixir가 필요함):

B="${SLIPDOCK_URL:-$(cat ~/.config/slipdock/url 2>/dev/null)}"   # 둘 다 설정되지 않았으면 사용자에게 물어보세요
curl -s -H "Authorization: Bearer $SLIPDOCK_TOKEN" "$B/api/guide"

서버 주소는 $SLIPDOCK_URL에서 가져오고, 없으면 ~/.config/slipdock/url에서 가져옵니다(slipdock url 또는 서버의 /install.sh가 작성). 둘 다 없다면 사용자에게 Slipdock 주소를 물어보고 임의로 추측하지 마십시오. 호스팅된 보드는 https://app.slipdock.us와 같고, 자체 호스팅된 보드는 사용자가 접근하는 이름을 사용합니다.

토큰이 있다면 전달하십시오($SLIPDOCK_TOKEN, 없으면 ~/.config/slipdock/token). 가이드에는 토큰이 필요하지 않지만, 토큰이 있으면 가이드 끝에 사용자의 실제 보드, 모든 목록, 그리고 준비 목록, 백로그, 진행 중 및 완료된 작업 목록이 무엇인지 나와 있어 작업을 선택하는 데 정확히 필요한 정보를 제공합니다.

가이드가 이 파일보다 우선합니다. 가이드는 실행 중인 서버에서 제공되므로 최신 상태입니다. 엔드포인트, 용어, 보드 레이아웃은 요청 시 생성됩니다. 이 파일은 가이드를 가져오라는 지시와, 가이드가 없을 때 해야 할 일만 알려줍니다.

아무도 이름을 대지 못하는 것을 찾기

slipdock cards <board> --search Q는 문자열로 보드 하나를 필터링합니다. 다른 필터는 단어 대신 상태를 묻고, "무엇을 선택해야 할까"에 답합니다: --deps ready는 미완료 카드에 의존하는 것을 제외하고, --no-assignee는 다른 사람의 작업을 제외하며, --due overdue는 기한이 지난 것입니다. 따라서 적격 목록은 한 번의 호출로 얻을 수 있습니다:

slipdock cards <board> --column "To Do" --open --deps ready --no-assignee

slipdock search <words...>는 다릅니다: 의미로 일치하며, 사용자가 볼 수 있는 모든 보드를 대상으로 하고, 카드뿐만 아니라 댓글과 상태 업데이트도 포함합니다. 사용자가 작업의 이름을 대지 않고 설명할 때("환불 반올림 문제에 대한 카드"), 원하는 것이 제목보다 댓글에 있을 때, 또는 어느 보드를 봐야 할지 모를 때 사용하십시오. 출력된 일치 청크를 읽은 다음, 카드를 건드리기 전에 slipdock card <id>로 전체 카드를 확인하십시오.

확장될 짧은 버전

• 에픽과 하위 카드. 최상위 카드는 에픽입니다: 결과물이며, 우선순위, 날짜, 토론을 담습니다. 작업은 하위 카드에 있으며, 각각 하나의 작업 단위입니다. 체크리스트 항목은 작업 내의 단계입니다. 발견한 새 작업은 에픽 아래에 하위 카드로 추가합니다(새 최상위 카드가 아님).
• 선택. 이미 진행 중인 작업을 완료하십시오; 그 다음 준비 목록(To Do), 그리고 거기에 적격한 작업이 없을 때만 백로그를 봅니다. 가장 높은 우선순위부터, 목록 내 위치로 동점을 해결합니다. 완료, 보관, 차단, 대기, 스누즈, 또는 다른 사람에게 할당된 것은 건너뛰십시오. --open --deps ready --no-assignee는 대부분의 건너뛰기를 처리합니다(스누즈된 카드는 slipdock cards에서 이미 제외됨). 또한 대체 카드(↪stand-in-for:#N)도 건너뜁니다: 이는 카드가 스프린트에 들어간 위치만 표시합니다. 보드가 PAUSED(JSON에서는 paused)로 응답하면, 사람이 그에 대한 러너 작업을 보류한 것입니다: 아무것도 선택하지 말고 중지하십시오. 선택한 카드에 하위 카드가 있으면, 그 안으로 내려가서 모든 하위 카드를 완료한 후 다음 최상위 카드를 위해 올라오십시오.
• 진행하면서 업데이트. 시작할 때 카드를 진행 중으로 이동하고 자신에게 할당하십시오; 모든 결정, 놀라운 일, 막다른 길에 댓글을 남기십시오; 플래그를 지정하십시오(blocked, review), 무엇을 기다리는지 설명하는 댓글과 함께; 사람만이 필요한 것을 제공할 수 있을 때, 대기를 열고 중지하십시오(slipdock wait <id> "필요한 것" [--on EMAIL] [--choice X]... 또는 update_card wait; 여러 질문은 --question Q --question Q / questions로, 각각 하나씩, 절대 하나의 블록으로 하지 마십시오): 카드에 waiting 플래그가 지정되고, 답변(slipdock answer)하면 작업이 다시 시작됩니다 — 또는 기다리는 것에 날짜가 있으면 대신 스누즈하십시오(slipdock snooze <id> <date> --note "…"): 목록에서 제거되었다가 해당 날짜에 목록 맨 위로 돌아옵니다; 완료 시 completed: true를 설정하고 그리고 완료 목록으로 이동하십시오. 모든 하위 카드가 완료된 것으로 롤업에 표시될 때만 에픽을 완료하십시오.
• 입증된 작업, 보드에 이 기능이 있는 경우(가이드에 verified work: …라고 표시됨). 작업을 시작하기 전에 카드의 기준을 작성하십시오(slipdock edit <id> --bar "…"). 작업이 시작되면 절대 변경하지 마십시오. 확인한 내용으로 완료하십시오(slipdock done <id> --evidence-commit <sha> --tests a,b --suite passed:38:0 --evidence "…"). 두 번째 에이전트가 검증하는 보드에서는 done이 카드를 제출하고 보류 상태로 둡니다: 직접 Done으로 이동하지 마십시오. 거부된 카드는 댓글에 이유, 작업의 프롬프트 및 get_card의 rejection과 함께 반환됩니다(핸드오프에 Rework: …라고 표시됨): 이유를 먼저 읽으십시오. 다음 작업 지침이기 때문입니다. 다른 사람의 카드를 검증하는 것은(자신의 것은 절대 안 됨) 깨끗한 트리에서 증거의 커밋을 체크아웃하고, 스위트를 실행하고(풀 리퀘스트 보드에서는 해당 커밋에서 CI 통과를 확인), 기준과 비교하여 판단한 다음, slipdock accept <id> 또는 slipdock reject <id> --reason "…"를 수행하는 것을 의미합니다. 풀 리퀘스트로 출시하는 보드(보드의 라인, 그리고 클레임된 작업의 프롬프트와 slipdock card에 명시됨)에서는 기본 브랜치를 푸시하지 마십시오: card-<id>에 커밋하고, 푸시하고, 풀 리퀘스트를 한 번 엽니다(gh pr create --head card-<id> --title "<title> (#<id>)" --fill; 거부된 카드의 다음 시도는 같은 브랜치를 푸시합니다). 체크를 확인하고(전체 테스트 실행: 푸시 전에는 추가하거나 변경한 테스트만 실행), slipdock done <id> --pr <url>로 완료합니다. 카드를 수락하면 병합됩니다; 직접 병합하지 마십시오. 병합 실패는 카드를 이유와 함께 거부된 상태로 되돌립니다: 브랜치를 리베이스하고 다시 제출하십시오.
• 레인, 이 기능이 있는 경우(보드 가이드에 lanes: on이라고 표시됨). 카드를 시작하기 전에 작업이 영향을 미칠 경로를 작성하십시오: slipdock edit <id> --paths "lib/foo/**,docs/manual.md", 작업 지침이 허용하는 한 좁게. 진행 중인 카드와 겹쳐서 이동이 거부되면 해당 카드가 명명됩니다: 경로를 좁히거나, 해당 카드에 의해 차단된 상태로 두십시오; 레인을 재정의할 수 있는 것은 사람뿐입니다. 푸시 보드에서 검증 대기 중인 카드는 레인과 종속 항목을 해제합니다; 풀 리퀘스트 보드에서는 병합까지 둘 다 유지합니다. 보드에 레인이 있든 없든, 경로가 있는 카드에서는 이름으로 해당 파일만 스테이징하고, 동일한 리포지토리에서 다른 세션이 활성화된 경우 자신의 git 워크트리에서 작업하십시오(git worktree add ../<repo>-lanes/card-<id> -b card-<id>). 단, 러너가 이미 워크트리에 넣은 경우는 예외입니다($SLIPDOCK_WORKTREE).
• 먼저 핸드오프를 읽고, 중간에 멈출 때는 남기십시오. 카드의 핸드오프(slipdock card <id> 상단의 Left off:; JSON의 handoff)는 마지막으로 작업한 사람이 남긴 곳입니다: 다음 한 단계와 짧은 메모입니다. 카드를 선택할 때 댓글보다 먼저 읽으십시오. 카드를 미완료로 멈출 때마다(세션 종료, 반환, 차단, 시간 초과) 핸드오프를 남기십시오: slipdock handoff <id> --next "<다음 한 단계>" --body "상태: … 주의사항: … 미해결: … 참고: …" (MCP를 통해서는 leave_handoff). 이전 핸드오프를 대체하며, 이력은 보관됩니다. 댓글은 로그를 유지하고, 핸드오프는 현재 상태입니다. 완료된 카드의 핸드오프는 사람을 위한 것입니다: 그들이 해야 할 일, 확인하거나 알아야 할 사항(배포, 재설치, 질문, 주의사항)을 --next로, 몇 가지 불릿 포인트로 상황을 설명합니다. 그들을 위해 남길 것이 없으면 비워 두고, 이전에 남긴 핸드오프는 slipdock handoff <id> --clear로 지우십시오.
• 푸시하기 전에 카드를 다시 읽고, 푸시 후에는 댓글을 다시 읽으십시오. 작업이 완료되면 slipdock card <id>를 다시 실행하십시오: 변경된 설명 또는 클레임보다 최신인 댓글이 있는 경우에도 이 카드입니다 — 커밋하기 전에 하십시오. 빌드가 시작되면 댓글을 한 번 더 읽어 중간에 추가된 내용이 있는지 확인하십시오.
• 인시던트 및 배포. 보드가 배포를 기록하는 경우(slipdock dora <board>가 배송 메트릭이 꺼져 있다고 말하는 대신 응답함), 중단이나 손상된 릴리스는 incident 태그가 붙은 일반 카드입니다; 원인이 된 배포를 알고 있다면 slipdock incident-of <card> <deploy-id>. 다른 카드와 마찬가지로 수정 커밋에 카드 이름을 넣으십시오(#57): 이것이 배포가 수정으로 계산되고 카드가 Shipped 라인을 얻는 방법입니다. 배포를 수동으로 기록하거나 완료하지 마십시오 — 그것은 CI의 작업이며, 자체 토큰이 있습니다.
• 정리 제안은 사람이 결정할 사항입니다. slipdock garden <board>(MCP를 통해서는 garden)는 보드의 가드너가 찾은 항목을 나열합니다: 완료되었지만 열려 있는 에픽, 진행 중인 카드, 중복, 고립된 페이지. 정리하라는 요청을 받으면 표시하고, 사람이 승인한 것만 적용하십시오(slipdock garden apply <id>, garden_decide); 무인 작업에서는 절대 적용하거나 기각하지 마십시오 — 기각은 기억됩니다.
• 장기 작업은 중간 업데이트를 받습니다. 작업이 짧은 시간 이상 걸릴 경우, 실행 중인 동안 각 마일스톤에 댓글을 남기십시오 — 완료된 것, 남은 것, 계획을 변경한 모든 것 — 그리고 percent_complete를 함께 업데이트하십시오. 마지막에 한 번에 작성하는 것은 너무 늦습니다: 진행 중인 카드에 이동 이후 새로운 내용이 없으면 버려진 것으로 읽힙니다. 여러 번의 작업에 걸쳐 실행되는 에픽도 동일한 처리를 받습니다. 각 하위 카드가 닫힐 때 한 줄씩 추가합니다.
• 댓글은 마크다운이며, 훑어 읽힙니다. 굵은 줄로 내용을 시작하고(**선택됨.**, 빌드됨., 결정: …), 짧은 불릿 포인트로, 각각 하나의 사실, 경로, 명령 및 커밋 ID는 백틱으로 묶습니다. 절대 하나의 조밀한 단락으로 작성하지 마십시오. 한 줄 이상은 slipdock comment --body - <<'EOF'…EOF`로 보내십시오(따옴표 처리되어 백틱이 보존됨); 명령줄의 단어는 줄 바꿈이 손실됩니다.
• 커밋하고 연결하십시오. 프로젝트가 git 리포지토리인 경우, 카드의 작업을 완료한 후 카드를 닫기 전에 카드 ID(#42)를 커밋 메시지에 포함하여 커밋하십시오. 마감 댓글은 커밋 링크를 포함하거나, PR이 열린 경우 PR 링크를 포함합니다(Commit: https://github.com/…/commit/abc1234). 연결할 원격이 없으면 짧은 해시와 브랜치를 대신 제공하십시오.
• 작성 시 토큰 비용. 카드의 마감 댓글은 작업에 사용된 토큰을 나타내는 줄로 끝납니다. 예: Token cost: ~135k tokens (context budget 15.00M → 14.86M, claim to close). 카드를 클레임할 때와 닫을 때 남은 토큰 카운터(시스템 메시지의 total_tokens left)를 읽고 차이를 제공하십시오. 여러 카드를 연속으로 작업한 경우, 각각의 클레임에서 측정하십시오. 카운터가 보이지 않으면 "Token cost: not measured"라고 말하고 추정하지 마십시오. 에픽의 진행 댓글에도 같은 수치를 추가하십시오.
• 먼저 즐겨찾기를 읽으십시오. slipdock favourites는 이 사람이 표시한 보드, 목록, 카드 및 저장된 보기를 나열합니다 — 그들이 실제로 작업하는 곳이며, 보드 목록만으로는 알 수 없습니다. 보드 이름 없이 "다음에 무엇을 작업해야 할까요?"라고 물으면 즐겨찾기가 가장 강력한 힌트입니다. 이것은 개인적인 것입니다: 요청하지 않으면 추가하거나 제거하지 마십시오.
• 보관된 보드는 제쳐둔 작업입니다. slipdock boards는 의도적으로 제외합니다; --all은 archived 상태와 함께 표시합니다. 보관된 보드의 모든 것은 읽고 쓸 수 있지만, 묻지 않고 보관된 보드에서 작업을 선택하지 말고, 새 작업을 거기에 넣지 마십시오.
• 카드가 담을 수 없는 것을 기록하십시오. 보드는 수행 중인 작업을 말합니다; 그것은 작동 방식, 결정된 사항과 이유, 또는 사물의 형태를 담기에 적합하지 않습니다. 이러한 것들은 보드의 위키에 넣으십시오 — slipdock page ls <board>, slipdock page read <page>, slipdock page new <board> <title...>. 테스트는 이 카드가 닫힌 후에 다시 읽힐지 여부입니다: 결정, 런북, 스펙 또는 조사 결과는 다시 읽힐 것이며 페이지에 속합니다(카드의 마감 댓글에서 코드 W-31로 링크됨); 진행 상황, 차단 요소 및 지금 발생한 것은 카드 댓글에 속합니다. 절대 둘 다 하지 마십시오 — 댓글을 반복하는 페이지는 아무도 신뢰하지 않는 페이지입니다. 페이지를 작성하기 전에 검색하십시오(slipdock page ls <board> --q <내용>): 기존 페이지를 확장하는 것이 배포에 대한 네 번째 페이지보다 낫습니다. 모든 편집에 --message를 전달하고, 직접 작성하지 않은 페이지의 모든 편집에는 --base-hash를 전달하여 저장이 다른 사람의 작업 위에 조용히 덮어쓰는 일이 없도록 하십시오.
• 제목을 짧게 유지하십시오. 카드 제목은 최대 약 60자이며, 시리즈는 <Series> <n>: <what> 형식입니다(Agent supervision 5: Parked jobs). 세부 사항은 설명에 넣으십시오. 카드 제목은 폴더가 되고 좁은 목록에 표시되며, 처음 40자를 공유하는 일련의 카드는 구분할 수 없습니다.
• 하지 마십시오: 카드를 삭제(대신 보관), 실제로 한 일과 일치하도록 제목을 다시 쓰기, 다른 사람의 카드 정리, 또는 진행 중인 카드에 이동 이후 새로운 댓글 없이 두기. 전체 보드를 보관하거나 재정렬하는 것은 더욱 벗어난 일입니다: 명시적인 요청이 있을 때만, 보드 이름을 대고 하십시오.

적용 시기

• "다음에 무엇을 작업해야 할까?", "계획을 계속 진행", "백로그 작업", "다음 작업" → 가이드를 가져온 다음, 규칙에 따라 선택하고 어떤 카드를 왜 선택했는지 말하십시오.
• "이 계획을 보드에 넣어", "이것을 작업으로 나누어" → 가이드 형태에 따라 하위 카드가 있는 에픽.
• 이미 보드에서 가져온 작업을 수행 중인 경우 → 진행 상황, 결정 및 차단 요소가 발생할 때 카드에 기록하며, 마지막에 한꺼번에 덤프하지 마십시오.
• 보드에서 가져온 작업을 완료한 경우 → 완료했다고 보고하기 전에 보드에서 마감 처리하십시오.

참고: 이 파일은 전체 내용을 포함하지 않을 수 있습니다. 최신 규칙은 항상 서버 가이드를 참조하십시오.