菜单
Relentlessly interviews the user about a proposed FeCIM physics, simulation, or GUI change before any code is written — covering source citation, educational-vs-validated framing, TDD-RED test, thread-safety, and honesty-audit alignment. Use when starting a non-trivial change to physics, ISPP, crossbar, or GUI logic.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Audits Go code for goroutine-to-widget access without fyne.Do(...) wrapping, the project's most common GUI freeze cause. Use when reviewing a PR that adds goroutines, async I/O, or simulation tickers in any pkg/gui/ or shell package.
Runs build flows for the canonical Fyne shell and module commands on this Go 1.25 monorepo. Use when building, packaging, or debugging build failures in cmd/fecim-lattice-tools or module GUI commands.
Runs the FeCIM test matrix (full, race, module-scoped, coverage, golden regen) and interprets physics regression failures using the 5 known bug patterns. Use when running tests, debugging test failures, or regenerating physics golden files.
Verifies and formats FeCIM physics/measurement claims against the project's published-source list and docs/4-research/honesty-audit.md. Use when adding a numeric claim, accuracy figure, or device-parameter assertion to code, docs, PR descriptions, or commit messages.
Enforces docs/4-research/honesty-audit.md policy by scanning PR diffs, READMEs, and presentation material for removed/unverified claims (87% MNIST, 30-states-as-fact, energy multipliers vs NAND/GPUs). Use before committing docs, PRs, or release notes that include accuracy or efficiency numbers.
Surveys FeCIM domain knowledge by searching references/, citations/, docs/4-research/, and the local Cognee KG, then synthesizes a cited research note. Use when investigating a physics topic, evaluating a paper, or grounding a design decision in literature.
| name | fecim-grill |
| description | Relentlessly interviews the user about a proposed FeCIM physics, simulation, or GUI change before any code is written — covering source citation, educational-vs-validated framing, TDD-RED test, thread-safety, and honesty-audit alignment. Use when starting a non-trivial change to physics, ISPP, crossbar, or GUI logic. |
Use this only when Juan explicitly wants design interrogation or when a non-trivial change is ambiguous enough that coding would risk unsupported physics. Otherwise prefer autonomous execution with documented assumptions. Ask each question one at a time. Do not move on until the user answers. Mark each branch RESOLVED before exit.
What changes, behaviorally? One sentence. If the answer references a UI element, ask which goroutine/main thread.
Source citation. Is this grounded in:
Educational vs validated framing. If the change touches accuracy/efficiency numbers, run through the honesty-audit removed/unverified list (87% MNIST, 30-states-as-fact, NAND/GPU energy multipliers).
TDD-RED test. What is the focused failing test that proves the new behavior? Path + name. If the user can't name one, BLOCK until they can.
Output a one-paragraph design summary the user signs off before any code is written:
Behavior: ...
Source: ...
Framing: validated | educational
RED test: <file:test>
Thread-safety: covered | n/a
UI-boundary: ok | n/a
This skill exists to enforce TDD before code is written. It cannot violate TDD itself; output is observation — TDD: N/A.