[Feature] Support non-GitHub forges in dev plugin workflows

[codeasier]

Problem

The plugins/dev workflows are currently only partially forge-agnostic.

Several skills in plugins/dev are tightly coupled to GitHub-specific conventions and gh CLI behavior:

• plugins/dev/skills/issue-submit/SKILL.md hardcodes gh api repos/.../contents/.github/ISSUE_TEMPLATE and gh issue create
• plugins/dev/skills/pr-followup/SKILL.md explicitly instructs the workflow to reason about gh semantics and reply to reviews using gh
• plugins/dev/skills/env-setup/SKILL.md already acknowledges that a gc command may exist, but that support stops at permissions/environment setup and is not integrated into issue/PR workflows

This makes the plugin work well for GitHub repositories, but fragile or unusable for other forges such as GitCode. In practice, the current workflows can mis-detect commands, assume GitHub-only API shapes, and fail to complete common follow-up actions such as reading review comments, replying, or submitting updates.

Proposed Solution

Introduce a minimal forge/provider abstraction for the plugins/dev remote collaboration workflows.

A possible approach:

1. Detect the forge/provider from repository remote host or explicit user input
2. Resolve the correct CLI/binary for that provider (gh, gc, etc.), distinguishing aliases from real executables
3. Normalize a small set of operations behind a provider adapter, for example:
   • fetch issue templates
   • create issue
   • fetch PR/MR metadata
   • fetch review/thread comments
   • reply to review/thread
   • check mergeability / checks / status
4. Keep the existing skill UX and SOP structure, but route remote operations through the provider adapter
5. Make issue-submit and pr-followup the first consumers; keep local-only workflows such as env-setup and worktree-clean mostly unchanged

This would allow the dev plugin to support GitHub first, while adding GitCode and potentially GitLab support without rewriting each skill independently.

Alternatives Considered

1. Patch each skill independently with ad-hoc if github / if gitcode branches

   • Simpler short term
   • Likely to duplicate logic and drift over time

2. Keep the plugin GitHub-only and document that limitation

   • Lowest implementation cost
   • Does not match actual user workflows where non-GitHub forges are already in use

3. Build a fully generic forge SDK abstraction from the start

   • Cleaner long term
   • Probably too large for the current plugin scope

A minimal adapter layer seems like the best tradeoff.

Additional Context

The current repository itself is hosted on GitHub (origin points to github.com/codeasier/claude-codeasier), but the dev plugin is intended to help with broader development workflows, and recent usage already exposed gaps when trying to use /dev:pr-followup against a GitCode PR with the gc CLI.

Relevant coupling points observed in the current codebase:

• plugins/dev/skills/issue-submit/SKILL.md:16
• plugins/dev/skills/issue-submit/SKILL.md:97
• plugins/dev/skills/pr-followup/SKILL.md:39
• plugins/dev/skills/pr-followup/SKILL.md:49
• plugins/dev/skills/env-setup/SKILL.md:114

[codeasier]

Thanks for the detailed write-up. I checked the current plugins/dev implementation against the cited files.

结论如下：

1. 问题是否真实存在：是，真实存在。

   • plugins/dev/skills/issue-submit/SKILL.md:16-19、:22-30、:35-37 直接要求使用 gh api repos/... 读取 GitHub issue template。
   • plugins/dev/skills/issue-submit/SKILL.md:96-97 直接要求用 gh issue create 提交 issue。
   • plugins/dev/skills/pr-followup/SKILL.md:39 明确要求参考 gh 语义，:49 明确要求“用 gh 回复 review”。
   • plugins/dev/skills/env-setup/SKILL.md:114 虽然提到如果存在则放行 gc，但这只覆盖权限/环境层，没有把 gc 接进 issue / PR 工作流。
   • 我额外扫了一遍 plugins/dev，当前没有现成的 provider / forge / adapter 抽象层可复用。

2. 建议是否合理：整体合理。
   你提出的“最小 provider abstraction”与当前问题规模匹配，明显优于在每个 skill 里继续堆 if github / if gitcode 分支。因为现在耦合点已经出现在多个 workflow 中，而且既有“命令名差异”，也有“远程 API / review 语义差异”。如果继续在 skill 文本里零散补丁，后续很容易漂移。

3. 正确边界是什么：应当做“最小远程操作抽象”，但不要过度泛化。
   我认为合理边界是：

   • 先覆盖 issue-submit / pr-followup 这两个明确依赖远程 forge 的技能；
   • 抽象的不是整个 forge SDK，而是一小组 workflow 真正需要的操作，例如：读取 issue 模板、创建 issue、读取 PR/MR 元数据、读取 review/thread、回复 comment/review、查询 merge/check 状态；
   • env-setup、worktree-clean 这类本地工作流没必要一起重做；
   • provider 检测既可以来自 remote host，也应该允许显式指定/覆盖，否则 alias、镜像 remote、或多 forge 环境下仍然容易误判。

4. 一个需要收窄的点：不要把 pr-followup 当前所有 GitHub 假设都视为同一层问题。
   例如 git rebase origin/main、git push --force-with-lease 这类是 Git 工作流，不是 GitHub 专属；真正需要抽象的是 review/comment/checks 这些远程协作动作。把 Git 层和 forge 层分开，会让实现更稳。

所以我的判断是：这个 issue 指出的兼容性缺口成立，提出的方向也合理；最合适的实现方式是为远程协作操作加一层最小 provider adapter，而不是把整个插件全面平台化。