SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsrock-feedback

rock-feedback

Coding & development

View repository

Updated 10-16 05:04

About this skill

Rock Feedback — Submit Skill Improvement Feedback

Organize the user's feedback about rock-* skills into a high-quality GitHub Issue or PR, and submit it to this plugin repository xdlkc/rock-marketplace。

The value of feedback depends on how specific and actionable it is. Your core job is not to mechanically relay a single sentence from the user, but to fill in the context (which skill, which version, what scenario, expected vs actual), so that maintainers can take action as soon as they receive it.

When to Use

  • The user expresses dissatisfaction, confusion, or suggestions for improvement about a certain skill
  • The user explicitly requests "file an issue / file a PR / give feedback on a problem"
  • A bug or documentation error is found while using rock-cli / rock-debug / rock-agent-debug / rock-eval
  • The user describes a scenario where "a skill should have been able to do something but did not do it well"

Target Repository

Fixed as xdlkc/rock-marketplace. Skills are located in plugins/rock/skills/<skill-name>/。

Decision Tree: Issue or PR?

用户的反馈是什么性质？
│
├─ 模糊的不满 / bug 现象 / 改进想法，但没有具体改法 ──→ 提 Issue
│     例："rock-debug 的日志搜索经常输出太多" "希望支持 xxx"
│
├─ 有明确、可落地的改动方案（改某行文档、加个命令说明、修个错别字） ──→ 提 PR
│     例："rock-eval 文档里 retry 命令的参数写错了，应该是 --filter error"
│
└─ 不确定 ──→ 默认提 Issue（成本低、维护者可讨论后再改）

Prefer Issue: Unless the user explicitly wants to directly modify the code, or the change is small enough to write correctly at a glance, file an Issue. An Issue lets maintainers participate in the decision-making and avoids submitting a PR that is not accepted.

Must Do Before Submitting: Clarify the Feedback

Low-quality feedback is of no help to maintainers. Before submitting, make sure these pieces of information are collected (ask the user for anything missing, or infer it from the current session/environment):

  1. Which skill — rock-cli / rock-debug / rock-agent-debug / rock-eval, or something else
  2. Version — read plugins/rock/plugin.json 's version(if in this repository), or ask the user which version is installed
  3. Scenario — what the user was doing at the time, which command/which piece of guidance was used
  4. Expected vs actual — how the skill was expected to behave, and how it actually behaved
  5. Optional — error output, reproduction steps, the fix direction envisioned by the user

Do not keep asking until the user gets annoyed. Use what can already be inferred from the session (for example, rock-eval was just being used to run regression), and only ask for the key items that are truly missing.

Path One: Submit an Issue

1. Organize the body

Use this template (trim according to the feedback type; for bugs use all fields, and for suggestions the reproduction steps may be omitted):

## 涉及 Skill
`<skill-name>` (version <x.y.z>)

## 问题 / 建议
<一句话说清核心>

## 场景
<用户在做什么，触发了什么>

## 期望表现
<应该怎样>

## 实际表现
<实际怎样；bug 附报错输出>

## 复现步骤（如适用）
1. ...
2. ...

## 可能的改进方向（可选）
<用户或你的设想>

2. Submit with the gh CLI (preferred)

First confirm that gh is available and logged in:

gh auth status

Submit (keep the title concise and include the skill prefix, so maintainers can categorize it easily):

gh issue create \
  --repo xdlkc/rock-marketplace \
  --title "[rock-debug] 日志搜索默认输出过多，建议加默认行数上限" \
  --body-file <(cat <<'EOF'
## 涉及 Skill
`rock-debug` (version 1.1.0)
... 正文 ...
EOF
)

After successful submission, give the user the returned issue link.

3. Fallback when gh is unavailable

If gh does not exist or is not logged in,do not interrupt— show the organized title + body to the user, and provide the web submission link:

https://github.com/xdlkc/rock-marketplace/issues/new

Tell the user: copy the title and body above, click the link, and paste them.

Path Two: Submit a PR

Take this path only when there is a clear, actionable change. Process: fork (if there is no permission) → branch → modify → submit PR.

1. Confirm the scope of changes

Clarify which file to modify and what to change. Common targets:

  • plugins/rock/skills/<skill>/SKILL.md — the skill's main guidance
  • plugins/rock/skills/<skill>/references/*.md — Attached reference documents
  • docs/ — Installation/Specification documents

Keep changes minimal: only touch feedback-related content, don't refactor along the way, don't change style. Follow this skill's existing Chinese style and structure.

2. Prepare a branch and make changes

If the workspace is this repository (git remote -v points to xdlkc/rock-marketplace) and you have push permission:

git checkout -b fix/rock-debug-log-default-limit
# 用 Edit 工具改文件

If you don't have push permission, fork first:

gh repo fork xdlkc/rock-marketplace --clone=false --remote

3. Submit a PR

Commit messages follow the project convention <type>(<scope>): <description>(see the repository's CLAUDE.md), with the scope set to the skill name:

git add -A
git commit -m "docs(rock-debug): cap default log search output to avoid flooding"
git push -u origin fix/rock-debug-log-default-limit

gh pr create \
  --repo xdlkc/rock-marketplace \
  --title "docs(rock-debug): cap default log search output" \
  --body-file <(cat <<'EOF'
Closes #<ISSUE_NUMBER>

## 动机
<这个 PR 解决什么反馈>

## 改动
- <改了什么>

## 验证
<怎么确认改对了，如有>
EOF
)

Give the user the PR link.

3.5. Automatic Issue closure (required)

When submitting a PR, you must add on the first line of the PR body Closes #N(N is the number of the associated Issue). GitHub automatically closes the corresponding Issue after the PR is merged into the default branch (main).

Supported keywords:Closes #N / Fixes #N / Resolves #N, the effect is the same.

⚠️ Writing it only in the commit message will not automatically close the Issue——keywords in the commit message only serve as a reminder on push and do not trigger automatic closure. It must be written in PR body , and only triggers when the PR is merged into the default branch .

If there is no corresponding Issue when submitting the PR, no need to add it. If you forgot to add it, you can close it manually after the PR is merged:

gh issue close <N> --repo xdlkc/rock-marketplace --comment "Fixed by #<PR_NUMBER>"

4. Fallback when gh is unavailable

After pushing the branch, give the user a link to create a PR on the web:

https://github.com/xdlkc/rock-marketplace/compare

Or show the diff and let the user decide how to submit.

Title convention

  • Issue：[<skill-name>] <一句话问题>, e.g. [rock-eval] retry 文档参数写错
  • PR：<type>(<skill-name>): <description>, with type set to fix/docs/feat/refactor

Common pitfalls

  • Feedback too vague: just saying "not easy to use" cannot be turned into an effective issue, be sure to fill in the scenario and expected/actual.
  • Submitting a PR when it should be an Issue: when there is no clear fix approach, don't change code on your own; file an Issue first to let the maintainer decide.
  • Out-of-scope changes: the PR should only change feedback-related content, avoid dragging in unrelated refactors.
  • Missing version: bug-type feedback must include the version number so the maintainer can judge whether it has already been fixed.
  • Pushing directly to main: always go through a new branch, never commit directly on main.
  • Forgetting to write Closes #N in the PR: after the PR is merged, the associated Issue will not be automatically closed. The first line of the PR body must have Closes #N(only having it in the commit message does not work).