Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/pascalebeier/hitkeep/hitkeep-workspacenpx skills add PascaleBeier/hitkeep --skill hitkeep-workspacegit clone --depth 1 https://github.com/PascaleBeier/hitkeepWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00056 | $0.00660 |
| Opus 5 | $0.00028 | $0.00330 |
| Sonnet 5 | $0.00011 | $0.00132 |
| Haiku 4.5 | $0.00006 | $0.00066 |
Grade A, and why
hitkeep-workspace scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 35 lines — stays where its author put it; the contents beside it link to each section on GitHub.
HitKeep Workspace
Treat AGENTS.md as policy and hk as the live workspace authority. Git worktree creation and deletion remain external responsibilities. Never infer workspace identity from the directory name or branch.
Inspect First
Use these local developer MCP operations whenever they are callable:
hk_contextfor the current worktree, workspace list, ports, URLs, catalog, handoff, and compact runtime/cache health.hk_run_statusfor asynchronous work and bounded cursor-addressed run or gate logs.hk_dev_start,hk_dev_status, andhk_dev_stopfor this worktree's container-only development generation; stopping requires its exact observed generation ID.hk_run_startfor setup, QA, builds, and smokes.hk_screenshotfor batched, workspace-managed visual-QA artifacts from the active local session.hk_run_cancelfor one exact observed active run.
Do not invoke equivalent workspace or run CLI commands unless the relevant MCP tool is not callable, the registration, startup, root-routing, or task-reload blocker has been reported, and the user has given explicit user approval. After approval, discover the equivalent command through ./hk catalog commands --output json, request --output json, and add --detach for action parity. Do not parse terminal prose.
Always use the workspace ID, Compose project, paths, ports, URLs, development event cursors, and finite-operation run IDs returned by hk. Verify an envelope's workspace ID before using a cursor or run ID. Never assume conventional ports are free or share mutable state between worktrees.
Operate
- Inspect status, the development session, and active finite runs before setup, browser work, e2e, or QA. Reuse equivalent active work rather than duplicating it.
- Query the live variant catalog, then start the container-only development session only when the task needs services.
- Development start streams until ready or failed and requires no session ID. Finite operations return run IDs and are polled with reasonable intervals. Do not treat client disconnect or a slow call as failure.
- Read bounded log tails for diagnosis. Carry
next_cursorinto subsequent development or run reads so repeated polling does not reload old output. Use returned artifact paths for complete local diagnostics instead of loading full logs into context. - Stop development with the workspace-scoped stop operation. Cancelling a development log observer never stops services; finite run cancellation still targets one validated run ID.
- Before handoff, refresh status and request handoff context. Report workspace ID, active runs, usable URLs, changed-path summary, failures, and the next safe action.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 35 lines · 56 tokens per session scan A 3010615c28a7
hitkeep-workspace is a skill published in the GitHub repository PascaleBeier/hitkeep (85 stars, last pushed 2d ago), licensed MIT. It adds 56 tokens to every session and 660 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
dd-code-generation
Use pup CLI for immediate Datadog operations or generate code for integration into applications.
authoring-ci-workflows
Use when adding or editing a GitHub Actions workflow, composite action, or reusable workflow under .github/ — new CI jobs, triggers, matrices, checkout/clone tuning, action pinning, GitHub App token auth, concurrency groups, timeout-minutes, paths filters, caching, or runner choice. Covers PostHog's workflow-authoring…
monitoring-capture-service
Guide for using the Grafana MCP to monitor and diagnose the capture service (rust/capture) in production. Use when investigating latency, event loss, Kafka backpressure, Redis issues, rate limiting, Envoy proxy issues, or any capture health question. Covers prod-us and prod-eu environments.
qa-frontend
Internal PostHog developer frontend/browser QA skill. Use only when a PostHog developer explicitly asks to run frontend QA, browser-test a PR, verify a UI flow against the local PostHog stack, use qa-frontend, or QA current frontend changes with browser/runtime evidence. Do not use for generic code review, PR review…
building-product-empty-states
Guide for adding a product setup empty state — the skippable first-run screen a product scene shows until real data arrives, built on the shared ProductEmptyState component. Use when adding an empty state or first-run/setup screen to a product scene, declaring emptyState on a SceneExport, writing a product…
django-migrations
Django migration patterns and safety workflow for PostHog. Use when creating, adjusting, or reviewing Django/Postgres migrations, including non-blocking index/constraint changes, multi-phase schema changes, data backfills, migration conflict rebasing, and product model moves that require SeparateDatabaseAndState. Also…