원클릭으로
graph-studio
Brainstorm and evolve the /graph visualization — storytelling, data layers, interaction design, and new graph modes
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Brainstorm and evolve the /graph visualization — storytelling, data layers, interaction design, and new graph modes
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | graph-studio |
| description | Brainstorm and evolve the /graph visualization — storytelling, data layers, interaction design, and new graph modes |
| metadata | {"author":"civicgraph","version":"0.1.0"} |
A creative workspace for evolving the CivicGraph force-directed graph visualization. Use this skill when you want to brainstorm what the graph should show, how it should feel, what stories it should tell, and what new modes or data layers to add.
/graph-studio — open-ended brainstorm about graph directions/graph-studio storytelling — focus on narrative and annotation ideas/graph-studio mode <name> — design a specific new graph mode/graph-studio review — screenshot the current graph and critique itRead the current implementation to understand what exists:
apps/web/src/app/graph/page.tsx — Frontend (react-force-graph-2d)
apps/web/src/app/api/data/graph/route.ts — API (hubs, justice, edge-first modes)
Check memory for the latest graph context:
~/.claude/projects/-Users-benknight-Code-grantscope/memory/MEMORY.md (## Graph Visualization section)
Query what's available to visualize:
# Entity types and counts
node --env-file=.env scripts/gsql.mjs "SELECT entity_type, COUNT(*) FROM gs_entities GROUP BY entity_type ORDER BY count DESC"
# Relationship datasets
node --env-file=.env scripts/gsql.mjs "SELECT dataset, COUNT(*), SUM(amount)::bigint FROM gs_relationships GROUP BY dataset ORDER BY count DESC"
# Justice funding topics
node --env-file=.env scripts/gsql.mjs "SELECT unnest(topics) as topic, COUNT(*) FROM justice_funding GROUP BY topic ORDER BY count DESC"
# ALMA intervention types
node --env-file=.env scripts/gsql.mjs "SELECT type, COUNT(*) FROM alma_interventions GROUP BY type ORDER BY count DESC"
# ALMA evidence levels
node --env-file=.env scripts/gsql.mjs "SELECT evidence_level, COUNT(*) FROM alma_interventions WHERE evidence_level IS NOT NULL GROUP BY evidence_level ORDER BY count DESC"
Structure ideation around these dimensions:
What questions should a user be able to answer by looking at the graph?
Each layer adds visual information without changing the graph structure:
How users explore and drill down:
mode=place — geographic graph, nodes = postcodes/LGAs, edges = funding flows between placesmode=evidence — ALMA-centered, interventions as hubs, linked orgs as spokes, colored by evidence levelmode=crosssystem — orgs that appear in 3+ datasets, showing all their different relationship typesmode=political — political donations + government contracts, showing donor→party→contract flowsmode=timeline — same graph but with a year slider, edges fade in/out by financial yearThe graph should feel like looking at a living system, not a static diagram:
After brainstorming, produce:
Top 3 Ideas — the highest-impact things to build next, ranked by:
Quick Wins — things that could be done in <30 minutes each
Moonshots — ambitious ideas that would take longer but be transformative
Updated Memory — save any new ideas/decisions to the Graph Visualization section of MEMORY.md
Take a screenshot of the current graph and provide specific visual feedback:
# Warm up then screenshot
curl -s -o /dev/null "http://localhost:3003/graph" --max-time 60
B=$(~/.claude/skills/browse/bin/find-browse) && $B goto "http://localhost:3003/graph" && sleep 25 && $B screenshot /tmp/graph-review.png
Critique:
| Mode | Data Source | Hub Type | Typical Size |
|---|---|---|---|
justice | justice_funding table | Programs (diamond) | 811 nodes, 1,596 edges |
hubs | gs_relationships | Top-connected entities | 4,592 nodes, 6,091 edges |
| edge-first | gs_relationships | None (top by amount) | ~2,500 nodes, 10K edges |
| Table | Rows | Graph Potential |
|---|---|---|
gs_entities | 100K | Node source for all modes |
gs_relationships | 199K | Edge source (but justice edges are self-loops!) |
justice_funding | 52K | Program→recipient edges (real connections) |
alma_interventions | 1.2K | Evidence overlay, 484 youth-justice tagged |
austender_contracts | 672K | Government procurement edges |
political_donations | 312K | Political money flow edges |
foundations | 10.8K | Foundation grantmaking |
gs_relationships where dataset='justice_funding' has 34,853 self-loops out of 34,857 edges. These are useless for graph visualization. The justice mode queries justice_funding table directly to build real program→recipient edges.
youth-justice, child-protection, ndis, family-services, indigenous, legal-services, diversion, prevention, wraparound, community-led
Surface-quality loop — judge a user-facing screen the way Ben does (Clarity / Value-shown / Meaning / Aesthetic / Friction), collect ranked findings without fixing mid-audit, then fix the top ones with Ben in the loop and ship them. Seeded from the buyer-flow UX audit. Self-paced loop; exit is Ben's taste-check, not "when done". Use on /polish, "polish this", "audit the UX", "does this surface read as value", or before declaring a buyer-facing screen good.
Data-to-Goals Leverage Map — inventory the whole data estate, align it to the buyer-wedge + mission goals, and surface the highest-value LATENT connections we already have the data for but aren't exploiting. Connect/deepen, never widen (data widening is paused). Self-paced loop that appends to a living map. Use on /leverage, "what should we build", "find valuable connections", "what are we sitting on", "align our data to goals".
Buyer-wedge strategy guardrail — evaluate any proposed feature, data work, or product decision against the SE-registry strategy (free open registry for everyone; paid evidence + tender tools for buyers). Use when deciding whether to build something, when scoping a feature, when prioritising between work items, or when the user asks "should we build X" / "/wedge".
Lighthouse-buyer workflow — find and prepare the first paying government buyer for the SE evidence + tender-pack product. Mines se_buyer_prospects (buyers who already contract with registry SEs), shortlists VIC/SA buyers with social-procurement obligations, and assembles an evidence-led outreach pack. Use when the user says "/lighthouse", "find buyers", "prospect buyers", or wants outreach material for a procurement team.