메뉴
Required format for creating or editing any GitHub issue — [C<score>] title convention, complexity rationale line, complete-body rule, attribution footer. Load BEFORE creating or editing a GitHub issue.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when the user says "new issue", "create an issue", "file an issue", "/new-issue", or asks to turn a bug, idea, or discussion into a GitHub issue. Takes an optional description of what the issue should cover; with no input, derives the issue from what was discussed in the current conversation. Verifies claims against the code before filing and produces a complete, complexity-scored issue — never a stub.
Use when the user asks to validate, review, or check whether a GitHub issue is valid. Takes a GitHub issue URL or number (defaults to the latest open issue in the current repo). Verifies every factual claim against the actual code with file:line citations rather than trusting the author's description; for non-trivial proposals, also checks architectural feasibility and proposal self-consistency.
Use when the user asks to validate a GitHub issue with Fable 5, always plan it with Fable 5, and autonomously drive it to a reviewed PR in one shot — "fable-validate-fableplan-loop", "fable validate, fable plan, and work on
Use when the user asks to validate a GitHub issue with Fable 5 and then autonomously drive it to a reviewed PR in one shot — "fable-validate-loop", "fable validate and work on
Use when the user asks to validate a GitHub issue (without Fable), conditionally plan it with fableplan, then autonomously drive it to a reviewed PR in one shot — "validate-fableplan-loop", "validate, plan, and work on
Use when the user asks to validate a GitHub issue and then autonomously drive it to a reviewed PR in one shot — "validate and work on this issue", "validate-issue-loop", "fully automate issue
| name | github-issue-format |
| description | Required format for creating or editing any GitHub issue — [C<score>] title convention, complexity rationale line, complete-body rule, attribution footer. Load BEFORE creating or editing a GitHub issue. |
[C<score>] <title> — a plain-language sentence understandable to an average 18-year-old, precise about component and behavior, e.g. [C95] Orders can be filled twice when two fills arrive at the same moment.validate-issue step 6: five axes → Capability band (which LLM / whether fableplan) + Volume (effort inside the band) → score = 25 × Capability + Volume. Axes: Scope, Coupling, Risk, Uncertainty, Verification.**Complexity: 95/100** — Capability 3 (Risk 4 — money/data-integrity on order-fill path); Volume 20 — Fable 5, xhigh · fableplan: no· fableplan: yes only when Capability = 2 (score 50–74 — Opus-class build planned by Fable first); every other band is · fableplan: no (bands 0–1 don't need a separate plan; band 3 is built by Fable 5 directly, so a fableplan stage is redundant). Always write it explicitly — absence is ambiguous, not "no".Created (or Updated when editing).