| name | generic-by-design |
| version | 1.0.0 |
| description | Scrub a skill, template, README, or code repo for organization-specific fingerprints —
internal cloud regions, branded SaaS products asserted as the user's stack, proprietary
cloud-service abbreviations, hardcoded vendor URLs, source-skill author attributions,
concept-author attributions, org / company names, internal filesystem paths,
stack-specific assertions ('our setup uses X'), and hardcoded scale fingerprints — and
replace each with a generic placeholder, role name, or multi-option illustrative list.
Use whenever the user says 'generic-by-design okay', 'scrub the proprietary refs', 'mask
the org leaks', 'make this generic', 'check for fingerprints', 'anonymize this
template', or any phrasing about turning org-specific content into reusable artifacts.
Ships a configurable fingerprint scanner (wordlists in scripts/data/), a pattern
catalog, a decision matrix, placeholder conventions, and synthetic worked examples.
|
| license | MIT |
| compatibility | claude-code opencode |
| allowed-tools | ["Read","Write","Edit","Grep","Glob","Bash"] |
| metadata | {"author":"MKAbuMattar"} |
Generic by Design
Scan an artifact for organization-specific fingerprints, decide which are leaks vs. legitimate references, then mask the leaks with generic placeholders or multi-option illustrative lists. The goal: anyone can install / fork / read the artifact without learning the original author's stack, history, or environment.
When to use
- The user says "generic-by-design okay" — the canonical trigger.
- The user pasted content (skill, template, README, blog post, code) lifted from a private repo and wants it sharable.
- The user is publishing a skill or library and asks to "make sure no internal stuff leaks".
- A scaffolded template has hardcoded values from the original cloud / vendor / org.
- A new skill was built by adapting an existing one and the source author's name appears in the credits.
Skip this skill for: code that genuinely needs the proprietary references (internal-only docs, runbooks for a specific environment), or for tool-name lists that are inclusive-by-design (a multi-provider list is intentional, not a leak).
How this skill is itself generic-by-design
The skill content (SKILL.md, references/, examples/) describes patterns abstractly — using placeholder shapes (<vendor-saas>, <cloud-region>, <source-author>) and synthetic worked-example names (Acme, FrontEdge, Cumulus, PayLink) — never concrete real vendor or author names that would anchor on the author's history.
The scanner's wordlists of concrete patterns live in scripts/data/*.txt — tool data, separated from skill content, the way a spell checker has a dictionary file. Users edit those wordlists to add their own org-specific patterns; the markdown content stays abstract.
If you run the scanner against this skill itself, it reports ~27 hits in markdown — all are teaching content: the literal phrases the catalog describes (e.g., "we use X" quoted as an example of a stack-assertion shape), synthetic placeholder examples (ab-north-4, Bastion, Acme), RFC-reserved IP ranges in placeholder docs, and the regex patterns in the scanner script. The triage rule: keep every hit whose surrounding context is "here is an example of what to look for" rather than "this is what we use". A grep for any real cloud / vendor / author / region name across the skill markdown returns zero hits.
Fingerprint categories
The patterns the scanner catches and the agent reasons about. See references/pattern-catalog.md for shapes and canonical replacements.
