Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问许可证需确认审计通过

forge-create-issue伪造创建问题

Agent Skill

用于围绕 GitHub 仓库、Issue、Pull Request、分支、提交和代码协作流程提供辅助能力。它适合让 Agent 查询项目状态、整理变更、辅助创建或检查协作事项,并把仓库中的信息转成可执行的下一步。使用时需要区分只读查询和写入操作;涉及创建 PR、修改 Issue、推送分支或访问私有仓库时,应确认 token 权限、目标仓库范围和用户授权。

总安装

636

周安装

26

GitHub Stars

64

下载量

206
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:forge-create-issue(伪造创建问题)
来源仓库:https://github.com/mgratzer/forge
仓库路径:skills/forge-create-issue
安装命令:
npx skills add https://github.com/mgratzer/forge --skill forge-create-issue
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/mgratzer/forge --skill forge-create-issue

简介

用于围绕 GitHub 仓库、Issue、Pull Request 和协作流程提供辅助能力。

  • 适合查询项目状态、整理变更或辅助创建协作事项。
  • 使用时需区分只读查询和写入操作,涉及私有仓库时确认 token 权限。
  • 创建 PR、修改 Issue 或推送分支前应核实用户授权和目标仓库范围。
  • 通过 npx skills add 从指定仓库安装,建议查看原始文档了解详细用法。

SKILL.md

Create Issue

Collaboratively plan and create well-structured Issues through interactive discussion. The Issue is created in the project's Issue tracker — see CONTEXT.md for provider detection.

Input

The issue idea or problem description: $ARGUMENTS

If no argument is provided, ask the user what they'd like to create an issue for.

Process

Step 1: Understand and Clarify

Parse the user's input, then use AskUserQuestion to gather:

  • Problem context — what triggered this, who's affected, current vs desired behavior
  • Success criteria — how will we know this is done
  • Constraints — technical limitations, dependencies

Step 2: Research the Codebase

Before proposing solutions, explore relevant code:

  • Find related existing implementations and patterns
  • Identify integration points and potential reuse
  • Look for similar past implementations

Verify external dependencies are accessible if relevant — flag broken ones before proceeding.

Step 3: Present Alternative Approaches

Always present 2-4 different approaches. Never jump to a single solution.

For each approach:

  • One-line summary
  • How it works (brief)
  • Pros and cons
  • Relative complexity (Low / Medium / High)
  • Key files affected

Let the user choose or combine approaches.

Step 4: Assess Scope

Evaluate if this should be one Issue or multiple.

Split when: distinct deliverables, different codebase areas, parallelizable work, or effort exceeds 1-2 days.

Keep together when: tightly coupled changes or splitting adds coordination overhead.

When splitting, slice vertically — each Issue is a thin end-to-end path through every layer the feature touches. See vertical-slicing.md for what makes a slice thin, common failure modes (horizontal slices in disguise, slices too thick to ship), and worked examples.

Classify each Issue as AFK (away-from-keyboard, autonomous agent execution) or HITL (human-in-the-loop, requires judgment during execution). See afk-vs-hitl.md for the classification test ("if the human disappears, where does the agent stall?"), common mis-classifications, and the mode lock-in rule.

Order Issues by dependency — earlier slices unblock later ones.

If splitting makes sense, offer: single Issue, multiple linked Issues, or epic with sub-issues.

Step 5: Draft the Issue

Title: Use conventional commit format — <type>(<scope>): <description>

Labels: When using GitHub, discover available labels with gh label list. When using the markdown provider, choose labels freely — there is no predefined set. Apply at least one type label and relevant area labels.

Body structure:

## Summary
[1-2 sentences]

## Problem / Motivation
[Why this needs to exist]

## Proposed Solution
[Chosen approach with implementation details]

### Alternatives Considered
[Other approaches and why they weren't chosen]

### Implementation Constraints
[When applicable: preferred libraries, config locations, patterns to follow, external dependencies]

## Acceptance Criteria
- [ ] [Specific, testable criteria]
- [ ] Tests added/updated
- [ ] Documentation updated (if applicable)

Step 6: Review and Create

Present the draft to the user. Iterate until satisfied. Then create the Issue in the project's Issue tracker:

GitHub:

gh issue create \
  --title "<type>(<scope>): <description>" \
  --body "$(cat <<'EOF'
<issue body>
EOF
)" \
  --label "<labels>"

For GitHub epics, create the parent issue first, then sub-issues with --parent <PARENT_NUMBER>.

Markdown (plan/ folder): Create the issue file following the plan-folder-spec — determine the next ID, write plan/issues/<ID>-<slug>.md with frontmatter and body, and append a row to plan/INDEX.md. Commit the new files.

Other provider: Use the tool or CLI declared in the project's AGENTS.md to create the issue with the same title, body, and labels.

Share the issue reference. Suggest using forge-implement to start implementation.

Guidelines

  • Be curious — challenge assumptions, ask "why" and "what if"
  • Explore first — always research the codebase before proposing solutions
  • Never skip alternatives — even if one approach seems obvious
  • Don't over-specify — leave room for implementer judgment
  • No time estimates

Related Skills

Next step: Use forge-implement to implement the issue.

Example Usage

/forge-create-issue add dark mode support
/forge-create-issue

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

36.39%
按下载量换算75

Claude

34.11%
按下载量换算70

Cursor

17.78%
按下载量换算37

Gemini CLI

9.11%
按下载量换算19

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills