Handle management of any GitHub related tasks, including creating or modifying issues, publishing a branch as a pull requests (or PRs), or creating or modifying sub-issues or child issues.
Scanned 9/12/2026
Install to Claude Code
npx -y skills add aibot88/sec_skill_store --skill aws-graph-explorer-.kiro-skills-github --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Aws Graph Explorer .Kiro Skills Github?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/aibot88-aws-graph-explorer-kiro-skills-github)More formats (shields.io, HTML) on the badges page.
---
name: github
description: Handle management of any GitHub related tasks, including creating or modifying issues, publishing a branch as a pull requests (or PRs), or creating or modifying sub-issues or child issues.
tools: ["git", "gh", "fs_read", "grep", "glob", "web_search", "web_fetch"]
---
# GitHub Project Management
## General
- Use the `gh` CLI for all GitHub operations when possible
- Never delete or change the status of issues or pull requests unless explicitly requested
- Never mention CVEs, security vulnerabilities, or security advisories in issues or PRs. Instead, describe the change as a dependency update (e.g., "Update fast-xml-parser to latest version" rather than "Fix CVE-2026-25896")
## Issues
- Always assign an issue type when creating issues: `Bug`, `Feature`, `Epic`, `Task`, or `Spike`
- Set the issue type via the REST API after creation:
```bash
gh api -X PATCH repos/{owner}/{repo}/issues/{number} --field type={type_name}
```
- Use the corresponding issue template for each type:
- `Bug` → `.github/ISSUE_TEMPLATE/01-bug-report.md`
- `Feature` → `.github/ISSUE_TEMPLATE/02-feature-request.md`
- `Epic` → `.github/ISSUE_TEMPLATE/03-epic.md`
- `Task` → `.github/ISSUE_TEMPLATE/04-task.md`
- `Spike` → `.github/ISSUE_TEMPLATE/05-spike.md`
- Use context from the codebase or the web to fill in additional detail when creating issues
- Only apply labels from the existing set; do not create new labels
- Do not add or remove labels unless explicitly requested
- For tasks and spikes, always assign a parent issue with the type bug, feature, or epic
## Sub-Issues
Create a sub-issue (child) under a parent issue:
```bash
PARENT_ID=$(gh issue view <parent-number> --json id --jq '.id')
CHILD_ID=$(gh issue view <child-number> --json id --jq '.id')
gh api graphql \
-H "GraphQL-Features: sub_issues" \
-f query="mutation { addSubIssue(input: { issueId: \"$PARENT_ID\", subIssueId: \"$CHILD_ID\" }) { issue { title } subIssue { title } } }"
```
Note: `gh issue create` does not support `--parent`. Create the issue first, then link it via the GraphQL API as shown above.
## Related Issues
When an issue or PR relates to another issue or PR, add a "Related Issues" section with a list of linked items. Always use a list format, even for a single item, because GitHub expands the reference number into the referenced item's title (e.g., `- Fixes #123` renders as "Fixes some bug #123").
Prefix each item with a brief relationship descriptor such as:
- `Fixes` or `Resolves` — closes the referenced issue
- `Part of` — contributes to a larger effort
- `Parent` — the parent issue or epic
- `Duplicate` — duplicates another issue
- Other brief descriptors as appropriate
Example:
```markdown
## Related Issues
- Resolves #123
- Part of #456
```
## Pull Requests
- Always publish pull requests as drafts
- Always setup tracking when publishing a branch to a remote
- In the title, describe the changes conceptually (e.g., "Add vertex filtering to graph view")
- In the title, do not use conventional commit prefixes like `docs:`, `feature:`, `refactor:`, `fix:`, etc
- Follow the pull request template in `.github/pull_request_template.md`
- Link to the corresponding issue when one exists (e.g., `Fixes #123`)
- Keep descriptions concise and focused
- Include a bulleted list of changes at the conceptual level with reasons for each change so reviewers can scan quickly
- When filling out the PR template checklist, only check an item if the action was actually performed during the current session. For example, only check `pnpm checks` or `pnpm test` if those commands were run and passed. Leave items unchecked when unsure.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!