저는 코딩 에이전트에게 수정하도록 요청하는 순간까지 짧은 버그 보고서를 선호합니다.

"마크다운 링크가 깨져요(Markdown links are broken)\

PASS bug packet
PASS complete packet; rejected vague packet

테스트는 의도적으로 모호한 기록에서도 통과하며, 이것이 거부된다는 것을 확인합니다. 바로 이 부분이 CI(지속적 통합)에 필요한 부분입니다. 행복 경로(happy path)만을 보여주는 스키마는 아무도 신뢰할 수 없는 또 다른 보기 좋은 문서가 됩니다.

제가 에이전트에게 전달하는 방법

저의 작업 프롬프트는 패킷 자체가 사실을 담고 있기 때문에 짧습니다:

Read bug-packet.json. Reproduce only on the pinned revision.
Write a failing test for all acceptance behaviors before changing routing.
Do not broaden URL handling beyond the stated /workspace path.
...

여전히 인간이 범위를 소유합니다. 에이전트는 문제가 이미 원인을 증명한다고 가장하는 대신, 조사할 충분한 구조화된 컨텍스트를 얻습니다.

스크린샷, 피처 경로(fixture paths), 브라우저 버전, 접근성 기대치, 또는 롤백 조건 등으로 형식을 확장할 수 있습니다. 이들을 모든 이슈 댓글을 나열하는 것이 아니라 증거가 되는 필드로 유지하세요.

놀라운 교훈은 AI 준비가 된 이슈가 더 좋은 인간의 이슈라는 것입니다. 이는 사실과 추측을 분리하고, 이차적인 상호작용을 가시화하며, 검토자에게 실제 마감선을 제공합니다.

공지: 저는 MonkeyCode 프로젝트에 기여합니다. 위의 사례는 링크된 공개 이슈, 풀 리퀘스트(pull request), 그리고 커밋 c58bcd4의 저장소를 기반으로 하며; 독립적인 패킷 검증기는 로컬에서 테스트되었습니다.