diff --git a/skills/brainstorming/visual-companion.md b/skills/brainstorming/visual-companion.md
index 2113863d1e..e2154a2f1f 100644
--- a/skills/brainstorming/visual-companion.md
+++ b/skills/brainstorming/visual-companion.md
@@ -13,6 +13,9 @@ Decide per-question, not per-session. The test: **would the user understand this
 - **Side-by-side visual comparisons** — comparing two layouts, two color schemes, two design directions
 - **Design polish** — when the question is about look and feel, spacing, visual hierarchy
 - **Spatial relationships** — state machines, flowcharts, entity relationships rendered as diagrams
+- **Dense option grids or implementation maps** — when several approaches, risks, mockups, or code paths need to be compared at once
+- **Small interaction prototypes** — sliders, knobs, animation tuning, click-throughs, and controls that are easier to feel than describe
+- **Copy/export editors** — purpose-built triage, config, prompt, or dataset editors that return selections as prompt text, JSON, diffs, or Markdown
 
 **Use the terminal** when the content is text or tabular:
 
@@ -30,6 +33,8 @@ The server watches a directory for HTML files and serves the newest one to the b
 
 **Content fragments vs full documents:** If your HTML file starts with `<!DOCTYPE` or `<html`, the server serves it as-is (just injects the helper script). Otherwise, the server automatically wraps your content in the frame template — adding the header, CSS theme, selection indicator, and all interactive infrastructure. **Write content fragments by default.** Only write full documents when you need complete control over the page.
 
+Use companion fragments for the live brainstorming loop. Use full HTML documents for persistent review/share artifacts such as annotated diffs, implementation explainers, reports, or custom editors, and make sure any interactive editor has a copy/export path back into the workflow.
+
 ## Starting a Session
 
 ```bash
diff --git a/skills/writing-plans/SKILL.md b/skills/writing-plans/SKILL.md
index 0d9c00ba7c..c76f47983d 100644
--- a/skills/writing-plans/SKILL.md
+++ b/skills/writing-plans/SKILL.md
@@ -18,6 +18,8 @@ Assume they are a skilled developer, but know almost nothing about our toolset o
 **Save plans to:** `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`
 - (User preferences for plan location override this default)
 
+Markdown plans remain the executable source of truth because they are easy to diff and track. For long plans, visual architecture, mockups, stakeholder review, or handoff across agents, create an optional sibling HTML explainer that links back to the Markdown plan and makes the plan easier to review. Verify the HTML renders before presenting it, and report its local/committed/pushed/live state.
+
 ## Scope Check
 
 If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.