Skip to main content

sdd-2b-prep-issue

Generate structured GitHub Issue text from SDD spec and plan artifacts. Use when: a specification is complete and needs to be represented as a GitHub Issue for external tracking, sprint planning, or team visibility.

소스 정보

저장소
willvelida/biotrackr
최근 소스 활동
2026년 8월 22일 06:02
감지된 SKILL.md 언어
영어
스타
6
포크
3

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
sdd-2b-prep-issue
description
Generate structured GitHub Issue text from SDD spec and plan artifacts. Use when: a specification is complete and needs to be represented as a GitHub Issue for external tracking, sprint planning, or team visibility.
argument-hint
[slug=...]
# SDD Phase 2b: Prep Issue Generate structured issue text from a completed specification for external tracking in GitHub Issues. ## Inputs * **slug** (Optional): Slug from prior phases. Inferred from the most recent SDD plan directory if omitted. ## When to Read References Load only the reference the current problem needs: * Spec section names the issue body mirrors: `.github/instructions/sdd-conventions.instructions.md` * Restating a complexity score correctly: `docs/standards/harness-governance.md` * Service names used for scope labels: `AGENTS.md` ## Step 0: Doctrine Resolution Before starting, resolve project conventions: 1. Check for project doctrine files: * `docs/project-rules/` (constitution.md, rules.md, idioms.md, architecture.md) * `copilot-instructions.md`, `AGENTS.md`, `CONTRIBUTING.md`, `README.md` 2. If no doctrine found, scan the codebase for dependency manifests, build systems, and directory patterns. 3. Extract: build command, test command, coverage threshold, naming conventions, CI platform. 4. Unknown values become explicit `[TODO]` markers — never assume silently. ## Step 1: Load Spec Context 1. Read the specification from `.copilot-tracking/plans/{date}/{slug}/{slug}-spec.md`. 2. If clarifications exist, read the Clarifications section. 3. If a plan exists, read the plan's complexity score and phase count. ## Step 2: Generate Issue Text Produce structured issue text with these sections: ### Title Format: `feat({scope}): {summary from spec}` Where `{scope}` is the primary affected module or service in kebab-case. ### Body ```markdown ## Summary {One-paragraph summary from spec} ## Goals {Bulleted goals from spec} ## Non-Goals {Bulleted non-goals from spec} ## Acceptance Criteria {Numbered acceptance criteria from spec} ## Complexity {CS-N score with brief rationale} ## Affected Services {List from spec's Affected Modules/Services} ## Links - Spec: `.copilot-tracking/plans/{date}/{slug}/{slug}-spec.md` - Plan: `.copilot-tracking/plans/{date}/{slug}/{slug}-plan.md` (if exists) ``` ### Labels Suggest GitHub labels based on the spec content: - Type label: `enhancement`, `bug`, `infrastructure`, `documentation` - Complexity label: `complexity:cs-{N}` - Affected service labels from the spec ## Step 3: Output Present the generated issue text in a fenced code block ready for copy-paste into GitHub Issues. Do not create the issue automatically — present the text for user review. --- > [!IMPORTANT] > **STOP.** Present the issue text to the user. Do not create the GitHub Issue — the user handles issue creation.
GitHub에서 보기