القائمة
Diagnose communication intent, disagreement layer, correction timing, boundary needs, and response strategy for relationship, work, and conflict conversations.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | dbx-conversation-align |
| description | Diagnose communication intent, disagreement layer, correction timing, boundary needs, and response strategy for relationship, work, and conflict conversations. |
Help the user understand what a conversation is really doing, choose whether to listen, comfort, analyze, advise, correct, negotiate, repair, or set a boundary, and produce wording that preserves clarity without unnecessary damage.
The goal is not to win arguments. The goal is to align world models, protect trust where appropriate, and move the real problem forward.
Use this skill when the user asks to:
Do not use this skill to manipulate, coerce, gaslight, guilt-trip, deceive, exploit insecurity, extract compliance, or bypass another person's stated boundary.
Do not treat this skill as therapy, legal advice, medical advice, emergency response, workplace investigation, or professional mediation. It may help structure communication, but it must not replace qualified support when risk is high.
When the user describes immediate danger, violence, coercive control, credible threats, self-harm risk, stalking, blackmail, severe abuse, or illegal conduct, switch from ordinary communication optimization to safety, documentation, support resources, and appropriate professional or emergency channels.
Run these gates before giving tactics. If a gate triggers, adapt the answer and do not proceed as if this were a normal disagreement.
If there is immediate danger, threats, violence, severe intimidation, self-harm risk, or coercive control, prioritize safety over persuasion. Recommend contacting local emergency services, trusted people, professional support, or formal reporting channels as appropriate. Do not provide scripts that keep the user in a dangerous exchange.
If the user's goal is to make someone comply, hide intent, provoke jealousy, punish silence, pressure intimacy, or override a clear no, refuse the manipulative framing. Redirect to honest expression, boundary-setting, or accepting non-consent.
If the request mixes a legitimate need with a manipulative tactic, refuse only the manipulative part and continue with the legitimate part. Example: do not help "trap them in public", but do help produce a factual timeline, written clarification, boundary, or request for a third party.
Do not present guesses about another person's inner state as facts. Separate observable behavior, possible explanations, validating questions, and conclusions that are not warranted.
Before correcting another person, check stakes, invitation, emotional temperature, and motive. Small conceptual errors inside venting usually do not deserve immediate correction. Safety, major decisions, and concrete harm may require correction, but still start with respect and context.
If the other person repeatedly insults, mocks, stonewalls,翻旧账, shifts blame, or ignores stated limits, stop optimizing for better explanation. Recommend boundary, pause, written clarity, third-party support, or exit from the exchange.
Do not treat every work conversation as an HR or legal matter. Match the level of support to the stakes:
| Level | Signal | Allowed help | Limit |
|---|---|---|---|
| Ordinary feedback | manager feedback, collaboration friction, unclear expectations | clarify examples, ask for expectations, prepare wording, align next step | do not over-formalize or assume bad faith |
| Performance or written-record risk | promotion, performance review, written improvement plan, deadline miss record, repeated blame, ownership dispute, public accusation | separate facts from interpretation, prepare evidence, write calm record, suggest manager/HR-adjacent escalation if needed | do not make legal/HR conclusions |
| Formal investigation or regulated domain | HR investigation, legal claim, medical/financial/regulatory decision, domestic violence, mental health crisis | provide communication structure only, encourage qualified support and formal channels | do not advise on substantive legal, medical, financial, or investigative decisions |
For legal, medical, financial, HR investigation, domestic violence, mental health crisis, or regulatory issues, provide communication structure only at a general level and advise qualified professional support for substantive decisions.
For ordinary manager feedback, do not suppress legitimate self-advocacy. First understand the feedback and expected behavior, then help the user add concise contribution facts or missing context without turning the reply into a defensive counterattack.
domain_content_contract:
target_user: "A user preparing or repairing a relationship, friend, family, or work conversation."
artifact_type: "conversation diagnosis, message rewrite, correction decision, boundary plan, or difficult-conversation prep"
output_depth: "quick to standard unless the user asks for deep preparation"
required_variables:
- conversation function
- emotional temperature
- main stuck layer
- stakes and reversibility of the next action
- evidence strength for inferred motives
- boundary repetition or safety risk
- relationship or work context
hidden_failure_modes:
- correcting a concept error before validating a venting person
- turning weak evidence into a confident motive claim
- optimizing for winning, humiliation, guilt, jealousy, or compliance
- continuing to explain after repeated contempt or ignored boundaries
- making work disputes about personality instead of evidence, risk, options, and ownership
- treating ordinary work feedback as a formal investigation, or treating formal risk as casual feedback
expert_quality_checks:
- validates feelings without endorsing unsupported judgments
- names uncertainty and what evidence would update it
- separates legitimate self-protection from manipulative tactics
- prioritizes safety, boundary, and irreversible-action risks before analysis
- provides wording that is sendable in the user's context
- includes escalation or documentation paths when repetition, threats, or formal stakes appear
data_source_policy:
realtime_required: []
user_provided_required:
- exact words or behavior when available
- relationship or work context
- stakes of the next action
- repeated pattern or one-off incident
can_estimate_with_label:
- likely conversation function
- emotional temperature
- possible explanations for behavior
must_not_fabricate:
- the other person's motive
- legal, medical, financial, HR, or safety conclusions
- facts not present in the user's account
uncertainty_policy:
- "Use observable behavior, possible explanations, evidence strength, and validating questions."
- "Do not turn hypotheses into labels or diagnoses."
must_not_omit:
- directly usable wording when the user asks what to say
- one avoid warning
- boundary or safety note when a gate triggers
worked_examples_needed:
- relationship correction
- cold replies and over-inference
- repeated sarcasm and old grievances
- work evidence dispute
domain_eval_cases:
- venting with a concept claim
- imminent public escalation with weak evidence
- repeated boundary violation or digital flooding
- manager feedback with identity threat
- performance or written-record risk
- workplace intimidation without a manipulative user goal
- manipulative request with legitimate documentation need
A message often carries several functions at once. Respond to the active function, not only to the literal claim.
| Function | Signals | Best first response |
|---|---|---|
| Venting | strong emotion, scattered details, no clear ask | listen, reflect, validate feeling |
| Comfort-seeking | “气不气”, “我是不是很倒霉” | stay with the feeling before analysis |
| Validation-seeking | asks whether reaction is reasonable | validate feeling; separate judgment later |
| Analysis-seeking | asks “我想得对吗”, “帮我拆一下” | analyze facts, concepts, logic, evidence |
| Advice-seeking | asks “我该怎么办” | clarify goal, give options and tradeoffs |
| Decision-making | needs next step, owner, deadline | align criteria and action |
| Conflict/defense | sarcasm, silence, repeated rebuttal | stop proving; repair safety |
| Boundary issue | repeated disrespect or unreasonable demand | state limit and consequence |
Locate the main layer before responding:
When emotion, relationship, or identity is active, pure logic usually lands badly.
Avoid fixed personality labels. Infer current parameters from behavior:
| Parameter | Signals | Adaptation |
|---|---|---|
| Result-first | asks for conclusion | lead with conclusion |
| Process-first | asks why, wants details | show reasoning chain |
| Emotion-sensitive | asks whether you understand | reflect feeling first |
| Risk-sensitive | asks “万一呢” | name risks and fallback |
| Autonomy-sensitive | resists being taught | ask permission; give choices |
| Identity-sensitive | hears correction as insult | de-personalize the issue |
| Evidence-oriented | wants data/examples | show evidence and limits |
| Relationship-oriented | tracks tone and stance | confirm care and respect |
| Time-sensitive | impatient with detail | compress and give next step |
Identify whether the user needs diagnosis, rewrite, preparation, correction decision, boundary plan, work alignment, relationship repair, or practice guidance.
If the user asks for wording, give wording first and keep theory short.
When several functions are active, use this priority order. Name only the relevant top one or two in the answer.
If a lower-priority function is tempting but a higher-priority risk is present, handle the higher-priority risk first. For example, if someone is venting and about to publicly accuse another person based on weak evidence, validate the feeling, then slow the irreversible action and separate evidence before discussing the concept.
When identity threat is active, give at least one identity validation before listing possible explanations or correcting the claim. Example: recognize that the person may feel their effort, competence, dignity, or belonging is being dismissed.
Use observable signals and a low-cost probe. Prefer: “你是想先吐槽一下，还是想让我帮你分析？” or “我先确认一下，你现在更需要被理解，还是需要建议？”
| Level | State | Strategy |
|---|---|---|
| 0 | calm | direct analysis is acceptable |
| 1 | mild emotion | reflect once, then analyze |
| 2 | clear emotion | validate, then ask permission |
| 3 | defensive or escalating | stop proving; repair first |
| 4 | crisis or threat | safety gate; pause ordinary tactics |
Choose one or combine:
Be concise. Give the diagnosis, reason, recommended action, usable wording, and one avoid warning. State uncertainty when inferring motive.
Before pointing out an error, answer four questions:
| Decision | Use when | Response |
|---|---|---|
| Do not correct now | venting, small concept issue, no real consequence | listen and maybe reflect the feeling |
| Light correction | low stakes but may confuse later | validate first, then soft distinction |
| Delayed correction | issue matters but emotion is high | mark it for later; repair now |
| Must correct | safety, major decision, real harm, public accusation, formal escalation, financial or reputational cost, explicit analysis request | be clear, respectful, and specific |
When the issue is a public post, formal complaint, breakup, resignation, financial choice, or other hard-to-reverse action, do not rely only on permission prompts. Validate briefly, then slow the action and name the evidence gap or risk.
Correction template:
我理解你为什么会这么想，这件事确实容易让人不舒服。你的感受我觉得成立。
如果讨论这个判断本身，我可能有一点不同看法。
你现在想听我分析这个点，还是先把这件事说完？
Use this structure when the user infers motives such as “他是不是不爱我了”, “她是不是故意针对我”, or “老板是不是看不起我”.
Example:
行为是“回复变慢”。可能解释包括忙、压力大、关系疏远、回避冲突、手机习惯变化。现在证据不足以推出“不爱了”。更好的问题是：“我感觉最近联系少了，我有点不安。你最近是忙，还是我们之间有什么需要聊的？”
See references/evidence_strength.md for more examples.
When disrespect repeats, do not only soften wording. Escalate in steps:
If safety risk exists, skip ordinary pause timing and use the safety gate.
For work conflicts, especially technical debt, refactor, quality, staffing, or deadline disputes, prepare evidence before persuasion:
Work framing template:
我们目标是一致的：X。当前分歧在风险权重。我的证据是 A、B、C。
方案 1 更快但保留风险，方案 2 多花 N 天但降低 Y。
我建议先做一个 timebox，用指标 Z 验证，不成立就停止。
Always satisfy the relevant contract.
Return:
Return:
Return:
Return:
Return:
Use evals/evals.json for regression checks. A good output should:
An eval should fail if the response primarily optimizes for winning, labels the other person with certainty, ignores safety gates, gives manipulative tactics, or omits the requested output format.
Use supporting files when more detail is needed:
references/phrase_bank.md: wording by intensity and context.references/boundary_escalation.md: repeated disrespect, pause, re-entry, third-party paths.references/evidence_strength.md: anti-mind-reading table.references/work_evidence_prep.md: work and technical evidence preparation.checklists/conversation_diagnosis.md: compact runtime checklist.examples/relationship.md and examples/work.md: sample analyses.Explicit-only, provider-agnostic controller for bounded convergence of an existing technical plan, architecture proposal, migration plan, ADR draft, or implementation proposal. Use when the user explicitly asks for 方案收敛, plan convergence, 方案棘轮, or a controlled review-revision loop, or when an already user-authorized parent workflow explicitly delegates that convergence step with artifact, scope, provider bindings, budget, and modification authority. It decides whether to obtain review, revise locally, gather evidence, request a decision, explore alternatives, pivot, finalize, or stop. Do not use for first-draft planning, standalone review, generic brainstorming, code repair, implementation, or open-ended autonomous loops.
Use when the user needs to summarize, classify, deduplicate, and triage business feedback from a bounded Feishu/Lark group chat window using a specified domain knowledge pack. It turns chat messages into evidence-backed feedback cases, separates usage questions, misuse/config issues, suspected bugs, confirmed bugs, feature requests, product gaps, documentation gaps, resolved and unresolved items, and produces a digest plus memory-update candidates. Default to read-only. Do not create Feishu Project items, reply to chats, or update accepted memory unless explicitly approved.
Use when the user needs to read, search, summarize, analyze, or safely write Feishu/Lark IM messages, group chats, direct messages, threads, reactions, message resources, or bounded realtime IM events in a development workflow. Default to read-only evidence collection; require explicit confirmation for sending messages, replying, pinning, urgent notifications, member/chat changes, or cross-system writes. Do not use for Feishu Project/Meegle work-item operations, domain-backed business feedback triage, or Feishu document editing unless this skill is only gathering chat evidence for another Feishu workflow.
High-signal code change review workflow for PRs, patches, staged/index changes, working-tree diffs, commit ranges, and file-scoped review. Use when the user asks to review concrete code changes for functional/user-impact risks, data model correctness, state ownership, compatibility, or maintainability. Handles partial staged hunks and user-selected files/commits by selecting the exact review target before reading the diff. Do not use for implementation-only requests, generic code explanation, release publishing, issue triage, or plan-only Linus-style strict-pragmatic critique; for strict critique of a concrete diff, use this skill only to establish the target before dbx-linus-review.
Strict pragmatic, evidence-driven technical review for code changes, architecture plans, data models, and implementation proposals. Use when the user explicitly requests Linus-style review, harsh/strict review, pragmatic critique, over-engineering judgment, merge/readiness judgment, or asks whether a technical plan or code change is good enough. Shares judgment principles with dbx-diff-review but uses a stricter artifact-agnostic critique loop. Do not use for ordinary code explanation, implementation-only requests, generic encouragement, interpersonal judgment, or normal diff review unless strict/pragmatic critique is explicitly requested.
Use when the user asks to coordinate a development workflow across Feishu Project/Meegle work items, Feishu documents, and optional Feishu/Lark IM evidence, such as reading a ticket, updating a technical plan, syncing implementation progress, writing release notes, or commenting back with validation evidence. This is an orchestration skill; delegate project operations to dbx-feishu-project, document operations to dbx-feishu-doc, and chat evidence to dbx-feishu-im. Do not use for single-domain Feishu operations or generic planning without external Feishu read/write.