signature-rollout
Skill0 starsChanged 32 days agoMITView on GitHub
Decide and apply who gets which Scribe signature (manual recipients, smart-field condition rules, org-unit/group targeting, and future-email auto-assignment), then verify the rollout landed. Use when assigning, retargeting, or auditing signature coverage.
In this repository6 other files it gives its agents.
- marketing-campaignsSkill
- signature-analyticsSkill
- signature-authoringSkill
- signature-troubleshootingSkill
- teammate-dataSkill
- workspace-auditSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 33
Verify: re-run list_signature_recipients, then list_signature_installations to confirm the signature actually installed (see the …
- Very specific: line 40
If someone still has the signature after a removal, look at their sources.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Rolling a signature out to the right people
Assignment in Scribe has four independent sources, and they add up rather than override
each other. list_signature_recipients returns each recipient with a sources array telling
you why they are assigned, plus the current selection rule config. Read it before changing
anything — otherwise you will "fix" a person who is matched by a rule you did not look at.
| Source | Tools | Use it for |
| Manual emails | add_signature_recipients / remove_signature_recipients (signature_id + email_ids) | Exceptions, pilots, one-off people |
| Smart-field conditions | set_signature_recipient_rules (conditions) | "Everyone whose Department is Sales" |
| Org units / groups | add_signature_recipient_entities / remove_signature_recipient_entities (integration_entity_ids) | Directory-driven teams |
| Future emails | set_signature_recipient_rules (assign_to_all_future_emails) | The company default signature |
Procedure
list_signaturesto get the template'sid;list_teammates/list_emailsto resolve people toemail_ids (each email row carries its owningteammate_id; aliases and primary addresses are both listed).- For directory targeting,
list_integration_entitiesgives the org units and groups (uuid,kind,name,teammates_count) you can point a signature at. - Apply the narrowest change that expresses the intent. Prefer conditions or org units over pasting a long list of email ids — those keep working as people join and leave.
set_signature_recipient_rulesreplaces the wholeconditionstree. It is an array of OR-groups, each an array of ANDed conditions. Read the current tree first and send the full intended result;[]clears every condition. Manual and org-unit targeting are untouched.- Confirm with the user before applying — this changes what goes out on real email.
- Verify: re-run
list_signature_recipients, thenlist_signature_installationsto confirm the signature actually installed (see thesignature-troubleshootingskill when rows come backfailed).
Gotchas
- Removing manual recipients does not remove people matched by a condition or an org unit.
If someone still has the signature after a removal, look at their
sources. - A workspace whose team list is managed by a Google/Microsoft directory integration rejects teammate and email create/delete with 409 — the directory is the source of truth. Change it there, not in Scribe.
- Assignment is per email, not per teammate: a teammate with aliases can have different signatures on different addresses.
- Coverage question ("who has no signature?"): list emails, list recipients per signature, and
diff. The
workspace-auditskill does this sweep end to end.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

