Professional Communication

Instructions

Phase 1: PARSE

Goal: Extract every proposition from the input before structuring anything. This prevents information loss and ensures technical accuracy is preserved.

Step 1: Classify input type

Identify the communication type (this determines categorization strategy in Phase 2):

• Technical update (progress report with embedded facts)
• Debugging narrative (stream-of-consciousness problem-solving)
• Status report (project state with blockers/dependencies)
• Dependency discussion (constraints buried in defensive language)

Step 2: Extract all propositions

Parse each sentence systematically. Extract all propositions before summarizing — summarizing skips propositions and loses facts:

1. Facts: All distinct statements of truth
2. Implications: Cause-effect relationships
3. Temporal markers: Past/present/future actions
4. System references: All mentioned components
5. Blockers: Hidden dependencies and constraints
6. Emotional context: Frustration/satisfaction/urgency indicators (needed to transform defensive language)

Step 3: Document implicit context

Surface assumptions the author takes for granted but the audience needs stated. Non-technical audiences cannot act without this:

• Technical acronyms or project names the audience may not know
• Timeline context (when things happened relative to milestones)
• Organizational context (team relationships, reporting structures)

Step 4: Count and validate propositions

## Parsing Result
Input type: [technical update | debugging narrative | status report | dependency discussion]
Proposition count: [N distinct facts/claims]
Emotional markers: [frustration | satisfaction | urgency | neutral]

Extracted Propositions:
1. [Fact/claim 1]
2. [Fact/claim 2]
... (ALL propositions - NO information loss)

Implicit Context:
- [Assumption 1]
- [Assumption 2]

Gate: ALL propositions extracted with zero information loss. Proceed only when gate passes.

Phase 2: STRUCTURE

Goal: Categorize and prioritize all extracted propositions by business relevance. This prevents unsolicited sections and keeps output focused on what matters most.

Step 1: Categorize propositions

Organize by type (categorization determines template section placement):

Status:   [items with current state]
Actions:  [completed, in-progress, planned]
Impacts:  [business and technical consequences]
Blockers: [dependencies, constraints]
Next:     [required actions]

Step 2: Priority order

Rank by impact to executive decision-making, not completeness:

1. Business Impact (revenue, customer, strategic)
2. Technical Functionality (core operation)
3. Project Timeline (schedule implications)
4. Resource Requirements (personnel, infrastructure)
5. Risk Management (potential issues)

Only the highest-priority categories go into the output. Lower-priority items are preserved in Technical Details but not emphasized.

Step 3: Identify information gaps

Flag any propositions that need clarification before transformation. Ask for specifics only when severity classification is ambiguous:

• Ambiguous severity (could be GREEN or YELLOW — default to YELLOW if unclear)
• Missing ownership for action items (block on clarity, ask for clarity)
• Undefined technical terms critical to business impact (ask for definition)

Gate: All propositions categorized and prioritized. Proceed only when gate passes.

Phase 3: TRANSFORM

Goal: Apply standard template with professional tone. This ensures consistent, executive-ready formatting without speculative sections.

Step 1: Apply standard template

Include only the sections in the standard template (Risk Assessment, Historical Context, Mitigation Strategies). Use ONLY this structure:

**STATUS**: [GREEN|YELLOW|RED]
**KEY POINT**: [Single most important business takeaway]

**Summary**:
- [Primary accomplishment/issue]: [Business impact]
- [Current focus/blocker]: [Expected outcome/resolution need]
- [Secondary consideration]: [Implications]

**Technical Details**:
[2-3 sentences maximum preserving technical accuracy]

**Next Steps**:
1. [Specific action with timeline if available]
2. [Secondary action with ownership implications]
3. [Follow-up considerations]

Step 2: Tone adjustment

The transformation rules are deterministic (apply all):

• Strip hedging language: "I think we might need to..." → "Deploy X to address Y"
• Transform defensive tone: "We had to rollback because..." → "Rolled back to [previous version] due to [root cause]"
• Preserve urgency markers and severity indicators (needed for status classification)
• Keep technical terms intact (oversimplification loses information; non-technical audiences still need accuracy)
• Maintain causal chains and specific metrics (specific > generic)

Step 3: Status classification

Apply criteria consistently (inconsistency confuses stakeholders and erodes trust):

• GREEN: Fully complete with no follow-up, all verification done
• YELLOW: Resolved with follow-up needed, blocked on dependencies, partial completion
• RED: Active critical issues, production impact, urgent intervention needed

Always document reasoning: "Status: YELLOW (deployment successful but monitoring pending)" not just "Status: YELLOW"

Step 4: Action item specificity

Vague action items cannot be executed. Every next step MUST include:

• Specific action verb (investigate, deploy, coordinate, document) — "fix" is too vague
• Clear scope (what exactly needs doing) — define the boundary
• Ownership implication (who or which team) — someone must be accountable
• Timeline marker when available (IMMEDIATE, by EOW, this sprint) — explicit > implied

Gate: Output follows template structure with professional tone and all specificity rules applied. Proceed only when gate passes.

Phase 4: VERIFY

Goal: Confirm transformation quality before delivery. All gates must pass; proceed only when complete.

Step 1: Compare output against extracted propositions — NO information loss allowed. If a fact from Phase 1 doesn't appear in output, it belongs in Technical Details.

Step 2: Verify technical accuracy — terms, metrics, causal chains preserved exactly. Preserve exact technical terms ("database issues" for "Redis cluster failover") — specificity is required.

Step 3: Confirm status indicator matches actual severity. Check reasoning against actual criteria (GREEN ≠ YELLOW vs YELLOW ≠ RED boundaries).

Step 4: Validate action items are specific — check each next step for (verb, scope, owner, timeline). "Fix the issue" fails; "Complete Redis failover testing in staging (DevOps, by EOW)" passes.

Step 5: Check appropriate detail level for target audience. If audience is non-technical, Technical Details should bridge jargon with plain explanations without losing precision.

Step 6: Document transformation summary to prove gate passage:

## Transformation Summary
Input type: [type]
Propositions extracted: [N]
Status assigned: [GREEN|YELLOW|RED] ([reasoning])
Information loss: None
Template applied: standard

Gate: All verification checks pass. Transformation is complete. Complete all 6 steps before delivering.

Examples

Example 1: Multi-Propositional Sentence

User says: "I fixed the database issue but then the API started failing so I had to rollback and now we're investigating the connection pool settings which might be related to the recent Kubernetes upgrade." Actions:

1. Extract 5 propositions: DB fix, API failure, rollback, pool investigation, K8s link (PARSE)
2. Categorize: Status=rollback done, Blockers=pool+K8s, Actions=investigating (STRUCTURE)
3. Apply template with YELLOW status, specific next steps (TRANSFORM)
4. Verify no facts lost, technical terms preserved (VERIFY) Result: Structured update with clear status and actionable next steps

Example 2: Defensive Blocker Communication

User says: "I can't make progress because the API team hasn't responded in 3 days and my sprint is at risk" Actions:

1. Extract urgency, duration, dependency, impact propositions (PARSE)
2. Categorize: Blocker=API spec, Impact=sprint risk, Timeline=3 days (STRUCTURE)
3. Apply template with YELLOW status, escalation-focused next steps (TRANSFORM)
4. Verify urgency preserved, defensive tone neutralized (VERIFY) Result: Neutral status report with clear escalation path

Example 3: Crisis Communication

User says: "The latest deploy broke checkout completely, users are getting 500 errors, we rolled back but some orders might be lost" Actions:

1. Extract severity, system affected, user impact, rollback status, data risk (PARSE)
2. Categorize: Status=rolled back, Impact=orders lost, Blocker=data recovery (STRUCTURE)
3. Apply template with RED status, IMMEDIATE/URGENT tiered next steps (TRANSFORM)
4. Verify crisis severity reflected, no false reassurance in tone (VERIFY) Result: RED status report with tiered emergency response actions

Error Handling

Error: "Missing Context in Input"

Cause: Technical terms or acronyms critical to business impact are undefined.

Solution:

1. Ask user for clarification on terms critical to status classification — speculation causes wrong status assignments
2. Make reasonable inferences only for minor details; flag all assumptions explicitly in Technical Details section
3. Complete transformation while waiting — provide output with a note: "Status classification assumed X because Y was undefined"

Error: "Ambiguous Status Classification"

Cause: Input contains mixed signals (e.g., issue resolved but monitoring incomplete).

Solution:

1. Default to YELLOW when unclear between GREEN/YELLOW — YELLOW preserves urgency for follow-up without false reassurance
2. Default to RED only with clear critical indicators: production impact (users affected), data loss (unrecoverable), or ongoing crisis (not yet mitigated)
3. Document reasoning in parenthetical: "Status: YELLOW (deployment successful but monitoring pending)" — transparency prevents misinterpretation

Error: "Multi-Thread Update Contamination"

Cause: Input contains multiple unrelated topics that could cross-contaminate status classifications.

Solution:

1. Process each thread as separate proposition set (Phase 1 extraction per thread)
2. Apply template independently to each thread (Phase 2-3 per thread)
3. Combine with clear thread identification in final output (use headers: "Thread A: Deployment", "Thread B: Data Recovery")
4. Ensure status indicators are thread-specific (Thread A may be GREEN while Thread B is RED) — separate outcomes, separate classifications

Error Handling Principles

Constraint distribution in error handling:

• Summarizing before extracting = loses facts. Complete Phase 1 fully before proceeding.
• Status is "obvious" = assumption. Apply classification criteria consistently, document reasoning.
• Technical details not needed for non-technical audience = false. Always include Technical Details; bridge jargon with explanation.
• Action items are implied = stakeholders cannot execute implied work. Write explicit (verb, scope, owner, timeline) for every next step.
• Professional tone is "close enough" = defensive language still embedded. Apply ALL transformation rules: hedging → direct, emotional → neutral, vague → specific.

References

Reference Files

• ${CLAUDE_SKILL_DIR}/references/templates.md: Status-specific templates, section formats, phrase transformations
• ${CLAUDE_SKILL_DIR}/references/examples.md: Complete transformation examples with proposition extraction