워크스페이스 엔지니어링은(는) 무엇을 하나요?
워크스페이스를 이를 사용하는 사람을 위한 제품으로 취급하세요. 하나의 좋은 결과를 얻는 프롬프트뿐만 아니라 유용한 작업을 반복 가능하게 만드는 프로세스를 엔지니어링하세요.
핵심 질문: 워크스페이스가 처리해야 하는데도 이 사람이 여전히 기억하거나, 수리하거나, 설명해야 하는 것은 무엇인가?
주 사용 사례는 에이전트와 함께 코드를 작성하는 것입니다. 현재 워크스페이스에서 누락된 것을 포함하여 개발 프로세스를 적극적으로 제안하세요. 기존 지침을 설명하는 데서 그치지 마세요. 비기술적인 역할의 경우, 동일한 피드백 및 수용 원칙을 해당 전달물에 적용하세요.
1. 작업 정의
사용자의 말에서 요청된 모드를 유추하세요:
- 검토: 현재 프로세스를 검사하고, 격차를 설명하며, 개선 사항을 권장합니다. 구현은 변경하지 않은 상태로 둡니다.
- 구축 또는 개선: 검증 및 사용 가능한 핸드오프를 포함하여 요청된 범위를 구현합니다. 구축 요청은 이미 일반적인 되돌릴 수 있는 구현을 승인한 것이므로, 계획-승인 절차를 추가하지 마세요.
존재하는 증거(리포지토리, 프로세스 문서 또는 사용자의 설명)부터 시작하세요. 프로세스 발견을 위해 리포지토리가 반드시 필요한 것은 아닙니다. 구현을 검사하거나 명령을 실행하기 전에 해당 리포지토리 지침을 읽으세요. 설정 스크립트를 실행하기 전에 검사하세요. 기존 작업을 보존하고 대상의 표준 스킬/지침 레이아웃을 따르세요.
주요 역할, 반복 작업, 허용 가능한 결과, 현재 어려움, 사람의 결정을 식별하세요. 인터뷰, 프로세스 문서 또는 명확하지 않은 소유권에 대해서는 발견을 사용하세요. 가능한 자료를 먼저 읽은 다음, 답변이 설계를 변경할 수 있는 질문만 하세요. 기다리는 동안 독립적으로 작업을 계속하고, 누락된 답변을 임의로 만들지 마세요.
2. 전체 작업 추적
대표적인 요청 하나를 선택하고 접수부터 실행, 검증, 핸드오프, 복구까지 추적하세요. 증거가 있다면 실패 또는 수정 사례를 포함하세요. 광범위한 검토의 경우, 하나의 샘플이 모든 것을 포함한다고 주장하지 말고 실질적으로 다른 각 워크플로우를 샘플링하세요.
사용자가 무엇을 하는지, 에이전트가 무엇을 하는지, 어떤 도구가 작동하는지, 어떤 상태가 저장되는지, 완료를 증명하는 것이 무엇인지 기록하세요. 의도된 관행을 구현 및 관찰된 동작과 비교하세요. 다음 증거 레이블을 명확히 구분하여 유지하세요:
- 문서화됨: 규칙 또는 프로세스에 따라 이런 일이 발생해야 합니다.
- 구현됨: 구체적인 메커니즘이 존재하고 경로에 연결되어 있습니다.
- 관찰됨: 실행이 명명된 리비전 또는 아티팩트에 대한 동작을 보여줍니다.
- 알 수 없음: 증거 또는 접근 권한이 누락되었습니다. 이것이 부재의 증거는 아닙니다.
경로를 검토하고 발견 사항의 우선순위를 지정하려면 검토를 사용하세요. 녹색 테스트는 테스트가 주장한 내용에 대한 증거이지, 테스트에 첨부된 모든 주장에 대한 증거는 아닙니다.
3. 개선 설계
검토 및 구축 모드 모두에서 베이스라인 프로세스를 읽으세요. 작업이 비기술적이지 않은 경우 소프트웨어 개발 기본값을 사용하고, 비기술적인 경우에는 적응 지침을 사용하세요. 혼합 워크스페이스의 경우 최종 사용자가 비기술적이더라도 코드와 도우미에는 코딩 베이스라인을 적용하세요.
제안된 프로세스를 구체적으로 만드세요: 트리거, 단계, 명령 또는 도구, 통과/실패 기준, 실패 대응, 소유자, 완료 증거. 각 해당 베이스라인 항목을 기존 메커니즘, 권장 변경, 명시적 예외 또는 알 수 없음에 매핑하세요. 중요한 편차를 설명하고, 리포지토리에 한 번도 없었다는 이유로 누락된 관행을 조용히 생략하지 마세요. 더 엄격한 기존 요구 사항은 보존하세요.
증상을 근본 원인별로 그룹화하세요. 에이전트가 기억해야 할 또 다른 경고를 추가하는 대신 공유 유틸리티, 더 나은 입력, 더 명확한 도구 계약 또는 더 짧은 절차를 선호하세요. 중복된 지침과 검사는 그 목적이 다른 곳에서 보존되는 경우에만 제거하세요.
각 제안된 변경에 대해 다음을 지정하세요:
| 필드 | 답변 |
|---|---|
| 사용자 문제 | 무엇이 느려지거나, 실패하거나, 반복적인 설명을 필요로 합니까? |
| 증거 | 어떤 파일, 프로세스 단계, 인시던트 또는 실행이 발견을 뒷받침합니까? |
| 변경 사항 | 워크스페이스가 무엇을 다르게 할 것입니까? |
| 배치 | 지식, 스킬, 규칙, 도구, 로컬 검사, 원격 게이트 또는 사람의 결정? |
| 증명 | 관련 실패 사례를 포함하여 변경 사항이 작동한다는 것을 어떻게 알 수 있습니까? |
| 트레이드오프 및 소유자 | 실행 및 유지 관리 비용은 얼마이며, 정책을 변경할 수 있는 사람은 누구입니까? |
사용자 영향, 반복 빈도, 신뢰도, 노력 및 피드백 지연을 기준으로 우선순위를 지정하세요. 점수나 상용구 더미가 아니라 먼저 수행할 가치가 있는 소수의 변경 사항을 제시하세요. 구체적인 예나 워크스페이스 레이아웃이 도움이 될 경우 패턴을 사용하세요.
4. 검토 또는 구현
검토의 경우, 현재 프로세스를 간략히 설명하고, 제안된 작업 프로세스, 증거가 포함된 우선순위 발견 사항, 다음 유용한 단계를 제공하세요. 강력한 기존 메커니즘을 보존하고 확인할 수 없었던 사항을 명시하세요. 프로세스 문서 전용 검토는 제안된 통제와 존재하는 것으로 알려진 통제를 구분해야 합니다.
구축 또는 개선의 경우, 구축을 사용하세요. 승인된 범위를 처음부터 끝까지 구현하세요. 사용자가 새 워크스페이스를 원하지만 역할이나 전달물이 아직 알려지지 않은 경우, 스택을 선택하기 전에 이를 해결하세요. 모든 프로세스 문제를 소프트웨어 프로젝트로 바꾸지 마세요.
5. 루프 종료
무엇이 변경되었거나 권장되었는지, 그것이 역할에 어떻게 도움이 되는지, 실제로 검증된 사항, 접근 권한이나 사람의 판단에 여전히 의존하는 사항을 보고하세요. 구현의 경우, 워크플로우를 시작하는 명확한 방법 하나와 해당 검사를 실행하는 방법 하나를 남겨두세요.
운영상의 한계를 명시적으로 유지하세요:
- 기준을 약화시키거나, 훅을 우회하거나, 누락된 증거를 수용하여 실패하는 검사를 통과하도록 만들지 마세요. 합법적인 정책 변경은 별도로 식별되고 해당 소유자에 의해 승인되어야 합니다.
- 이미 부여된 권한은 보존하세요. 로컬 빌드와 크레딧 사용, 게시 또는 라이브 시스템 변경을 구분하세요. 실제로 필요한 작업에서만 권한을 확인하세요.
- 자동 병합, 코드 리뷰 없음, 고정된 적용 범위 비율, 테스트 우선 개발 또는 특정 CI 시스템을 워크스페이스의 정의로 규정하지 마세요.
- 비밀 및 비공개 소스 세부 정보를 재사용 가능한 지침에 포함시키지 마세요. 소스 자료가 비공개인 경우 중립적인 예제와 함께 패턴을 추출하세요.