nlsmdn

Plugin nlsmdn from marketplace nlsmdn in nielsmadan/skills. Commands read from the repo's manifest — 2 days ago.

Skills (60)

• blind-spots

  Surface consequential decisions a plan, design, or research brief left silently assumed, by interviewing the user in dependency order. Use when the user says "blind spots", "grill me", "stress-test this plan", "poke holes in this", "what am I missing", "interrogate this design", "what haven't I deci

• brainstorm

  Work out how to solve a problem the user can already name — interview them with `blind-spots` to understand it, generate structurally different approaches, validate each with an independent critic, then present the survivors with trade-offs and a recommendation. Use when the user says "brainstorm",

• check-agent-logs

  Search past Claude Code, Codex, Droid, OpenCode, and Pi session logs to recover context from earlier work across the current project and sibling checkouts. Use when a bug, topic, or decision was handled in a previous session but its agent or checkout is unknown; when the user says "we fixed/discusse

• code-review

  Clean up comments and mechanical loose ends, then review code with comprehensive and quick modes. Use when reviewing code changes, PRs, or specific files for quality, bugs, and best practices.

• codebase-review

  Review a whole codebase aspect by aspect, with aspects fitted to the project type (mobile, desktop, web frontend, static site, CLI, backend, library) — overview, docs truth-check, architecture, tests, security, the type's own foundations, feature deep dives, consistency, architecture roadmap — writi

• commit

  Commit ONLY the changes this session made, never another agent's work in the same checkout. With a message argument, makes one commit; with no argument, splits the session's work into the fewest self-contained commits and generates a short message for each — feat/fix/chore in the user's own repos, t

• debug-log

  Add debug logging to trace code execution. Use when debugging, tracing control flow, or investigating unexpected behavior. Any language (JS/TS, Python, Go).

• deslop

  Copy-edit text to strip AI/LLM writing tells ("slop") and make it read as human-written — overused words (delve, showcase, robust), significance-inflation phrases ("stands as a testament to", "plays a pivotal role"), scene-setting openers ("in today's fast-paced world"), hedging, em-dash overuse, ru

• doc

  Assess documentation for gaps, staleness, quality, and files outside the defined doc set. Clarify project terminology and maintain domain glossaries and decision records. Preserve useful knowledge in canonical docs, then remove superseded or unnecessary files. Check changed code when the tree is dir

• evaluate-tech

  Structured evaluation before adopting a library, tool, or hosted service — enumerate candidates wide, then score every one against an identical rubric where maintenance health is a mandatory gate, not an afterthought. Use when the user asks "which library/package should I use", "what should we use f

• explain

  Generate project explanation docs in docs/explain/ covering architecture, flows, syntax, system APIs, infra, and testing, or explain a code diff, commit, branch, or PR directly in the conversation with --diff. Use when asked to explain how a project works, document its architecture, or walk through

• flutter-upgrade

  Flutter upgrade workflow. Use when upgrading Flutter SDK, bumping Flutter version, migrating to a new Flutter release, or resolving breaking changes after a Flutter update.

• guide

  Walk the user through a multi-step task (e.g. cloud console / permission / dashboard setup) with a live step tracker that is re-printed at the bottom of every reply so they never scroll up. Use when the user asks to "guide me through", "walk me through", "give me step by step" instructions, "how do

• hard-fix

  Escalation workflow for stubborn bugs. Use when a bug persists after multiple fix attempts, you've tried several approaches, or you're stuck.

• huh

  Expand an explanation with the surrounding context needed to understand it. Use when the user invokes `huh`, asks to explain the previous reply in more detail, or supplies text to unpack.

• ideation

  Generate ideas with structure when you're stumped — on what to build next, what the real problem is, or how to solve it. Pulls in research for context, diverges wide using matched frameworks, then converges on a prioritized few. Use when the user says "I'm stuck", "I'm stumped", "ideate", "brainstor

• improve-agent-instructions

  Audit and improve the always-loaded agent instruction files (AGENTS.md, CLAUDE.md, GEMINI.md). Triggers "check/audit/update/improve/fix/revise CLAUDE.md or AGENTS.md", "project memory optimization", "trim my instruction file". Not for general docs.

• library-docs

  Generate and refresh a per-repo `library-use` reference — official docs, changelog links, pinned versions, and distilled correct-usage conventions for the repo's fast-moving / niche libraries. Use when the user says "library-docs", "doc links", "document the libraries we use", "generate/refresh libr

• longshot

  Run a long autonomous build session from a brief — interview the user with `blind-spots`, prepare the plan and review it with `review-plan`, and wait for explicit final approval to start implementation. Only then decide later ambiguities as recorded rulings and execute without check-ins. Per task a

• optimize-seo

  Audit and optimize web pages for SEO — meta tags, Open Graph, JSON-LD, structured data. Triggers "optimize SEO", "check SEO", "add meta tags", "SEO audit".

• pdf

  Read, extract, merge, split, rotate, watermark, create, fill forms, encrypt/decrypt, or OCR PDF files. Use whenever a `.pdf` is mentioned or a PDF is requested.

• perf-test

  Set up and run performance tests (profiling, load testing, or E2E scenarios), preserving occasional manual procedures and results for future repetition. Use when measuring code or endpoint performance, or before/after optimization work.

• plan

  Lightweight planning workflow — plan read-only in-session when already on Opus or stronger, otherwise delegate planning to an Opus subagent (or adopt a plan already agreed in the conversation), then implement in auto mode after a single go-ahead gate, run QA and one `code-review --multi`, fix findin

• pre-existing

  Fix any test/lint/type/build/CI failure instead of dismissing it as pre-existing, flaky, or unrelated. Triggers on red checks or `/pre-existing`.

• qa-tour

  Prepare a developed feature for a short interactive walkthrough, then use guide to help the user click through its main workflow themselves. Use for "qa-tour", "give me a tour of the new feature", "walk me through trying this feature", or "let me click through what we built". Defaults to staged and

• qa

  Exercise a developed feature through its real user or consumer interface, enumerate paths and edge/error/loading states first, and report evidence and coverage. Use for "qa", "QA the last feature", "test this feature end to end", "manual QA", or "check the user flows". Defaults to the last developed

• read-docs

  Search internal project docs (docs/, README.md, CLAUDE.md, *.md) for patterns, conventions, architecture. Use proactively before features, in new code areas, or when debugging.

• release-review

  Run a comprehensive pre-release review of a whole product, working through every command, parameter and config surface with the user, one item at a time. Rulings are collected in an on-disk changes ledger, ruled batches are handed to parallel implementer sessions as soon as they are ready, and the p

• research-general

  Research a non-technical topic online (science, history, news, policy, regional/regulatory, consumer purchases, personal decisions, fact-check). Use when asked to research, look up, or fact-check a non-technical question; the default for research in non-code repos (e.g. a notes vault). For technical

• research-tech

  Research any technical / developer topic online — libraries, errors, best-practice/how-to, tool·library·model comparisons, product capabilities, and ecosystem/community signal. Use when you'll act on the answer as a developer (write code, debug, choose a tool). For non-technical topics (science, his

• resolve-conflicts

  Resolve git conflicts from any operation (merge, rebase, cherry-pick, stash, revert). Use when encountering conflicted files during git operations.

• review-architecture

  Review system architecture — layering, module boundaries, coupling/cohesion, pattern fit, quality attributes (scalability, resilience, evolvability), and architectural smells. Triggers "review architecture", "architecture review", "system design review", "check architecture".

• review-cleancode

  Review code for clean-code principles — SOLID, DRY, YAGNI, KISS, code smells. Triggers "review clean code", "check DRY/SOLID", "code smells".

• review-cli

  Language-agnostic review of a command-line tool's interface and behaviour — exit codes and signals, broken-pipe handling, stdout/stderr discipline, TTY detection and destructive-action gating, dry-run integrity, partial failure and idempotency, config precedence, flag and help design, and error mess

• review-comments

  Review and clean up code comments for necessity, accuracy, non-duplication, clarity, and concise explanation of rationale. Use when comments may restate code, repeat a "why" already explained in the file, contain stale or vague claims, or need tightening before a PR.

• review-consistency

  Review whether changes follow the patterns the codebase already uses — compare each added or changed construct with its existing siblings for naming, placement, mechanisms (error handling, logging, config, helpers), shape, and registration, and cite the precedent for every divergence. Triggers "revi

• review-correctness

  Review code for bugs, incorrect state transitions, races, and failure handling, including closed-world branching, unknown external values, swallowed errors, masking defaults, invariants, deadlines, cancellation, and retry safety. Use for "review correctness", "review logic", "review defensive", "che

• review-functional

  Review code against pragmatic functional principles — effects pushed to the edges, no hidden shared state, no mutation of a caller's data, deterministic functions, declarative transforms. Deliberately non-dogmatic: currying, point-free style, recursion and monads are out of scope and are never findi

• review-history

  Analyze how code changed over time. Use when investigating regressions, understanding why code was written a certain way, or finding when a behavior changed.

• review-interfaces

  Review interface design for functions, classes, modules, components — naming, params, encapsulation, YAGNI, usability. Triggers "review interfaces".

• review-library-use

  Review code for correct use of the repo's third-party libraries — checks the scoped files against the version-specific conventions recorded in the repo's `library-use` reference (docs-derived correct-usage rules, API contracts, footguns). Catches stale-API usage, deprecated patterns, and doc-violati

• review-logs

  Analyze Claude Code session transcripts for failure patterns and suggest fixes. Triggers "review logs", "session analysis", "failure patterns".

• review-perf

  Performance analysis for algorithmic complexity, memory leaks, N+1 queries, and render issues. Use when code feels slow, after adding loops/queries, or before scaling up.

• review-plan

  Multi-agent review of implementation plans. Use after creating a plan but before implementing, especially for complex or risky changes.

• review-product

  Review a product from the user's perspective — build/refine a user persona, map their use cases (jobs-to-be-done), then audit the product for friction, gaps, and things to add or change. Triggers "review product", "product review", "review from the user's perspective", "product/UX critique", "what's

• review-python

  Python-specific code review focused on JUDGMENT-level design a linter and type checker can't decide — modeling state so invalid combinations are unrepresentable, keeping parsed data parsed instead of re-widening it to dicts, exception hierarchies that callers can act on, async task lifetime and canc

• review-react

  React-specific code review for both react-dom and React Native, focused on JUDGMENT-level component design a linter can't decide — state modeling and placement, effects that shouldn't be effects, component boundaries and identity, render cost calibrated to whether React Compiler is on, and platform

• review-rust

  Rust-specific code review focused on JUDGMENT-level design that clippy and the compiler cannot decide — modeling state so invalid combinations are unrepresentable, sum types that get flattened into correlated primitives, closed vocabularies carried as strings, units that live only in comments, error

• review-security

  Security audit for vulnerabilities, secrets, and unsafe patterns. Use before releases, after adding auth code, or when reviewing third-party integrations.

• review-swift

  Swift-specific code review focused on JUDGMENT-level design a linter and the compiler can't decide — state modeling with enums and value types (make invalid states unrepresentable), optional and error modeling, concurrency isolation intent, ARC ownership, SwiftUI identity/lifetime/dependencies, and

• review-swiftui

  Review SwiftUI presentation and interaction on macOS and other Apple platforms. Checks control semantics, navigation and presentation, adaptive layout, localization, keyboard focus, and window commands against concrete user workflows. Use for "review swiftui", "swiftui review", or reviewing a SwiftU

• review-tidy

  Coordinate comment cleanup through review-comments and fix the mechanical loose ends a change leaves behind — docs, examples and config that name a symbol, flag or path the change renamed or removed; imports, private helpers and files it orphaned; test names that no longer match; and the project's o

• review-todo

  Explicitly invoked workflow for large completed reviews spanning multiple areas. Proposes a persistent implementation plan, waits for approval, then implements and commits accepted findings. Start or resume only when the user names review-todo; ordinary requests to fix review findings do not activat

• review-typescript

  TypeScript-specific code review focused on JUDGMENT-level type design a linter can't decide — type modeling (make invalid states unrepresentable), inference-vs-annotation calls, and casts/`any` that hide a real modeling problem. Deliberately does NOT duplicate the project's linter, and checks first

• rn-upgrade

  React Native upgrade workflow. Use when upgrading React Native, bumping RN version, migrating to a new RN release, or resolving breaking changes after a React Native update.

• second-opinion

  Get external AI opinions on a problem or question. Use when you want diverse perspectives from the agent CLIs you are not running (Claude, Codex, Pi, OpenCode, Droid).

• skill-creator

  Guide for creating or improving Claude skills. Triggers "create a skill", "build a skill", "new skill", "improve this skill", "skill for [use case]".

• squash-commits

  Squash unpushed commits into clean, higher-level feat/fix/chore commits that follow the project commit policy. Use when local history has too many small/WIP/fixup commits (common after superhuman or gsd runs), or the user says "squash commits", "squash my commits", "tidy history", "clean up commits"

• status

  Report the current coding-session status: summarize staged, unstaged, and untracked files; identify the last task and whether its work is present or committed; report code-review coverage; summarize active plans or review todos; list remaining session work; and recommend the next task. Use when the

• temp

  Make temporary code changes for testing that can be easily undone.

Similar plugins