Skip to main content

task-prd-creator

Create a well-written PRD, task, or GitHub issue/sub-issue for a feature, bug, or enhancement. Use when planning work, writing GitHub issues, breaking down epics into sub-issues, or creating local task files. Common prompts: create a task, write a PRD, open a GitHub issue, create a sub-issue, plan this feature, write up this bug, break this down into issues, I want to add X, implement Y.

Quellinformationen

Repository
shipshitdev/v0
Letzte Quellaktivität
23. April 2026 um 11:55
Erkannte Sprache von SKILL.md
Englisch
Sterne
1
Forks
0

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

Datei-Explorer
3 Dateien

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
name
task-prd-creator
description
Create a well-written PRD, task, or GitHub issue/sub-issue for a feature, bug, or enhancement. Use when planning work, writing GitHub issues, breaking down epics into sub-issues, or creating local task files. Common prompts: create a task, write a PRD, open a GitHub issue, create a sub-issue, plan this feature, write up this bug, break this down into issues, I want to add X, implement Y.
disable-model-invocation
true
allowed-tools
Bash(gh *)
# Task & PRD Creator Write a clear, actionable PRD or task. Output depends on where the user tracks work. ## Step 1: Detect workflow preference Check in order: 1. User explicitly says "GitHub issue", "local file", or both 2. Check if `gh auth status` succeeds and a GitHub remote exists → GitHub available 3. Check if `.agents/TASKS/` or `.agents/PRDS/` exist → local available 4. If ambiguous, ask: "GitHub issue, local file, or both?" ## Step 2: Understand the request Ask only what's missing — don't interrogate if context is clear: - What problem does this solve? - Who's affected? (user-facing, internal, infra) - Any hard constraints or dependencies? - Is this part of a larger epic? (→ sub-issue) - Priority: critical / high / medium / low ## Step 3: Research before writing - Read relevant architecture docs if available (`.agents/SYSTEM/ARCHITECTURE.md`) - Search codebase for related patterns - Check for existing issues on same topic: `gh issue list --search "[keyword]"` ## Step 4: Write the PRD See `references/full-guide.md` for the full PRD structure. A good PRD has: - **Problem** — why this exists, what breaks without it - **Goal** — one sentence, measurable outcome - **Scope** — what's in, what's explicitly out - **Acceptance criteria** — testable, not vague - **Technical notes** — approach, risks, dependencies Keep it tight. No filler. Acceptance criteria must be checkable by a human. ## Step 5: Output to correct destination ### GitHub (primary if available) **New issue:** ```bash gh issue create \ --title "[type]: clear title" \ --body "$(cat <<'BODY' [PRD content here] BODY )" \ --label "feature" \ --assignee "@me" ``` **Sub-issue** (linked to parent): ```bash # Create sub-issue gh issue create --title "..." --body "..." # Link as sub-issue to parent #N gh issue develop N --checkout # only if needed # Use: gh api repos/{owner}/{repo}/issues/{parent}/sub_issues --method POST -f sub_issue_id={child_id} ``` **Draft PR from issue:** ```bash gh issue develop [issue-number] --branch "feature/[name]" ``` ### Local files (optional, or when no GitHub) - Task: `.agents/TASKS/[kebab-name].md` - PRD: `.agents/PRDS/[kebab-name].md` See `references/full-guide.md` for local file templates. ## Step 6: Get approval before creating Show the draft PRD. Wait for "looks good" or edits. Then create. ## Rules - `disable-model-invocation: true` → only runs when user explicitly invokes - Never create files or GitHub issues without user seeing the draft first - Sub-issues should be small enough to ship in one PR - If requirements are unclear, write the problem statement first — not the solution ## Related - `spec-first` — spec-driven development before writing code - `gh-fix-ci` — fix CI on existing PRs - `strategy-expert` — broader roadmap and content planning
Auf GitHub ansehen