본문으로 건너뛰기
cccskills
무료GitHub에 공개

github-evidence-triage

Performs read-only GitHub issue or PR triage with evidence links. Use when analyzing public or repository GitHub issues/PRs without mutating labels, comments, branches, reviews, merges, or issue state.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

연동 도구GitHub
설치 방법 보기

포함된 파일(1)

  • SKILL.md4.4 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

GitHub Evidence Triage

Purpose

Use this skill to analyze a GitHub issue or pull request and produce a source-grounded triage report.

This skill is read-only. It does not comment, label, approve, reject, close, merge, push, or call write GitHub APIs.

When to Use

Use when the user asks to:

  • triage a GitHub issue or PR
  • determine whether a bug report is reproducible or already fixed
  • summarize PR risk before review
  • connect an issue/PR to repository files, commits, tests, or docs
  • produce evidence for a change package from GitHub context

Zero-Action Policy

Never:

  • comment on issues or PRs
  • close or reopen issues
  • edit labels, milestones, assignees, branches, or project boards
  • approve, request changes, or submit PR reviews
  • merge PRs
  • push branches
  • call write GitHub API methods

Allowed:

  • read issue/PR metadata and comments
  • inspect related code and tests
  • inspect git history
  • produce a triage report

Evidence Rule

Every factual claim about repository code, commits, issues, or PRs should include a stable reference:

  • issue or PR URL
  • commit SHA
  • file path and line range
  • copied command output from a fresh read-only command

No evidence means no claim. Mark unsupported claims as [UNVERIFIED].

🛑 Evidence availability fallbacks:

ConditionConservative fallback
Missing GitHub URL or repository/numberAsk for the URL or exact repo plus issue/PR number; do not infer from vague text.
Ambiguous issue vs PR referenceResolve read-only if possible; otherwise ask before triage.
Private repo, permission denied, or auth unavailableReport BLOCKED or PARTIAL with the inaccessible URL and continue only with user-provided/local evidence clearly marked.
Rate limit, network failure, deleted item, or unavailable APIRetry only if cheap and safe; otherwise report the failure and mark affected claims [UNVERIFIED].
Evidence conflicts across comments, commits, or filesSeparate claims by source and avoid a definitive conclusion until reconciled.

Output Placement

  • If the triage belongs to an existing OpenSpec change, write inside that change directory only when the user or current workflow requests a file.
  • For every non-OpenSpec source, including a single local source document, ask whether to write a source-adjacent file, create a sibling folder, append to an existing spec/design document, or keep the report chat-only.
  • Chat-only output is allowed.

Workflow

  1. Identify the issue/PR URL, repository, and user question.
  2. Fetch/read issue or PR metadata, description, comments, commits, and changed files as needed.
  3. Inspect linked code, tests, docs, and git history only as needed for the claim.
  4. Separate reporter claims, maintainer statements, observed repository facts, inferred risks, and unverified items.
  5. Synthesize impact and next step from the evidence; do not paste a chronological comment list unless chronology is the finding.
  6. Produce a triage report with no write actions.

Red flags: requests to comment, label, close, approve, request changes, merge, push, or mutate branch/issue state. Stop and confirm this skill is read-only instead of performing the action.

Synthesis Over Listing

  • Group evidence by claim: reproduction, scope, root-cause signal, affected files, test evidence, maintainer decision, and unresolved conflict.
  • When comments disagree, identify the source/date/commit behind each side and avoid a single winner until evidence resolves it.
  • Separate "what GitHub says" from "what local code shows" and from "what the triager infers".
  • Keep recommendations read-only unless ROSE or the user explicitly opens an implementation package.

Output Contract

STATUS: TRIAGED | PARTIAL | BLOCKED

SUBJECT:
- URL:
- Type: issue | PR
- User question:

EVIDENCE:
- URL / commit / file:line - fact

FINDINGS:
- <finding with evidence>

RISK / IMPACT:
- <risk with evidence or [UNVERIFIED]>

RECOMMENDED NEXT STEP:
- <read-only recommendation or bounded implementation/review suggestion>

UNVERIFIED:
- <claim that lacks evidence or N/A>

NO-ACTION CONFIRMATION:
- No comments, labels, reviews, merges, pushes, or write API calls were performed.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Review a single academic paper, preprint, DOI, arXiv link, or user-provided PDF/text with source-grounded critique. Use for paper summaries, methodology review, novelty checks, reproducibility concerns, or "review this paper" requests; do not use for multi-paper surveys, systematic literature reviews, citation management, or implementation from a paper.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Rosetears520/aili-workflows22026년 9월 27일 업데이트

AI regression scouting routing. Use when agents, prompts, skills, model/tool routing, harness fixtures, or generated-output expectations change and need regression scenarios; do not use for ordinary product-code regressions.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Rosetears520/aili-workflows22026년 9월 27일 업데이트

Run the AILI delivery lifecycle from natural-language IDEATE, DEFINE, BUILD, and SHIP intent or the equivalent slash shortcuts; use for idea shaping, spec/test definition, bounded BUILD package queues, review-repair closeout, or adapter routing without exposing internal stage commands.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Rosetears520/aili-workflows22026년 9월 27일 업데이트

Android native Kotlin/Compose app development, Material 3 UI, accessibility, and Gradle builds.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Rosetears520/aili-workflows22026년 9월 27일 업데이트

Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Rosetears520/aili-workflows22026년 9월 27일 업데이트

Route an explicitly requested independent/delegated browser QA assignment or durable E2E evidence need; do not trigger for direct Playwright/DOM/console/network inspection, ordinary UI implementation, backend-only work, or production-mutating flows.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Rosetears520/aili-workflows22026년 9월 27일 업데이트

Rosetears520의 스킬 모두 보기

이 스킬의 문제 신고