exam-prep

Plugin exam-prep from marketplace nutsskills in PeanutGT/NutsSkills. Commands read from the repo's manifest — 4 days ago.

Skills (16)

• clarify

  Use when a request is vague, open-ended, or a new feature idea (I want to build X, add support for Y), before writing a spec, plan, or code. Decides whether questions are needed at all, then interviews one question at a time until goals, constraints, and edge cases are unambiguous.

• code-review

  Use when reviewing a diff, branch, or PR, when asked whether it is safe to merge, and when acting on review comments (the reviewer says X, address the feedback). Covers giving reviews on two separate axes (spec and standards) and verifying feedback before applying it.

• debug

  Use when facing a bug, failing test, error message, crash, flaky or slow behavior, or anything that works differently than expected, before proposing or making any fix.

• design

  Use when adding a new module, service, API, or data model, choosing between architectural approaches, or when code is hard to test or change. Covers module boundaries, interfaces, domain naming, and recording decisions.

• exam-prep

  把講義、投影片、課本、手寫筆記照片、考古題（可上傳或給 Google Drive 連結）重新組織成排版精美的複習 PDF：學習講義、重點整理、題型解題卡、Cornell 回憶筆記、分層講義、練習題與驗算過的解答、公式小抄，附概念地圖與圖表。使用者提到期中考、期末考、小考、複習、整理重點、整理教材、做講義、出練習題、考古題、study guide、exam prep、cheat sheet，或丟了課堂資料想學懂或準備考試時使用。

• fresh-eyes

  Use before handing over a spec, plan, or design for approval, before an irreversible or cross-module decision, before claiming a non-obvious fact (safe, scales, matches the spec), and when reviewing a large diff. A reviewer with no conversation history reads it cold.

• music-studio

  Create instrumental music and BGM (game loops, video scores, study/work background, personal tracks) locally with ACE-Step 1.5 on the user's NVIDIA GPU, with fully customisable defaults, style library, description lexicon and workflows plus a local dashboard. Use whenever the user wants to make, gen

• nutshell

  Use at the start of every software engineering task (building, fixing, reviewing, planning, refactoring, shipping), together with any more specific skill that applies. Holds the always-on baseline rules and picks which engineering skill to load next.

• plan

  Use when work has more than a few steps, touches several files, or follows an approved spec, before starting implementation. Breaks the work into small vertical slices that can each be verified on their own.

• repo-map

  Use when starting work in an unfamiliar or large repository, before broad grep/glob/read exploration, or when you need to know where a function, class, or module is defined and which files use it. Builds a compact map of files, public symbols, and imports so you open only the files that matter.

• ship

  Use when committing changes, writing a commit message, opening a pull request, or finishing a development branch. Covers branch naming, commit hygiene, PR descriptions, and the pre-merge checklist.

• simplify

  Use when code works but is hard to read or change, after a feature is complete and green, or when asked to refactor or clean up. Reduces complexity without changing behavior.

• spec

  Use when requirements are agreed and need to become a written spec with testable acceptance criteria, before planning or implementing a feature.

• tdd

  Use before writing any implementation code for a feature, bugfix, or behavior change. Drives the work with one failing test at a time (red, green, refactor) at an agreed public seam.

• verify

  Use before claiming any work is done, fixed, working, or passing, before saying a task or requirement is complete, and before committing or opening a PR. Requires running the check and showing its output as evidence.

• writing-skills

  Use when creating a new skill, editing an existing skill, or when a skill fails to trigger or is not followed. Covers the SKILL.md template, writing descriptions that trigger, and testing skills with evals.