better-dsh 0.2.5 → 0.3.0-c

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/docs/user-guide/skills/bundled/github/github-github-code-review.md

@@ -1,499 +0,0 @@
----
-title: "Github Code Review — Review PRs: diffs, inline comments via gh or REST"
-sidebar_label: "Github Code Review"
-description: "Review PRs: diffs, inline comments via gh or REST"
----
-
-{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}
-
-# Github Code Review
-
-Review PRs: diffs, inline comments via gh or REST.
-
-## Skill metadata
-
-| | |
-|---|---|
-| Source | Bundled (installed by default) |
-| Path | `skills/github/github-code-review` |
-| Version | `1.1.0` |
-| Author | Hermes Agent |
-| License | MIT |
-| Platforms | linux, macos, windows |
-| Tags | `GitHub`, `Code-Review`, `Pull-Requests`, `Git`, `Quality` |
-| Related skills | [`github-auth`](/docs/user-guide/skills/bundled/github/github-github-auth), [`github-pr-workflow`](/docs/user-guide/skills/bundled/github/github-github-pr-workflow) |
-
-## Reference: full SKILL.md
-
-:::info
-The following is the complete skill definition that Hermes loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.
-:::
-
-# GitHub Code Review
-
-Perform code reviews on local changes before pushing, or review open PRs on GitHub. Most of this skill uses plain `git` — the `gh`/`curl` split only matters for PR-level interactions.
-
-## Prerequisites
-
-- Authenticated with GitHub (see `github-auth` skill)
-- Inside a git repository
-
-### Setup (for PR interactions)
-
-```bash
-if command -v gh &>/dev/null && gh auth status &>/dev/null; then
-  AUTH="gh"
-else
-  AUTH="git"
-  if [ -z "$GITHUB_TOKEN" ]; then
-    if _hermes_env="${HERMES_HOME:-$HOME/.hermes}/.env"; [ -f "$_hermes_env" ] && grep -q "^GITHUB_TOKEN=" "$_hermes_env"; then
-      GITHUB_TOKEN=$(grep "^GITHUB_TOKEN=" "$_hermes_env" | head -1 | cut -d= -f2 | tr -d '\n\r')
-    elif grep -q "github.com" ~/.git-credentials 2>/dev/null; then
-      GITHUB_TOKEN=$(uv run python3 "${HERMES_HOME:-$HOME/.hermes}/skills/github/github-auth/scripts/git-credential-token.py")
-    fi
-  fi
-fi
-
-REMOTE_URL=$(git remote get-url origin)
-OWNER_REPO=$(echo "$REMOTE_URL" | sed -E 's|.*github\.com[:/]||; s|\.git$||')
-OWNER=$(echo "$OWNER_REPO" | cut -d/ -f1)
-REPO=$(echo "$OWNER_REPO" | cut -d/ -f2)
-```
-
----
-
-## 1. Reviewing Local Changes (Pre-Push)
-
-This is pure `git` — works everywhere, no API needed.
-
-### Get the Diff
-
-```bash
-# Staged changes (what would be committed)
-git diff --staged
-
-# All changes vs main (what a PR would contain)
-git diff main...HEAD
-
-# File names only
-git diff main...HEAD --name-only
-
-# Stat summary (insertions/deletions per file)
-git diff main...HEAD --stat
-```
-
-### Review Strategy
-
-1. **Get the big picture first:**
-
-```bash
-git diff main...HEAD --stat
-git log main..HEAD --oneline
-```
-
-2. **Review file by file** — use `read_file` on changed files for full context, and the diff to see what changed:
-
-```bash
-git diff main...HEAD -- src/auth/login.py
-```
-
-3. **Check for common issues:**
-
-```bash
-# Debug statements, TODOs, console.logs left behind
-git diff main...HEAD | grep -n "print(\|console\.log\|TODO\|FIXME\|HACK\|XXX\|debugger"
-
-# Large files accidentally staged
-git diff main...HEAD --stat | sort -t'|' -k2 -rn | head -10
-
-# Secrets or credential patterns
-git diff main...HEAD | grep -in "password\|secret\|api_key\|token.*=\|private_key"
-
-# Merge conflict markers
-git diff main...HEAD | grep -n "<<<<<<\|>>>>>>\|======="
-```
-
-4. **Present structured feedback** to the user.
-
-### Review Output Format
-
-When reviewing local changes, present findings in this structure:
-
-```
-## Code Review Summary
-
-### Critical
-- **src/auth.py:45** — SQL injection: user input passed directly to query.
-  Suggestion: Use parameterized queries.
-
-### Warnings
-- **src/models/user.py:23** — Password stored in plaintext. Use bcrypt or argon2.
-- **src/api/routes.py:112** — No rate limiting on login endpoint.
-
-### Suggestions
-- **src/utils/helpers.py:8** — Duplicates logic in `src/core/utils.py:34`. Consolidate.
-- **tests/test_auth.py** — Missing edge case: expired token test.
-
-### Looks Good
-- Clean separation of concerns in the middleware layer
-- Good test coverage for the happy path
-```
-
----
-
-## 2. Reviewing a Pull Request on GitHub
-
-### View PR Details
-
-**With gh:**
-
-```bash
-gh pr view 123
-gh pr diff 123
-gh pr diff 123 --name-only
-```
-
-**With git + curl:**
-
-```bash
-PR_NUMBER=123
-
-# Get PR details
-curl -s \
-  -H "Authorization: token $GITHUB_TOKEN" \
-  https://api.github.com/repos/$OWNER/$REPO/pulls/$PR_NUMBER \
-  | python3 -c "
-import sys, json
-pr = json.load(sys.stdin)
-print(f\"Title: {pr['title']}\")
-print(f\"Author: {pr['user']['login']}\")
-print(f\"Branch: {pr['head']['ref']} -> {pr['base']['ref']}\")
-print(f\"State: {pr['state']}\")
-print(f\"Body:\n{pr['body']}\")"
-
-# List changed files
-curl -s \
-  -H "Authorization: token $GITHUB_TOKEN" \
-  https://api.github.com/repos/$OWNER/$REPO/pulls/$PR_NUMBER/files \
-  | python3 -c "
-import sys, json
-for f in json.load(sys.stdin):
-    print(f\"{f['status']:10} +{f['additions']:-4} -{f['deletions']:-4}  {f['filename']}\")"
-```
-
-### Check Out PR Locally for Full Review
-
-This works with plain `git` — no `gh` needed:
-
-```bash
-# Fetch the PR branch and check it out
-git fetch origin pull/123/head:pr-123
-git checkout pr-123
-
-# Now you can use read_file, search_files, run tests, etc.
-
-# View diff against the base branch
-git diff main...pr-123
-```
-
-**With gh (shortcut):**
-
-```bash
-gh pr checkout 123
-```
-
-### Leave Comments on a PR
-
-**General PR comment — with gh:**
-
-```bash
-gh pr comment 123 --body "Overall looks good, a few suggestions below."
-```
-
-**General PR comment — with curl:**
-
-```bash
-curl -s -X POST \
-  -H "Authorization: token $GITHUB_TOKEN" \
-  https://api.github.com/repos/$OWNER/$REPO/issues/$PR_NUMBER/comments \
-  -d '{"body": "Overall looks good, a few suggestions below."}'
-```
-
-### Leave Inline Review Comments
-
-**Single inline comment — with gh (via API):**
-
-```bash
-HEAD_SHA=$(gh pr view 123 --json headRefOid --jq '.headRefOid')
-
-gh api repos/$OWNER/$REPO/pulls/123/comments \
-  --method POST \
-  -f body="This could be simplified with a list comprehension." \
-  -f path="src/auth/login.py" \
-  -f commit_id="$HEAD_SHA" \
-  -f line=45 \
-  -f side="RIGHT"
-```
-
-**Single inline comment — with curl:**
-
-```bash
-# Get the head commit SHA
-HEAD_SHA=$(curl -s \
-  -H "Authorization: token $GITHUB_TOKEN" \
-  https://api.github.com/repos/$OWNER/$REPO/pulls/$PR_NUMBER \
-  | python3 -c "import sys,json; print(json.load(sys.stdin)['head']['sha'])")
-
-curl -s -X POST \
-  -H "Authorization: token $GITHUB_TOKEN" \
-  https://api.github.com/repos/$OWNER/$REPO/pulls/$PR_NUMBER/comments \
-  -d "{
-    \"body\": \"This could be simplified with a list comprehension.\",
-    \"path\": \"src/auth/login.py\",
-    \"commit_id\": \"$HEAD_SHA\",
-    \"line\": 45,
-    \"side\": \"RIGHT\"
-  }"
-```
-
-### Submit a Formal Review (Approve / Request Changes)
-
-**With gh:**
-
-```bash
-gh pr review 123 --approve --body "LGTM!"
-gh pr review 123 --request-changes --body "See inline comments."
-gh pr review 123 --comment --body "Some suggestions, nothing blocking."
-```
-
-**With curl — multi-comment review submitted atomically:**
-
-```bash
-HEAD_SHA=$(curl -s \
-  -H "Authorization: token $GITHUB_TOKEN" \
-  https://api.github.com/repos/$OWNER/$REPO/pulls/$PR_NUMBER \
-  | python3 -c "import sys,json; print(json.load(sys.stdin)['head']['sha'])")
-
-curl -s -X POST \
-  -H "Authorization: token $GITHUB_TOKEN" \
-  https://api.github.com/repos/$OWNER/$REPO/pulls/$PR_NUMBER/reviews \
-  -d "{
-    \"commit_id\": \"$HEAD_SHA\",
-    \"event\": \"COMMENT\",
-    \"body\": \"Code review from Hermes Agent\",
-    \"comments\": [
-      {\"path\": \"src/auth.py\", \"line\": 45, \"body\": \"Use parameterized queries to prevent SQL injection.\"},
-      {\"path\": \"src/models/user.py\", \"line\": 23, \"body\": \"Hash passwords with bcrypt before storing.\"},
-      {\"path\": \"tests/test_auth.py\", \"line\": 1, \"body\": \"Add test for expired token edge case.\"}
-    ]
-  }"
-```
-
-Event values: `"APPROVE"`, `"REQUEST_CHANGES"`, `"COMMENT"`
-
-The `line` field refers to the line number in the *new* version of the file. For deleted lines, use `"side": "LEFT"`.
-
----
-
-## 3. Review Checklist
-
-When performing a code review (local or PR), systematically check:
-
-### Correctness
-- Does the code do what it claims?
-- Edge cases handled (empty inputs, nulls, large data, concurrent access)?
-- Error paths handled gracefully?
-
-### Security
-- No hardcoded secrets, credentials, or API keys
-- Input validation on user-facing inputs
-- No SQL injection, XSS, or path traversal
-- Auth/authz checks where needed
-
-### Code Quality
-- Clear naming (variables, functions, classes)
-- No unnecessary complexity or premature abstraction
-- DRY — no duplicated logic that should be extracted
-- Functions are focused (single responsibility)
-
-### Testing
-- New code paths tested?
-- Happy path and error cases covered?
-- Tests readable and maintainable?
-
-### Performance
-- No N+1 queries or unnecessary loops
-- Appropriate caching where beneficial
-- No blocking operations in async code paths
-
-### Documentation
-- Public APIs documented
-- Non-obvious logic has comments explaining "why"
-- README updated if behavior changed
-
----
-
-## 4. Pre-Push Review Workflow
-
-When the user asks you to "review the code" or "check before pushing":
-
-1. `git diff main...HEAD --stat` — see scope of changes
-2. `git diff main...HEAD` — read the full diff
-3. For each changed file, use `read_file` if you need more context
-4. Apply the checklist above
-5. Present findings in the structured format (Critical / Warnings / Suggestions / Looks Good)
-6. If critical issues found, offer to fix them before the user pushes
-
----
-
-## 5. PR Review Workflow (End-to-End)
-
-When the user asks you to "review PR #N", "look at this PR", or gives you a PR URL, follow this recipe:
-
-### Step 1: Set up environment
-
-```bash
-source "${HERMES_HOME:-$HOME/.hermes}/skills/github/github-auth/scripts/gh-env.sh"
-# Or run the inline setup block from the top of this skill
-```
-
-### Step 2: Gather PR context
-
-Get the PR metadata, description, and list of changed files to understand scope before diving into code.
-
-**With gh:**
-```bash
-gh pr view 123
-gh pr diff 123 --name-only
-gh pr checks 123
-```
-
-**With curl:**
-```bash
-PR_NUMBER=123
-
-# PR details (title, author, description, branch)
-curl -s -H "Authorization: token $GITHUB_TOKEN" \
-  https://api.github.com/repos/$GH_OWNER/$GH_REPO/pulls/$PR_NUMBER
-
-# Changed files with line counts
-curl -s -H "Authorization: token $GITHUB_TOKEN" \
-  https://api.github.com/repos/$GH_OWNER/$GH_REPO/pulls/$PR_NUMBER/files
-```
-
-### Step 3: Check out the PR locally
-
-This gives you full access to `read_file`, `search_files`, and the ability to run tests.
-
-```bash
-git fetch origin pull/$PR_NUMBER/head:pr-$PR_NUMBER
-git checkout pr-$PR_NUMBER
-```
-
-### Step 4: Read the diff and understand changes
-
-```bash
-# Full diff against the base branch
-git diff main...HEAD
-
-# Or file-by-file for large PRs
-git diff main...HEAD --name-only
-# Then for each file:
-git diff main...HEAD -- path/to/file.py
-```
-
-For each changed file, use `read_file` to see full context around the changes — diffs alone can miss issues visible only with surrounding code.
-
-### Step 5: Run automated checks locally (if applicable)
-
-```bash
-# Run tests if there's a test suite
-python -m pytest 2>&1 | tail -20
-# or: npm test, cargo test, go test ./..., etc.
-
-# Run linter if configured
-ruff check . 2>&1 | head -30
-# or: eslint, clippy, etc.
-```
-
-### Step 6: Apply the review checklist (Section 3)
-
-Go through each category: Correctness, Security, Code Quality, Testing, Performance, Documentation.
-
-### Step 7: Post the review to GitHub
-
-Collect your findings and submit them as a formal review with inline comments.
-
-**With gh:**
-```bash
-# If no issues — approve
-gh pr review $PR_NUMBER --approve --body "Reviewed by Hermes Agent. Code looks clean — good test coverage, no security concerns."
-
-# If issues found — request changes with inline comments
-gh pr review $PR_NUMBER --request-changes --body "Found a few issues — see inline comments."
-```
-
-**With curl — atomic review with multiple inline comments:**
-```bash
-HEAD_SHA=$(curl -s -H "Authorization: token $GITHUB_TOKEN" \
-  https://api.github.com/repos/$GH_OWNER/$GH_REPO/pulls/$PR_NUMBER \
-  | python3 -c "import sys,json; print(json.load(sys.stdin)['head']['sha'])")
-
-# Build the review JSON — event is APPROVE, REQUEST_CHANGES, or COMMENT
-curl -s -X POST \
-  -H "Authorization: token $GITHUB_TOKEN" \
-  https://api.github.com/repos/$GH_OWNER/$GH_REPO/pulls/$PR_NUMBER/reviews \
-  -d "{
-    \"commit_id\": \"$HEAD_SHA\",
-    \"event\": \"REQUEST_CHANGES\",
-    \"body\": \"## Hermes Agent Review\n\nFound 2 issues, 1 suggestion. See inline comments.\",
-    \"comments\": [
-      {\"path\": \"src/auth.py\", \"line\": 45, \"body\": \"🔴 **Critical:** User input passed directly to SQL query — use parameterized queries.\"},
-      {\"path\": \"src/models.py\", \"line\": 23, \"body\": \"⚠️ **Warning:** Password stored without hashing.\"},
-      {\"path\": \"src/utils.py\", \"line\": 8, \"body\": \"💡 **Suggestion:** This duplicates logic in core/utils.py:34.\"}
-    ]
-  }"
-```
-
-### Step 8: Also post a summary comment
-
-In addition to inline comments, leave a top-level summary so the PR author gets the full picture at a glance. Use the review output format from `references/review-output-template.md`.
-
-**With gh:**
-```bash
-gh pr comment $PR_NUMBER --body "$(cat <<'EOF'
-## Code Review Summary
-
-**Verdict: Changes Requested** (2 issues, 1 suggestion)
-
-### 🔴 Critical
-- **src/auth.py:45** — SQL injection vulnerability
-
-### ⚠️ Warnings
-- **src/models.py:23** — Plaintext password storage
-
-### 💡 Suggestions
-- **src/utils.py:8** — Duplicated logic, consider consolidating
-
-### ✅ Looks Good
-- Clean API design
-- Good error handling in the middleware layer
-
----
-*Reviewed by Hermes Agent*
-EOF
-)"
-```
-
-### Step 9: Clean up
-
-```bash
-git checkout main
-git branch -D pr-$PR_NUMBER
-```
-
-### Decision: Approve vs Request Changes vs Comment
-
-- **Approve** — no critical or warning-level issues, only minor suggestions or all clear
-- **Request Changes** — any critical or warning-level issue that should be fixed before merge
-- **Comment** — observations and suggestions, but nothing blocking (use when you're unsure or the PR is a draft)

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/docs/user-guide/skills/bundled/github/github-github-issue-to-pr.md

@@ -1,95 +0,0 @@
----
-title: "Github Issue To Pr — Carry a GitHub issue to a verified PR with honest CI state"
-sidebar_label: "Github Issue To Pr"
-description: "Carry a GitHub issue to a verified PR with honest CI state"
----
-
-{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}
-
-# Github Issue To Pr
-
-Carry a GitHub issue to a verified PR with honest CI state.
-
-## Skill metadata
-
-| | |
-|---|---|
-| Source | Bundled (installed by default) |
-| Path | `skills/github/github-issue-to-pr` |
-| Version | `0.1.0` |
-| Author | Ben Barclay (benbarclay), Hermes Agent |
-| License | MIT |
-| Platforms | linux, macos, windows |
-| Tags | `GitHub`, `Issues`, `Coding`, `Pull-Requests`, `CI` |
-| Related skills | [`github-issues`](/docs/user-guide/skills/bundled/github/github-github-issues), [`github-pr-workflow`](/docs/user-guide/skills/bundled/github/github-github-pr-workflow), [`systematic-debugging`](/docs/user-guide/skills/bundled/software-development/software-development-systematic-debugging), [`test-driven-development`](/docs/user-guide/skills/bundled/software-development/software-development-test-driven-development), [`requesting-code-review`](/docs/user-guide/skills/bundled/software-development/software-development-requesting-code-review) |
-
-## Reference: full SKILL.md
-
-:::info
-The following is the complete skill definition that Hermes loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.
-:::
-
-# GitHub Issue to Pull Request
-
-Turn a GitHub issue into a tested, verified PR. This skill owns the end-to-end discipline — premise validation, duplicate sweeps, class-level fixes, and honest CI reporting; the sibling GitHub and development skills own their own mechanics.
-
-## When to Use
-
-- "Fix issue #123 and open a PR."
-- "Implement this GitHub feature request."
-- "Take this bug from issue to green CI."
-
-Don't use for: reviewing an existing PR, or answering a code question with no requested change.
-
-## Procedure
-
-### 1. Read the live issue — body AND full thread
-
-Use `terminal` to run `gh issue view <N> --comments`. The body is a snapshot from filing time; the newest comments carry the live state: partial fixes already merged, new root-cause analyses, maintainer decisions, or questions directed at you that change the task. Also read repository instructions (`AGENTS.md`, contribution docs) with `read_file`. Done when the currently requested behavior, non-goals, and any unanswered thread questions are known.
-
-### 2. Sweep for existing and duplicate work
-
-Before writing anything, run `gh pr list --search "#<N>" --state all` plus at least two keyword/synonym variants of the symptom (`gh pr list --search "<subsystem> <symptom>" --state open`). Popular issues attract multiple independent fixes; building a duplicate wastes the work and the credit. Also check whether a recent commit already fixed it: `git log --oneline -20 -- <relevant files>`. Done when you know every open PR and recent commit touching this issue, or that none exist.
-
-### 3. Validate the premise against current code — and against design intent
-
-Reproduce the bug or demonstrate the missing behavior on the current default branch with a failing test or fixture, using `search_files` and `read_file` to trace the reported path. Then check the second question: is the "bug" actually deliberate design? Run `git log -p -S "<symbol>"` on the code the issue wants changed and read the original commit's intent — a missing link or restriction is often the feature. Challenge stale or flawed issue prose instead of implementing it blindly. Done when the root cause or feature gap is demonstrated in current code AND the change doesn't fight an intentional design.
-
-### 4. Define acceptance and risk
-
-List acceptance criteria, interfaces, migrations/state changes, compatibility, security/privacy, rollout, and rollback. Map every criterion to a test or explicit verification. Done when review has a finite contract.
-
-### 5. Implement the smallest complete change — and fix the class
-
-Work on an isolated branch or worktree, loading `systematic-debugging` or `test-driven-development` when the bug class calls for them. Add regression tests first, then implement. When the fix is in hand, `search_files` for the same bug shape at sibling call sites and fix the whole class in this PR — an incomplete fix that leaves known siblings broken is worse than none. Every changed line must trace to the issue; no drive-by cleanup. Done when targeted tests pass, the original failure no longer reproduces, and sibling sites are fixed or explicitly ruled out.
-
-### 6. Prove the regression test bites (sabotage run)
-
-Temporarily restore the old behavior of the exact function under test, run the new test, and confirm it FAILS; then restore the fix and confirm it passes. A regression test that passes with and without the fix proves nothing. Done when the test demonstrably fails on pre-fix code.
-
-### 7. Run repository quality gates, then open the PR immediately
-
-Run the formatter, lint, typecheck, and the repo's canonical test entrypoint on affected areas; use `requesting-code-review` on the diff. Then push and open the PR right away — the PR is what dispatches CI, and CI latency is the long pole; do not sit on finished work. Load `github-pr-workflow` for PR mechanics: conventional branch/commit, body linking the issue with problem, approach, tests, risk, and exclusions. Read the PR back and verify head SHA, base, title, and files. Done when the PR exists with the intended diff and CI is running.
-
-### 8. Shepherd CI honestly and close the loop
-
-Inspect live checks and failure logs via `gh pr checks` / `gh run view --log-failed`. Distinguish failures introduced by your diff from pre-existing baseline or infrastructure failures — reproduce on the default branch when unsure, and rerun once only for genuine infra flakes. Never say "green," "merged," or "released" without live evidence of that exact state. When the PR lands, comment on the issue with the PR link and a one-line explanation so the reporter gets a traceable resolution. Done when CI state, remaining blockers, and the issue thread all reflect reality.
-
-## Pitfalls
-
-- Coding before reading issue comments, sweeping for duplicate PRs, or reading current code.
-- "Fixing" behavior that the original commit shows is intentional design.
-- Fixing a symptom at one call site while sibling sites keep the same bug.
-- Shipping a regression test that also passes without the fix.
-- Opening a PR with unrun tests or unrelated formatting churn.
-- Claiming the issue is delivered because a PR exists.
-
-## Verification
-
-- [ ] Full issue thread read; newest comment state reflected in the plan.
-- [ ] Duplicate-PR sweep run with issue number + 2 keyword variants.
-- [ ] Premise reproduced on current code; design intent checked via git history.
-- [ ] Regression test proven to fail without the fix.
-- [ ] Sibling call sites fixed or explicitly ruled out.
-- [ ] Every changed line traces to the issue.
-- [ ] CI state reported from live evidence only; issue commented with the PR link.