professional-communication

# Professional Communication Skill

## Overview

This skill transforms dense technical communication into clear, structured business formats using **proposition extraction** (identify all facts and relationships) and **deterministic templates** (apply consistent structure). It extracts every detail without loss, categorizes by business relevance, applies a standard template with professional tone, and verifies completeness before delivery.

**Core principle**: Transformation ≠ creation. Only restructure existing input; always extract from existing input and restructure it for executive clarity with preserved technical accuracy.

---

## Reference Loading Table

| Signal | Load These Files | Why |
|---|---|---|
| transforming raw engineer notes: stream-of-consciousness debugging, blockers, crisis updates | `examples.md` | Loads detailed guidance from `examples.md`. |
| drafting from section templates; phrase transformations | `templates.md` | Loads detailed guidance from `templates.md`. |

## 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**

```markdown
## 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):

```markdown
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:

```markdown
**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**: F