dotfiles

Evidence-first research-paper reviewer for cryptography, ZK, security, confidential computing, MCP, and LLM-security. Use when Codex needs to review or audit .tex, .org, .md, or .txt papers and research notes, search literature, check prior art and non-obviousness, assess novelty, threat models, proofs, security claims, evaluation, venue readiness, or compare a revised draft with an earlier review. Do not use to draft, rewrite, or directly edit paper prose. Produce evidence, prioritized findings, required outcomes, and acceptance checks for crypto-writer or the author.

Author-side research paper and research-note assistant for cryptography, ZK, security, confidential computing, MCP, and LLM-security. Use when Codex needs to plan, outline, draft, restructure, or revise .tex, .org, .md, or .txt papers or notes, turn experiment results into paper prose, apply review findings, manage outline.yaml/fields.yaml/results JSON workflows that feed a paper or note, or run a small research experiment whose output is a paper or note. For independent peer review, literature search, prior-art or non-obviousness checks, or threat-model, proof, evaluation, and venue-readiness audits, use crypto-reviewer instead. Combine both skills when writing changes research claims.

Apply Unix philosophy and pragmatic Linux engineering to simplify software, place knowledge in data, shape deep tools with focused responsibilities and composable interfaces, make behavior inspectable, and evolve designs without speculative machinery. Use when the user asks to unixify or apply Unix philosophy, or asks about Unix-style composition, module or responsibility boundaries, pipelines and filters, CLI automation, policy-mechanism separation, replaceable interfaces, machine-oriented I/O, observable failure behavior, or evolvable interfaces. Do not trigger for ordinary Unix or Linux usage or generic software design without one of these signals.

Relentlessly interview the user to sharpen a plan or design against the project's domain model while updating its glossary and architectural decision records. Use when the user wants to stress-test a plan against existing code, terminology, CONTEXT.md, or ADRs and keep those documents current as decisions crystallize.

Activate a session-wide policy that permits architecturally justified breaking changes and removes compatibility with project-owned historical interfaces from design constraints. Use only when the user explicitly invokes `$allow-breaking-change`; never trigger implicitly from generic refactoring, simplification, architecture, compatibility, or breaking-change discussion. Keep the policy active across projects and tasks for the rest of the current conversation unless the user overrides it for a task or disables it.

Use this skill proactively for Emacs-related tasks, especially live Emacs runtime inspection; buffer metadata, region, point, narrowing, window, project.el, LSP, Magit, and org-mode-aware workflows; command, variable, binding, hook, keymap, remap, advice, and minibuffer state debugging; reloading init files, package state, or stale runtime configuration; reproducing package load failures; debugging Magent, *magent*, *magent-log*, tool call hangs, task drift, UI rendering mistakes, performance regressions, or Magent compile/test failures; inspecting *Messages*, *Warnings*, and *Backtrace*; byte-compiling files; running ERT tests; or interacting with a running Emacs instance via emacsclient.

Review Emacs Lisp snippets, files, and packages for correctness, declaration and API misuse, load-time side effects, compatibility, package metadata, idiomatic style, and maintainability. Use when Codex is asked to review, audit, assess, or prepare Elisp for packaging or MELPA; report prioritized findings and do not edit unless explicitly asked.

Submit Git work as a pull request by creating or reusing a `submit-pr/` branch, staging all repository changes, generating a Conventional Commit, pushing to `origin`, and opening a GitHub pull request. Use only when the user explicitly invokes `$submit-pr`; never trigger implicitly from generic requests to commit, push, or create a pull request. Treat text following the invocation as optional context for the commit and pull request.

Manage plans, TODO/PROJ items, deadlines, notes, and summaries in the central project Org file resolved by `(+org-project-current-file)` or `(+org-project-file-dwim)`. Use only when the user explicitly invokes `$project-plan`; never trigger implicitly from planning language, the presence of a plan or project Org file, or a request to create, review, or update a plan. If invoked without any follow-up prompt, switch to plan mode, list the current active plans, and ask the user which one to execute or review.

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

Apply the KISS principle to reduce accidental complexity while preserving required behavior. Use when the user asks to simplify a design, plan, implementation, API, workflow, or explanation; requests the smallest viable solution; wants to avoid overengineering; or needs a review for premature abstraction, speculative extensibility, unnecessary layers, options, dependencies, or moving parts.