skills-jk - SKILL.md Agent Skill

name: skills-jk description: Use when working in the skills-jk repository or maintaining this repo-local Hermes setup; contains migrated repo-specific memory and user preferences. version: 1.0.0 author: Hermes Agent license: MIT metadata: hermes: tags: [repo-context, migrated-memory] related_skills: []

Skills Jk

Overview

This skill is a compact trigger/index for repo-specific context migrated out of .hermes/memories/MEMORY.md and .hermes/memories/USER.md so global memory stays focused on durable user preferences rather than repository implementation details.

Load this skill before substantial work in the named repository or platform area. The detailed migrated notes are kept in references/migrated-memory-and-user-context.md.

When to Use

The current task is in or about skills-jk.
The user asks about prior conventions, repo-specific constraints, route/content policy, migration status, or operational quirks for this area.
You are about to edit code, documentation, GitHub wiki pages, CI, deployment, or infrastructure connected to this area.

Required Context

Read references/migrated-memory-and-user-context.md after loading this skill. Treat entries from USER.md as user preferences/constraints and entries from MEMORY.md as repo facts or workflow lessons. If a note is stale when checked against the live repo, update this skill or its reference rather than writing the stale fact back into global memory.

Common Pitfalls

For skills-jk open-PR repair sweeps, inspect every open PR, use isolated .worktrees/ when the root checkout is dirty, rebase each PR branch onto latest origin/main, preserve both sides of skill/reference-list conflicts when both are valid additions, push with --force-with-lease only after confirming the PR is still open and the head ref/SHA match, then re-read final PR states. Detailed reusable workflow: github-pr-workflow reference references/open-pr-sweep-rebase-conflict-resolution.md.
Do not copy repo-specific facts back into global memory unless they are broadly reusable across repositories.
Do not treat migrated notes as a substitute for live repo verification when code, CI, routes, or deployment state may have changed.
Keep new findings in this skill or a more specific existing skill for the repo/workflow.
For this repo-local Hermes setup, user-facing preferences and configuration changes are repo-managed by default. Track durable config/profile files such as .hermes/config.yaml, .hermes/profiles/<profile>/config.yaml, and .hermes/profiles/<profile>/SOUL.md; keep secrets and runtime state such as .env, sessions, logs, cron output, auth/state DBs, and process files ignored.
When maintaining bin/gh-runners, keep busy-job lookup interactive by default: scan the small, evidence-ranked high-runner-usage repo set first, keep --busy-repo for exact targeting, and require --scan-all-repos for the expensive full organization scan. Also truncate display-only workflow/job/title fields because GitHub job metadata can include very long PR/body text. Detailed workflow: references/gh-runners-busy-repo-scan-scope.md.
When curating or migrating skills into skills-jk, keep the library class-level: prefer rich umbrella skills plus references/ detail over many narrow one-session skills. Do not duplicate a repo-local skill that already exists in another repository's .hermes/skills; leave that repo-specific source of truth in its owning repo and only keep genuinely reusable cross-repo procedures here.
Before adding any new .hermes/skills/**/references/*.md file, run the reference dedupe preflight in references/reference-dedupe-preflight.md. Patch the canonical owner reference when the lesson is a repeated incident or clarification rather than a new durable topic.
When turning analysis or improvement recommendations into PRs, split work by allowed surface. If the user excludes Hermes Agent source-code changes, do not touch ~/.hermes/hermes-agent code; create only repo-local skills/docs/config/profile changes under skills-jk, using separate PRs for distinct improvements.
Repo-dependent workflow skills and gates do not belong in global/user-scope agent guidance. If a workflow is tied to one repository (for example reverse-sync), keep its detailed SKILL.md and AGENTS.md trigger in the owning repository context, and remove global ~/AGENTS.md / ~/.codex/skills/ copies rather than preserving them as user-wide constraints.
During skill-library/refactor work, Hermes may generate same-session repo-managed residue such as .hermes/config.yaml skills.disabled edits, new skill references, or one-line pointers in loaded skills. Treat those as a separate scope unless the user asked for that config/skill-index change. Back them up, restore or split them into their own PR, and loop git status --short --branch until root main is clean before reporting completion.
When editing root-level governed/memory directive skills under skills/, write the guidance as shared Hermes/Codex policy rather than Hermes-only policy unless the behavior is truly tool-specific. For shared durable directives, explicitly point agents to workspace/skills-jk/skills/ as the repo-managed storage location and prefer updating an existing owner skill there before creating a new skill.

Verification Checklist

Skill loaded because the task matches skills-jk.
Migrated context reference reviewed when repo-specific history matters.
references/reference-dedupe-preflight.md reviewed before adding a new skill reference file.
Live repo/source checked before acting on potentially stale implementation details.