keystone

Plugin keystone from marketplace keystone in j-loyd/keystone. Commands read from the repo's manifest — 4 days ago.

Skills (33)

• api-security

  Security review for APIs — the OWASP API Security Top 10 (2023) for REST, GraphQL, and webhooks / third-party consumption, with the idempotency, SSRF, and inventory details reviews usually miss. Use when building or reviewing any endpoint, resolver, webhook receiver, or outbound API call. Pairs with

• audit

  Scan for over-engineering and report what to cut — reinvented stdlib, unneeded dependencies you could drop or inline, abstractions with one caller or that nobody needed, dead flexibility. Use when the user says "audit this codebase", "what can I delete", or "is this overbuilt". Scope boundary — code

• brief

  Turn technical work (a spec, PR, ticket, design note, or the current session) into a one-page plain-English brief a business reader can understand and act on, leading with what you need from them (approve, choose, or just know). Use when the user runs /brief.

• challenge

  Use to stress-test a finished doc — a spec, plan, PRD, or ADR — before building from it, and when the user says "challenge this" or "attack the assumptions". A reviewer with zero authorship memory (ideally a different model) enumerates and attacks the doc's assumptions AND challenges whether its cho

• codebase-design

  Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

• cso

  Chief Security Officer audit — infrastructure-first review covering secrets, supply chain, OWASP Top 10, LLM/agent security, and a STRIDE threat model. Use when the user runs /cso before shipping anything sensitive.

• debt

  Harvest deliberate-shortcut markers (keystone comments) into a ledger and flag the ones with no revisit trigger — the kind that silently become permanent. Reports only; optionally persists. Use when the user runs /debt.

• designing-agent-systems

  Decide the shape of anything agent-shaped before building it — LLM tool loops, subagent dispatch, orchestration topology, HITL gates, effort and budget. Use when the user says "should I use an agent", "one agent or many", or "orchestrator", or when agent code is about to be written with no design no

• domain-modeling

  Build and sharpen a project's domain model. Use when discussing codebase terminology (which word to standardize on), writing or editing a GLOSSARY.md, or recording or editing an ADR.

• finishing-a-development-branch

  Decide how to land completed work — merge, PR, or discard. Use when implementation is done and tests pass, and when the user says "ready to merge", "open a PR", or "clean up this branch". Presents options and never commits or pushes on its own.

• grill-with-docs

  Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates the docs (GLOSSARY.md, ADRs) inline as decisions crystallise. Use when the user wants to stress-test a plan against their project's language and documented decisions.

• grilling

  Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

• guard

  Keystone's opt-in safety modes in one skill — fence Edit/Write to a directory, ask before destructive shell commands, or both, then lift them. Use when the user runs /guard (freeze, careful, on, off, or status) to protect a sensitive or shared repo.

• handoff

  Write a forward-looking resume note for the current work — what's done, what's next, and the gotchas — so a fresh session can pick up mid-task without re-deriving everything. Use when the user runs /handoff before pausing, a context reset, or handing work to another session. Resume it with /pickup.

• implement

  Build a spec's tickets on one integration branch — an implementer subagent per unblocked ticket in its own worktree, merge as each lands, then one final review. Re-running resumes from the frontier. Use when the user runs /implement after /spec and /to-tickets.

• improve-codebase-architecture

  Find deepening opportunities in a codebase, informed by the domain language in GLOSSARY.md, the decisions in docs/adr/, and the structural map in docs/codebase/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase m

• investigate

  Root-cause a bug, test failure, or unexpected behavior before proposing any fix — reproduce, confirm the cause, then fix with a regression test. Escalates to an architecture question after three failed fixes. Use when the user runs /investigate with a symptom.

• llm-security

  Security review for LLM and agent code — prompt injection, tool/output abuse, data exfiltration, excessive agency, RAG/memory poisoning. Use when building or reviewing anything that calls an LLM, runs an agent loop, exposes tools to a model (especially destructive ones like delete, send, or pay), do

• long-running-agents

  Use when designing or reviewing agent work that outlives one context window or one sitting — overnight/autonomous runs, recurring or scheduled agents, "keep going until it's done" loops, or any run needing budget ceilings and stuck-loop detection. Trigger on continuous loops, cron/scheduled agents,

• onboard-codebase

  Orient in a codebase on first contact and leave a durable map behind — detects greenfield vs. brownfield and writes a docs/codebase/ map plus seeded domain docs. Use when the user runs /onboard-codebase in an unfamiliar repo.

• pickup

  Resume interrupted work — pick up where you left off by reading the newest open /handoff note and the open tickets, reconciling them with git, and continuing without restarting. Use after the context is compacted, after a crash, or after a deliberate /handoff. (Named pickup, not resume, to avoid col

• qa

  Systematically QA a running web app in a real browser — execute test scenarios, find bugs, grade the result, and (optionally) fix them. Use when the user runs /qa with a URL and what to exercise.

• receiving-code-review

  Evaluate review feedback on its merits before acting on it. Use when a reviewer, agent, or CI leaves comments and the user says "address the review" or "is this feedback right", or pastes review output. Verify each claim and push back on the wrong ones rather than complying reflexively.

• resolving-merge-conflicts

  Work through an in-progress merge or rebase conflict hunk by hunk, resolving by intent rather than by picking a side, then finish the operation. Use when git reports conflicts, a rebase stops mid-stack, or the user says "fix the conflicts", "this won't merge", or "I'm stuck in a rebase". Covers sema

• security-review

  Review code you wrote for exploitable vulnerabilities by tracing untrusted input to dangerous sinks. Use when adding auth, handling user input or file uploads, creating endpoints, working with secrets or payments, and when the user asks "is this secure" or "security review this". Anchored to OWASP T

• setup

  Configure a repo for /spec, /to-tickets, and /implement — where tickets live (local .scratch/ files by default; GitHub, GitLab, or Linear optional), the label vocabulary, and the domain-doc layout (GLOSSARY.md + ADRs). Use when the user runs /setup, once per repo, or to switch trackers.

• ship

  Prepare a change to ship — run tests, review the diff, bump VERSION, update CHANGELOG, and draft the PR. Stops before committing; commits/pushes only on explicit go-ahead. Use when the user runs /ship.

• spec

  The single entry point for building a feature — interview if fuzzy, write the spec with an integrate-first section and an over-engineering gut check, break it into tickets, then hand off to /implement. Use when the user runs /spec with an idea, a problem, or a path to a draft.

• to-tickets

  Break a spec, plan, or the current conversation into tracer-bullet tickets, each declaring its blocking edges, and publish them to the configured tracker (one local file per ticket by default). Use when the user runs /to-tickets, or when /spec reaches its tickets step.

• using-git-worktrees

  Get an isolated workspace before risky or parallel work. Use when the user says "do not touch main", "run these in parallel", or "use a worktree", or before executing a plan that spans many files. Prefers native harness isolation, falls back to git worktree.

• variant-analysis

  After finding one bug or vulnerability, systematically find every other instance of the same pattern across the codebase. Use immediately after any bug fix, security finding, or code-review issue — before closing it out — and when asked to "find similar issues", "check if this happens elsewhere", or

• verification-before-completion

  Run the check and read its output before claiming anything works. Use before saying done, fixed, passing, or "should work", before opening a PR, and when the user asks "did you actually run it" or "are you sure". Evidence first — a completion claim with no command behind it is a guess.

• wrap

  End a work session by saving what would otherwise be lost — one question, a candidate list, and the user picks what to keep (repo lessons, decisions, corrections, drops, open items). Use when the user is calling it a day, at a natural stopping point after a fix or feature lands, or to note what is w

Subagents (3)

• code-reviewer

  Reviews a diff for production-readiness — correctness, safety boundaries (SQL, secrets, LLM trust), scope, and reuse — and returns a PASS/CONCERNS/FAIL verdict. Dispatch it for a pre-merge review so the review runs in its own context, unanchored by the implementation reasoning.

• implementer

  Implements one ticket against the real codebase — writes the failing test first, follows existing patterns, edits code. The only crew member who writes implementation code. Dispatched per ticket by /implement, one worktree each.

• security-reviewer

  Audits code/diffs for security issues by tracing untrusted input to dangerous sinks and adversarially verifying each finding. Covers OWASP Top 10 (2025), API Top 10 (2023), and the LLM Top 10 (2025) via the security-review, api-security, and llm-security skills. Dispatched by /cso.

Hooks (10)

• SessionStart

  R="${CLAUDE_PLUGIN_ROOT}"; [ -f "$R/hooks/instincts.js" ] || R="${PLUGIN_ROOT}"; if [ -f "$R/hooks/instincts.js" ]; then node "$R/hooks/instincts.js"; else echo '{"systemMessage":"keystone: instincts.

• SessionStart

  R="${CLAUDE_PLUGIN_ROOT}"; [ -f "$R/hooks/learnings.js" ] || R="${PLUGIN_ROOT}"; if [ -f "$R/hooks/learnings.js" ]; then node "$R/hooks/learnings.js"; else echo '{"systemMessage":"keystone: learnings.

• SessionStart

  echo '{"hookSpecificOutput":{"hookEventName":"SessionStart","additionalContext":"Context was just compacted. Re-orient before continuing: check task progress against the original request. If you were

• SessionStart

  echo '{"hookSpecificOutput":{"hookEventName":"SessionStart","additionalContext":"Session started. If in-flight work exists in this repo, read docs/handoffs/README.md (the continuity index: newest hand

• PreToolUse

  R="${CLAUDE_PLUGIN_ROOT}"; [ -f "$R/hooks/guard.js" ] || R="${PLUGIN_ROOT}"; if [ -f "$R/hooks/guard.js" ]; then node "$R/hooks/guard.js"; else printf '%s' '{"hookSpecificOutput": {"hookEventName": "P

• PostToolUse

  R="${CLAUDE_PLUGIN_ROOT}"; [ -f "$R/hooks/scan.js" ] || R="${PLUGIN_ROOT}"; if [ -f "$R/hooks/scan.js" ]; then node "$R/hooks/scan.js"; else S="${CLAUDE_SESSION_ID:-nosession}"; M="${TMPDIR:-/tmp}/key

• PostToolUse

  jq -r '.tool_response.filePath // .tool_input.file_path' | { read -r f; case "$f" in *.py) command -v ruff >/dev/null 2>&1 && ruff format "$f";; *.js|*.ts|*.jsx|*.tsx|*.json|*.css|*.scss|*.html|*.md|*

• Notification

  command -v afplay >/dev/null 2>&1 && afplay /System/Library/Sounds/Tink.aiff || true

• Notification

  R="${CLAUDE_PLUGIN_ROOT}"; [ -f "$R/hooks/notify.js" ] || R="${PLUGIN_ROOT}"; [ -f "$R/hooks/notify.js" ] && node "$R/hooks/notify.js" || true

• Stop

  command -v afplay >/dev/null 2>&1 && afplay /System/Library/Sounds/Tink.aiff || true

Similar plugins