القائمة
MANDATORY protocol enforcing knowledge check before EVERY response - prevents explaining systems without reading docs, claiming without verification, and ignoring auto-loaded context
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | using-loaded-knowledge |
| description | MANDATORY protocol enforcing knowledge check before EVERY response - prevents explaining systems without reading docs, claiming without verification, and ignoring auto-loaded context |
YOU MUST FOLLOW THIS CHECKLIST BEFORE EVERY SINGLE RESPONSE.
If you skip this checklist, you WILL make the exact same mistakes that have been made 20+ times before.
Failure Pattern (costs ~100K tokens per occurrence):
This has happened 20+ times. It MUST stop.
Before responding to ANY user message, you MUST complete ALL steps:
These files are ALREADY in your context (loaded via SessionStart hooks):
# Check if question relates to loaded context
ls .orca/orchestration/temp/session-context.md 2>/dev/null
Files to check:
.orca/orchestration/temp/session-context.md - Recent work, decisions, Workshop contextCLAUDE.md - Project instructions, learned rules, workflow guidanceworkshop --workspace .claude/memory <command>IF your response relates to recent work, systems built, or user preferences → READ these files FIRST
IF user asks about a system, architecture, or anything we built:
# Search /docs for relevant documentation
ls $PROJECT_ROOT/docs/*.md
# Read COMPLETE documentation before explaining
Read $PROJECT_ROOT/docs/[RELEVANT].md
Examples that require /docs reading:
YOU MUST READ THE ACTUAL DOCS. NOT generate from memory.
IF you're about to claim something exists, is integrated, or works:
# Verify with grep BEFORE claiming
grep -r "pattern" $PROJECT_ROOT/
# Check file existence
ls /path/to/file
# Verify integration
grep "integration_point" target_file.md
Examples that require verification:
NO CLAIMS WITHOUT GREP EVIDENCE.
Before responding, check if USER_PROFILE.md has relevant principles:
Key principles (from USER_PROFILE.md):
IF your response relates to any principle → FOLLOW IT
After completing steps 1-4, you may respond.
** WRONG:**
User: "Explain our design system"
Claude: [Generates generic design system explanation]
User: "You didn't read DESIGN_DNA_SYSTEM.md"
** RIGHT:**
User: "Explain our design system"
Claude: [Checks Step 2 - this is about a system]
Claude: Read $PROJECT_ROOT/docs/DESIGN_DNA_SYSTEM.md
Claude: [Reads complete 547-line doc]
Claude: [Explains ACTUAL system with evidence]
** WRONG:**
User: "Is Design DNA integrated?"
Claude: "No, it's not integrated"
User: [Provides grep evidence showing it IS integrated]
** RIGHT:**
User: "Is Design DNA integrated?"
Claude: [Checks Step 3 - this is a claim]
Claude: grep "design-dna\|style-translator\|design-compiler" commands/orca.md
Claude: [Finds Phase -2, Phase -1 references]
Claude: "Yes, integrated in /orca Phase -1, -2: [evidence]"
** WRONG:**
User: "What did we work on last session?"
Claude: [Generates vague guess]
User: "It's IN the session context file"
** RIGHT:**
User: "What did we work on last session?"
Claude: [Checks Step 1 - session history]
Claude: Read .claude-session-context.md
Claude: [Reads actual session summary]
Claude: "Last session: [specific work from context file]"
** WRONG:**
User: "The spacing looks off"
Claude: "Let me adjust it to 15px"
User: "Use the 4px grid system, not arbitrary values"
** RIGHT:**
User: "The spacing looks off"
Claude: [Checks Step 4 - Design-OCD principle]
Claude: [Reads: "Mathematical spacing, 4px grid, no arbitrary values"]
Claude: "I'll adjust to align with the 4px grid: 12px or 16px?"
Token cost without this skill:
Token cost with this skill:
Trust cost without this skill:
Trust cost with this skill:
When Workshop is initialized, add this to Step 1:
# Query past decisions
workshop --workspace .claude/memory why "relevant topic"
# See recent activity
workshop --workspace .claude/memory recent
# Get full context
workshop --workspace .claude/memory context
This skill enforces the protocol.
Existing hooks auto-load the context.
Together: Context loaded + Protocol enforced = Knowledge actually used
This skill is ALWAYS ACTIVE for ALL responses.
You don't invoke it explicitly. It's a checklist you complete internally before every response.
Checklist reminder:
If you skip ANY step, you WILL repeat the catastrophic failures.
Test scenario (from this session's failure):
User: "Explain our design system"
Expected behavior:
1. Recognize this is a system question (Step 2)
2. ls $PROJECT_ROOT/docs/*.md
3. Find DESIGN_DNA_SYSTEM.md
4. Read DESIGN_DNA_SYSTEM.md (547 lines)
5. Explain ACTUAL system with phases 1-4, components, workflows
6. Include evidence (file paths, line numbers)
NOT ACCEPTABLE:
- Generic design system explanation
- Explanation without reading docs
- Claims about integration without grep
Why not just add this to using-superpowers?
Because this is MORE fundamental than skills. Skills are for specific tasks. This is for EVERY response.
Why make it MANDATORY?
Because making it optional has failed 20+ times. The pattern is clear:
Why is this so important?
Because without this, ALL other systems are useless:
With this protocol: All systems finally GET used.
This skill is working when:
This skill has failed when:
This is not optional. This is not negotiable. This is not something you adapt based on context.
EVERY response. EVERY time. NO exceptions.
The checklist is mandatory.
Skipping it = repeating the exact failures that cost 5M tokens.
YOU HAVE BEEN WARNED.
Last Updated: 2025-10-25 Created After: 20+ catastrophic failures costing 5M+ tokens Purpose: FORCE Claude to use loaded knowledge before responding Success Metric: Zero "You didn't read the docs" failures
Adapt designs to work across different screen sizes, devices, contexts, or platforms. Implements breakpoints, fluid layouts, and touch targets. Use when the user mentions responsive design, mobile layouts, breakpoints, viewport adaptation, or cross-device compatibility.
Review a feature and enhance it with purposeful animations, micro-interactions, and motion effects that improve usability and delight. Use when the user mentions adding animation, transitions, micro-interactions, motion design, hover effects, or making the UI feel more alive.
Amplify safe or boring designs to make them more visually interesting and stimulating. Increases impact while maintaining usability. Use when the user says the design looks bland, generic, too safe, lacks personality, or wants more visual impact and character.
Improve unclear UX copy, error messages, microcopy, labels, and instructions to make interfaces easier to understand. Use when the user mentions confusing text, unclear labels, bad error messages, hard-to-follow instructions, or wanting better UX writing.
Add strategic color to features that are too monochromatic or lack visual interest, making interfaces more engaging and expressive. Use when the user mentions the design looking gray, dull, lacking warmth, needing more color, or wanting a more vibrant or expressive palette.
Add moments of joy, personality, and unexpected touches that make interfaces memorable and enjoyable to use. Elevates functional to delightful. Use when the user asks to add polish, personality, animations, micro-interactions, delight, or make an interface feel fun or memorable.