The `pr +close` shortcut called the `refuse_merge` API, which is
misleading — "close" suggests a benign operation, but the actual
behavior is to refuse/reject the pull request permanently.
Rename the shortcut to `pr +refuse` so the name matches the API
semantics, and add a warning in the docs that it must never be used
as a substitute for `pr +merge`.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Resolved conflicts between PR #24 (+versions, +version-diff) and PR #26
(+reviews, +review). Unified prReviewsPath() to use existing prV1Path() helper.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Add a convenience command to comment on pull requests directly,
without needing to look up the underlying issue ID first.
Internally resolves the PR's issue ID via pr +view, then posts
to the issues journals API.
- gitlink-shared: add 'PR Collaboration Workflow' section with Fork flow,
correct/incorrect examples, and self-owned repo exception
- gitlink-pr: replace single-path PR creation with two sections:
1. Fork flow for contributing to others' repos (mandatory)
2. Direct branch flow for self-owned repos (allowed)
Ensures AI agents follow standard open-source collaboration practices
instead of pushing branches directly to upstream repositories.
Problem:
AI agents (e.g., Claude Code) sometimes use `gh` (GitHub CLI) instead of
`gitlink-cli` when operating on GitLink repositories, causing 'command not
found' errors or targeting the wrong platform.
Solution:
- Add '⛔ Tool Boundary' section to gitlink-shared/SKILL.md with platform-
to-tool mapping table, judgment criteria, and dual-platform guidance
- Add CRITICAL one-liner to all 10 sub-skills ensuring agents see the
constraint even without reading shared
- Does NOT block `gh` for GitHub operations — only prevents misuse on
GitLink resources
Tested with 5 scenarios confirming:
1. GitLink operations correctly use gitlink-cli
2. GitHub operations still use gh when appropriate
3. Ambiguous cases default to gitlink-cli when skill is loaded