GithubIssue

Generate structured GitHub issue cards for the WeBuddhist team. Use this when a backend dev needs to document a new or changed endpoint, or when a frontend/a...

Security Scan

The skill's purpose (authoring and creating GitHub issue cards) is coherent, but the runtime instructions require the GitHub CLI and access to a GitHub auth token while the skill metadata does not declare these binaries or credentials — an unexplained gap that users should understand before installing.

Purpose & Capability

The skill claims to create and link GitHub issues and project items using `gh` commands, which legitimately requires the GitHub CLI and an authenticated GitHub token with appropriate scopes. However, the skill's metadata lists no required binaries or env vars. The missing declaration of `gh` (or equivalent) is an incoherence.

Instruction Scope

The SKILL.md instructions stay on-topic: parse inputs, generate an issue body, prompt the user, list repos/projects and create an issue and project item. Instructions do not request unrelated files or system data. They do, however, instruct running `gh` commands which will use the user's GitHub credentials and data — expected for this purpose.

Install Mechanism

This is instruction-only (no install spec, no code files). That limits disk installation risk. There are no downloads or external install mechanisms to review.

Credentials

The skill implicitly requires access to GitHub credentials (a `gh`-authenticated session or GITHUB_TOKEN) and specifically asks to check `gh auth status` and to refresh auth with `project` scope. Yet requires.env and primary credential are empty. The skill should declare the need for the GitHub CLI and clarify required credential scopes; the current lack of declared credentials is disproportionate to the metadata.

Persistence & Privilege

always is false and the skill does not request persistent system-wide changes. It will invoke `gh` commands when run, which is expected. Autonomous invocation is allowed by default but not, by itself, a new concern here.

What to consider before installing

This skill appears to do what it says (generate and create GitHub issue cards) but it omits important runtime requirements. Before installing or enabling it: - Confirm that the agent environment has the GitHub CLI (`gh`) available and up-to-date; the skill's metadata should list this but currently does not. - Be aware the skill will use your GitHub authentication (the `gh` session or a token) and may run `gh auth status`, `gh repo list`, `gh project list`, `gh issue create`, and `gh project item-add`. Ensure the token/session has only the minimum scopes (it explicitly needs the `project` scope) and that you trust the skill to act with those permissions. - Because the skill's source/homepage is unknown, consider testing it in a separate account or organization with limited privileges first. - If you plan to install it broadly, ask the publisher to update the skill metadata to declare required binaries (gh) and the required credential/scopes (e.g., GITHUB_TOKEN or gh-authenticated session with `project` scope) so you can make an informed permission decision.

Context: The WeBuddhist team (backend, frontend, app devs) uses GitHub issue cards to document API endpoints during integration. Cards must be consistent so any dev can scan them and know: what's the endpoint, what goes in, what comes out, and what can go wrong. This skill generates those cards.

Accepted Inputs:

• OpenAPI/Swagger spec (YAML/JSON) → extract endpoints automatically
• Natural language → "we added a language filter to GET /plans/tags"
• Inline details → method, path, params, response pasted in chat
• Existing issue number → reads via gh issue view for context
• Any combination of the above

Instructions:

1. Parse the input. Extract: HTTP method, path, query params, request body, response body, status codes, headers. If info is missing, mark as [TBD].

2. Pick the card type:

   • New endpoint → full card
   • Endpoint edit → full card + "Current Behavior" / "Proposed Change" sections after Context
   • Backend fix → full card, focus Context on the bug, still include the related endpoint and response so devs know which API surface is affected

3. Generate the card using the template below. Do NOT output any conversational text — output ONLY the formatted markdown so it can be directly copied into GitHub.

4. Show the card to the user for review. Wait for approval before proceeding.

5. After approval, ask for target repo:

   • Run: gh repo list <org> --limit 50 --json name,description
   • Show list, user picks

6. Ask for project board:

   • First check auth scope: gh auth status — if project scope is missing, tell user to run gh auth refresh -s project
   • Run: gh project list --owner <org> --format json
   • Show list, user picks

7. Create and link:

   • gh issue create --repo <org>/<repo> --title "<title>" --body "<body>"
   • gh project item-add <project-number> --owner <org> --url <issue-url>
   • Show the issue URL

Never auto-create. Always: generate → review → repo → board → create.

Card Template:

# <Short clear title>

## Context
<1-2 sentences: why this endpoint exists, or what's changing and why>

## Endpoint
\`\`\`
<METHOD> <path>
\`\`\`

## Headers
| Header | Required | Description |
|--------|----------|-------------|
| `Authorization` | Yes | Bearer token |

## Query Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|

## Request Body
\`\`\`json
{}
\`\`\`

## Response
**200 OK**
\`\`\`json
{}
\`\`\`

## Status Codes
| Code | Description |
|------|-------------|
| 200 | Success |
| 401 | Unauthorized |
| 404 | Not found |
| 422 | Validation error |

## Notes
- <Edge cases, gotchas, related issues>

Omit sections that don't apply (e.g., no Request Body for GET, no Query Params for POST with body only).

For endpoint edits, add after Context:

## Current Behavior
## Proposed Change

Prerequisites:

• The gh token needs the project scope. If project commands fail, run: gh auth refresh -s project

Rules:

• Realistic example values — Tibetan text for bo fields (སྒོམ), UUIDs for IDs, real names like "Morning Meditation"
• Multilingual fields as objects: { "en": "Meditation", "bo": "སྒོམ" }
• OpenAPI schemas → concrete JSON examples, not raw schema
• Short scannable notes — bullets, not paragraphs
• [TBD] for unknowns, never invent behavior
• Always ask user to pick repo and project board