Getting started
Choose the Clawdbase workflow that matches the decision you need to make.
Most Clawdbase work begins in one of three places: the public registry, authenticated Page registration, or Developer Access.
Evaluate before execution
Use registry search to resolve the exact Agent, Skill or source identity. Open its Page, read Trust and Confidence independently, inspect the evidence timestamp and follow any Creator or lineage links.
Register what you control
Choose Register Page, select X, Telegram or GitHub, then authenticate at the source. Clawdbase reads the authoritative provider identifier from the callback and matches or creates one canonical Page.
Never enter a handle as proof of control. A display handle can change and is not an authority signal.
Integrate programmatically
Open Console > Developer Access, create a scoped Access Key, select an operation in the playground and run a test. Store the key as a server-side secret; it is shown only once. See the full activation path if you have not connected an identity yet.
Pre-execution check
A practical workflow for evaluating an artifact.
Trust and Confidence
Interpret both scores without collapsing them.
Developer quickstart
Run the first authenticated operation.
Five-minute orientation
Search the registry
Start on the Clawdbase home experience and search for an owner, repository, handle or display name. Narrow the result set by Page type and source when names overlap.
Open the canonical Page
Confirm the Page type and source before comparing Trust and Confidence. A similarly named X account and Creator are separate subjects with separate scores.
Inspect freshness
Read the last-scored timestamp and score state. A stale score can still be displayed, but your policy should decide whether it is fresh enough for the proposed action.
Choose a next action
Continue, sandbox, request review, refresh evidence or stop. Clawdbase returns evidence; the consuming workflow owns the decision.
What you can evaluate
| Page | Typical question | Supporting context |
|---|---|---|
| Agent | Should this autonomous artifact receive tools or credentials? | Creator, repository, lineage and requested permissions |
| Skill | Should this capability be installed or enabled? | Package or repository origin and Creator |
| Creator | Who stands behind the artifact? | GitHub authority and associated artifacts |
| X account | Is this communication identity consistent with the claimed origin? | X-native verification and account evidence |
| Telegram account | Is this account, channel or bot the intended communication identity? | Telegram-native verification and identity type |
Common first-use mistakes
- Treating Confidence as a second Trust score. It measures evidence strength and coverage.
- Assuming a verified badge means the associated code is safe. Verification proves control of the source identity.
- Comparing scores from different Page types as though they describe the same subject.
- Copying an Access Key into browser code. Access Keys belong in a server-side secret store.
- Refreshing repeatedly without an evidence-freshness policy.
For a repeatable evaluation procedure, continue to Pre-execution check.