sutanto62/nalgene-mode

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 spec - for '/create-a-skill', 'make a skill for X', 'new skill', or 'does this skill meet spec'.

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.

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

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.

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.

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.

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', or before sharing prose with a broad audience.

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.

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.

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.

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.

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.

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'.

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 — into a playbook that picks the research angles. Never recommends adopting or replacing anything — presents the landscape with dates and sources, and flags where this project's own scale or constraints might not fit. Use for 'what's new in X', 'any known issues with Y', 'what's the broader landscape for Z', or 'what are people doing differently for this kind of problem'.

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.

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 works.