anonymisation — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited anonymisation (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.
Consulting and PMO content is credible because it draws on real experience. That experience is governed by NDAs and trust relationships. Breaking either costs you future clients, legal standing, and referrals. This skill is the binding rule for extracting lessons from real experience without exposing the parties.
If you cannot satisfy this rule, drop the example and use an industry baseline.
This skill is organisation-neutral. The values specific to your organisation — who your core audience is, who owns confidentiality sign-off, which agreements bind you — live in a local overlay (CALIBRATION.local.md) kept out of version control, not in this file. Create your own from the template in this directory's README. The four-layer structure and decision procedure below are universal.>
The examples below are illustrative and fictional. They demonstrate the failure modes, not real engagements, and they name no real party. Keep it that way: when editing this skill, never replace a fictional example with a real case, even as a "bad" one. A document about anonymisation must itself be anonymised.
Each layer must be checked independently before publishing.
Rule: No reader should be able to deduce the client, vendor, sector + scale combination, or project from the content — alone or combined with other public information.
Failure modes:
Rule: Prefer industry baselines. If real project data must be used, normalise it.
Rule: The story around the numbers leaks too. Scrub the use case as carefully as the data.
Rule: No pejorative framing of anonymised actors.
Calling an unnamed SIer "old-fashioned" reads as a complaint about an identifiable party even when no name is given. It also damages the audience relationship — the actors you anonymise are often part of your own audience (see your calibration overlay). Frame systemic issues as patterns ("traditional fragmented-reporting workflows remain common in mid-market SIers"), not as critiques of unnamed individuals.
For every paragraph drawing on real experience, in order:
All fictional — illustrating the failure mode, naming no real party.
Bad 1 — Sector triangulation + vendor inference.
"At the largest e-commerce company in [country], we introduced a data-analytics AI for marketing analysis. As consultant and programme PMO on a global-consulting-firm engagement, we simulated 3–5 year sales forecasts from historical sales data."
Why bad: "the largest e-commerce company in [country]" resolves to a single named firm. "Global consulting firm" on that account narrows to two or three names. Both parties become identifiable, alone or combined with public information — NDA exposure, legal risk, loss of trust. The leak is the collocation, not any single phrase, and it happens in any language: the same sentence in translated marketing copy triangulates exactly the same way.
Bad 2 — Project-shape signature.
"We help a consumer-finance company automate its call-centre operations using AI operators. The programme runs about 30 people across an AI vendor, a systems integrator, and freelancers."
Why bad: sector + size + team composition together form a signature that narrows to a small set of known engagements. Sharing any follow-on challenge would expose more. Loss of trust.
Bad 3 — Pejorative framing of an unnamed party.
"A systems integrator ran the multi-vendor, multi-stakeholder setup with an outdated mindset from almost 20 years ago. They forced every stakeholder to write fragmented task reports and to sit through endless meetings."
Why bad: the underlying problem (fragmented reporting and meeting overload) is legitimate and the SIer audience would benefit from it being surfaced. But the framing reads as a complaint about a specific identifiable party, and the tone alienates the very readers the content is trying to reach. Contrast Good 2, which frames the same issue as a pattern.
Good 1 — Industry baseline + normalised learning.
"The industry baseline for infrastructure migration success sits at around 30%. In our experience that ratio rises to roughly 80% when the project treats data migration as a deliberate, calibrated risk during planning rather than an execution-phase problem."
Why good: public baseline anchors the claim. The learning is expressed as a ratio improvement, not absolute numbers. No client, no project, no time anchor. The point about calibrated PERT and planning lands clearly.
Good 2 — Pattern across engagements.
"PMO work is not only about the current project or programme — it is also about organisational change management running alongside. Busy managers consistently lack the time to observe and contemplate the systemic problems shaping their delivery environment. The PMO can help by surfacing systemic feedback loops from observational data and offering scenario planning backed by Monte Carlo simulation."
Why good: real insight from real engagements, framed as a pattern across engagements rather than a single case. No identifying data, no actor critique, no time anchor.
The skill triggers on any content moving toward a public surface:
The skill does not gate internal-only artefacts (operational trackers, sprint retros, internal docs). But internal material frequently gets extracted into public content later; applying the discipline at write time saves rework.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.