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 skills add open-latch/latch --skill source-command-latch-seedgit clone --depth 1 https://github.com/open-latch/latchWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/open-latch/latch/source-command-latch-seed)<a href="https://agentmods.dev/skills/open-latch/latch/source-command-latch-seed"><img src="https://agentmods.dev/badge/skills/open-latch/latch/source-command-latch-seed/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/open-latch/latch/source-command-latch-seed"><img src="https://agentmods.dev/badge/skills/open-latch/latch/source-command-latch-seed.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00037 | $0.00899 |
| Opus 5.5 | $0.00015 | $0.00360 |
| Sonnet 5.5 | $0.00007 | $0.00180 |
| Haiku 4.5 | $0.00004 | $0.00090 |
Grade A, and why
source-command-latch-seed 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 1mo ago.
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.
What it actually says
Latch seed for Cursor
Latch operation id: latch-seed preview
Latch Cursor skill boundary: use only the current sessionStart marker or a
transcript path the user explicitly supplied. Never scan private Cursor history
directories.
Read the exact Latch Cursor current session id from the current prompt context;
the beforeSubmitPrompt hook re-injected it from this chat's payload. Pass
--cursor-session-id ID to the wrapper. Never omit it or reuse an id from
another chat.
Before any Shell call, read the workspace .cursor/mcp.json and use
mcpServers.latch.env.LATCH_PYTHON when present, otherwise
mcpServers.latch.command, as <CURSOR_MCP_PYTHON> and LATCH_PYTHON. Never fall back to a
PATH python3; the MCP interpreter owns latch's native dependencies.
Use latch_home only to construct the absolute wrapper path. Do not export
LATCH_HOME or CLAUDE_KB_HOME in the Shell call; managed Cursor operation
receipts do not allow those environment assignments.
Resolve latch_home as ${CURSOR_PLUGIN_ROOT} when set, otherwise use the
absolute checkout in the project-sync footer. Select native cursor for plugin
installs or the backend in that footer. Run the host-appropriate bin/latch_seed.sh or .ps1
wrapper with --source cursor --format json and the seed/model backend
environment set. First run preview-only and show the receipt/candidates. The
first Shell call must request Cursor required_permissions: ["all"], because
the wrapper writes latch-owned budget/session state outside the open workspace.
Do not make a sandboxed attempt first and retry with permission: the managed
preview receipt is one-shot and consumed by the first exact attempt. Cursor's
normal user-approval flow still applies, and this does not authorize apply. The
attempt alone does not arm apply: only a matching successful JSON result
verified by postToolUse does. Failed, malformed, missing, cross-session, or
unexecuted previews require a new preview. Only after the user reviews that
preview, ask for an exact selection-bearing confirmation:
- Whole report:
/latch-seed apply all - Reject the whole nonempty report:
/latch-seed apply none - Scoped:
/latch-seed apply <ID> [<ID> ...], with every approvedcand-...and/orcluster-...review ID as a separate space-delimited token, for example/latch-seed apply cand-0123456789ab cluster-abcdef012345.
Bare /latch-seed apply, prose standing in for IDs, duplicate IDs, and
all/none mixed with IDs are invalid. The managed receipt validates every
scoped ID against the bound preview and records only that exact selection.
none is valid only after a successful preview containing at least one
candidate.
For whole-report confirmation, rerun with
--preview-digest DIGEST --apply --yes. For reject-all confirmation, rerun with
--preview-digest DIGEST --apply --dismiss-all; never add --yes or an
approval selector. For scoped confirmation, omit --yes and translate exactly
the confirmed tokens to --approve-candidate ID and/or --approve-cluster ID;
do not add, remove, or substitute IDs. Unselected items are dismissed for those
exact source revisions. Use the exact returned JSON preview_digest. Apply
must load the cached reviewed candidates without a second model call; a
missing, changed, or stale digest, malformed confirmation, or unknown ID is a
hard stop. The apply Shell call must again request Cursor
required_permissions: ["all"] on its first and only attempt because it writes
staging KB state outside the workspace and consumes a one-shot receipt. Report
inserted staging node ids and the catch-demo command. A missing/mismatched
marker is a hard stop.
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.
- 1mo ago First seen · 68 lines · 37 tokens per session scan A a013daee60d4
source-command-latch-seed is a skill published in the GitHub repository open-latch/latch (9 stars, last pushed 10d ago), licensed Apache-2.0. It adds 37 tokens to every session and 899 once invoked, about $0.0001 per session on Opus 5.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-31.
Other skills, from other repositories
ctx
Use ctx as working memory for prior agent work. Before starting or continuing work in an unfamiliar area, resuming earlier work, or revisiting an investigation, search prior sessions to ground yourself in earlier context. Use ctx blame to trace a line, file, commit, or PR to the agent session that produced it. Use…
personalize-ai-assistant
Build or update privacy-first AI-assistant configuration and reusable preference skills for Codex, Claude Code, Cursor, Gemini CLI, and similar tools. Use when the user provides explicit preferences, existing config files, example rules, or asks to optimize AGENTS.md, CLAUDE.md, assistant rules, memory files, or…
krimto-write-fact
Use when the user asks you to remember something for later, save team knowledge, record a decision, or note a durable fact about the project, person, or team. Triggers on "remember that", "save this", "add to memory", "note for the team". Do not use for conversational context.
krimto-hierarchical-scope
Use when deciding what scope to store a fact at, or when reasoning about whether a fact applies to the current user. Krimto uses a user -> team -> org hierarchy with precedence rules. Triggers when scope selection is required.
krimto-recall-team
Use when starting a task, joining a conversation about a project, or before answering a question that needs team context. Triggers on "what do we know about X", "team's approach to Y", or before any domain-specific work.
project-knowledge-maintainer
Maintain a project-level knowledge base for coding agents using AGENTS.md, knowledge files, bug memory, decisions, and changelog records.