Menu
Use when creating, writing, or drafting a GitHub issue. Covers tone, conciseness, detail, scope, and audience-fit — not investigation or gh mechanics.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.