Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →hashintel/managing-git-workflow
Git workflow for HASH including branch naming, PR creation, and PR reviews.
Passed 21 of 22 test cases with the skill, and 12 of 22 without it.
and 13 more in the full report
10 fixed11 passed either way0 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
I want to fetch inline code review comments for PR #412 on hashintel/hash using the GitHub REST API via gh CLI. Should I query the issue comments endpoint /repos/hashintel/hash/issues/412/comments or a different endpoint?
| Checked | Without skill | With skill |
|---|---|---|
| Specifies querying the pull request inline comments endpoint /repos/hashintel/hash/pulls/412/comments. | Passed | Passed |
| Instructs to send the GitHub JSON Accept header with the request. | Missed | Passed |
The instructions your model reads when the skill loads.
Use ordinary Git and GitHub as the public baseline. No particular Git client or access to HASH's Linear workspace is required to contribute.
Treat .github/CONTRIBUTING.md as the source of truth for contribution policy and .github/pull_request_template.md as the source of truth for PR content.
When the work has an associated HASH Linear issue, preserve traceability in the branch and pull request:
<shortname>/<team-key>-xxxx-description, with the Linear identifier in lowercase; for example, ln/fe-1437-hash-monorepo-import or ln/h-6786-agent-guidance-layout.{ISSUE-ID}: Description, preserving the identifier's uppercase form; for example, H-6786: Stop copying HASH agent guidance into unused tool folders._(internal)_ when it is not publicly accessible.Current HASH Linear identifiers commonly use FE-, SRE-, BE-, or H- prefixes.
Contributors without access to HASH's Linear workspace do not need a Linear identifier. Use a descriptive branch name and PR title, and link the relevant public issue or discussion for significant work. Minor documentation fixes may go straight to a PR as described in the contributing guide.
In every case, keep the PR description self-contained so contributors and reviewers without access to internal systems can understand the change. Fill every applicable section of the PR template and say when a section is unknown or inapplicable.
Gather the public review record and the complete diff:
gh pr view <PR_NUMBER> --comments
gh pr diff <PR_NUMBER>
gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
/repos/hashintel/hash/pulls/<PR_NUMBER>/comments
Use the PR description and linked public issue or discussion as the public review contract. If the PR references a HASH Linear issue and the reviewer has access, fetch it and use its requirements as an additional review baseline. Treat inaccessible internal links as supplemental provenance, not as requirements the public artifact may omit.
test cases passed, vs 12 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.