harikrishnan94
- 10 skills
- 0 followers
- 2 hours ago last updated
- ▌ Reduce Complexity · harikrishnan94Structural review of an in-progress change — a PR or feature branch — for accidental complexity accreted while the change was built. Told to "reduce complexity", "simplify this PR", or "clean up this branch before review", it applies the proven-safe simplifications by default and reports what changed; asked a question — "did this change accrete cruft", could this be expressed more simply — or told "report only", it reviews without editing. Not for line-level style cleanup (humanize) or bug-hunting (code review).
- ▌ Delegate To Cursor · harikrishnan94 bundleOffload the implementation typing of a settled plan to the Cursor CLI (`cursor-agent`), which reaches Grok, Gemini, GPT/Codex and Composer, while you keep the planning and the verification. Use when the plan is settled and the remaining work is mechanical or wide-but-shallow — scaffolding, a repetitive refactor across many files, filling in tests, a contained fix with a test as its oracle — and cost or throughput matters; also for a read-only review from a different model family. Do NOT use it for ambiguous intent, architecture decisions, security-sensitive changes, or anything under roughly ten minutes of typing, where the per-run startup and the cost of writing the brief exceed what delegation saves.
- ▌ Clarify Intent First · harikrishnan94Do read-only reconnaissance, then ask targeted clarifying questions before starting work on an ambiguous or underspecified request. Use this at the START of any coding, debugging, refactoring, or investigation task where the request could reasonably be read more than one way — asks like "make this faster", "fix the flaky test", "refactor X", "add support for Y", "look into this regression", "clean this up" — and at the moment a human is about to launch a long or expensive autonomous run. Trigger it even when the request feels clear enough to start on, as long as two plausible readings would produce materially different work. Do NOT trigger it for well-specified requests, one-step lookups, or anything answerable by reading the code. Do NOT let it block an already-running unattended job — see Unattended mode.
- ▌ Spec · harikrishnan94Use when the user explicitly asks for a specification, spec, or contract. Produces a persistent specification with no open decisions in its scope: what, why, observable behavior, constraints, and acceptance criteria. Never produces task breakdowns, estimates, or how-to guidance.
- ▌ Humanize · harikrishnan94Reduce unnecessary code and comment lines so reviewers can understand and verify a change without the author's agent history. Use whenever writing or modifying code a human will review — a PR, a patch, a commit on a shared branch — and when cleaning up an existing diff on explicit cues like "humanize this", "this looks AI-generated", "AI slop", "reviewers keep flagging generated code", or "clean this up before I open the PR". Applied to an existing diff it fixes the code by default and reports what changed. Removes verbose comments, planning leftovers, unexplained labels, and redundant code while preserving behavior and useful rationale. Keeps comments, commit messages and PR text in plain sentences. Honors required AI disclosure.
- ▌ Watch Pr · harikrishnan94 bundleKeep a GitHub PR green while preserving its motivation. Diagnose CI blockers, resolve merge conflicts and ClickHouse private sync, validate authorized fixes, and retain state for unattended watching or handoff.
- ▌ Brain Dump · harikrishnan94 bundleGenerate a per-workstream Done and Handover note ("brain dump") by scanning all agent sessions in a time window across Cursor (local IDE chats AND cloud / background / worktree sessions), Claude Code, Codex, and Copilot CLI. Use when the user asks for a brain dump, daily notes, end-of-day summary, handover notes, a "what did I do" recap, or to capture done / handover items across projects. Default window is since the last invocation; also accepts a duration (2d, 8h) or a date.
- ▌ Plain Prose · harikrishnan94Make prose a reader understands in one pass, including a reader who does not read English as a first language. Use whenever drafting or cleaning up text a person will read — a commit message, a PR description or review reply, a GitHub or Jira comment, a Slack message, an email, a design doc, a README, a code comment — and on cues like "this is hard to follow", "too dense", "simplify the wording", "make this readable", "explain it plainly", or "I had to read that twice". Shortens the distance between words that depend on each other, puts the new point where the reader expects it, replaces a team's private vocabulary with the thing it names, and keeps every fact: it simplifies the sentence, never the content. Not about voice, tone, or personality, and not about code-level review tells.
- ▌ Prompt Builder · harikrishnan94 bundleUse when the user wants a task prompt for an agent to execute — delegated engineering work (build, optimize, investigate, decide, document, repair), especially long-running, unattended, or high-assurance tasks where the result must be trustworthy. Produces a right-sized prompt with a runnable completion oracle, doer≠grader verification, and honest failure paths. NOT for system prompts or chatbot personas, conversational/creative prompts, or wording tweaks to an existing prompt; for tiny tasks it emits a short LIGHT prompt, never the full template.
- ▌ Second Opinion · harikrishnan94Produce a self-contained brief the user can paste into a separate, independent model session for a second opinion on a spec, plan, or implementation diff. Use when the user asks for a second opinion, a peer review, an independent review, or wants to hand off the current spec/plan/impl to another model. Mandates severity-labeled findings (Low/Medium/High/Critical) and instructs the reviewer to return its output as a prompt demanding confirm/reject with detailed arguments per finding.