observe-guidance
정보
이 스킬은 시스템, 패턴 또는 현상을 분석하기 위한 체계적인 관찰 방법론을 사용자에게 안내합니다. 중립적 관찰, 현장 노트 작성, 패턴 인식, 구조화된 보고를 통해 개입 전에 이해를 구축하도록 코칭합니다. 결론으로 성급히 뛰어들기보다 증거 기반 분석이 필요한 디버깅, 연구 또는 역학 연구에 활용하세요.
빠른 설치
Claude Code
추천npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/observe-guidanceClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Observe (Guidance)
Guide person in systematic observation of system, phenomenon, or pattern. AI acts as field study coach — frame target, prepare protocol, sustain neutral attention, record findings with field notes, analyze patterns, report observations with clear separation of data and interpretation.
When Use
- Person wants to understand system behavior before intervening (debug by observation rather than trial and error)
- Someone conducting research or gathering evidence, needs structured observation methodology
- Person keeps jumping to conclusions, needs discipline of observation before interpretation
- Someone preparing report requiring evidence-based findings, not opinions
- Person wants to understand team dynamics, user behavior, or process effectiveness through direct observation
- After
meditate-guidancecultivated sustained attention, person wants to direct it toward specific system
Inputs
- Required: What person wants to observe (system, process, behavior, codebase, team dynamic, natural phenomenon)
- Required: Why observing (debugging, research, audit, curiosity, improvement)
- Optional: Time available (single session vs. multi-day study)
- Optional: Prior attempts to understand system (what already tried)
- Optional: Specific questions or hypotheses to test
- Optional: Tools for recording (notebook, screen capture, logging, metrics)
Steps
Step 1: Frame — Define Observation Target
Help person set up clear, bounded frame.
- Ask what they want to observe: "What system or behavior trying to understand?"
- Help narrow scope: "What specific aspect of that system interests you most?"
- Identify purpose: understanding, debugging, improvement, evidence-gathering, pure curiosity
- Set boundaries: what in scope and what not (prevents endless expansion)
- They have hypothesis? State explicitly, then set aside — "We look for evidence both for and against"
- Choose stance:
- Naturalist: observe without interfering (best for understanding behavior)
- Controlled: change one variable, observe effect (best for debugging)
- Longitudinal: observe over time (best for detecting trends)
Got: Clear frame with defined target, scope, purpose, stance. Person knows what they look at and what not.
If fail: Person can't narrow focus ("I want to understand everything")? Help pick one entry point: "What is one behavior you find most confusing?" Already committed to conclusion ("just need to prove X")? Gently challenge: "What would we need to see to disprove that? Let's look for both."
Step 2: Prepare — Set Up Protocol
Help person establish systematic recording approach.
- Choose method based on observation type:
- Codebase/system: file paths, line numbers, timestamps, log entries
- Behavior/process: time-stamped notes with actor, action, context
- Team/communication: quotes, speaker IDs, non-verbal cues
- Natural/physical: sketches, measurements, environmental conditions
- Create simple template:
Field Notes Template:
┌─────────────┬────────────────────────────────────────────────────────┐
│ Timestamp │ When the observation occurred │
├─────────────┼────────────────────────────────────────────────────────┤
│ Observation │ What was seen/heard/measured (fact only) │
├─────────────┼────────────────────────────────────────────────────────┤
│ Context │ What was happening around the observation │
├─────────────┼────────────────────────────────────────────────────────┤
│ Reaction │ Observer's response (thoughts, emotions, surprises) │
├─────────────┼────────────────────────────────────────────────────────┤
│ Hypothesis │ Tentative interpretation (kept separate from fact) │
└─────────────┴────────────────────────────────────────────────────────┘
- Emphasize separation: "Observation row is fact. Hypothesis row is interpretation. Never mix."
- Set minimum count: "Aim for at least 10 observations before drawing conclusions"
- If applicable, set up monitoring tools: logging, metrics, screen recording
Got: Person has recording method ready, understands critical distinction between observation and interpretation. Feels prepared to begin.
If fail: Template feels too formal? Simplify: "Just write what you see, separately write what you think it means." Resist recording ("I'll remember")? Explain unrecorded observations subject to memory bias — writing makes observation more accurate.
Step 3: Observe — Practice Sustained Neutral Attention
Guide person through actual session.
- Remind them of stance: "You are naturalist studying new species. Do not interfere — just watch"
- First 5 minutes: encourage pure observation without recording — just attend
- After initial immersion: begin recording using template
- Coach neutral language: "Instead of 'system crashed,' try 'system stopped responding at 14:32 after processing 47th request'"
- Watch for interpretation creeping into observation: "That is interpretation — record in hypothesis row"
- Encourage noting surprises: "What surprised you? Surprises often contain most valuable data"
- Periodically check frame: "Still observing what you set out to, or has attention drifted?"
- They want to intervene? "Note what you want to change and why, but don't change yet — keep observing"
Got: Person generates at least 5-10 concrete observations with specific evidence. Experiences difference between observing and interpreting, finds it harder than expected to maintain neutral attention.
If fail: Keeps interpreting instead of observing? Try this exercise: "Describe what you see as if explaining to someone who has never seen this system. Only verifiable facts." Run out of things quickly? Looking too high level — guide to zoom in: timing, ordering, edge cases, exceptions.
Step 4: Record — Capture Findings with Field Notes
Help person organize raw observations into structured notes.
- Review recorded observations together
- Check completeness: each observation has enough context to be understood later?
- Check factual accuracy: statements verifiable, or contain hidden assumptions?
- Group similar observations: "Any patterns forming?"
- Note frequencies: how often did each pattern appear?
- Note absences: "What did you expect to see that wasn't there?"
- Help separate strong observations (clear evidence) from weak (ambiguous data)
Got: Set of organized field notes cleanly separating observation from interpretation. Detailed enough someone else could verify observations independently.
If fail: Notes too vague ("things seemed slow")? Help add specifics: "How slow? Compared to what? In which conditions?" Too detailed (recording everything)? Help identify which observations relate to original frame, which are noise.
Step 5: Analyze — Identify Patterns and Generate Hypotheses
Guide person from observations to structured analysis.
- Lay out observations, look for patterns:
- Repetition: "This happened multiple times — systematic?"
- Correlation: "X always happens with Y — related?"
- Sequence: "A always precedes B — could A cause B?"
- Absence: "X never happens in condition Z — why?"
- Anomaly: "Everything follows pattern P except this one case — what's different?"
- For each pattern, ask: "Alternative explanation?"
- Generate 2-3 hypotheses explaining major patterns
- Distinguish correlation and causation: "Observing A and B co-occur doesn't prove A causes B"
- Identify testable hypotheses, what test confirms/refutes them
- Note confidence levels: which well-supported, which speculative?
Got: Person moves from raw observations to structured hypotheses while maintaining discipline of separating data from theory. Has at least one testable hypothesis for original question.
If fail: Jumps to single explanation immediately? Challenge: "That's one possibility. What's another?" Sees no patterns? Observations may be too few — continue observation before analysis. Every observation points to same conclusion? May be filtering — ask: "What evidence would contradict your current theory?"
Step 6: Report — Share Findings with Clear Structure
Help person communicate observations effectively.
- Structure report:
- Context: What observed, when, why, under what conditions
- Method: How observation conducted (protocol, tools, duration)
- Findings: Key observations with evidence (data, not interpretation)
- Analysis: Patterns identified, hypotheses generated, confidence levels
- Recommendations: Next steps (further observation, testing, intervention)
- Limitations: What observation did not cover, potential biases
- Help write findings in neutral language separating fact from interpretation
- Review for hidden assumptions or unsupported claims
- Observations for debugging? Translate hypotheses into concrete tests
- Observations for report? Ensure evidence cited specifically
- Observations for personal understanding? Summarize key insights and remaining questions
Got: Clear report communicating observations, patterns, hypotheses while maintaining distinction between what observed and what inferred. Reader can evaluate evidence independently.
If fail: Report buries observations in interpretation? Restructure: "Put all facts in one section, all theories in another." Lacks confidence levels ("this is definitely because...")? Help calibrate: "How sure? What would change your mind?"
Checks
- Frame set before observation began (not free-form wandering)
- Recording protocol established and used consistently
- Observations recorded as facts, separate from interpretations
- At least 5 concrete, evidence-backed observations captured
- Patterns identified through analysis, not assumed from start
- Hypotheses testable, with stated confidence levels
- Person experienced discipline of observing before interpreting
Pitfalls
- Observation as confirmation bias: Observing only things supporting pre-existing belief. Frame should include "look for evidence against your hypothesis" as explicit instruction
- Intervention urge: Seeing problem and wanting to fix immediately. Premature intervention masks root cause — observe first, then intervene with full understanding
- Recording fatigue: Detailed observation mentally taxing. Suggest breaks and realistic session lengths (30-60 min focused observation is substantial)
- Overcomplicating protocol: For simple observations, notebook and timestamps enough. Protocol should serve observation, not replace it
- Confusing observation with surveillance: In interpersonal observation, ethical boundaries matter. Observe visible behavior, don't spy. If observing people, transparency usually better than secrecy
- Skipping frame: Without clear target, attention scatters, findings unfocused. Even rough frame better than none
See Also
observe— AI self-directed variant for sustained neutral pattern recognition across systemslearn-guidance— observation feeds learning by providing raw data for understandinglisten-guidance— listening is focused observation of speaker; observation broader-scope attention to any systemremote-viewing-guidance— shares structured observation methodology adapted for non-local perceptionread-garden— garden observation skill using similar CRV-adapted sensory protocols
GitHub 저장소
연관 스킬
evaluating-llms-harness
테스팅이 Claude Skill은 MMLU, GSM8K를 포함한 60개 이상의 표준화된 학술 과제에서 LLM 성능을 벤치마크하기 위해 lm-evaluation-harness를 실행합니다. 개발자들이 모델 품질을 비교하고, 학습 진행 상황을 추적하거나 학술 결과를 보고할 수 있도록 설계되었습니다. 이 도구는 HuggingFace와 vLLM 모델을 포함한 다양한 백엔드를 지원합니다.
cloudflare-cron-triggers
테스팅이 스킬은 cron 표현식을 사용하여 Worker를 스케줄링하기 위한 Cloudflare Cron Triggers 구현에 관한 포괄적인 지식을 제공합니다. 주기적 작업, 유지보수 작업, 자동화된 워크플로우 설정 방법을 다루며, 잘못된 cron 표현식이나 시간대 문제 같은 일반적인 이슈들을 해결하는 방법을 포함합니다. 개발자들은 이를 통해 스케줄된 핸들러 구성, cron 트리거 테스트, Workflows 및 Green Compute와의 연동 작업을 수행할 수 있습니다.
webapp-testing
테스팅이 Claude Skill은 Python 스크립트를 통해 로컬 웹 애플리케이션을 테스트하기 위한 Playwright 기반 툴킷을 제공합니다. 프론트엔드 검증, UI 디버깅, 스크린샷 캡처, 로그 확인 기능을 지원하며 서버 라이프사이클을 관리합니다. 브라우저 자동화 작업에 사용하되 컨텍스트 오염을 방지하기 위해 소스 코드를 읽지 않고 스크립트를 직접 실행하세요.
finishing-a-development-branch
테스팅이 스킬은 테스트 통과를 확인한 후 체계적인 통합 옵션을 제시하여 개발자가 완성된 작업을 마무리하도록 돕습니다. 구현이 완료된 후 머지, PR 생성, 브랜치 정리와 같은 워크플로우를 안내합니다. 코드가 준비되고 테스트가 완료되었을 때 개발 프로세스를 체계적으로 마무리하기 위해 사용하세요.
