nalgene-mode

Plugin nalgene-mode from marketplace nalgene in sutanto62/nalgene. Commands read from the repo's manifest — 3 days ago.

Skills (19)

• check-sql-performance

  Verify a SQL or ORM change doesn't regress query cost before calling it done. Use when a diff touches a raw SQL statement, a cursor/db execute, an ORM query that can run per-row, or a reporting/aggregate view - for 'check SQL performance', 'N+1 query', 'verify ORM performance', or 'EXPLAIN ANALYZE'.

• create-a-skill

  Scaffold a new skill's SKILL.md, validate its frontmatter and structure against the Agent Skills spec (agentskills.io), and run a lightweight evaluation pass before handing it off. Use whenever asked to create, author, add, or scaffold a skill, write a new SKILL.md, or check an existing one against

• how

  Use for 'how does X work', code walkthroughs before changing something, and placement/ownership/layering questions ('where should this live', 'which package owns this'). Explains subsystem architecture and runtime flow at onboarding depth.

• nalgene-help

  Answers 'which skill for X' without doing the work. Type /nalgene-help with a question about this plugin.

• nalgene-mode

  Router for nontrivial work: give it a goal and a way to check it's done, it picks a playbook, gates on openspec when the change is non-trivial, and runs the right skills as each step fires. Use for /nalgene-mode or requests to work in this style.

• openspec-explore

  Read-only lookup of what openspec already documents about a feature, before exploring code. Use before answering a 'how does X work' question, and as step 0 of the how skill.

• openspec-gate

  Drive the openspec propose -> validate -> implement -> archive loop for non-trivial changes. Use before starting a feature, API change, or cross-cutting refactor, or whenever asked to 'openspec' something.

• plain-speech

  Rewrite text so anyone can read it once and understand it, with no AI-sounding tells left in it. Short sentences, common words, no unexplained jargon — works for a non-technical reader, not just a technical one. Use for '/plain-speech', 'make this sound human', 'simplify this for a general reader',

• principle-fix-root-causes

  Apply when debugging. Trace a symptom back to the first place the system went wrong and fix it there. A guard is a fix only when the state it handles is legitimate.

• principle-measure-query-cost

  Apply before claiming a SQL or ORM query change is faster or cheaper. Run EXPLAIN ANALYZE (or the ORM's query count) before and after on the same input - reasoning like 'fewer joins' or 'one subquery instead of three' isn't proof on its own.

• principle-minimize-reader-load

  Apply when writing or reviewing a diff. Favor the version a reviewer can hold in their head - fewer layers, less hidden state, no comments that restate the code.

• principle-outcome-oriented-execution

  Apply when planning a multi-step change, migration, or rewrite with explicit phases. Converge on the target shape - don't let a temporary compatibility state become permanent.

• principle-prove-it-works

  Apply before reporting any claim of success, a fix, or a measured number. Run it and show the real output - a green build is not proof.

• principle-report-dont-recommend

  Apply when presenting options, research findings, or a comparison the person will decide on - a landscape report, an architecture choice, a library pick. Describe tradeoffs and let the person weigh them against context you don't have; don't resolve the decision for them, even with a hedge.

• statechart

  Check a TLA+ model of a system that moves between states, such as a product flow, a protocol, or a service, and draw it as a Mermaid statechart. The report gives the shortest path to each state that breaks a rule. Use for /statechart, or to show a bug as a path through states.

• teach

  Explain a subsystem or change plainly, opening with the project's high-level architecture so a new learner has somewhere to put the rest. Runs how and why and blends what they find into one explanation. Use for 'teach me this', 'help me understand X', 'explain this codebase/change to me'.

• tech-advisory

  Give an outside, no-judgment perspective on a technology, library, stack, design pattern, algorithm, or AI model: recent news, known issues, notable alternatives, and community sentiment, via live web research. Routes the ask — a general goal, an issue already hit, or a decision between options — in

• technical-writing

  Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for /technical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.

• why

  Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, or historical motivation. Investigates source control history and openspec documents in parallel, then returns a cited, confidence-tiered read on decisions and tradeoffs. Use how for what the code does and how it w

Subagents (1)

• nalgene-explorer

  Read-only general-purpose investigator. Used by the how and why skills for exploring, explaining, or investigating the history of a codebase. Never edits, writes, or runs a mutating command.