visualize-plan
Renders planned changes — architecture and before/after comparisons, risk heat maps, execution order, dependency graphs, impact metrics — in your chosen output format (ASCII + emojis, an interactive HTML playground, or a NotebookLM infographic). Stores visualizations in memory for cross-session reference. Use when reviewing implementation plans, comparing approaches, assessing risk, or analyzing change propagation.
What this skill does
# Plan Visualization
Render planned changes as structured ASCII visualizations with risk analysis, execution order, and impact metrics. Every section answers a specific reviewer question.
**Core principle:** Encode judgment into visualization, not decoration.
```bash
/ork:visualize-plan # Auto-detect from current branch
/ork:visualize-plan billing module redesign # Describe the plan
/ork:visualize-plan #234 # Pull from GitHub issue
```
## Argument Resolution
```python
PLAN_INPUT = "$ARGUMENTS" # Full argument string
PLAN_TOKEN = "$ARGUMENTS[0]" # First token — could be issue "#234" or plan description
# If starts with "#", treat as GitHub issue number. Otherwise, plan description.
# $ARGUMENTS (full string) for multi-word descriptions (CC 2.1.59 indexed access)
```
---
## CRITICAL: Task Tracking
```python
# 1. Create main task IMMEDIATELY
TaskCreate(subject="Visualize plan: {PLAN_INPUT}", description="Plan visualization with ASCII rendering", activeForm="Analyzing plan context")
# 2. Create subtasks for each phase
TaskCreate(subject="Detect or clarify plan context", activeForm="Detecting plan context") # id=2
TaskCreate(subject="Gather data and explore architecture", activeForm="Gathering plan data") # id=3
TaskCreate(subject="Render tier 1 header", activeForm="Rendering header") # id=4
TaskCreate(subject="Render sections + dispatch to chosen format(s)", activeForm="Rendering sections") # id=5
TaskCreate(subject="Offer actions and store in memory", activeForm="Finalizing visualization") # id=6
# 3. Set dependencies for sequential phases
TaskUpdate(taskId="3", addBlockedBy=["2"]) # Data gathering needs context first
TaskUpdate(taskId="4", addBlockedBy=["3"]) # Header needs gathered data
TaskUpdate(taskId="5", addBlockedBy=["4"]) # Sections need header rendered
TaskUpdate(taskId="6", addBlockedBy=["5"]) # Actions need sections done
# 4. Before starting each task, verify it's unblocked
task = TaskGet(taskId="2") # Verify blockedBy is empty
# 5. Update status as you progress
TaskUpdate(taskId="2", status="in_progress") # When starting
TaskUpdate(taskId="2", status="completed") # When done — repeat for each subtask
```
## STEP -1: Check Memory for Prior Plans
```python
# Search for related prior visualizations
mcp__memory__search_nodes(query="plan visualization {PLAN_INPUT}")
# If found, offer to compare with previous plan
```
## STEP 0: Detect or Clarify Plan Context
**First**, attempt auto-detection by running `scripts/detect-plan-context.sh`:
```bash
bash "$SKILL_DIR/scripts/detect-plan-context.sh"
```
This outputs branch name, issue number (if any), commit count, and file change summary.
**If auto-detection finds a clear plan** (branch with commits diverging from main, or issue number in args), proceed to Step 1.
**If ambiguous**, clarify with AskUserQuestion:
```python
AskUserQuestion(
questions=[{
"question": "What should I visualize?",
"header": "Source",
"options": [
{"label": "Current branch changes (Recommended)", "description": "Auto-detect from git diff against main"},
{"label": "Describe the plan", "description": "I'll explain what I'm planning to change"},
{"label": "GitHub issue", "description": "Pull plan from a specific issue number"},
{"label": "Quick file diff only", "description": "Just show the change manifest, skip analysis"}
],
"multiSelect": false
}]
)
```
---
## STEP 0.5: Choose Output Format (Front Door)
Decide **how** to render before gathering data. First **probe capabilities**, then ask only for what's available. Full procedure: `Read("${CLAUDE_SKILL_DIR}/references/format-dispatch.md")`.
Use the established MCP-probe pattern — `Read("${CLAUDE_SKILL_DIR}/../chain-patterns/references/mcp-detection.md")` — not ad-hoc checks:
```python
# infographic is available IFF the notebooklm studio tool resolves:
ToolSearch(query="select:mcp__notebooklm-mcp__studio_create")
```
Gate the options: **ascii** always (the floor); **playground** if the `playground` skill is installed (ships with ork); **infographic** if `studio_create` resolved above (server reachable + `nlm login` done). If only ASCII is available, skip the question.
If only ASCII is available, **skip the question** and render ASCII. Otherwise ask (hide ungated options, surface a one-line install/auth hint instead):
```python
AskUserQuestion(questions=[{
"question": "How should I render this plan?",
"header": "Format",
"options": [
{"label": "ASCII + emojis (Recommended)", "description": "Fast, in-chat, zero-dependency. Always the floor — rendered first even if you also pick a richer format."},
{"label": "Interactive playground", "description": "Single-file HTML explorer written to docs/<branch-dir>/plan-viz.html (also satisfies the PR Playground gate). Delegates to the playground skill."},
{"label": "NotebookLM infographic", "description": "Stakeholder-ready infographic/slides via notebooklm studio_create. Async — fired and notified, never blocks."},
{"label": "All available", "description": "ASCII inline now + the richer formats linked as they finish."}
],
"multiSelect": false
}])
```
**ASCII floor rule:** always render ASCII first/inline regardless of choice — never `await` the async NotebookLM job. Record the chosen format(s) as `FORMATS` for STEP 4 dispatch.
---
## STEP 1: Gather Data
Run `scripts/analyze-impact.sh` for precise counts:
```bash
bash "$SKILL_DIR/scripts/analyze-impact.sh"
```
This produces: files by action (add/modify/delete), line counts, test files affected, and dependency changes.
For architecture-level understanding **and the default before/after section [0]**, spawn an Explore agent that maps the component graph at BOTH the base and the head:
```python
Agent(
subagent_type="Explore",
prompt="Map component architecture of {affected_directories} at TWO points: (a) base = each file as returned by `git show origin/main:<path>` (NOT the working tree — avoids conflating uncommitted edits), (b) head = current working tree. Return per point: components, dependencies, data flows; mark what is added [+], removed [-], or changed [~] between them. Use the ascii-visualizer skill for diagrams.",
model="haiku"
)
```
If the diff touches frontend (`*.tsx`/`*.css`/route files), also run a `design-context-extract` pass so the design surface is part of before/after. Patterns: `Read("${CLAUDE_SKILL_DIR}/references/before-after-arch-patterns.md")`.
Build a compact **plan brief** (markdown) from this data — the single interchange every non-ASCII format consumes (see `format-dispatch.md`).
---
## STEP 2: Render Tier 1 Header (Always)
Use `assets/tier1-header.md` template. Load `Read("${CLAUDE_SKILL_DIR}/references/visualization-tiers.md")` for field computation (risk level, confidence, reversibility).
```
PLAN: {plan_name} ({issue_ref}) | {phase_count} phases | {file_count} files | +{added} -{removed} lines
Risk: {risk_level} | Confidence: {confidence} | Reversible until {last_safe_phase}
Branch: {branch} -> {base_branch}
[0] Before/After [1] Changes [2] Execution [3] Risks [4] Decisions [5] Impact [all]
```
---
## STEP 3: Ask Which Sections to Expand
**Section [0] Before/After is rendered automatically as the lead** whenever the Explore map shows structural changes (skipped with a one-line note otherwise) — so it is never buried behind a picker choice. The options below select among the remaining sections [1]–[5]; "All sections" includes [0].
```python
AskUserQuestion(
questions=[{
"question": "Which sections to render?",
"header": "Sections",
"options": [
{"label": "All sections", "description": "Full visualization with all 6 core sections"},
{"label": "Changes + Execution", "description": "File diff tree and execution swimlane"},
{"label": "Risks + Decisions", "description": "Risk dashboard and deciRelated in Web Dev
generating-lwc-components
IncludedLightning Web Components with PICKLES methodology and 165-point scoring. Use this skill when the user creates or edits LWC components, builds wire service patterns, or writes Jest tests for LWC. TRIGGER when: user creates/edits LWC components, touches lwc/**/*.js, .html, .css, .js-meta.xml files, or asks about wire service, SLDS, or Jest LWC tests. DO NOT TRIGGER when: Apex classes (use generating-apex), Aura components, or Visualforce.
tanstack-query
IncludedManage server state in React with TanStack Query v5. Set up queries with useQuery, mutations with useMutation, configure QueryClient caching strategies, implement optimistic updates, and handle infinite scroll with useInfiniteQuery. Use when: setting up data fetching in React projects, migrating from v4 to v5, or fixing object syntax required errors, query callbacks removed issues, cacheTime renamed to gcTime, isPending vs isLoading confusion, keepPreviousData removed problems.
document-processor-api
IncludedProcess documents with Nutrient DWS. Use when the user wants to generate PDFs from HTML or URLs, convert Office/images/PDFs, assemble or split packets, OCR scans, extract text/tables/key-value pairs, redact PII, watermark, sign, fill forms, optimize PDFs, or produce compliance outputs like PDF/A or PDF/UA. Triggers include convert to PDF, merge these PDFs, OCR this scan, extract tables, redact PII, sign this PDF, make this PDF/A, or linearize for web delivery.
nutrient-document-processing
IncludedProcess documents with Nutrient DWS. Use when the user wants to generate PDFs from HTML or URLs, convert Office/images/PDFs, assemble or split packets, OCR scans, extract text/tables/key-value pairs, redact PII, watermark, sign, fill forms, optimize PDFs, or produce compliance outputs like PDF/A or PDF/UA. Triggers include convert to PDF, merge these PDFs, OCR this scan, extract tables, redact PII, sign this PDF, make this PDF/A, or linearize for web delivery.
tanstack-query
IncludedManage server state in React with TanStack Query v5. Covers useMutationState, simplified optimistic updates, throwOnError, network mode (offline/PWA), and infiniteQueryOptions. Use when setting up data fetching, fixing v4→v5 migration errors (object syntax, gcTime, isPending, keepPreviousData), or debugging SSR/hydration issues with streaming server components.
accelint-nextjs-best-practices
IncludedNext.js performance optimization and best practices. Use when writing Next.js code (App Router or Pages Router); implementing Server Components, Server Actions, or API routes; optimizing RSC serialization, data fetching, or server-side rendering; reviewing Next.js code for performance issues; fixing authentication in Server Actions; or implementing Suspense boundaries, parallel data fetching, or request deduplication.