Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/celigo/ai/managing-usersnpx skills add celigo/ai --skill managing-usersgit clone --depth 1 https://github.com/celigo/aiWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00056 | $0.03064 |
| Opus 5 | $0.00028 | $0.01532 |
| Sonnet 5 | $0.00011 | $0.00613 |
| Haiku 4.5 | $0.00006 | $0.00306 |
Grade A, and why
managing-users scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 230 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Managing Users
A user (internally called an "ashare") represents a person's access grant to a Celigo account, defining what they can see and do. Concerns when managing users:
- Access strategy -- choosing between account-wide access (administrator, manage, monitor) and per-integration access for least-privilege control
- Integration-level permissions -- granting manage or monitor access to specific integrations, optionally combined with account-wide monitor as a baseline
- Security enforcement -- requiring MFA or SSO per user to meet compliance requirements
- Feature flags -- controlling access to APIM features and whether monitor-level users can edit retry data
- Lifecycle -- inviting, disabling, and removing users as team composition changes
Users are an account administration concern, not a flow or integration resource.
Access Strategies
There are four strategies for granting access. Choose based on the principle of least privilege.
Administrator
Full account administration. Can edit all resources, manage users, and change account settings. Cannot transfer ownership or manage owner permissions.
Manage (Account-Wide)
Can edit all integrations and resources. Cannot view or edit account settings, invite users, or manage other users.
Monitor (Account-Wide)
Read-only plus operational access. Can view all integrations, run flows, and troubleshoot errors (retry/resolve). Cannot modify configurations, enable/disable flows, or view connections and API tokens. Optionally grant allowToEditRetryData so monitor users can edit retry payloads.
Integration-Only (Custom)
No account-wide accessLevel. Access is granted per-integration via integrationAccessLevel[], each entry specifying an integration ID and either monitor or manage. The user sees only the integrations they are granted.
A common hybrid pattern: set accessLevel: monitor for baseline read-only access across all integrations, then use integrationAccessLevel to grant manage for specific integrations the user owns.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 230 lines · 56 tokens per session scan A e3edfd8a6b50
managing-users is a skill published in the GitHub repository celigo/ai (3 stars, last pushed 5d ago), licensed MIT. It adds 56 tokens to every session and 3,064 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
prepare-mcp-integration
Prepare MCP/vendor integrations through cited research, a content PR, exact-revision human approval, and one governed Paperclip connector PR per approved connection. Use for new integration research and delivery; not for ad hoc connector coding that bypasses the playbooks.
webhook-subscriptions
Webhook subscriptions: event-driven agent runs.
agent-builder
Use when creating, improving, or troubleshooting Claude Code subagents. Expert guidance on agent design, system prompts, tool access, model selection, and best practices for building specialized AI assistants.
creating-skills
Use when creating new agent skills or improving existing ones - ensures skills are discoverable, scannable, and effective through proper structure, discovery optimization, and real examples.
creating-integration-docs
Use when adding or editing Nango integration documentation - creates and maintains integration pages, setup guides, connect guides, navigation, and provider metadata following established patterns.
running-and-testing-locally
Use when running the Nango application locally for development and browser testing - covers Docker services, dev commands, service URLs, and troubleshooting startup issues.