Skills
Skills live in home/exact_dot_agents/exact_skills/exact_k-<name>/ and deploy to ~/.agents/skills/k-<name>/SKILL.md.
Claude Code, Pi, OMP, Codex, and OpenCode read the same tree. A model-invoked skill loads when its description matches the request. Manual skills require explicit invocation or an authorized handoff; reading their files alone does not authorize their workflows.
Skills provide task procedures. The global operating rules govern delegation, approvals, verification, and memory writes.
README writing
k-readme is model-invoked for README creation, edits, and reviews. k-code-quality also loads it when a repository task touches a README.
It applies ReadmeRoast to an existing local file after drafting, then checks each finding against the project and the requested scope.
Scores are advisory: factual accuracy and useful examples matter more than reaching 100. Curated lists and internal READMEs do not need artificial install or screenshot sections.
The CLI is pinned in the pnpm package list and installed through the pnpm package workflow. The skill checks that the file exists before invoking the CLI, preventing an already-missing path from reaching its GitHub mode. External URLs and heading anchors are outside the CLI's link check. If the binary is unavailable, the skill uses its rubric without claiming a score.
Anti-slop writing and UI
k-anti-slop covers all six antislop domains and adds local guidance for technical documentation, interface copy, data displays, and localization.
Its nine references load by the requested change; a narrow edit does not load every category present in the surrounding artifact.
k-code-quality loads it for every edit or review, so the shared reviewer prompt gets it on every review; k-code-quality-web, k-communication, k-readme, and generated-content work in k-artifact route matching work to it. It preserves facts, intended voice, and design direction; existing SOP verification and approval rules remain authoritative.
The bundled Python contrast calculator runs locally without an MCP server. See the inspection, coverage, and adoption decisions.
Review and verification
Prefer the smallest in-scope design that rules out the error class in application logic and data. Tests protect its observable invariant; see the global rules and design principles.
Comments retain required directives or critical non-obvious constraints. Material implementation changes need durable behavioral coverage: reuse existing tests and add only missing protection. Static checks and disposable probes do not replace it. The comment and test guidance define case selection, independent oracles, and removal of redundancy.
After a prototype question is settled, record its verdict in the task record and delete or absorb the prototype within authorized scope. Absorbed material behavior needs the same durable coverage; scheduled cleanup is not completion.
k-review handles local changes, PRs, feedback, and plans. Verify freezes scope and acceptance, launches two fresh reviewers, and fixes supported findings through unbounded rounds. Narrowed and fix-diff reviews do not replace the closing whole-scope round. The loop ends with no new supported medium-or-higher finding and its low findings fixed; recurring-cause stopping rules remain with the fix procedure.
The review skill defines exact targeting, evidence, baseline, and reporting requirements. k-light-review covers small, self-authored, low-risk changes inline; both routes use k-code-quality and the relevant secondary guidance.
Review targets and the Verify workflow are separate choices. Local fixes follow the canonical authorship rules, including explicit requests to fix another author's work.
k-communication preserves relevant domain facts while excluding session provenance. It keeps related facts together and asks a closing question only when the recipient has something to decide or do.
Review queues reuse verified evidence only while its source and check inputs still match the saved snapshot, including local uncommitted and untracked files. Changed inputs refresh only the affected evidence and checks. A saved PR discussion must have been read completely before it can support a conclusion.
k-diagnosing-bugs puts an unresolved runtime criterion under Open: with the missing evidence or check as its blocker. k-code-quality-web reports static evidence under Checked: and claims requiring a live check under Open:. The evidence ledger excludes quoted and fenced examples, including fences inside lists, from report-citation checks.
Catalog
| Skill | Use | Invocation |
|---|---|---|
k-ai-kb | Use to search past-session knowledge with ,ai-kb before working on a subsystem or unfamiliar error, or to store a verified reusable gotcha or recipe. | |
k-anti-slop | Use when writing or reviewing prose, technical docs, UI, accessibility, responsive or localized content, data displays, or code comments. | |
k-artifact | Use for cache-only HTML artifacts, visual reports/diagrams, or live-page overlays without worktree writes. | |
k-behavior-map | Use before and after changing code in a git repo: collects the change's impact list (what it can break, and what new behavior must fit), checks it against the per-repo behavior map with ,behavior-map, maps unmapped areas, and maintains entries (area init, update, add, refresh, promote, resolve). | |
k-build | Manual-only recipe to implement an approved spec inline, with necessary checks and one verification run on the finished change. | manual |
k-cleanup | Use before reporting finished work: remove task leftovers, restore your stashes, keep branches and worktrees. | |
k-cli-skills | Use when creating a new CLI tool skill or upgrading an existing CLI skill to a newer installed version. | |
k-code-quality | Use when editing, reviewing, refactoring, or de-slopping implementation code or any repository artifact. | |
k-code-quality-react | Use when editing, reviewing, or refactoring React/JSX/TSX components, hooks, or client-side UI behavior. | |
k-code-quality-tests | Use when adding, editing, reviewing, or debugging tests or test plans. | |
k-code-quality-web | Use for browser-rendered markup, CSS, layout, visual states, accessibility, or focus behavior edits/reviews. | |
k-codebase-design | Use for module interfaces, seams, deepening, testability, AI navigation, or deep-module vocabulary. | |
k-communication | Use when drafting human-visible communication; apply canonical tone/style before external text. | |
k-compose-issue | Use when drafting GitHub issue title/body or publication packet; no gh side effects. | |
k-compose-pr | Use when drafting PR title/body or publication packet; no gh side effects. | |
k-diagnosing-bugs | Use for hard bugs, regressions, flaky failures, crashes, thrown errors, or slowness. | |
k-git | Use for local git operations: status, diff, log, staging, branches, commits, pushes, rebases, conflicts. | |
k-github | Use for GitHub effects and GitHub issue context/targeting: PRs, issues, comments, reviews, labels, releases, merges, gists, attachments. | |
k-google-workspace | Use for gws Google Workspace: Gmail, Drive, Calendar, Docs, Sheets, Slides, Forms, Contacts, Chat, Tasks, Apps Script. | |
k-handoff | Use when the user says handoff, save a handoff, continue, resume, or pick up <topic>, or switches harness mid-task; writes or reads a cross-harness session note with ,handoff. | |
k-improve-branch | Manual-only: propose one evidence-backed improvement to the current branch, PR, or issue goal. | manual |
k-improve-codebase | Manual-only: propose one evidence-backed improvement to the current codebase. | manual |
k-improve-local | Manual-only: propose one evidence-backed improvement to the local changes. | manual |
k-improve-targeted | Manual-only: propose one evidence-backed improvement to a targeted part of the codebase. | manual |
k-instruction-boundaries | Use when writing or refactoring AI-facing instructions; define forbidden behavior with hard boundaries and add affirmatives only when they sharpen execution. | manual |
k-interview-me | Interview the user until you have 100% confidence about what they actually want. | manual |
k-jscpd | Use for duplicated-code checks during refactors, cleanup, DRY work, clone investigation, or jscpd reporting. | |
k-knip | Use when finding unused JS/TS files, deps, exports, package entries, or missing/unlisted deps with knip. | |
k-letsfg | Use when searching flights, fares, routes, airlines, dates, or prices with LetsFG connectors. | |
k-light-review | Use for one quick inline review of a small, low-risk, self-authored local change. | |
k-live-ui-windows | Manual-only Windows/VirtualBox environment for live-UI verification: connects Playwriter to a Windows guest's browser over CDP through a host NAT port-forward, then verifies through the shared ~/.agents/skills/k-review/references/live-ui-runtime.md machinery. | manual |
k-long-jobs | Use when a command can take minutes or outlast the tool timeout: time limits, background jobs, waiting in the same turn. | |
k-nano-banana | Use only when the user names Nano Banana, ,nano-banana, Gemini/Google image, or gemini-*-image. | |
k-omp | Use in OMP to select native structured-read, code-intelligence, and agent tools. | |
k-playwriter | Use for real-browser browsing and automation, and for UI checks, screenshots, and visual QA the user asks for. | |
k-pr-fix-loop | Manual authorized PR-fix batch: scoped fixes, one verification run, then commit, push, and scoped replies. | manual |
k-present-pr | Build and open a self-contained HTML walkthrough that makes a PR review-ready. | manual |
k-prototype | Use when building a throwaway prototype to sanity-check logic/state or explore UI direction before committing. | |
k-public-sources | Use when inspecting external public source or synthesizing evidence across sources. | |
k-readme | Use when creating, editing, or reviewing README files; apply ReadmeRoast checks to the project's actual audience and scope. | |
k-review | Use to review local changes, a PR, review threads (PR fixes), or a plan, and for independent verify rounds (two fresh reviewers and a fix loop, repeated until a whole-scope round is clean). | |
k-sem | Use when entity history across file moves, per-entity blame, or entity-level diff with rename/cosmetic classification needs ,sem; indexed structural queries only on explicit request. | |
k-slack | Use for Slack MCP effects: send/schedule messages, thread replies, reactions, canvas create/update, Slack drafts. | |
k-spec | Use when a request needs a written implementation plan with acceptance criteria before coding. | |
k-text-tournament | Manual-only comparison of materially different prose alternatives against a stated rubric. | manual |
k-tmux | Use when running/probing tmux panes, sessions, sockets, popups, captures, config, or tmux-hosted CLIs. | |
k-ui-capture | Use when the user asks to prove UI visual/behavior, audit a diff for capturable changes, or capture/upload pre/post PR screenshots/videos. | |
k-walkthrough | Explore a codebase interactively: trace execution flows, map component relationships, and render architectural diagrams. | manual |
k-worktrees | Use for worktrees with ,w or ,gh-worktree: create, switch, open, list, prune, remove, PR checkout. | |
k-writing-great-skills | Use when authoring/refactoring skills: invocation, triggers, references, leading words, pruning. |