arxiv Paper Search

Search arxiv for academic papers related to the given query.

Instructions

1. Use WebSearch to search for: arxiv ${query} and arxiv ${query} 2024 2025 2026
2. For each relevant paper found (up to 10), extract:
   • Title
   • Authors
   • Date
   • arxiv URL
   • Abstract summary (2-3 sentences)
   • Key contributions
3. Present results in a structured markdown table
4. Highlight papers most relevant to agent memory systems if applicable
5. Note any survey/review papers separately as they provide broader context

Benchmark & Compare

Compare multiple agent memory projects across key dimensions.

Instructions

1. For each project in ${projects}:
   • Search for benchmarks, performance reports, and comparisons
   • Analyze the architecture and API design
   • Check community feedback (GitHub issues, discussions, Reddit, HN)
2. Compare across these default criteria (override with ${criteria} if provided):
   • Memory Types: What types of memory are supported
   • Retrieval Strategy: How memories are retrieved (vector, graph, hybrid)
   • Scalability: How it handles large memory stores
   • API Design: Ease of integration
   • Ecosystem: Integrations with LLM frameworks
   • Performance: Latency, throughput if data available
   • Community: Stars, contributors, activity
3. Output a comparison matrix (markdown table)
4. Provide a recommendation summary with trade-offs

GitHub Repo Explorer

Perform a deep analysis of a GitHub repository.

Instructions

1. Use WebSearch to find the repo's README, documentation, and key discussions
2. Use the GitHub MCP tool (if available) to:
   • List repo structure and key directories
   • Read core source files
   • Check recent issues and PRs for insights
3. Analyze and report:
   • Overview: What the project does, star count, maintenance status
   • Architecture: How the codebase is organized, key abstractions
   • Tech Stack: Languages, frameworks, dependencies
   • Design Patterns: Notable patterns and design decisions
   • API Surface: Key public interfaces
   • Strengths: What the project does well
   • Weaknesses/Gaps: Limitations or missing features
4. If a focus area is specified, go deeper on that aspect

Research Survey

Conduct a comprehensive research survey combining academic and open-source sources.

Instructions

1. Academic Search: Use WebSearch to find 5-10 recent papers on ${topic} from arxiv, ACL, NeurIPS, ICML, etc.
2. Open Source Search: Use WebSearch to find top GitHub repos related to ${topic} (sort by stars, recency)
3. Industry Search: Look for blog posts, technical reports from major AI labs (OpenAI, Anthropic, Google, Meta)
4. Synthesize findings into a structured report:
   • Executive Summary
   • Academic Landscape (key papers, trends)
   • Open Source Landscape (key projects, comparisons)
   • Industry Trends
   • Gap Analysis
   • Recommendations
5. Write the report to ${output} or repo_pages/surveys/${topic}-survey.md if no output specified
6. Use markdown tables for comparisons, include all source links

arxiv Paper Search

Search arxiv for academic papers related to the given query.

Instructions

1. Use WebSearch to search for: arxiv ${query} and arxiv ${query} 2024 2025 2026
2. For each relevant paper found (up to 10), extract:
   • Title
   • Authors
   • Date
   • arxiv URL
   • Abstract summary (2-3 sentences)
   • Key contributions
3. Present results in a structured markdown table
4. Highlight papers most relevant to agent memory systems if applicable
5. Note any survey/review papers separately as they provide broader context

Benchmark & Compare

Compare multiple agent memory projects across key dimensions.

Instructions

1. For each project in ${projects}:
   • Search for benchmarks, performance reports, and comparisons
   • Analyze the architecture and API design
   • Check community feedback (GitHub issues, discussions, Reddit, HN)
2. Compare across these default criteria (override with ${criteria} if provided):
   • Memory Types: What types of memory are supported
   • Retrieval Strategy: How memories are retrieved (vector, graph, hybrid)
   • Scalability: How it handles large memory stores
   • API Design: Ease of integration
   • Ecosystem: Integrations with LLM frameworks
   • Performance: Latency, throughput if data available
   • Community: Stars, contributors, activity
3. Output a comparison matrix (markdown table)
4. Provide a recommendation summary with trade-offs

Commit Current Changes

Stage and commit pending changes with a conventional-commits message. Does not push. For push + PR, use /push-to-github after.

This repo follows conventional-commits for a consistent history that maps cleanly onto the manually-maintained CHANGELOG.md sections (Added / Fixed / Performance / Changed / Documentation). Releases are manual — versioning and the changelog are bumped by hand on release (the release-please automation was removed).

Hard rules (MUST)

• MUST use conventional-commits format. Type is one of: feat, fix, refactor, perf, docs, chore, test, build, ci, style, revert.
• MUST NOT git commit --amend, git reset, git push, git config, git rebase -i, git commit --no-verify.
• MUST NOT commit files matching: .env*, *.key, *.pem, id_rsa*, credentials*, secrets*, *.db (incl. hebb.db), .claude/scheduled_tasks.lock, any file with secret / password / token in the name. If git status shows any, abort and ask the user.
• MUST stage explicitly by path (git add <paths>) — never bare git add . / git add -A. List what will be staged first.
• MUST create a new feature branch when current branch is main (or master). MUST NOT commit directly to main.
• MUST show the generated commit message to the user and get confirmation before running git commit.
• MUST follow the project's CLAUDE.md — but this skill only ships code that's already in the working tree; it does not author new code.

Pre-flight (run in parallel)

git rev-parse --git-dir                    # in a git repo?
git rev-parse --abbrev-ref HEAD            # current branch
git status --porcelain                     # working tree state
git log -5 --pretty=format:'%s'            # recent commit style reference

If not a git repo → exit.

Workflow

Step 1 — Classify state

From git status --porcelain:

• If output is empty → nothing to commit. Print "working tree clean" and exit.
• Otherwise → continue to Step 2.

Step 2 — Sensitive-file gate

Scan the porcelain output for these patterns:

.env  .env.*  *.key  *.pem  id_rsa*  credentials*  secrets*  *.db  hebb.db
*secret*  *password*  *token*  .claude/scheduled_tasks.lock

If any match, abort:

⚠️ Detected potentially-sensitive paths: <list> Aborting to avoid leaking secrets. Tell me which paths to include (e.g. paths="file1 file2") or add them to .gitignore first.

Step 3 — Inspect changes

git diff --staged                          # already-staged changes
git diff                                   # unstaged tracked changes
git status --porcelain                     # for path classification

Cap each diff output by paths if it's huge — read just enough to classify type/scope.

Step 4 — Generate commit message

Priority: ${message} argument > auto-generated.

If ${message} is provided:

• validate it matches the conventional-commits regex (see Step 5 of /push-to-github)
• use it verbatim
• skip the generation logic, jump to Step 5

If auto-generating:

Type (priority: ${type} argument > auto-detect):

• feat — new functionality, new public API, new CLI command, new endpoint, new module
• fix — bug fix, corrected behavior, error handling fix
• refactor — code change with no behavior change (rename, extract, restructure)
• perf — performance improvement
• docs — only changes under repo_pages/, README*, *.md, or docstrings
• test — only changes under tests/ or eval/
• chore — deps, lockfiles, .gitignore, build config, tooling, .claude/**
• build — only pyproject.toml build section, Dockerfile, packaging
• ci — only .github/workflows/**, .github/dependabot.yml
• style — formatting only (whitespace, quotes), no logic change

When multiple types apply, pick the most user-visible one (feat > fix > refactor > perf > docs > test > chore).

Scope (priority: ${scope} argument > auto-detect):

Subject (after <type>(<scope>): or <type>:):

• Imperative mood ("add foo", not "added foo" / "adds foo")
• Lowercase first letter, no trailing period
• ≤72 chars total line length
• Describe what changed at a high level; specifics go in body

Body (only if non-obvious): one short paragraph on why. Skip for self-evident changes.

Breaking change: if the diff removes/renames a public function, CLI flag, __all__ export, or HTTP endpoint, append ! after the scope (feat(cli)!: rename X to Y) AND add a BREAKING CHANGE: footer describing the migration.

Multiple unrelated changes: if the working tree has 2+ unrelated concerns (e.g. a feature + a docs fix), ask the user whether to:

• (a) make multiple commits — recommended
• (b) bundle them all (use most-prominent type + body listing all changes)

Step 5 — Confirm message with user

Show the user:

About to commit:

  Branch: <current-or-new-branch>
  Files (N):
    M  src/hebb/foo.py
    A  src/hebb/bar.py
    ...

  Message:
    feat(scope): subject line

    Optional body paragraph explaining why.

OK to proceed? [respond yes / edit / cancel]

If user says edit → take their revised message verbatim. If user says cancel → stop, don't commit. If user says yes → continue.

Step 6 — Create branch if on main

CURRENT=$(git rev-parse --abbrev-ref HEAD)

• If CURRENT ∉ {main, master} → reuse it. Skip branch creation.
• Else → derive SLUG from the commit message:
  • take the part after <type>(<scope>): (the subject)
  • lowercase, replace runs of non-alphanumeric with -, trim leading/trailing -
  • prefix with <type>/ (e.g. feat/add-health-endpoint, fix/fts5-stemming)
  • truncate to 50 chars total
  • if git rev-parse --verify "refs/heads/$SLUG" succeeds (branch exists locally) OR git ls-remote --exit-code --heads origin "$SLUG" succeeds (exists on remote), append -2, -3, … until unique
  • git switch -c "$SLUG"

Step 7 — Stage explicit paths

Determine the path list:

• if ${paths} provided → use those exact paths
• else → take all paths from git status --porcelain (excluding the sensitive ones already rejected in Step 2)

Print exactly what will be staged:

Staging:
  M  eval/benchmarks/convomem_bench.py
  M  src/hebb/retrieval/searcher.py
  A  src/hebb/retrieval/lexical_signals.py
  ...

Then:

git add <path1> <path2> ...

Re-check no sensitive files snuck in:

git diff --cached --name-only | grep -E '\.(env|key|pem|db)$|credentials|secrets|password|token|id_rsa' && echo "ABORT"

Step 8 — Commit

Use HEREDOC for safe quoting:

git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>

<optional body>

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
EOF
)"

If a pre-commit hook fails:

1. Read the stderr
2. Decide if the hook is right (e.g. ruff caught a lint issue → fix it; mypy caught a type error → fix it)
3. Fix the underlying issue with Edit
4. Re-stage the affected files: git add <paths>
5. Create a new commit (do NOT --amend)

If the hook reports a non-fixable issue (e.g. a hook config error), abort and tell the user.

Step 9 — Report back

Output:

• Branch name (created or reused)
• Commit SHA: git rev-parse --short HEAD
• Commit subject (first line of message)
• Next step hint: "Run /push-to-github to push and open a PR."

Quick decision tree

working tree clean? ── yes → "nothing to commit", done
   │
   no
   ▼
sensitive files in changes? ── yes → ABORT, ask user
   │
   no
   ▼
generate conventional-commits message ── show to user, get confirmation
   │
   ▼
on main? ── yes → git switch -c <slug-from-message>
   │
   no → reuse current branch
   ▼
git add <explicit paths>     (re-check no secrets in staged)
   │
   ▼
git commit (HEREDOC; no --amend, no --no-verify)
   │
   pre-commit hook fails? ── yes → fix root cause, re-stage, NEW commit
   │
   no
   ▼
report branch / SHA / subject; hint /push-to-github

Failure handling summary

GitHub Repo Explorer

Perform a deep analysis of a GitHub repository.

Instructions

1. Use WebSearch to find the repo's README, documentation, and key discussions
2. Use the GitHub MCP tool (if available) to:
   • List repo structure and key directories
   • Read core source files
   • Check recent issues and PRs for insights
3. Analyze and report:
   • Overview: What the project does, star count, maintenance status
   • Architecture: How the codebase is organized, key abstractions
   • Tech Stack: Languages, frameworks, dependencies
   • Design Patterns: Notable patterns and design decisions
   • API Surface: Key public interfaces
   • Strengths: What the project does well
   • Weaknesses/Gaps: Limitations or missing features
4. If a focus area is specified, go deeper on that aspect

Push to GitHub

Pure "send my committed work upstream" skill. Pushes whatever commits are already in the local branch but not yet on the remote, then opens (or reports) a PR.

Out of scope (handled by /commit):

• Staging files
• Creating commits
• Creating branches
• Anything about uncommitted changes in the working tree

This skill does not look at the working tree at all. Uncommitted files are the user's business; this skill only cares about commits.

Hard rules (MUST)

• MUST NOT run git add, git commit, git stash, or any staging/committing command.
• MUST NOT inspect or report on working-tree cleanliness as a precondition.
• MUST NOT git push --force, git push --no-verify, git reset --hard, git commit --amend, git config, or git rebase -i.
• MUST abort if there are no unpushed commits on the current branch.
• MUST NOT create a PR when on main / master (those are the trunk; pushing there is the release trigger — publish.yml ships to PyPI when pyproject.toml's version changes on main).

Pre-flight (run in parallel)

git rev-parse --git-dir                    # in a git repo?
git remote get-url origin                  # has remote?
gh auth status                             # gh CLI authed?
git rev-parse --abbrev-ref HEAD            # current branch

Bail out if any fail:

Workflow

Step 1 — Find unpushed commits

BRANCH=$(git rev-parse --abbrev-ref HEAD)

# Refresh the remote ref so we have an up-to-date view
git fetch origin "$BRANCH" 2>/dev/null || true

# Three cases:
#   (a) upstream is set → diff against @{u}
#   (b) no upstream but remote branch exists → diff against origin/$BRANCH
#   (c) remote branch does not exist → every local commit on this branch is unpushed
if git rev-parse --verify --quiet '@{u}' >/dev/null 2>&1; then
    UNPUSHED=$(git log --oneline '@{u}..HEAD')
    BASE='@{u}'
elif git ls-remote --exit-code --heads origin "$BRANCH" >/dev/null 2>&1; then
    UNPUSHED=$(git log --oneline "origin/${BRANCH}..HEAD")
    BASE="origin/${BRANCH}"
else
    UNPUSHED=$(git log --oneline HEAD)
    BASE='(new branch — no remote counterpart)'
fi

Step 2 — Abort if nothing to push

If UNPUSHED is empty, abort:

❌ Nothing to push. Local branch <BRANCH> is up-to-date with <BASE>.

If you have uncommitted changes you want to ship, run /commit first.

Stop here.

Step 3 — Show what will be pushed

Print to the user (don't ask for confirmation — pushing committed work is the explicit user request):

Pushing <N> commit(s) on <BRANCH> → origin/<BRANCH>:

  abc1234 feat(retrieval): add lexical signals
  def5678 test(retrieval): add lexical signals tests
  …

Step 4 — Push

git push -u origin "$BRANCH"

Step 5 — PR step (skip when on main / master)

If BRANCH ∈ {main, master}:

• skip PR creation entirely
• in the report, mention: "Pushed directly to <BRANCH>. Releases are manual — to ship, bump the version in pyproject.toml (+ src/hebb/__init__.py, .release-please-manifest.json, .claude-plugin/plugin.json) and add a CHANGELOG.md entry; the pyproject.toml version change on main triggers publish.yml."
• jump to Step 6

Otherwise, check whether a PR already exists for this branch:

gh pr view --json url,state,title 2>/dev/null

• If state == OPEN → skip create; record the existing URL
• If state == MERGED / CLOSED → create a fresh PR (branch was re-used)
• If gh pr view fails (no PR yet) → create

Create:

# Title: ${title} arg if provided, else latest commit subject
TITLE=$(git log -1 --pretty=format:'%s')   # or ${title}

# Body: ${body} arg if provided, else generated from unpushed commit subjects
BODY=$(cat <<EOF
## Summary

$(git log --pretty=format:'- %s' "${BASE}..HEAD")

## Test plan
- [ ] <fill in relevant checks>

🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)

gh pr create --title "$TITLE" --body "$BODY"

Note: the PR title is not validated against conventional-commits in this skill. What matters for the manually-maintained CHANGELOG.md is the commit subjects (authored via /commit or by hand); the PR title is cosmetic.

Step 6 — Report back

Output:

• Branch: <BRANCH>
• Pushed range: <BASE>..<HEAD short SHA> (or "new branch, all commits")
• Commits pushed: <N>
• PR URL (if a feature branch) — newly created or pre-existing
• For main / master pushes: note that releases are manual — a pyproject.toml version bump on main is what triggers publish.yml

Quick decision tree

unpushed commits exist? ── no → ABORT: "nothing to push"
   │
   yes
   ▼
git push -u origin <branch>     (no --force, no --no-verify)
   │
   ▼
branch == main/master? ── yes → done; releases are manual (bump version to publish)
   │
   no
   ▼
gh pr view → state == OPEN? ── yes → report existing URL
                              no  → gh pr create
   │
   ▼
report branch / range / PR URL

What this skill explicitly does NOT do

• Does not read git status or git diff for working-tree changes
• Does not stage, commit, amend, or stash
• Does not create or switch branches
• Does not validate commit messages (that's /commit's job)
• Does not force-push or bypass hooks

If any of those are needed, use /commit first or do it manually before invoking this skill.

Research Survey

Conduct a comprehensive research survey combining academic and open-source sources.

Instructions

1. Academic Search: Use WebSearch to find 5-10 recent papers on ${topic} from arxiv, ACL, NeurIPS, ICML, etc.
2. Open Source Search: Use WebSearch to find top GitHub repos related to ${topic} (sort by stars, recency)
3. Industry Search: Look for blog posts, technical reports from major AI labs (OpenAI, Anthropic, Google, Meta)
4. Synthesize findings into a structured report:
   • Executive Summary
   • Academic Landscape (key papers, trends)
   • Open Source Landscape (key projects, comparisons)
   • Industry Trends
   • Gap Analysis
   • Recommendations
5. Write the report to ${output} or repo_pages/surveys/${topic}-survey.md if no output specified
6. Use markdown tables for comparisons, include all source links