Using Skilify to build skills locally, submit for review, and provision them

This article describes the author → review → admin provisioning loop for package skills when your organization uses Endpoint AI (including device-backed Skilify submission). It complements Company settings skills management and MCP connectors (see How to create an MCP connector).

1. Build a skill locally with Skilify

Harriet provides a built-in Skilify skill that teaches the assistant to package repeatable playbooks as an Anthropic-compatible skill folder: a SKILL.md file at the root (with YAML front matter: name, description) plus optional files such as references/….

Practices

• Treat the package as instructions, not secrets: do not embed API keys or private customer data.
• Test the skill end-to-end on a clean session using only what is in the folder before submitting—reviewers see incomplete packages as wasted time.

On a provisioned endpoint, Skilify can submit through device credentials stored in your Harriet config file (typically ~/.harriet/config.json), which includes device_id, api_key, and server (your Harriet base URL). The assistant may expose list_skill_packages and submit_skill_package as tools, or you can use the same flows documented for your deployment.

2. Submit into the review queue (not instant publish)

Before submitting, obtain explicit agreement from the person responsible: the package will be visible to reviewers and stored for moderation and possible publication to teammates.

Duplicate check: use list_skill_packages (or the equivalent list operation your client exposes) to search for similar names or descriptions. Harriet may reject a submission if the skill name already exists for your organization.

Submit: use submit_skill_package pointed at a directory on disk whose root contains SKILL.md. Provide a clear name, description, and optional review notes for moderators. You can reference MCP connector identifiers your organization has already created if the skill should depend on specific integrations.

Submitted packages enter the review queue. They are not auto-published—even for account owners—until an approver acts.

If automated submission is unavailable: an admin can create a package skill in the Endpoint AI console (Harriet skills authoring) and paste the same files manually, then use Submit for review there. Use exact copy-paste per file as your internal runbook requires.

3. Review and approve

Approvers with the right permissions open the Endpoint AI console and the review queue (for example the console route that lists pending skills and connectors). They can approve, reject, or request changes. Another reviewer may need to approve if policy forbids self-approval of your own submission.

When a package skill is approved, it becomes eligible for assignment like any other managed skill.

4. Provision to teams or users (admins)

After approval, administrators distribute the skill:

• Assign the skill to management groups, user groups, or individuals according to your governance model.
• Set defaults for private chat, public channels, or the website widget where your product supports it—only where policy allows.
• Use Quick assign from Harriet skills so the Assign “…” dialog can target Team or User, This Harriet skill, or a Profile—see How do I share Harriet skills with my team? for step-by-step UI behavior.

Users only receive capabilities that admins have assigned; merely approving a skill does not automatically grant it to every employee unless your defaults and group rules say so.

Guardrails

• Rotate device API keys if a laptop is lost; treat them like other integration secrets.
• Revisit assignments when people change roles or teams.
• For MCP-backed package skills, ensure the underlying connector is reviewed and tool permissions are constrained (see How MCP tools work inside workflow agents and MCP authorization and stored credentials).