
Claude Skills by vivantel
github.com/vivantelAdd `lint`, a new skill: an on-demand, full-repo validation pass over a project's `docs/{facts,decisions,guardrails,skills}/` tree, independent of what changed in any particular session. It is a separate skill from `steward`, not a mode of it — a third temporal pattern (on-demand, full-scan) distinct from `steward`'s "after a work session" framing and `bootstrap`'s one-time setup, matching this plugin's established pattern of splitting skills by *when* they run rather than bundling multiple temp
Add `query`, a new skill: given a question, search `docs/{facts,decisions,guardrails,skills}/` and answer using only what those artifacts say, citing every artifact the answer drew from as a `Refs:` trailer — the same citation format `attribute` already uses, so this plugin has one citation convention, not two.
Add `brainstorm`, a new skill: given a problem or feature description, produce 5-7 distinct approaches (each with pros, cons, risks, and an effort estimate), then synthesize 2-3 recommended directions. It writes nothing to disk and never queries `docs/{facts,decisions,guardrails,skills}/` — unlike every other skill in this plugin, `brainstorm`'s job is unconstrained ideation, not knowledge-base-grounded work.
Add `onboard`, a new skill: given a role (e.g. "backend dev", "QA", "writer"), read `docs/{facts,decisions,guardrails,skills}/` and produce a 5-day action plan — daily goals, which of this plugin's skills to run and when, and links to the specific artifacts relevant to that role — without writing anything to disk. If critical artifact types are missing entirely (most importantly, no facts at all), the plan says so explicitly rather than producing a plan that quietly assumes context that was neve
Add `refactor-plan`, a new skill: given a refactoring goal, produce a phased plan — (1) query the knowledge base for relevant decisions and guardrails, (2) map dependencies affected by the change, (3) produce step-by-step phases with verification checkpoints and rollback strategies, (4) recommend which facts or decisions need updating once the refactor lands — citing specific artifact paths throughout, and flagging for confirmation any step that would violate a standing guardrail rather than sil
Add `quickstart`, a new skill: run `bootstrap`'s setup (or confirm it's already done), then immediately walk the user through capturing one real, current decision as a full artifact in the same sitting — instead of leaving "now go use `roadmap` sometime" as a cold follow-up action a new user has no particular reason to take next.
Add `uninstall`, a new skill: run manually, before actually uninstalling the `kms` plugin (Claude Code has no uninstall/disable lifecycle hook — see `docs/facts/0007-claude-code-plugin-uninstall-lifecycle.md` — so this can never be automatic). It finds every trace `bootstrap` (or `steward`'s ongoing sync) could have left in the target project:
Add `conform`, a new skill: given a pending changeset — the staged diff by default, or a commit range, or a flexible free-text target like "the last 3 PRs" the agent resolves at invocation time — search `docs/{decisions,guardrails}/` for anything relevant to what the diff touches, and flag any part of it that appears to violate an existing guardrail. Cites every guardrail (and, for context, the decision behind it) by path, the same discipline `query`/`refactor-plan` already use. Read-only: repor
This repo (`vivantel/kms`, working dir `/home/ubuntu/projects/vivantel/kms`) is a Claude Code / Codex plugin marketplace, one plugin (`kms`) at `plugins/kms/`. See `AGENTS.md` at the repo root, and now also `docs/skills/kms-architecture.md`, for full structure before making any change not covered by this plan. This plan came out of a `roadmap` interview; see `docs/decisions/0031` through `0033` for the decisions it recorded.
Write commit messages and PR descriptions that lead with intent (why, not what), using Conventional Commits type prefixes and Refs: trailers linking to docs/{facts,decisions,guardrails,skills}/ artifacts. Use when the user wants to commit changes with attribution, or generate a PR description, e.g. \"commit this with attribution\", \"write a PR description for this branch\".
One-time setup of a fact/decision/guardrail/skill knowledge system in a project that has none yet, or a gap-fill pass over one that's incomplete — extract intents from git history, extract facts from existing docs, audit guardrails for missing derivation, and inventory fitness functions. Use when the user wants to set up knowledge management for a project, e.g. "bootstrap the knowledge system here", "set up facts/decisions/guardrails for this repo".
Generative ideation partner that explores multiple approaches to a problem or feature without writing anything or consulting the knowledge base. Use when the user wants options generated before any decision exists, e.g. "brainstorm approaches for implementing websocket reconnection logic", "what are some ways to solve X".
Turn what a work session produced into durable knowledge — draft new decisions, update changed facts, flag contradictions, catch human-doc drift. Use after a work session that touched decisions, facts, or documented behavior, e.g. "run the knowledge check", "did anything here need capturing as a decision or fact".
Generate a CHANGELOG.md entry from git commit history (since the last tag, or full history if none exists), grouped Keep a Changelog style from Conventional Commit type prefixes and Why-bodies. Use when the user wants a changelog produced or updated, e.g. "generate a changelog", "update the changelog for this release".
Interview the user relentlessly about a plan, decision, or idea until reaching shared understanding. Use when the user wants their thinking stress-tested, or asks to be "grilled" or "interviewed".
Checks whether a pending changeset conforms to existing decisions and guardrails before it lands. Use before committing or merging, e.g. "does this diff conform to our guardrails", "check this PR against what we've decided", "conform check the last 3 PRs".
Full-repo validation pass over a project's fact/decision/guardrail/skill knowledge system — dangling references, stale prose cross-references, missing required fields, numbering collisions, expired decisions, redundant guardrails, audit-log-style facts, verbosity, and stale derived artifacts — independent of what changed this session. Use when the user wants the whole knowledge base checked for health, e.g. "lint the knowledge base", "check the whole docs/ tree for problems".
Creates a role-specific onboarding plan from a project's existing knowledge artifacts, without writing anything. Use when the user wants a ramp-up plan for a specific role, e.g. "onboard me as a frontend developer for this project", "what should a new QA hire read first here".
Answer a question from a project's fact/decision/guardrail/skill knowledge base, with citations to the artifacts the answer is drawn from — never from memory or inference when the knowledge base already has the answer. Use when the user asks what was decided, why a rule exists, or what's currently true about the project, e.g. "what did we decide about X", "why does this guardrail exist".
Sets up a project's knowledge system and captures one real decision live, in the same sitting, so the value is felt immediately rather than left for later. Use when a user is trying this plugin for the first time, e.g. "get me started with this", "set this up and show me how it works".
Produces a safe, phased refactoring plan that respects existing decisions and guardrails, without writing anything. Use when the user wants a refactor planned against what the project has already committed to, e.g. "plan a refactor of the payment module to use Stripe instead of Braintree", "plan migrating from REST to GraphQL".
Interview the user about a plan or decision, then capture the outcome as durable knowledge-management artifacts (facts, intents/decisions, guardrails, procedures) plus a self-sufficient standalone roadmap. Use when the user wants a decision captured as project knowledge — not just discussed — e.g. "interview me and save this as knowledge", "capture this as an ADR", "turn this into a roadmap".
Finds everything bootstrap/capture added to this project and offers to detach or remove it, before you actually uninstall the kms plugin. Use when a team is winding down use of kms, e.g. "we're uninstalling kms, clean up what it added", "remove kms's guardrails from this repo".