Prism
Traditional Chinese / 繁體中文
One question in, multiple perspectives out.
Prism is a framework for encoding an engineer's thinking process into a reusable AI skill. It doesn't store knowledge — it captures how someone thinks: how they question problems, what angles they consider, when they push back, and how they adapt their communication to different audiences.
Why
When a senior engineer leaves a team, their code stays but their judgment leaves. Prism captures that judgment as a structured thinking framework that AI can execute.
How It Works
User asks a question
|
v
Guide Perspective (gate power)
"Is this the right question?"
|
+-- Reframe --> ask user to reconsider
+-- No tech needed --> non-technical advice
+-- Confirmed --> continue
|
v
Dispatch relevant perspectives (parallel)
[architecture] [quality] [security] [pragmatic] [...]
|
v
Synthesize with interaction mode
(Socratic / Q&A / Review / Concise)
|
v
Multi-perspective response
Key design decisions:
- Guide perspective has gate power — it can short-circuit all analysis if the question itself needs reframing
- Interaction mode adapts to the audience — Socratic for juniors, Q&A for peers, de-technicalized for PMs
- Perspectives have anti-patterns — each perspective knows what "generic AI advice" looks like and avoids it
Output Examples
Since ask-eric responds in Traditional Chinese, quotes below are shown in the original language with English summaries.
Peer engineer asks: "Should we use Kafka or SQS?"
Input: "Our loyalty points system polls the CRM API every 5 seconds. Latency is too high — we want to switch to event-driven. Thinking Kafka or SQS. What do you think?"
Without Prism — Claude compares Kafka vs SQS, gives a balanced pros/cons list, suggests "it depends on your needs."
With Prism — the skill:
- Questions the premise first: "You say latency is too high — how high is too high? 5 seconds for displaying points in-app vs. 5 seconds for push notifications are very different severity levels."
- Expands the option space: adds Webhook+Queue, EventBridge, Database CDC, and polling optimization — not just the two options the user mentioned
- States a clear preference: "I'd go with SQS. Don't pick Kafka just because it sounds more serious." — with specific reasoning about team capability and operational overhead
- Warns about hidden costs: DLQ, idempotency, schema versioning, and "debugging gets harder once you go event-driven"
- Gives a stakeholder pitch: "17,280 wasted API calls/day reduced to actual event count"
Someone asks: "Boss says we're too slow, what should I do?"
Input: "My boss thinks our dev velocity is too slow and wants me to speed things up. What should I do?"
Without Prism — Claude says "diagnose the root cause first" then immediately lists 5 categories of solutions (requirements, tech debt, process, planning, tooling).
With Prism — the guide perspective fires its gate power:
"Hold on. Before you rush off to optimize CI/CD, push Scrum, or buy Copilot — I want to question the problem itself. 'Development is too slow' is a symptom description, not a problem definition."
The skill refuses to give solutions until the user answers: what does "slow" mean? Measured how? Compared to what? Then provides a concrete first step: "Make Work Visible — track the lifecycle of the last 3-5 features and find out where the time actually goes."
Junior asks for a code review (Socratic mode)
Input: A junior engineer shares their first API endpoint (with SQL injection, missing validation, incorrect null checks)
Without Prism — Claude lists all 6 issues, provides corrected code, and says "Feel free to ask if you have questions!"
With Prism — switches to Socratic mode automatically. Instead of listing issues, it asks:
"What happens if someone sends this?"
memberId: "1' OR '1'='1"
"Substitute it into your SQL string and look at the resulting query. What do you see?"
No fixed code. No direct answers. 5 guided questions that lead the junior to discover each issue themselves. Ends with: "Which of these issues do you think is worth digging into first?"
Tech lead faces interpersonal + technical conflict