メニュー
Create a structured GitHub issue (bug, feature, or chore) in the current repo. Use when the user wants to file or report an issue, or runs /ps:issues-report.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Recurring engagement harvest for Pedro's social posts. Opens a browser, sweeps a week or month of his LinkedIn and/or Twitter/X posts, reads each post's impressions, reactions, comments, and reposts plus a few notable comments, and saves it as structured time-series data in the psstack performance store. Promotes high performers to exemplars so /ps:post drafts from what actually works. Use when Pedro wants to measure post performance, run the weekly/monthly engagement pull, refresh the social data store, or runs /ps:post-pulse. Not for drafting posts (that's /ps:post).
Draft social posts in Pedro Sanders' voice for LinkedIn or Twitter/X, aligned with his content strategy — Voice AI infra, Fonoster, KARMA training, and Voice AI consulting. Use this skill any time Pedro asks for a post, a draft, content for the week, a hook, a carousel/thread script, a "punch up" of a draft he wrote, repurposing content from a release/changelog/customer call/talk into a post, or whenever the work is content for his personal brand on social. Trigger even when he doesn't name a network — phrases like "write a post", "tweet this", "I want to share", "draft something about [Fonoster|KARMA|Voice AI|telecom]", or "turn this into content" should all invoke this skill. Network is chosen with --network linkedin|twitter (default linkedin). Do NOT use it for long-form essays, blog posts, newsletters longer than a paragraph, marketing copy for landing pages, or generic non-Pedro creator content. Runs /ps:post.
Drive ONE OpenSpec change all the way to production-ready through fixed stages — design (Pencil) → spec reconcile → build (Storybook-first) → tests (unit + e2e) → sync → archive. Resumable across sessions via a per-change checkpoint. Use when the user wants to refine/ship/drill a single feature to done, or runs /ps:ship.
Turn raw project notes into a polished, branded biweekly executive report PDF — anonymizing teammate and customer names along the way. Use when the user wants to write an executive report, status report, or biweekly update from messy notes, or runs /ps:executive-report.
Report which version of the ps (psstack) plugin is currently running, so you can confirm whether recent skill changes have been picked up. Use when the user asks "what version", "which psstack version", "is my latest change live", or runs /ps:version.
Scaffold a new TypeScript/Node project from a captured, opinionated baseline. Presents recurring dependency groups (Prisma SQLite/Postgres, tRPC, Vite+React+Tailwind, Tauri, Expo, CLI/oclif, LangChain LLM, Storybook, docs/media, Playwright/Maestro E2E) plus opt-in workflow tooling (psstack commands, OpenSpec) as choices, confirms the stack, then scaffolds Zod-validated functions with DI + mocha/sinon tests + tooling. Use when starting a new project or service from scratch, or runs /ps:bootstrap.
| name | issues-report |
| description | Create a structured GitHub issue (bug, feature, or chore) in the current repo. Use when the user wants to file or report an issue, or runs /ps:issues-report. |
| license | MIT |
| metadata | {"author":"psanders","version":"1.0"} |
Create a well-structured GitHub issue in the repo you're currently in. Repo-agnostic — works in any git repo with a GitHub remote.
Input: The argument (if any) is a free-form description of the issue. If none given, ask.
REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
If this fails, stop and tell the user: run inside a git repo with a GitHub remote, authenticated via gh (gh auth status). Use $REPO in the create command below.
If no input was provided, use AskUserQuestion (one call):
If input was provided as args, infer the type from context ("broken", "error", "crash" → Bug; "add", "support", "allow" → Feature; "cleanup", "refactor", "update" → Chore). If ambiguous, ask.
Use AskUserQuestion — "Priority?": P0 – Blocking, P1 – High, P2 – Normal (Recommended), P3 – Low.
Use the matching template:
Bug:
## Summary
<one sentence>
## Steps to Reproduce
<numbered steps or "TBD">
## Expected Behavior
<what should happen>
## Actual Behavior
<what actually happens>
## Priority
<P0/P1/P2/P3>
Feature:
## Summary
<one sentence>
## Problem / Motivation
<pain point>
## Proposed Solution
<what to build>
## Acceptance Criteria
- [ ] <criterion>
## Priority
<P0/P1/P2/P3>
Chore:
## Summary
<one sentence>
## Why Now
<what it unblocks>
## Done When
- [ ] <criterion>
## Priority
<P0/P1/P2/P3>
Print the title and body. Ask with AskUserQuestion — "Create this issue?": Yes, create it / Edit first / Cancel. On "Edit first": ask what to change, update, show again, confirm. On "Cancel": stop.
Map type to a label, but only apply labels that actually exist in this repo — different repos use different label sets. Check first:
gh label list --repo "$REPO" --json name -q '.[].name'
Default mappings (use the repo's nearest equivalent; skip the label if none exists): Bug → bug, Feature → enhancement, Chore → documentation/chore. Priority: apply a P0/P1/P2/P3 (or priority:*) label only if the repo has one; otherwise the priority stays in the body.
gh issue create \
--repo "$REPO" \
--title "<title>" \
--body "<body>" \
--label "<label>" # omit --label entirely if no matching label exists
Print the issue URL on success.
[Bug], [Feature], or [Chore].--label for labels confirmed to exist in the repo.gh fails, show the error and suggest gh auth status.