저장소 검사

검사 자동으로 작성하기

대시보드의 시작하기에서 저장소 검사 설정을 선택하세요. HeyDeer가 저장소와 지난 풀 리퀘스트를 읽은 뒤 검사를 추가하는 풀 리퀘스트를 엽니다. 크레딧은 사용하지 않습니다.

직접 쓰는 코딩 에이전트가 작성하게 하려면 이 프롬프트를 전달하세요.

Add HeyDeer repository checks to this repository following the guide below, and open a pull request with them. If it needs no new check, explain why instead.

# Write repository checks

A check is a Markdown file in `.agents/checks/` that states a requirement. Each check adds a reviewer of its own to every pull request that changes the files it covers, on top of a general review that already looks for common bugs and security issues. Add one only for a requirement that is specific to this codebase, costly to miss and easy to overlook.

1. Learn what the team cares about: the code, AGENTS.md or CLAUDE.md, REVIEW.md, the checks already in `.agents/checks/`, and as much of the merged pull requests and their review discussions as you need to see what reviewers keep asking for and where bugs were fixed.
2. Choose the requirements, usually one or two, leaving out what existing checks cover. Give each check one requirement or a few closely related ones, and keep one requirement in one check.
3. Write each check as `.agents/checks/<name>.md`, its name starting with a letter or digit and using only letters, digits, `.`, `_` and `-`, excluding every case variant of `README.md`:
   - Start with YAML frontmatter whose `files` lists glob patterns, relative to the repository root, for the files where the requirement can break. A pattern without a slash matches in any folder, a `!` prefix excludes, and the last matching pattern decides; exclusions need an including pattern. Compare the patterns with `git ls-files` so they match those files and little else. Add `skills` only to name repository skills the check needs.
     ```
     ---
     files:
       - "src/api/**/*.ts"
       - "!**/*.test.ts"
     ---
     ```
   - Below it, state the requirement as a condition on the code: what breaks it, what satisfies it and why it matters, with a short incorrect and correct example from this codebase. Most checks fit on a screen; a file can be up to 16000 bytes.
   - Write it in the language of the repository's own Markdown, such as its README and AGENTS.md, even when you write the pull request in another language.
4. In the pull request, say what each check covers and why it is worth a reviewer. Link the discussions that led to a check when there are any.

검사 추가하기

1. .agents/checks/에 api-workspace-scope.md 같은 Markdown 파일을 만드세요.
2. 파일은 프런트매터로 시작하고, 검사 대상 파일을 files 아래에 나열하세요.
3. 프런트매터 아래에 요구 사항을 작성하세요. 무엇이 요구 사항을 어기는지, 무엇이 충족하는지, 왜 중요한지를 적습니다.
4. 풀 리퀘스트로 커밋하세요. HeyDeer는 풀 리퀘스트에서 검사를 읽으므로, 새 검사는 그 풀 리퀘스트 자체의 검토에도 적용됩니다. 풀 리퀘스트가 바꿀 수 있는 것을 참고하세요.

.agents/checks/api-workspace-scope.md

---
files:
  - "src/api/**/*.ts"
  - "!**/*.test.ts"
---
# API handlers scope queries to the caller's workspace

Every query in an API handler that reads or writes a table with a
`workspace_id` column must filter on the workspace returned by
`requireWorkspace()`. Without that filter, one customer can read
or change another customer's data.

Fail when a handler queries such a table without that filter.
Pass when every such query filters on the workspace, or when the
handler only touches tables without a `workspace_id` column.

Incorrect:

```ts
const invoice = await db.query.invoices.findFirst({
  where: eq(invoices.id, id),
});
```

Correct:

```ts
const { workspaceId } = await requireWorkspace(req);
const invoice = await db.query.invoices.findFirst({
  where: and(eq(invoices.id, id), eq(invoices.workspaceId, workspaceId)),
});
```

• 폴더 바로 아래에 있고 프런트매터에 files가 있는 .md 파일이 각각 하나의 검사입니다. HeyDeer는 README.md나 다른 검토 도구용으로 작성된 검사 등 폴더의 다른 파일은 무시합니다.
• 파일 이름은 문자나 숫자로 시작해야 하며 문자, 숫자, ., _, -만 사용할 수 있습니다.

효과적인 검사 작성하기

해당하는 검사마다 전용 검토자가 붙으므로 검사는 철저하지만 크레딧을 더 사용합니다. 검사는 놓치면 비용이 크고 간과하기 쉬운 요구 사항에만 쓰고, 나머지는 REVIEW.md나 AGENTS.md에 두세요.

• 코드베이스에 고유한 내용을 쓰세요. 모든 검토에서 이미 흔한 버그와 보안 문제를 찾으므로, “쿼리는 안전해야 한다” 같은 검사는 비용만 늘고 더 찾아내지 못합니다.
• 검사 하나에는 요구 사항 하나, 또는 밀접하게 관련된 몇 가지만 넣으세요. 관련 없는 요구 사항을 묶은 검사는 각각을 더 얕게 확인합니다.
• 요구 사항 하나를 여러 검사로 나누지 말고, files는 요구 사항이 깨질 수 있는 곳으로 한정해 필요한 곳에서만 검사가 실행되게 하세요.
• 요구 사항은 코드에 대한 조건으로 쓰세요. 무엇이 요구 사항을 깨고 무엇이 충족하는지, 왜 중요한지를 쓰면 HeyDeer가 예상하지 못한 경우도 판단할 수 있습니다. 코드베이스에서 가져온 짧은 잘못된 예와 올바른 예를 덧붙이세요.
• 좋은 검사는 대부분 한 화면에 들어갑니다. 여러 검사에 같은 배경 지식이 필요하다면 그 내용을 스킬로 옮기세요.
• 새 검사는 요구 사항을 어기는 풀 리퀘스트로 테스트하고, 발견 사항에 해당 검사의 이름이 표시되는지 확인하세요.

결과 표시 방식

코드가 검사를 어기면 HeyDeer는 GitHub와 HeyDeer에서 저장소 검사: 뒤에 검사 파일 이름을 표시한 발견 사항을 보고합니다. 발견 사항이 없는 검사는 검토에 아무것도 추가하지 않습니다.

이 발견 사항은 다른 발견 사항과 똑같이 HeyDeer Review 검사와 자동 승인에 반영됩니다. HeyDeer Review 검사의 요약에는 실패한 저장소 검사의 수도 표시됩니다.

HeyDeer가 검사를 완료하지 못하면 HeyDeer Review 검사가 “검토 미완료” 상태로 실패합니다. 검토를 다시 요청하세요.

프런트매터 참조

프런트매터는 두 --- 줄 사이에 작성하는 YAML이며, 아래 키를 사용합니다.

HeyDeer는 다른 검토 도구가 읽는 키 등 그 밖의 키는 무시합니다.

제외 패턴만 있는 경우처럼 검사가 유효하지 않으면 HeyDeer는 그 검사를 건너뛰고 검토 안내에 표시합니다. 검토는 계속 진행되지만 HeyDeer가 자동으로 승인하지는 않습니다.

검사 대상 파일

변경된 파일 중 하나 이상이 검사와 일치하면 검사가 적용되며, HeyDeer는 해당 파일에 집중해 검사를 수행합니다.

• 모든 변경 파일을 검사하려면 files: ["**"]를 사용하세요.
• 패턴은 저장소 루트 기준 상대 경로이며 *, **, {a,b}를 지원합니다. *.sql처럼 슬래시가 없는 패턴은 모든 폴더에서 일치합니다.
• 패턴은 순서대로 적용되며 파일과 마지막으로 일치하는 패턴이 결과를 결정합니다. 따라서 뒤쪽 패턴으로 앞선 제외 패턴이 제거한 파일을 다시 포함할 수 있습니다.
• 생성된 파일은 절대 일치하지 않습니다.

검사가 무시되는 것 같다면 문제 해결을 참고하세요.

제한

워크스페이스는 모든 저장소를 합쳐 30일 동안 검사 생성 작업을 최대 30개까지 시작할 수 있으며, 실패하거나 취소된 작업도 포함됩니다.

검사 파일은 최대 16,000바이트까지 작성할 수 있습니다.

한 번의 검토에서는 일치하는 검사를 파일 이름 순서로 최대 10개까지 실행합니다. 나머지는 HeyDeer가 검토 안내에 나열하고, HeyDeer Review 검사에는 “검토 미완료”가 표시되며, HeyDeer는 그 검토를 자동 승인하지 않습니다.

일치하는 검사가 줄어들도록 검사 범위를 좁히거나 검사를 합치세요. 먼저 실행할 검사를 정하려면 10-auth.md처럼 파일 이름 앞에 숫자를 붙이세요.

검사가 유효하지 않은 경우

프런트매터나 files 키가 없는 파일은 무시됩니다. 유효하지 않은 YAML, 크기 제한을 초과한 프런트매터, 빈 files 패턴, 제외 패턴만 있는 파일은 건너뛰고 보고합니다.

변경된 파일과 일치하는 검사에 대해 HeyDeer는 파일 이름, 파일 크기, 스킬 이름도 검증합니다. 유효하지 않은 검사는 건너뛰고 검토 안내에 표시합니다. 검토는 계속되지만 HeyDeer가 자동 승인하지는 않습니다.

풀 리퀘스트에서 검사를 수정한 다음 @heydeer review 댓글을 남기세요.