메뉴
Use when creating, writing, or drafting a GitHub issue. Covers tone, conciseness, detail, scope, and audience-fit — not investigation or gh mechanics.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when opening a PR and driving it to green CI — push the branch, write a high-level PR description, watch checks, fix failures, and keep looping until green; also use when an already-open PR gets new commits.
Use when the user starts, resumes, switches, saves, or recalls a named task or ongoing work across sessions (e.g. "remember this", "continue X", "what was I doing on Y", "track this task").
Git commit workflow. Load when finishing any code-change task (after verification) to commit and push, or when explicitly staging/committing.
Use when modifying or adding a transform, loss, model, method, package, task-model, config, docs page, or example in a Lightly AG repo (lightly-ssl or lightly-train) and you need repo-specific conventions.
Spawn a subagent to run a task. Use when you want to delegate work to a separate pi instance.
Use when configuring or replicating LT-DETR v2 (ltdetrv2-s/m/l/x) COCO benchmarks via the lightly-train wrapper — model alias map, global vs per-rank batch size, recipe invariants, ECDet config mapping, cluster pins, and common gotchas.
| name | issue-authoring |
| description | Use when creating, writing, or drafting a GitHub issue. Covers tone, conciseness, detail, scope, and audience-fit — not investigation or gh mechanics. |
Guidelines for writing a good GitHub issue. Assumes investigation is done
(use codebase-exploration / gh-cli for that) and mechanics are handled
(gh-cli covers gh issue create --body-file).
Sound human. Write prose with voice, not stacked headers of corporate hedging. Read it aloud — if it sounds bot-generated, rewrite. "We've decided to remove the integration" beats "This issue proposes the removal of...".
Concise and decisive. State what matters; cut the rest. Don't over-cite or over-justify — one telling detail beats a table of every supporting fact. If a reader needs the full evidence, link it; don't reproduce it.
Match detail to purpose. A chore wants action (checklist). A discussion or spike wants findings. Don't dump investigation output into a task that wants a handoff — and don't force a checklist onto an open question.
Be scope-honest. If something looks in-scope but belongs elsewhere, say
so and defer it with a link. Scope creep turns a good first issue into a
trap for the contributor who picks it up.
State the audience before writing — it sets tone, assumed context, detail, and labels. Match the row; let it steer the draft.
| Audience | Tone | Detail | Labels |
|---|---|---|---|
| Contributor pickup | Direct, actionable; assume less context | Task as checklist; flag maintainer-only steps; defer out-of-scope with links | help wanted, good first issue (only if truly scoped & trap-free) |
| Maintainer sync | Terse; assume shared context | Just the decision/change; skip background | usually none |
| Bug triage | Neutral, reproducible | Description + repro + expected/actual + env | bug |
| Discussion / spike | Open, exploratory | Findings + open questions; no forced checklist | enhancement / feature request |
good first issue only if genuinely scoped and trap-free.