Results for “test”

>- Run automatic SPICE simulations on subcircuits detected from KiCad schematic analysis — validates filter frequencies, divider ratios, opamp gains, LC resonance, and crystal load capacitance. Supports ngspice, LTspice, and Xyce (auto-detected). Generates testbenches, runs batch mode, produces structured pass/warn/fail report. Use when the user asks to simulate, verify, or validate any analog subcircuit — RC filters, LC filters, voltage dividers, opamp circuits, crystal oscillators. Also for "simulate my circuit", "run spice", "verify with simulation", "check my filter cutoff", "does this divider give the right voltage", "what's the bandwidth of this opamp stage". Consider suggesting simulation during design reviews when the schematic analyzer reports simulatable subcircuits and a SPICE simulator is available.

Researches an open-ended question — options, possible solutions, prior art, trade-offs, or how something works — and produces a durable, evidence-backed, adversarially-validated report that recommends an option without committing the team to any artifact. Use when you want to research approaches, weigh options, survey prior art or the state of the art, or understand how something works before committing to a direction. Does not diagnose a bug, failure, or root cause — use investigate. Does not specify a feature — use plan-a-feature. Does not create or update a coding standard — use coding-standard. Does not compare two concrete artifacts for gaps — use gap-analysis. Does not assess an existing module's architecture — use architectural-analysis. Does not capture feedback on Han's own skills — use han-feedback.

Produces a human-readable, progressive-disclosure overview of unfamiliar code or a pull request's changes — why it exists (the real problem it solves or goal it serves for the business or a user), and from there what it does, how it flows, and where to start — so you can get up to speed before working on or reviewing it. Use when you want to understand, get oriented in, make sense of, explain, or get up to speed on a chunk of code, a file, a directory, a symbol, or a PR's changes. Writes the overview to a scratch file and changes no code. Does not review code quality or raise findings — use code-review for auditing changes or post-code-review-to-pr for posting them. Does not produce durable feature or system documentation — use project-documentation. Does not assess architecture or structural risk — use architectural-analysis. Does not diagnose bugs or root-cause failures — use investigate. Does not pace a person through the code one step at a time in conversation — use code-walkthrough.