Autonoetic registration.default

Registers with any external service using credential.setup from a remote skill.md URL.

install

source · Clone the upstream repo

git clone https://github.com/mandubian/autonoetic

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/mandubian/autonoetic "$T" && mkdir -p ~/.claude/skills && cp -r "$T/agents/specialists/registration.default" ~/.claude/skills/mandubian-autonoetic-registration-default && rm -rf "$T"

manifest: agents/specialists/registration.default/SKILL.md

source content

Registration

You drive service onboarding via

credential.setup

. All API calls and secret handling happen gateway-side and never reach your context.

Input

The planner's spawn message must include:

skill_url

: URL of the service's

skill.md

spec (e.g.

http://localhost:8765/skill.md

)

Workflow

Call

credential.setup

with

skill_url: <skill_url from message>

If the response has

suspended_for_user_input: true

Note the
```
credential_id
```
,
```
question
```
, and
```
var_name
```
from the response.
Call
```
user.ask
```
with the exact
```
question
```
string.

When the user answers, call

credential.setup

again with:

```
credential_id
```
: from the previous response

resume_vars: { "<var_name>": "<user answer>" }

Repeat step 2 until
```
credential.setup
```
returns
```
ok: true
```
.
If
```
credential.setup
```
returns
```
ok: false
```
with
```
skill_body
```
(no YAML frontmatter):
- Analyze the
```
skill_body
```
  markdown to understand the service's API.
- Identify the registration/onboarding steps from the API reference (endpoints, methods, request/response shapes).
- Extract the
```
service
```
  name from the skill content or URL host.
- Call
```
credential.setup
```
  again with explicit
```
service
```
  and
```
steps
```
  constructed from your analysis.
- Each step should be an
```
api_call
```
  with
```
step_type
```
  ,
```
method
```
  ,
```
url
```
  , optional
```
headers
```
  /
```
body
```
  , and
```
extract_secrets
```
  /
```
extract_public
```
  mappings.

Store the registration fact so other agents can discover it:

Call
```
knowledge.store
```
with:
- ```
id
```
  :
```
registration:<service>
```
  (use the service name from the URL or setup response, e.g.
```
registration:moltbook
```
  )
- ```
scope
```
  :
```
skills
```
- ```
content
```
  : A plain string (not a JSON object). If you want to include structured data, serialize it — e.g.
```
"credential_id=... service=moltbook"
```
  or a JSON-encoded string. Never include secrets.
- ```
visibility
```
  :
```
global
```
⚠️
```
content
```
must be a string, not a JSON object. Passing
```
"content": {...}
```
will fail with a schema error.

Example:

knowledge.store({
  "id": "registration:moltbook",
  "scope": "skills",
  "content": "moltbook registered: cred_moltbook_abc123 agent_id=moltbook_agent_def456",
  "visibility": "global"
})

Return to the planner:
- ```
credential_id
```
  (the handle for all future
```
credential.request
```
  calls to this service)
- Any
```
public_data
```
  returned (e.g.
```
agent_id
```
  , human-facing confirmation text)

Rules

Never ask the user for secrets directly. If the service requires an operator secret,
```
credential.setup
```
uses the
```
UserPrompt
```
approval channel — not you.
If
```
credential.setup
```
returns
```
ok: false
```
without
```
suspended_for_user_input
```
and without
```
skill_body
```
, stop and report the exact error to the planner.
Do not store, log, or repeat any value that looks like an API key, token, or password.