obsidian-arrow-sandbox

Use when creating, updating, testing, or viewing components and stories in obsidian-arrow-sandbox. Covers the full authoring workflow — building Arrow components with Obsidian classes and oas-* utilities, creating *.stories.ts files in stories/views/ or stories/components/ (not src/), the complete defineStories API (variants, children, status, kind, readableWidth, decorator, per-variant notes), viewing the story viewer at /components, keeping code DRY through sub-component extraction, and knowing when to reach for utilities vs. Obsidian's own classes.

Use when updating or maintaining an EXISTING scaffolded obsidian-arrow project — refresh managed files with create-obsidian-arrow refresh (scripts, docs, CI, tools, src/main.ts, src/utilities.css, test — never src/components/), update agent skills with pnpm skills:update, fix skills scoping for nested repos, and re-pull Obsidian styling.

Use when writing @arrow-js/core (v1.0.6) html template literals — reactive vs static (wrap reactive reads in arrow functions), full-value attribute binding where returning false removes the attribute, .property and @event binding, keyed lists, and async component(fn, { fallback }) via boundary(); plus the footguns — no literal HTML comments and no partial attribute values (both throw Invalid HTML position at render), and @event handlers must type the param as Event not a narrowed subtype like MouseEvent (TS2345).

Use when designing the component structure for a new view area or refactoring an existing one. Surveys the codebase for existing components and shared patterns, proposes a src/views/ + src/components/ hierarchy with file trees, asks targeted questions to confirm decisions, checks for DRY violations and improper primitive use, and produces a locked hierarchy doc the migration agent can execute. Run this BEFORE writing any component code or migration plan.

Use when building reactive Obsidian plugin UI with @arrow-js/core beyond basic templates — icons (Obsidian uses Lucide; the data-icon sweep since setIcon can't run inside templates), CSS scoping/specificity against Obsidian's global rules, component mount/unmount lifecycle in an ItemView, organizing shared reactive state, and imperative-DOM/floating-UI work (popovers, menus, positioning, focus, measuring). Complements arrow-js-obsidian-templates (syntax) with integration patterns. For the full CSS decision hierarchy (Obsidian classes → oas-* utilities → custom CSS) and token/class reference, see obsidian-arrow-css.

Use when porting an Arrow component from the obsidian-arrow-sandbox into the real Obsidian plugin, or wiring a check that the plugin copy hasn't drifted from the sandbox source. Covers the content-addressed porting-parity tool (scripts/component-hash.mjs), the canonical-form rules, a port-parity manifest, and a husky/CI pre-commit hook. The sandbox is the source of truth; the plugin copy must match.

Use when prototyping or building Arrow.js UI for an Obsidian plugin in the obsidian-arrow-sandbox project — covers running the sandbox, pulling Obsidian's real app.css from the local install, the dev/verify workflow, CSS scoping, and porting a finished component into a plugin's ItemView with near-zero refactoring. For the full component + story authoring workflow, see the obsidian-arrow-stories skill.

Use when styling Arrow.js components for an Obsidian plugin — deciding between Obsidian's semantic classes, oas-* utility classes, and custom CSS; reading the live token and class references; writing scoped rules that win the specificity battle without leaking; using CSS custom properties for overrides; and auditing components to minimize hand-written CSS.