write-recommendation — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited write-recommendation (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
LinkedIn recommendations are read very differently from posts. They are checked by hiring managers, prospective clients, and prospective partners as evidence. A generic-sounding recommendation actively hurts the recommended person because the reader concludes the recommender did not really know them. This skill exists to write recommendations that prove the user actually worked with the person and noticed something specific about them.
Hiring managers in 2026 are AI-aware. A recommendation that reads as templated lowers trust in the candidate. The strongest signal a recommendation can send is specificity: a specific project, a specific moment, a specific habit the recommender observed. That signal is hard to fake, which is why it carries weight.
But specificity also requires effort. Most people writing a recommendation default to generic ("X was a pleasure to work with, always reliable and a great team player") because writing the specific version requires recalling actual moments. This skill exists to draw out those moments and shape them into a recommendation that is both warm and credible.
Trigger when:
Do NOT trigger when:
"What is one specific moment or pattern from working with [name] that comes to mind? Not their general qualities, but a thing that happened. A decision they made, a meeting they ran, a problem they solved, a habit you noticed."
If the user cannot answer this, the recommendation is going to be generic no matter how it is written. Push gently for one specific thing. If they still cannot, ask whether they want to write the recommendation at all.
If voice-profile.md exists, read it.
LinkedIn recommendations are read more carefully than posts because they are short and the reader is making a decision. A few format facts:
There is a structure that produces strong recommendations. It is not a template; it is a shape.
1. Open with the relationship and context (1-2 sentences). Who they were to the user, when, what they worked on together. This grounds the reader in the basis for the recommendation.
2. Land on one specific quality, with a specific example (2-4 sentences). This is the heart of the recommendation. Not "X is detail-oriented." Instead: "When we hit the production outage in March, X was the person who noticed the deployment timestamp was off by an hour. Three other people had looked at the same dashboard. None of us saw it." That kind of specificity proves the recommender was there.
3. Add a second quality if it earns its place (2-3 sentences). Some recommendations work better with two distinct traits highlighted. Some work better with one trait developed in depth. Decide based on the material.
4. Close with a forward-looking line (1 sentence). Who they would be great for. "Any team building data infrastructure at scale is lucky to have her." Avoid generic closers ("I highly recommend X to anyone").
Output must read as written by a human on the first pass. The constraints below are how you write, not a checklist to apply later. Do not narrate this process to the user. Do not show a "before humanizer / after humanizer" sequence. Just produce clean output.
Hard bans — never appear in output:
- **Speed:** ...). Write as prose.Required patterns:
Final scan before output:
— and –. Any hit means redraft.Full 33-pattern reference: see humanizer/SKILL.md in this plugin.
Recommendation for: [name]
Relationship at time of writing: [user's role / their role]
Length: [N] words
---
[recommendation text]Optionally offer: "Want a second version with a different specific moment, or this length?"
User wants to recommend a former direct report (Priya, a senior engineer) who is now interviewing.
User's specific moment: "When our payments service started dropping requests during the holiday rush, Priya stayed up rewriting the retry logic. The thing was she didn't ask permission. She just shipped a fix at 3am and wrote a postmortem before standup."
Output:
Recommendation for: Priya
Relationship at time of writing: Engineering Manager / Senior Software Engineer
Length: 187 words
---
Priya reported to me for two years on the payments team. We worked on the systems that processed the company's checkout flow, the systems where outages cost us money in real time.
The thing I noticed about Priya is that she trusts her own read. During our 2024 holiday rush, our payments service started dropping requests under load. The on-call alert went off at 11pm. By 3am Priya had rewritten the retry logic and shipped a fix. She had not asked anyone for permission. She wrote a postmortem before standup the next morning. The fix held through the entire holiday week.
I do not always agree with engineers who ship without asking. I always agreed with Priya. She had built the judgment to know what was reversible and what was not, and she was right almost every time. That is rare in someone her age in years.
She is going to be an excellent senior or staff engineer on any team that wants someone who will fix the broken thing without ceremony. Any team building payments or financial infrastructure should be talking to her.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.