Run any Skill in Manus with one click

issues-report

Stars4

Forks1

UpdatedJune 21, 2026 at 17:57

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.

Installation

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.

Run Skill in Manus

Source

psanders

psanders/psstack

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

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"}

Report Issue

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.

Steps

0. Detect the repo

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.

1. Gather information

If no input was provided, use AskUserQuestion (one call):

"What do you want to report?" (open text)
"Type?" with options: Bug, Feature, Chore

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.

2. Ask for priority (skip if already given)

Use AskUserQuestion — "Priority?": P0 – Blocking, P1 – High, P2 – Normal (Recommended), P3 – Low.

3. Draft the issue body

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>

4. Show preview and confirm

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.

5. Create the issue

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.

Guardrails

Title must start with [Bug], [Feature], or [Chore].
Never create the issue without user confirmation.
Only pass --label for labels confirmed to exist in the repo.
If gh fails, show the error and suggest gh auth status.

More from this repository

same repository

post-pulse

psanders/psstack

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).

2026-07-174

post

psanders/psstack

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.

2026-07-174

ship

psanders/psstack

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.

2026-07-114

executive-report

psanders/psstack

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.

2026-07-024

version

psanders/psstack

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.

2026-07-014

bootstrap

psanders/psstack

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.

2026-06-294

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"}

Report Issue

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.

Steps

0. Detect the repo

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.

1. Gather information

If no input was provided, use AskUserQuestion (one call):

"What do you want to report?" (open text)
"Type?" with options: Bug, Feature, Chore

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.

2. Ask for priority (skip if already given)

Use AskUserQuestion — "Priority?": P0 – Blocking, P1 – High, P2 – Normal (Recommended), P3 – Low.

3. Draft the issue body

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>

4. Show preview and confirm

5. Create the issue

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'

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.

Guardrails

Title must start with [Bug], [Feature], or [Chore].
Never create the issue without user confirmation.
Only pass --label for labels confirmed to exist in the repo.
If gh fails, show the error and suggest gh auth status.