القائمة
Use when writing or updating unit tests in the Silo repo. Covers the co-located Vitest setup, the pure-logic (no @testing-library/react) style and how to extract testable helpers, driving host state directly via the valtio store, and the contract-and-edges coverage expectations.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Use when adding or changing any public @silo-code/sdk symbol — a new ctx method, exported type, or field — or when editing the project positioning / Context7 index. Covers the docs-in-sync workflow (TSDoc, @public/@internal + @category tags, barrel re-export, hand-authored ctx member page, pnpm docs:api, roadmap flip) and how apps/docs is indexed by Context7.
Launch (or attach to) the Silo dev app and drive it for runtime verification through the dev automation RPC bridge — exec commands, eval DOM, capture screenshots, and create/activate/delete workspaces, terminals, editors. This is the repo's GUI evidence-capture handle for the `verify` skill. Use when verifying a change by running the real app and observing it. Always works inside a throwaway sandbox workspace, never the user's real workspaces.
Capture a 600×400 documentation screenshot from the running Silo app and composite it on the standard wallpaper. Use whenever adding or updating screenshots in apps/docs/public/img/guide/.
Help the user design, write, compile, and install a Silo extension from a natural-language description. The extension follows the same format as any publishable Silo extension and can be shared via npm or a tarball URL when ready.
استنادا إلى تصنيف SOC المهني
| name | silo-testing |
| description | Use when writing or updating unit tests in the Silo repo. Covers the co-located Vitest setup, the pure-logic (no @testing-library/react) style and how to extract testable helpers, driving host state directly via the valtio store, and the contract-and-edges coverage expectations. |
Every change that adds or changes behavior ships with unit tests in the same
change. Tests are part of the work, not a follow-up. Don't mark a task done
until pnpm test is green with coverage for what you added.
How testing works here:
*.test.ts / *.test.tsx next to the source it
covers; the package vitest.config.ts picks up src/**/*.{test,spec}.{ts,tsx}.
Run everything with pnpm test, or one package with
pnpm --filter <pkg> exec vitest run <path>.@testing-library/react is intentionally not a dependency). When the logic
you're adding lives inside a component, extract it into a pure, exported
helper and test that — e.g. view-switcher-model.ts (switcher show/segmented/
dropdown rules), markdown-preview/menu.ts (context-menu enablement), and
markdown-preview/match.ts (file matching) were factored out of their
components precisely so the rules are unit-testable. Components stay thin glue.store (the valtio proxy) and
the relevant registries in beforeEach, exercise the service, assert on the
store — see editor-service.test.ts and editor-registry.test.ts.viewType fallback,
read-only Cut/Paste, and the single-view/diff/untitled hidden cases).