rizqirizqi/astroidal

astroidal은(는) 무엇을 하나요?

Astroidal은 AI 코드 리뷰 맵, 스코어러, 도우미입니다. 블래스트 반경을 그리고, 증명할 수 있는 항목에 점수를 매깁니다. 변경 사항을 매핑하고, 실제 버그를 검색한 후, 발견된 사항을 평가합니다. 차트와 테이블은 파일로 저장됩니다. 채팅 응답은 사람이 붙여넣을 수 있는 짧은 산문 요약입니다.

버그 카탈로그는 이 파일과 같은 디렉토리에 있는 references/review-lenses.md입니다. 발견 사항을 판단하기 전에 먼저 읽으십시오. 이 파일은 .astroidal/ 디렉토리에 있지 않습니다.

Astroidal을 의존성으로 추가하지 마십시오. package.json, 잠금 파일, pyproject.toml, go.mod 또는 Cargo.toml을 편집하여 설치하지 마십시오.

실행하기

다음 순서대로 명령어를 확인하십시오:

1. PATH에 이미 astroidal이 있는 경우 astroidal
2. npx --yes astroidal

패키지 이름을 다운로드할 수 없고, 사용자가 로컬 체크아웃을 가리킨 경우 npx --yes <path-to-the-astroidal-package> 또는 node <path>/dist/cli.js를 실행하십시오.

저장소당 한 번 스킬을 설치합니다:

npx --yes astroidal init

--global 플래그를 전달하면 이 머신의 모든 저장소에 대해 한 번만 설치합니다:

npx --yes astroidal init --global

글로벌 설치는 최신 Astroidal이 graph 또는 rank를 실행할 때 해당 스킬 파일이 Astroidal이 작성한 파일과 동일하다면 업데이트됩니다. 편집된 스킬은 init --force를 실행할 때까지 유지됩니다. init을 다시 실행하여 프로젝트 설치를 새로 고치십시오.

범위 선택

graph를 한 번 실행하십시오. 출력되는 범위 참고 사항을 읽으십시오. 해당 범위가 잘못된 경우 아래 플래그를 사용하여 한 번만 다시 실행하십시오. 그 이후에는 다시 실행하지 마십시오.

요청	명령어
현재 편집 내용 (추적되지 않은 파일 포함)	npx --yes astroidal graph
작업 트리가 더티(dirty) 상태일 때, 이 브랜치 또는 해당 풀 리퀘스트	npx --yes astroidal graph --base <default-branch>
깨끗한 기능 브랜치	npx --yes astroidal graph
풀 리퀘스트 번호 또는 URL	npx --yes astroidal graph --pr 12,18,24
모든 열린 풀 리퀘스트	npx --yes astroidal graph --open
작성자, 레이블 또는 베이스별 열린 풀 리퀘스트	npx --yes astroidal graph --open --author NAME --label NAME --base BRANCH
현재 풀 리퀘스트와 그 아래 스택	npx --yes astroidal graph --stack
하나의 커밋	npx --yes astroidal graph --commit SHA
스테이징된 변경 사항만	npx --yes astroidal graph --staged
언스테이징된 변경 사항 및 추적되지 않은 파일	npx --yes astroidal graph --unstaged

배치는 하나의 병합된 맵입니다. 풀 리퀘스트를 별도의 보고서로 검토하지 마십시오.

GitHub

이 리뷰에 여전히 필요한 항목이 있으면 gh를 호출하십시오. 맵은 이미 로컬 우선 읽기를 수행했으므로 동일한 파일을 다시 나열하거나, 이미 저장된 diff를 다시 가져오거나, 검사를 폴링하지 마십시오. 제목, 베이스 또는 본문이 누락된 경우 gh pr view와 같은 몇 가지 대상 호출은 괜찮습니다. gh를 스팸하지 말고, 풀 리퀘스트에 댓글을 달거나, 승인하거나, 리뷰어를 요청하지 마십시오.

GitLab

이 리뷰에 여전히 필요한 항목이 있으면 glab를 호출하십시오. 맵은 이미 로컬 우선 읽기를 수행했으므로 동일한 파일을 다시 나열하거나, 이미 저장된 diff를 다시 가져오거나, 파이프라인을 폴링하지 마십시오. 제목, 베이스 또는 본문이 누락된 경우 glab mr view와 같은 몇 가지 대상 호출은 괜찮습니다. glab를 스팸하지 말고, 병합 요청에 댓글을 달거나, 승인하거나, 리뷰어를 요청하지 마십시오.

버그 검색

다음 순서대로 읽으십시오:

1. .astroidal/packets/bug-map.md
2. .astroidal/packets/architecture.md
3. .astroidal/packets/security.md
4. .astroidal/packets/performance.md
5. .astroidal/packets/ux.md
6. .astroidal/packets/correctness.md
7. 이 스킬 옆에 있는 references/review-lenses.md

카탈로그의 게이트(gate), 스펙 패스(spec pass), 표준 패스(standards pass)를 적용하십시오. 그런 다음 Added lines에 있는 파일과 일치하는 각 언어 섹션을 적용하십시오. 다른 언어 섹션은 건너뛰십시오.

버그 맵에서 변경된 모든 경로를 다루십시오. Added lines 섹션부터 시작하십시오. 해당 섹션은 변경 사항이며, 풀 리퀘스트당 하나의 블록입니다. diff가 원격에서 가져온 경우 심볼 발췌문이 비어 있을 수 있으며, 스택에서는 팁만 포함됩니다. 발췌문이 비어 있다는 것은 변경 사항이 없다는 의미가 아니라 컨텍스트가 누락되었다는 의미입니다.

첫 번째 가능성이 있는 파일에서 멈추지 마십시오. Added lines의 모든 비-테스트 소스 블록에 대해:

• 블록 전체를 읽으십시오. 블록이 하위 라인이 증거 파일에 있다고 명시하는 경우 해당 하위 라인도 포함하십시오.
• 파일 이름과 일치하는 클래스뿐만 아니라 카탈로그를 기준으로 해당 블록을 확인하십시오. 아래 다섯 가지 클래스는 최소 기준입니다.
• 하나의 파일에 둘 이상의 풀 리퀘스트가 나열된 경우 각 블록을 검토하십시오. 매핑된 본문은 스택 팁만 해당합니다.
• 블록만으로 버그를 확인하거나 거부하기에 충분하지 않은 경우 파일을 여십시오.
• 각 변경된 심볼에 대해 맵이 나열하는 1-홉 호출자와 피호출자를 검사하십시오. 변경 사항이 이들을 손상시킬 수 있는 경우에만 검사하십시오.

특히 다음을 찾으십시오: 잘못된 분기, 거짓(falsy) 또는 빈 값을 누락된 것으로 처리, 오프바이원(off-by-one) 또는 시간대 불일치, 실패 후 재시도를 차단하는 잠금 또는 상태, 문자열 연결로 생성된 URL 또는 쿼리, 잘못된 ID를 사용하는 인가 검사, 1-홉 호출자가 여전히 이전 방식으로 사용하는 계약. 영향도가 높은 점수는 발견 사항이 아니며, 블록을 건너뛰는 핑계가 될 수 없습니다.

다음 모든 클래스를 검색하십시오:

• 로직 및 에지 케이스: 잘못된 분기, 오프바이원, 삼켜진 오류, 널 크래시
• 데이터 손실 및 상태: 마이그레이션, 경합 조건, 부분 쓰기, 오래된 캐시
• 깨진 계약: API, 타입, 라우트, 내보내진 동작, 스키마 불일치
• 보안 버그: 인가 갭, 인젝션, 시크릿, 안전하지 않은 신뢰 경계
• UX 흐름 버그: 막다른 골목, 누락된 오류/빈/로딩 상태, 깨진 탐색

중요한 문제를 찾으십시오. 패킷의 단서는 힌트일 뿐, 발견 사항이 아닙니다. 코드 냄새, 긴 파일, 누락된 테스트 또는 의존성 업데이트는 카탈로그의 게이트를 통과하는 경우에만 발견 사항입니다. 구체적인 실패를 명명하지 않는 포매팅, 네이밍, 주석, 칭찬, 질문 및 리팩터링은 무시하십시오.

발견 사항 작성

.astroidal/findings.json을 작성하십시오:

{
  "findings": [
    {
      "pr": 12,
      "severity": "high",
      "description": "무엇이 깨지는지, 한두 문장으로.",
      "path": "src/auth.ts",
      "line": 12,
      "quote": "파일에서 복사한 정확한 라인",
      "recommendation": "버그를 제거하는 구체적인 변경 사항.",
      "category": "security"
    }
  ]
}

severity는 카탈로그의 게이트를 사용하여 critical, high 또는 medium입니다.

• critical: 사용자가 접근하는 경로에서 발생하는 크래시, 데이터 손실, 인가 우회, 인젝션 또는 시크릿 노출.
• high: 현실적인 잘못된 결과, 손실된 쓰기, 경합 조건 또는 깨진 계약.
• medium: 실패하는 현실적인 에지 케이스. quote는 added-lines 블록, 매핑된 파일 또는 1-홉 이웃 파일에서 복사한 정확한 하나의 라인입니다. 해당 라인을 도입한 풀 리퀘스트로 pr을 설정하거나, 로컬 변경 사항인 경우 생략하십시오.

무엇이 깨지는지 말하고, 심볼 이름을 지정하고, 버그를 제거하는 변경 사항을 제시하십시오. 보안 및 아키텍처의 경우 해당 변경 사항이 유효한 이유를 설명하십시오. 애매하게 말하지 말고, 인용된 라인을 반복하지 말고, 질문을 제기하지 마십시오. 모든 비-테스트 소스 파일의 Added lines가 카탈로그에 대해 확인되었고 그중 어느 것도 중요한 버그를 포함하지 않는 경우에만 빈 findings 배열이 유효합니다.

변경된 파일들이 디렉토리가 이미 보여주지 않는 어떤 이유로 함께 속하는 경우, 해당 그룹의 이름을 지정하십시오. 차트는 디렉토리를 자체적으로 그리고, 임포트를 선으로 그립니다. 그룹은 이러한 디렉토리 경계를 넘나드는 흐름, 기능 또는 공유 계약을 위한 것입니다.

{
  "findings": [],
  "groups": [
    {
      "name": "결제 링크",
      "paths": ["apps/admin/lib/whatsapp.ts", "apps/admin/lib/proxied-link.ts"]
    }
  ]
}

짧은 이름과 최소 두 개의 매핑된 경로를 사용하십시오. 추가로 함께 속하는 것이 없으면 groups를 생략하십시오.

그런 다음 다음을 실행하십시오:

npx --yes astroidal rank

rank가 인용(quote) 또는 경로(path)가 잘못되어 발견 사항을 삭제하는 경우, 해당 발견 사항을 한 번 수정하고 다시 rank를 실행하십시오. 개수를 유지하기 위해 대체 버그를 만들어 내지 마십시오. 세 번째로 rank를 실행하지 마십시오.

응답

채팅에 짧은 산문 요약을 작성하십시오. 사람이 붙여넣을 수 있는 한 줄로 시작하십시오: Astroidal {점수} · 통과 또는 Astroidal {점수} · 먼저 수정. 그런 다음 가장 심각한 문제와 두 개의 출력 경로인 .astroidal/review.md 및 .astroidal/constellation.html을 명시하십시오. 발견 사항 테이블을 붙여넣지 마십시오. 차트를 다시 만들지 마십시오. 병합 여부는 여전히 사람이 결정합니다.