Enrikkk
- 9 skills
- 0 followers
- 5 hours ago last updated
- ▌ Drop Jargon · enrikkkRe-explain your own immediately previous message in plain, simple language with no jargon, assuming the user does not already know the technical background. Use whenever the user says they did not understand, that you were too technical, that you were spitting jargon, asks you to explain it simpler or more clearly, or invokes /drop-jargon explicitly.
- ▌ Merge Audit · enrikkkDeep, after-the-fact audit of a merge that has already happened — whether it was done through /merge-branches or manually — hunting for code that got silently skipped, dropped, or broken during the merge. Invoked by the user with /merge-audit [<branch-a> <branch-b>] [<merge-commit>], or whenever they ask to double-check, verify, sanity-check, or audit a merge they just did or did earlier. With no arguments, infers the branches from the most recent merge in this conversation; if that isn't clear, asks. Produces a structured findings report and a persistent log file under merge_logs/, then — for any real findings — walks the user through resolving each one via an MCQ, the same interactive pattern /merge-branches uses, before dispatching fixes to a subagent. Static analysis only (diffs, reference integrity, typecheck, the project's test suite) — it does not boot the app or exercise code live; that's /test-features' and /run's job.
- ▌ Explain Code · enrikkkExplain a function, class, or file block-by-block in plain English. Use whenever the user asks to explain, walk through, break down, or understand what a piece of code does (e.g. "explain this function", "walk me through X", "what does this file do"), or when invoked explicitly as /explain-code <path or symbol>.
- ▌ Log Progress · enrikkkWrite an end-of-session/end-of-task progress record so a future agent starts with full context. Invoked by the user with /log-progress. Logs to BOTH the project memory directory and the project's own state doc. Records what was done, what was decided and why, the numbers that were measured, the traps discovered, and — importantly — what was left as future work.
- ▌ Narrate Work · enrikkkKeep the user informed in real time while searching, investigating, debugging, or running multi-step work, instead of going silent and returning only a conclusion. ALWAYS ACTIVE — apply this by default in every session without being asked, whenever a task involves more than one or two tool calls (grepping a codebase, reading logs, querying a database, bisecting a bug, running experiments, launching subagents). Also use when the user says you are being a black box, asks what you are doing, or asks you to keep them posted.
- ▌ Test Features · enrikkkRun a deep testing pass on a feature (or set of features) after it's implemented — functional correctness, edge cases, data integrity, the project's own automated suite, live/real-environment behavior as an actual user would hit it, AI/agent-specific risks when relevant, and whether the change broke anything else. Invoked by the user with /test-features [what to test], or whenever they ask to "test what we just built," "verify this feature," or run a "testing session." With no argument, the scope is whatever was implemented in the just-finished coding session — inferred from the diff/recent changes and the conversation, cross-checked against each other. If the scope is ambiguous (several distinct changes, unclear which one is meant), ask the user rather than guessing. This is a verification skill, not a bug-fixing or test-authoring skill by default — see the bug-handling and coverage-gap rules below for the exact boundary.
- ▌ Merge Branches · enrikkkWalk the user through resolving git merge conflicts between two branches interactively — one file at a time, one conflict at a time, each decided by an MCQ with a real recommendation. Invoked by the user with /merge-branches <branch-a> <branch-b>, or whenever they ask to merge, reconcile, or integrate a divergent branch (especially a co-founder's or teammate's) and want to review the actual content rather than accept git's or a model's silent auto-resolution. Handles both ordinary content conflicts and add/add conflicts (both sides independently built the same file from scratch since the branches diverged).
- ▌ Explain Workflow · enrikkkWork out loud as a teacher, not just a reporter — show each step as you take it, show the actual change, and explain why you chose it over the alternatives, so the user can follow along, understand the reasoning, and learn the workflow itself. Use when the user asks you to show your work step by step, to explain what you are doing as you do it, to walk them through it as you go, says they want to follow/understand your workflow, or invokes /explain-workflow. Stays active for the rest of the session once invoked.
- ▌ Log Progress Compact · enrikkkLog all session progress AND write a resume handoff immediately before the user compacts the context. Invoked by the user with /log-progress-compact. Does everything /log-progress does, then records the in-flight working state — the task mid-execution, the exact next action, what is already verified, and what is settled — so that after the compaction you continue seamlessly, as if it never happened.