Custom Skills And Plugins

Custom skills and plugins are capabilities that you or your agents create, or that you choose to import from another supported app. Neotask keeps them separate from built-in and managed catalog content so ownership, review, setup, and storage remain clear.

This page describes the durable custom-artifact flow. If that service is not enabled for your workspace, or a save cannot be finalized, Neotask reports a pending or failed state instead of claiming that the item is safely stored.

What Counts As Custom

Where An Item Appears

The destination you choose is part of the saved target record and, for a canonical item, its assignment:

Destination Skill location Plugin location
Main personal workspace Your My Skills Add-ons, as metadata with runtime isolation
Selected standalone agent That agent's My Skills Add-ons metadata; no executable assignment
Company That company's Skills workspace Add-ons metadata; no executable assignment

Personal, agent, and company assignments are not inferred from a local folder. If the target cannot be verified, Neotask does not publish the item to another scope.

Customer plugin code does not execute in the current desktop Gateway process. Its source, provenance, review state, and declared setup requirements remain visible in Add-ons, but its card shows Runtime isolation required and does not offer Add, credential-save, or binary-install actions. A future executable customer plugin runtime must be isolated, killable, and scoped to the exact assignment and target. Managed built-in, catalog, and company-released plugins keep their established trusted release and runtime paths.

For customer plugins, metadata-only describes the card and runtime registration. It does not mean that retained source bytes are discarded: an eligible source package can remain in private cloud backup and in the inert local quarantine described below, without becoming installed or executable.

What A Card Shows

My Skills and Add-ons receive display metadata only, such as the name, summary, source, target, version, lifecycle state, dependency names, and setup status. Cards do not receive or render:

This keeps the readable catalog view separate from the files that are inspected, stored, and materialized for runtime use.

Save, Review, And Install Lifecycle

  1. Neotask builds a bounded package for the exact destination and computes its checksum.
  2. A successful durable save uploads the bytes through a short-lived, exact-object upload authorization into private encrypted storage. The app never receives general AWS credentials.
  3. The package is checked for integrity, unsafe archive paths, secrets, compatibility, dependency declarations, and the expected skill or plugin family.
  4. A compatible custom skill can enter review and setup. Customer plugin packages can enter review, but executable packages remain metadata-only with Runtime isolation required. A foreign or source-only plugin remains inert as Conversion required until a separately inspected Neotask plugin package exists.
  5. For a compatible custom skill, the local copy is materialized only for an authorized assignment and exact version. Neotask verifies the signed manifest and bytes, then restores the complete skill file tree before use. Gateway normally runs the skill from that verified local tree; it does not stream code from cloud storage at execution time. Customer plugin code is not materialized for execution while runtime isolation is required.

Common card states include Draft, Conversion required, Review pending, Available, Needs setup, Needs authentication, Installed on this device, Failed, Revoked, and Archived. The displayed state is meant to describe the actual lifecycle, not just the presence of a file on one computer. Installed on this device does not apply to executable customer plugin code while runtime isolation is required.

Dependencies And Credentials

A custom item can declare requirements without embedding their values in the package.

A custom skill stays in Needs setup or Needs authentication until every required dependency is satisfied. A customer plugin stays inactive with Runtime isolation required, even when all declared dependencies are present. Metadata alone never marks an item installed or executable.

Storage And Sync

For a successful durable save, MongoDB and Construct store the target and, for canonical versions, the assignment, along with lifecycle, approval, provenance, dependency metadata, and audit state. Private S3-backed object storage holds user-created, imported, and Create Skill package or source bytes under opaque tenant and target namespaces. It is the durable byte authority and cloud backup for those customer artifacts. Built-in bytes remain part of the Neotask release/build or managed catalog and are not moved into customer storage. Managed GitHub/catalog paths are unchanged.

For new customer-created or imported bytes, Neotask does not treat an old metadata-only registration as a completed durable save. This does not convert or bulk-upload existing installed metadata: built-in, managed catalog/GitHub, scoped, and activity-synced installation records keep their existing metadata and release paths.

For an active custom skill assignment, Neotask downloads only the exact signed version, verifies its manifest, digest, files, and modes, and materializes its complete local working tree, including SKILL.md, references, templates, scripts, and assets, with safe executable modes preserved. That local tree is the normal Gateway execution source. Create, approval, and support-file updates do not report success until the exact tree is verified locally, and they never substitute an unverified direct local write when cloud materialization fails. The durable version lets another authorized clean device restore the same tree, while local presence alone never creates ownership or assignment authority. Customer plugin source may be retained durably for review, but its code/bundle remains metadata-only and inert until an isolated runtime exists.

On another authorized device, retained customer plugin source can also be restored as the exact verified package archive and a receipt in a private local quarantine backup. That backup sits outside every plugin-discovery folder. It is not extracted into a plugin tree, registered, sent to the page, or executed; it exists for recovery and a later explicit review/conversion flow only.

After a successful durable save, another authorized desktop can discover the saved item. For a reviewed item with an active assignment, it can request the exact approved version. If cloud reconciliation is unavailable, Neotask keeps an honest retry or unavailable state and does not erase the last verified local copy or clear its in-memory exact credentials merely because authentication expired or a remote response is empty or transient. Only a definitive response that the exact assignment is forbidden, absent, or gone can deauthorize the local lifecycle state.

Imports And Provenance

An imported custom item keeps its supported source provenance, original timestamps, destination association, and content identity. Neotask records the import and later artifact lifecycle in its own ledger. It does not copy the source provider's private telemetry, hidden reasoning, or internal administrative audit logs.

The source app is read locally during import. It is not contacted merely to copy local files. Any later connection to an external service is governed by that connection's own authorization and setup flow.

The supported migration flow for Claude, Hermes, and Codex personal or default-agent custom skills publishes them through the same durable customer-artifact path and then materializes the verified local tree. An item is not reported as migrated while authorization, review, setup, authentication, or integrity checks are unresolved. Claude project skills and commands remain explicitly local-only: they keep their safe project-local copy behavior and are not represented as cloud-backed artifacts. Managed Codex plugins, catalog items, GitHub content, and built-ins remain on their established paths.

When an import finds only a remote marketplace plugin reference, Neotask saves sanitized reference metadata as an inert Add-ons draft so it remains visible on another authorized device. It does not clone, download, install, or execute the referenced plugin. Conversion still requires a separately inspected Neotask plugin package.

See Import From Other AI Apps for supported sources, selection, audit-trail details, and trust boundaries.

Create Skill And Coding Mode

Create Skill uses the same custom-artifact rules and saves to the active personal, standalone-agent, or company target. Coding mode can prepare a custom plugin source draft for review. Saving that draft does not create a GitHub repository and does not make the code executable; it enters the same private inspection and conversion lifecycle described above.

Removing Or Revoking An Item

Use Disable on an exact custom-artifact card to remove its activation authority from this workspace. The durable assignment is changed first, then desktop reconciliation removes or quarantines its local runtime copy. The card, source, and immutable version remain available so Enable or Reinstall can restore the same authorized version on this or another device. Disabling also retires credentials bound to that exact assignment atomically with the desired-state change; it never removes another assignment's credentials. An earlier in-flight credential request cannot restore those values after the assignment has been disabled, revoked, or erased. Enable restores assignment availability, but it does not resurrect retired credential values. Neotask reports the local change as complete only after a complete current reconciliation succeeds; if that pass is unavailable or incomplete, the card stays pending instead of claiming that the device already converged.

Deleting an owning target is a separate erasure lifecycle. Tenant deletion, company deletion (including company-owned agent and coding-project targets), standalone-agent deletion, tenant-member offboarding, and coding-project deletion fence new artifact work before removing matching metadata and every stored object version in the target's opaque namespace. A remote deletion failure retains opaque retry debt instead of reporting erasure complete. Shared immutable versions remain while another active assignment still references them. Even a target deleted before its first upload keeps an erased storage marker, so a late retry cannot silently recreate authority for that deleted target id.

Physical deletion of one individual artifact, including source/version reference-count cleanup in object storage, is not currently a card action. Disable is therefore reversible and must not be described as permanent artifact deletion. The separate Clear credentials action removes values for an exact authorized assignment; it does not delete the artifact record. An absent card or failed network read is never treated as an implicit deletion.