Bilingual exec report

Bilingual exec status report

When to use this

You have just finished engineering work. You need to send a report to a non-technical decision-maker (CEO, principal, board, your boss). The report needs to:

• Make the work visible without jargon.
• Reset expectations about how much one engineer can deliver, especially compared to a previous developer who appears to have done "everything" (because they had no choice).
• Honour the predecessor if applicable (deceased, retired, departed) — neither erase them nor blame them.
• Quantify the safety improvements, not just enumerate features.
• Be readable in 5 minutes — executives don't read 20-page reports.

This skill was specifically built for the situation where:

• The previous developer was at the company for 10+ years.
• The boss views that developer's tenure as the baseline ("everything used to just work").
• The boss views you as junior or replaceable, even though you're now doing everything that developer did plus modernizing the system.
• You need the report to be respectful but quietly recalibrate the comparison.

Output format

A Word document (.docx), 4 pages, designed to be read in one sitting. Sections:

1. Title block (1 page top)
2. Executive summary (3 short paragraphs)
3. Before vs. after table (8 capabilities, red→green)
4. Why this work was necessary (with the van analogy)
5. Effort and industry context (the team-equivalent table — most important)
6. What made this particularly difficult (4 specific constraints)
7. Recognition (predecessor acknowledgement)
8. Closing (the "invisible from outside, crucial from inside" line)

If a bilingual version is needed, produce a second document with the same content in the target language, properly RTL/LTR formatted.

The proven framings

Use these specifically. They have been tested in front of skeptical non-technical readers.

The opening sentence

"This [period] I built the engineering safety system that the [Platform Name] platform has not had in its [N] years of operation."

This sentence does several things in 25 words:

• Frames the work as building (not just maintenance).
• Frames the absence of the work as the gap, not your invention.
• Quantifies the system's age (anchoring the reader to "this is old, of course it needs this").
• Establishes "I" — you did this.

The "I am the sole engineer" paragraph (critical)

"I am the sole engineer on the team. There is no DevOps team, no QA team, and no second developer to back me up. Everything described in this report was built in one focused engagement, by one person, on free tools."

Three specific words to emphasise (bold them in the doc): sole engineer on the team, alone, free tools. These are the levers that recalibrate the boss's intuition.

The van analogy (use as-is or adapt)

"Imagine a delivery van used daily for 17 years that has never visited a mechanic. The van still runs. Deliveries still happen. But there are no service records, no warning lights, no roadside assistance, and no way to know what's been replaced. The van still works — but every day it works is, statistically, increasing the chance of the day when it doesn't. This work was the equivalent of installing a service record, a check-engine light, a dashcam, and a roadside assistance plan. None of this changes how the van drives. All of it changes how recoverable the next failure will be."

Why this works for non-technical readers:

• Concrete physical object instead of abstract software.
• Time anchoring (17 years).
• Acknowledges "the van still runs" — neutralizes the "but it works fine" objection.
• Statistical framing introduces risk in a way that feels intuitive.
• Closes with the precise insight: this changes recoverability, not behaviour.

The industry-context table (the most important section)

Two columns: "Activity completed in this engagement (alone)" vs "Typical staffing at peer organizations." Each row pairs an activity with the role(s) that would normally do it elsewhere.

This is the section that does the heavy lifting on resetting expectations. The visual contrast between "1 person did this" and "DevOps engineer + QA engineer + SRE + Security engineer + Technical writer" is impossible to miss.

| Activity completed in this engagement (alone)        | Typical staffing at peer organizations |
|------------------------------------------------------|----------------------------------------|
| Set up version-controlled mirror of production       | Backend engineer + DevOps engineer     |
| Build automated deployment pipeline                  | DevOps engineer (full-time role)       |
| Build automated testing layer                        | QA engineer                            |
| Build monitoring & alerting                          | Site Reliability Engineer (SRE)        |
| Build automated rollback safety net                  | DevOps engineer                        |
| Audit production server for risks                    | Security engineer / external auditor   |
| Document everything for handover                     | Technical writer + engineering lead    |

Closing sentence after the table:

"This is not a complaint. It is context. As the only engineer on the team, every one of the roles in the right-hand column was performed by the same person."

The "this is not a complaint" preempts the boss's defensive read.

The "what made this particularly difficult" bullets

Pick 4 specific constraints that your boss can grasp with one sentence each, even without technical knowledge. Examples:

PHP 5.6, out of support since 2019. Modern tooling assumes a more recent runtime, so the deployment script had to be written using language features available in 2014.

No direct shell access to the server, and the server further restricts which commands the language itself can run. Standard deployment tools require shell access; I had to build around its absence.

A misconfiguration on the host's side prevented the hosting control panel's own deployment feature from working at all. I discovered this only after attempting the conventional approach. I then built around it.

384 GB of files on the server, of which only 211 MB was actually source code. The pipeline had to surgically separate code from student content (videos, audio, uploaded documents) every time.

The pattern: bold the constraint, then explain in non-technical terms why it required engineering judgment.

The recognition section (use when there's a predecessor)

If the predecessor is deceased, the phrasing must be respectful and culturally appropriate:

"It would be inaccurate to write a report about this work without acknowledging the developer who maintained the platform for over two decades. The system has served its purpose for [N] years. That is not a small thing — it is, frankly, longer than most production software ever lasts. Whatever modernization happens from here builds on the foundation he laid."

"The work described in this report is not a correction of his work. It is the next layer — the layer that protects what he built so it can keep serving [users] under modern operating conditions, and so the institution is no longer dependent on the institutional knowledge of any single individual."

For Arabic / Islamic context, end with "رحمه الله" (May God have mercy on him) — appropriate for a deceased Muslim colleague.

For other religious / cultural contexts, adapt the closing phrase or omit.

The framing does three things at once:

• Honours the predecessor.
• Quietly establishes you are not in conflict with their legacy.
• Plants the idea that the institution should not depend on any single individual — including you.

The closing line

"This engagement modernized the engineering practices around the [Platform] platform without disrupting its operation for a single [user]. The platform was never down. No data was lost. No user noticed any change. What changed is invisible from the outside and crucial from the inside."

The bolded sentence is the takeaway. It survives memory better than any list.

Building the Word document

Use docx-js (npm docx package). Critical implementation details:

const { Document, Packer, Paragraph, TextRun, Table, TableRow, TableCell,
        Header, Footer, AlignmentType, HeadingLevel, BorderStyle, WidthType,
        ShadingType, PageNumber, PageBreak, LevelFormat } = require('docx');

// US Letter — docx-js defaults to A4, set explicitly
const pageSize = { width: 12240, height: 15840 };

// For Arabic/RTL paragraph, set on every Paragraph and TextRun:
new Paragraph({
  bidirectional: true,                    // mark paragraph as bidirectional
  alignment: AlignmentType.RIGHT,         // RTL alignment
  children: [new TextRun({
    text: "النص العربي",
    rightToLeft: true,                    // mark run as RTL
    font: "Calibri", size: 22,
  })],
});

// Table cells with shading: use ShadingType.CLEAR (not SOLID — SOLID is black on some readers)
new TableCell({
  shading: { fill: "1F3864", type: ShadingType.CLEAR },
  ...
});

// Table widths: ALWAYS use WidthType.DXA, not PERCENTAGE
// PERCENTAGE breaks in Google Docs renders.
new Table({
  width: { size: 9360, type: WidthType.DXA },        // 9360 = US Letter content width
  columnWidths: [3120, 3120, 3120],                  // must sum to width
  ...
});

// Bullets: NEVER use unicode "•" in text. Use numbering config:
numbering: {
  config: [{
    reference: "bullets",
    levels: [{
      level: 0, format: LevelFormat.BULLET, text: "•",
      alignment: AlignmentType.LEFT,
      style: { paragraph: { indent: { left: 720, hanging: 360 } } },
    }],
  }],
}
// Then: new Paragraph({ numbering: { reference: "bullets", level: 0 }, children: [...] })

Build a single JS file that takes a config object and emits both .docx files (English + bilingual). See examples/build-status-report.js for a complete working example.

Skill questions

When invoked, ask the user:

1. Platform name (e.g., "Mishkah", "Acme Registration System")
2. System age in years (when did it first go to prod?)
3. Domain (for the byline)
4. Engineer name (for sign-off)
5. Date of report
6. Predecessor present? (yes / no / deceased / retired)
7. Predecessor tenure (years)
8. Cultural / religious context for predecessor recognition (default: secular; "Islamic" adds رحمه الله closing)
9. Bilingual? (default English-only; if yes, target language — current support: English + Arabic)
10. Specific accomplishments (will be mapped onto the standard 8-row before/after table)
11. Specific constraints (will be turned into the 4-bullet "what made this difficult" section)

Generate both documents. Keep the source code (build-status-report.js) so the user can re-run and edit later.

Tone calibration

The default tone of this skill is:

• Professional, factual, never boastful.
• Confident but not defensive. Don't say "I had to do this because no one else would" — say "I am the sole engineer on the team, so this work was my responsibility."
• Concrete numbers wherever possible. "11,751 files placed under version control" beats "we improved version control."
• Quiet expectation-setting, not lectures. The team-equivalent table is more persuasive than any explanatory paragraph.
• Respectful of legacy without being apologetic about modernization. "It is not a correction of his work. It is the next layer."

Avoid:

• Sarcasm, anything that could read as score-settling.
• Detailed technical explanations the boss won't follow.
• The phrase "best practices" (signals jargon).
• Heroic narrative ("I worked tirelessly..."). Let the work speak.
• Anything that sounds like a complaint.

Why this skill exists

Most engineers, when asked to write a status report for a non-technical boss, default to either:

• Technical detail dump — boss skims, doesn't read, doesn't update their model of you.
• Achievement list — reads as bragging, triggers defensive responses.
• Modesty — under-sells the work, reinforces existing low estimate.

This skill encodes the framings that have actually worked in the real situation it was developed for: a solo engineer modernizing a 17-year-old system, reporting to a leader who compared them unfavourably to a long-tenured deceased predecessor, with a cultural expectation that one developer should "just handle it." The report did not directly contest the comparison; it provided enough context that the comparison naturally recalibrated.

The framings here are not magic. The boss may still under-value the work. But they will be working with better information.