本文へ移動
cccskills
無料GitHub で公開

psychological-safety

Build psychological safety in your team using Simon Sinek's Leaders Eat Last Circle of Safety model and Amy Edmondson's research. Use when a leader says "my team doesn't speak up", "people are afraid to fail", "nobody challenges bad ideas", "people only tell me what I want to hear", "I want my team to take more risks", "there's a blame culture", "people hide mistakes", or "I want to create a safe environment". Also trigger when someone describes a team where postmortems turn into blame sessions, where people stay quiet in meetings and then vent privately, where mistakes are hidden until they become crises, or where the same person speaks 80% of the time in every meeting. Psychological safety is not about comfort - it is the condition that makes high performance possible.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md10.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Overview

Based on "Leaders Eat Last" by Simon Sinek and Amy Edmondson's psychological safety research. Sinek's insight: humans are wired to withhold their best thinking in environments that feel unsafe. The Circle of Safety - the conditions under which people feel protected from external threats - is the leader's most fundamental responsibility. Without it, people use cognitive energy protecting themselves from internal threats (judgment, blame, embarrassment) rather than solving real problems. Edmondson's research found psychological safety is the single strongest predictor of team performance - more than talent, resources, or strategy.

The Four Stages of Psychological Safety

Edmondson and Sinek's work maps to a progression:

StageDescriptionSignal
InclusionPeople feel accepted as members of the teamNew members contribute within the first week
LearnerPeople feel safe asking questions and admitting they don't knowPeople say "I don't know" without hedging
ContributorPeople feel safe doing their work and trying new approachesPeople take initiative without asking permission
ChallengerPeople feel safe challenging the status quo and authorityPeople disagree with the leader openly

Most teams that think they have psychological safety are at Inclusion or Learner. True high performance requires Challenger safety.

Workflow

Step 1: Diagnose the Current Level

Observable signals that safety is low:

  • Meeting pattern: one or two people dominate, others are silent or give short answers
  • Retrospectives: problems are stated vaguely or attributed to external factors, never to internal decisions
  • Mistakes: people hide problems until they're unavoidable, then over-explain
  • Disagreement: happens in side conversations (Slack DMs, hallway chats) but not in the room
  • Questions: people ask questions privately in 1:1s that they won't ask in group settings

Observable signals that safety is high:

  • People raise problems early, when they're still small
  • People disagree with each other (and with you) in meetings, not just privately
  • Someone says "I made a mistake" or "I don't know" without a defensive disclaimer
  • New ideas come from multiple people, not just the same two people
  • Postmortems focus on system failures, not individual blame

Run a quick check: In your last 5 team meetings, how many distinct voices contributed substantively? If the answer is 2-3 in a team of 8+, safety is low.

Step 2: Identify the Leader's Contribution to the Problem

Before prescribing interventions, the leader must assess their own behavior. Most low-safety environments are created by the leader, not by team dynamics.

Common leader behaviors that erode safety:

Response to mistakes:

  • Does the team see you respond to failures with analysis or blame?
  • When you or your team makes a mistake, do you own it publicly?

Response to disagreement:

  • When someone challenges your idea, do you engage with curiosity or defend?
  • Do you treat counterarguments as threats or as information?

Response to bad news:

  • When someone brings you a problem, is your first reaction "thanks for telling me" or visible frustration?
  • Do people wait to bring you problems until they have a solution? (This is a sign they don't feel safe raising raw problems)

Body language and signals:

  • Do you check your phone or laptop in meetings?
  • Do you visibly react to opinions you disagree with before the person finishes speaking?

Complete this honestly:

When was the last time I admitted a mistake to my team? [date or "can't remember"]
When was the last time I changed my position because of someone's argument? [date or "can't remember"]
When someone challenged me, what did I actually do? [describe]
What do I do when someone brings me bad news? [describe]

Step 3: Build Inclusion Safety (Foundation)

If people don't feel like they belong on the team, nothing else works.

Actions:

  • Onboard new team members explicitly - make introductions, assign a peer buddy, check in weekly for the first month
  • Use names in meetings. "What do you think, [name]?" signals that you know who they are and their input matters
  • Acknowledge contributions publicly: "That point [name] made last week shaped how we approached this"
  • Make eye contact and face people when they speak - physical attention is a signal of safety

Step 4: Build Learner Safety

People need to feel safe not knowing before they'll ask questions that surface real problems.

Actions:

  • Model intellectual humility publicly: "I don't know the answer to that - let's find out" in front of the full team
  • Praise questions, not just answers: "That's an important question" before answering it
  • Create a "dumb question" norm - in meetings, explicitly invite the "basic" question that everyone is thinking but no one wants to ask
  • Run "pre-mortems" before big decisions: "What don't we know yet that we should know?" This normalizes not knowing

Step 5: Build Contributor Safety

People need to feel safe taking initiative before they'll operate without constant guidance.

Actions:

  • Give explicit permission to act: "You don't need my approval to [specific category of decisions]. Just do it and tell me."
  • When someone makes a mistake while taking initiative, treat it as learning, not failure: "What did you try? What did you learn? What's the next experiment?"
  • Debrief failed experiments with the same rigor as failed execution - distinguish between bad process and bad luck
  • Publicly celebrate initiative, not just results: "I want to call out that [person] tried a completely new approach here, even though it didn't work as expected"

Step 6: Build Challenger Safety

This is the hardest and most valuable stage. It requires the leader to be genuinely comfortable with dissent.

Actions:

  • Assign devil's advocate roles in major decisions - making it a role removes the personal risk of being "the difficult one"
  • Use "two-hat" meetings: first half, generate ideas freely; second half, critique them. Keep the phases separate so people don't self-censor in the first half
  • When someone challenges you, respond with questions first: "Tell me more about that" or "What are you seeing that I might be missing?"
  • Change your position visibly when you're persuaded: "I was wrong about that. [Name]'s point changed my thinking." This is the highest-signal behavior for challenger safety

Step 7: Psychological Safety Health Check

Run this with the team quarterly (anonymous survey or group exercise):

Psychological Safety Check - [team] - [date]

Rate each statement 1-5 (1=never, 5=always):

1. I feel comfortable raising a problem before I have a solution.
2. I can disagree with [manager name] or senior team members without negative consequences.
3. When mistakes happen, we analyze the system, not blame the person.
4. I can say "I don't know" without it reflecting poorly on me.
5. New ideas are welcomed, even if they challenge how we currently do things.

Average score: [x/5]

Lowest-scoring statement: [this is where to focus]
One action we'll take in the next 30 days: [specific, behavioral]

Anti-Patterns

1. Confusing psychological safety with conflict avoidance Bad: "We have a great culture - we never have conflict." Good: Low-conflict teams are often low-safety teams where disagreement goes underground. Healthy psychological safety produces more productive conflict, not less. The goal is conflict that makes decisions better, not silence that protects them.

2. Responding to bad news with problem-solving before acknowledgment Bad: Someone says "we're going to miss the deadline" and you immediately go to "OK what are our options." Good: First: "Thanks for telling me early. What happened?" The problem-solving matters, but if people learn that bad news triggers immediate interrogation, they wait longer to share it next time.

3. Praising psychological safety without modeling it Bad: Saying "I want you to speak up if you disagree" but visibly bristling when someone does. Good: People watch behavior, not words. The leader's reaction to the first challenge in the room determines whether everyone else will challenge. One dismissive response can undo months of stated intent.

4. Safety as a morale initiative, not a performance tool Bad: Running psychological safety workshops as an HR requirement and treating it as culture work unrelated to outcomes. Good: Edmondson's research is unambiguous: psychological safety predicts team performance. Frame it as a performance lever, not a feelings exercise. Teams that feel safe make fewer mistakes, learn faster, and produce better outcomes.

5. Group surveys without action Bad: Running a psychological safety survey and not acting on the results. Good: Surveying without acting is worse than not surveying. It signals that the data doesn't matter. Every survey must produce at least one visible action. Share what you heard and what you're going to do about it.

Quality Checklist

  • Diagnosed current safety level using observable meeting and behavior signals
  • Leader's own contribution to the problem assessed honestly
  • Starting at the right stage (don't skip to Challenger if Inclusion is broken)
  • At least one specific leader behavior change identified, not just team interventions
  • Quarterly health check or survey scheduled
  • Follow-up action taken on survey results within 30 days
  • Postmortems and mistake conversations reviewed for blame patterns

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Rate any product, feature, or experience on the 11-star scale (Brian Chesky's Airbnb thought experiment). Use when user says "rate this experience", "11-star", "star rating", "experience audit", "how good is this", "experience rating", "product audit", "quality assessment", or wants to evaluate product quality and identify improvement paths. Also trigger when user wants to benchmark a feature, assess where a product stands, or map out what "great" looks like - even if they don't explicitly say "11-star".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Generate A/B copy variants grounded in Eugene Schwartz's awareness and market-sophistication stages and John Caples' tested-headline discipline. Every variant declares its angle, the awareness stage it targets, and a falsifiable hypothesis, and the skill recommends which pair to test first and what delta counts as signal. Use when the user says "A/B test this", "write variants", "give me options", "test different angles", "copy variants", "ab copy", "test this headline", "multiple versions", "which version is better", or wants to test copy before publishing. For reviewing copy that already exists, see copy-review. For sample size and stopping rules, see growth-experiment. For diagnosing a page rather than its words, see page-cro. For full paid ad sets by platform, see ad-campaign-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write measurable acceptance criteria for requirements or user stories. Use when the user says "write acceptance criteria", "definition of done", "how do we test this", "fit criteria", "given when then", "Gherkin scenarios", "what does done look like", "testable conditions", "how will we know this works" - even if they don't explicitly say "acceptance criteria".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Build a strategic account plan for winning, retaining, or expanding a named account. Use when the user says "build an account plan", "strategic account planning", "how do I grow this account", "account expansion strategy", "whitespace analysis", "QBR prep", "key account review", "map the stakeholders in this account", "land and expand plan", "how do I break into [company]", or wants a structured strategy for a specific account.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write paid ad copy for LinkedIn, Google, Meta, and YouTube. Produces multiple variants per platform, each targeting a different Eugene Schwartz awareness level and Cialdini persuasion principle. Use when the user asks for ad copy, ad variants, "write LinkedIn ads", Google ads, Meta ads, paid social copy, ad headlines, or wants creative for a paid campaign. Reads brand voice, ICP, and positioning from knowledge/. For organic social posts, see linkedin-post or social-calendar. For the landing page the ad points at, see landing-page-writer. For testing variants, see ab-copy-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Design clean and consistent APIs. Use when the user says "design an API", "API design review", "design these endpoints", "REST API for X", "GraphQL schema", "API contract", "how should this endpoint work", "review my API design", or wants to create or improve an API interface - even if they don't explicitly say "API design".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

qa-aman のスキルをすべて見る

このスキルの問題を報告する