nash403-skills

Plugin nash403-skills from marketplace nash403 in nash403/skills. Commands read from the repo's manifest — today.

Skills (57)

• addressing-feedback

  Triage the feedback others left on my work and draft replies: review comments on my PR/MR, comments on a doc, an essay or any artifact, read from a platform or pasted. Use when I ask to look at, read, check, go through or answer the comments, feedback or review threads on something of mine, e.g. \"w

• auto-mode-orchestrator

  Carry a large piece of work to its finish line as an orchestrator: a long description, a list of tickets, or a ticket with sub-tickets. Background sub-agents do all the work, a wiki keeps the state through compactions, and I'm pinged only when it matters.

• bro

  Restate the last message in plain human language, with no jargon.

• bruce

  Bruce, a sparring partner who challenges my proposals instead of validating them, then argues his own: for an architecture or implementation doubt, a decision to make, or a discussion on any topic. Invoke when I ask what Bruce thinks.

• bump-dependencies

  Bump a project's dependencies group by group, from the least risky to the riskiest, verifying each group before the next. Works with any language and package manager. Use when I ask to update, upgrade or bump dependencies.

• clean-code

  My clean-code rules for any stack: naming, control flow, state and types, errors, plus the code smell catalog reviews check against. Use when writing or refactoring code, or when a review needs the smell baseline.

• cleanup-comments

  Review the comments in changed code and propose removing the noise: commented-out code, narrating comments, changelog stamps, debug leftovers, docs that restate the signature. Keeps the ones that carry a why. Use when I ask to clean up, prune or review comments, or before opening a PR or MR.

• code-review

  Review a range of code changes (a branch, a PR/MR, or work in progress since a fixed point) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents an

• designing-codebase

  Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

• deslop

  Remove AI-generated code slop and clean up code style

• diagnosing-bugs

  Diagnosis loop for hard bugs and performance regressions, driven by a tight feedback loop that goes red on the bug before any hypothesis.

• domain-modeling

  Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing its glossary (often GLOSSARY.md, or CONTEXT.md in older repos), or recording or editing an ADR.

• grill-with-docs

  Grill me on a plan or design in a repo, writing the glossary and ADRs as terms and decisions settle.

• grilling

  Grill/Interview the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

• handbook-for-review

  Write a review handbook for a branch or MR: the diff split into cohorts (one concern each, a file can sit in several), each saying what kind of change it is, how deep to read, where to look and what to check. For a human reviewer, with or without an agent. Use when I ask for a review handbook or a g

• handoff

  Compact the current conversation into a handoff document for another agent to pick up.

• implementation-loop

  Workflow for building anything, asked in the prompt or written in a ticket or spec: mindset, framing before code, branch, test-first at agreed seams, checks, review, a user-facing hand back, commit only on request, then continue or hand off. Use whenever I ask to build, implement, add or change some

• improve-codebase-architecture

  Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

• iterate-feature

  Build a feature iteration by iteration: each one ships one capability I can test, takes shortcuts it tracks, and narrows toward production quality, with an artifact per iteration that carries the state between sessions. Use when I start or continue an iteration of a feature.

• maintaining-docs

  Edit AI agent files (skills, rules, AGENTS.md/CLAUDE.md) or project documentation (READMEs, ARCHITECTURE, CODING_STYLE, CONTRIBUTING, monorepo/package docs) with the right reviewer stance, preserving the file's existing tone and workflow. Use when asked to edit, update or clean up one of these files

• managing-pr-stacks

  Open and update a stack of PRs or MRs, each targeting the branch of another instead of the base branch: merge options when opening one, and pushes that run CI only where it pays off when updating the whole stack. Use when opening a PR or MR on a non-base branch, or when I ask to update, rebase or pu

• mapping-codebase

  Create or update a project's code map: what each area of the repo is for and where to change what, so agents navigate without re-exploring. Use when I ask for a code map, or after changes that add, move or remove areas of the code.

• mapping-doc-ownership

  Keep a project's docs map: which doc owns which topic, so every piece of documentation has one home and the others link to it. Use before adding, moving or splitting documentation, when content looks duplicated across docs, or when I ask to create or update the docs map.

• noobify

  Reformulate what I'm working on for a non-technical reader. Use when I ask to noobify, vulgarize, explain something for a PM/designer/stakeholder, or say "how do I explain this to X".

• placing-produced-documents

  Decide where to save a document or artifact you produce (ADR, notes, report, plan…) when the skill producing it doesn't set its location. Use before writing any such file.

• post-mortem-this-session

  When asked, narrate the current session's work as a plain-language TL;DR and flag drift from the user's latest stated intent.

• pr-review

  Review a PR/MR's code, then give me a verdict on whether to approve it and draft the review threads worth posting.

• prototyping

  Build throwaway prototypes that answer a design question: whether a logic or state model holds up, or what a surface should look like or how it should behave, from a full page down to a single field. Use when I want to try options before building, can't picture how something would look or feel, or a

• research

  Investigate a question against high-trust primary sources and capture the findings as a Markdown file. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.

• resolving-merge-conflicts

  Use when you need to resolve an in-progress git merge/rebase conflict.

• retro

  Run a retrospective on a coding session and suggest changes to the agent's environment (files, checks, tooling) so the next runs go better.

• running-checks

  Which local checks to run and when: typecheck, lint, format and tests, scoped to what you touched, the full test suite only before pushing. Use before running any typecheck, lint, format or test command, and before committing, in any language or stack.

• sequencing-changes

  Order a change across commits, MRs and deploys so nothing breaks in between: expand and contract for contracts crossing a deploy boundary, a replacement built beside the old feature, feature flags, prefactoring. Use when splitting work into commits or MRs, writing a migration, removing or renaming a

• setup-personal-context

  Set up my personal context folder in a repository, new or existing: where its issue tracker, labels, git provider, glossary, docs and conventions are, as pointers into the committed files plus what only I need. Use when I ask to set up, refresh or fill in my personal context for a project.

• spawn-session

  Hand the current work off to a new session that starts right away, and report how to find it again.

• suggest-commit

  Stop before committing, hand the changes back for review, and propose a commit message I can use myself.

• syncing-pr-description

  Keep a PR or MR description true to its changes: compare it with the branch diff and update it when it drifted. Use before pushing to a branch with an open PR or MR, when a push is blocked because its description wasn't checked, or when I ask to check one.

• syncing-ticket-status

  Keep a ticket's status and labels in step with the work: in progress when it starts, in review when a PR or MR opens, ready to deploy or done once it's merged or pushed to the default branch. Use after a push, a PR or MR, or a merge tied to a ticket, or when I ask to update a ticket's status.

• tdd

  Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions red-green or red-green-refactor, or wants tests written for new code.

• ticket-conventions

  Conventions for writing single tickets in PM's voice. Ticket = any tracked work item (issue, story, bug, task). Use when I ask to draft, write, create, or convert a request into one, or to reword, reformat, or clean up an existing one.

• to-ac-report

  Reverse-engineer the acceptance criteria of an application view or API endpoint from static analysis, and emit an exhaustive HTML report.

• to-questionnaire

  Turn a decision you can't fully answer into a questionnaire for someone else to fill in.

• to-spec

  Turn the current conversation, or the context I give, into a spec and publish it to the project issue tracker if requested: no interview, just synthesis of what we've already discussed.

• to-tickets

  Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured or mentioned tracker.

• tracking-local-tickets

  Keep tickets as Markdown files in the repository instead of a remote issue tracker, private or committed. Use when I ask for local tickets, when the project's tracker is local, or when a skill must create, read or update a ticket locally.

• unslop

  Cut AI tells from any writing. MUST always apply for all your writing outputs and when I ask you to unslop / deslop text content.

• using-personal-context

  Find a project's context before asking me: issue tracker, labels, git provider, glossary, where docs go, conventions. Reads the committed files, then my personal context folder. Use whenever a task needs one of these and the prompt doesn't give it.

• wayfinder

  Find the way to a goal whose route is still unclear: chart the open questions as decision tickets on a map, local by default, resolve them one per session and add the ones discovered on the way, until nothing is left to decide.

• wizard

  Generate an interactive wizard that walks a human through steps only they can perform, or collects answers only they hold: a bash script for the terminal, or a single HTML form page to send to anyone. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar t

• working-with-worktrees

  Where to create git worktrees and how to bootstrap them. Use before creating any git worktree, whoever asks for it (the user or another skill), or when moving one.

• writing-adr

  Record an architecture decision as an ADR (architecture decision record). Use when I ask for an ADR, to record or document a technical decision, or when an accepted RFC needs its decision recorded.

• writing-git-changes-description

  How to word commit subjects/bodies and MR/PR titles/descriptions, and which merge options to set when opening an MR. Use before writing any commit message or MR/PR title or description.

• writing-prd

  Write or reword a PRD (product requirements document): the why, the what, and how success is measured. Use when I ask for a PRD, a product spec or a requirements doc.

• writing-review-comments

  How to write and post review comments and replies on a PR/MR: anchoring, one thread per concern, length, tone, language, resolving. Use before posting any review comment or reply, on any platform.

• writing-rfc

  Write or reword an RFC (request for comments): a design proposal put up for discussion before a decision is made. Use when I ask for an RFC, a design proposal or a request for comments.

• writing-spec

  Write or reword a spec, also called an epic: the user stories (or tasks) that reach one goal, plus the decisions they share. Use when I ask for a spec or an epic, or to reword or clean up one.

• zoom-out

  Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.

Hooks (2)

• PreToolUse

  "${CLAUDE_PLUGIN_ROOT}"/hooks/pr-description/check.sh

• PostToolUse

  "${CLAUDE_PLUGIN_ROOT}"/hooks/ticket-status-nudge/nudge.sh

Similar plugins