---
name: seekai
description: >
  Submits a deployed product to the Seek AI AI-tool directory on its owner's
  behalf: registers the site, gets explicit human approval, authors the
  listing content (English required, more locales optional), and optionally
  installs the dofollow backlink badge. Use when the user asks to list,
  submit, launch, or get a backlink for their deployed product, tool, or
  site. Not for products without a public HTTPS URL, not for managing
  listings the user does not own, and never for entering the user's
  Seek AI password.
---

# Seek AI product submission

Completing this skill lists the user's deployed product on Seek AI — a
curated bilingual directory of AI-built products — giving it a profile page
and, after badge verification, a dofollow backlink to their site.

## Terms

- **Claim** — one authorization request, identified by `claim_id`.
- **Authorization URL** — the page (`/authorize/:claim_id`) where the human approves.
- **User code** — short verification code shown beside the authorization URL.
- **Project token** — the `sk_proj_…` Bearer credential a claim yields; controls exactly one project.
- **Listing** — the product's directory entry at `/item/:slug`.
- **Content payload** — the editorial content object built in step 4 (English required; optional locales).
- **Badge** — the official Seek AI snippet installed in the product's footer.

## Non-negotiables

1. The product must be deployed at a public HTTPS URL the user controls — no localhost, no private previews.
2. Never request, collect, store, or transmit the human's Seek AI password; sign-in happens only on seekai.dev pages.
3. Send the project token only to `https://seekai.dev/api/agent/*` or `https://seekai.dev/api/mcp` — it controls the whole project.
4. Store the token outside the repository, source files, logs, screenshots, and chat output.
5. One token, one project; never reuse it for another domain.
6. Work only within the granted scopes; on `insufficient_scope`, stop that action and tell the user which permission is missing.

## Procedure — the only path

### 1. Register the project

Confirm the public deployment with the user, then register:

```http
POST https://seekai.dev/api/agent/register
Content-Type: application/json

{
  "agent_name": "<your agent name>",
  "name": "<product name, 2-80 chars>",
  "website": "https://<the-deployed-product>",
  "description": "<10-200 chars, what the product does>",
  "category": "<one category slug from GET https://seekai.dev/api/directory/taxonomy?view=flat&locale=en>",
  "pricing": "free | freemium | paid | contact",
  "notes": "<optional note for the reviewer>"
}
```

Fetch the taxonomy endpoint first; its `categories[].slug` values are the only
valid `category`. `pricing` may be omitted. The response returns
`authorization_url`, `user_code`, `device_code`, `interval`, and `guide_url`.

### 2. Hand off to the human

Show the human the exact `authorization_url` and `user_code`. Ask them to open
the URL, sign in or register on Seek AI, review the requested permissions,
and choose **Approve and continue**. Do not open an automated browser session
and never enter credentials on their behalf.

Tell them before they approve: step 4 needs the **`project.update`**
permission, which is unchecked by default on the approval page — they must
tick it. Approval with `project.submit` immediately creates the pending
listing; no separate submit call is needed.

### 3. Poll for the token

Poll no faster than the returned `interval` (default 5s):

```http
POST https://seekai.dev/api/agent/token
Content-Type: application/json

{ "device_code": "<device_code>" }
```

- `authorization_pending` — wait the interval, poll again (the human has 15 minutes to decide; after approval the token is claimable for 24 hours).
- `slow_down` — increase the interval by at least 5 seconds.
- `access_denied` — stop; do not register again unless the human asks to restart.
- `expired_token` — stop; tell the user a fresh registration is needed. Dead
  claims release on their own; if a listing already exists, its owner can
  re-issue the token instead (My tools → Agent authorization → Rotate).

On success, store `data.access_token` securely and note the scopes in
`data.scope`. Rotation and revocation: see the guide, § Token lifecycle.

### 4. Author the listing content

Fetch **`GET https://seekai.dev/api/agent/guide`** first. It is the
complete content spec — full JSON schema, SEO format, live controlled
vocabularies, and a clone-and-fill example payload that validates. Never
write the content payload from memory or from another directory's format.

Research the product at its official site, then author the full content
payload exactly per the guide: English is required, a complete `zh` (Chinese)
locale is optional — send it only if you can author it as a natural rendering;
omit the key otherwise. Only claims the official site verifiably supports,
unknown → omit, never invent pricing, dates, or company facts. You never
score — scorecards, GEO, and AI-readiness are computed by the platform
automatically after your content clears the enrich pipeline, never in the
submit response.

### 5. Submit and verify

```http
POST https://seekai.dev/api/agent/project/content
Authorization: Bearer <token>
Content-Type: application/json

<content payload per the guide>
```

If the response is `invalid_payload`, re-fetch
`GET /api/agent/project/content/contract`, fix the fields the message names,
and retry once. A `project_not_found` means no listing exists yet — approval
creates it only with the `project.submit` scope; if it was withheld, call
`POST /api/agent/project/submit` first (or ask the owner to grant the scope).
Then read `GET /api/agent/project/status` and report to the
user: review status (pending / published / rejected / needs changes), link
policy, and badge status if attempted. On `rejected`, the same response
carries `reviewer_note` — the editor's feedback; fix what it names and
resubmit (reruns replace in place). Reruns of this step replace the
content in place.

MCP note: every endpoint above has an equivalent tool at
`POST /api/mcp` (same Bearer token); the tool catalog is in the guide,
§ MCP tool catalog.

## Badge installation (optional — the owner's explicit choice)

The dofollow backlink is a trade: the official Seek AI badge goes into the
product's footer (a visible link back to its listing), and in exchange the
listing's outbound link switches from `nofollow` to `dofollow` for 30 days
after verification. It edits the owner's code and triggers a deploy — never
assume it, even when permission exists.

Prerequisite: `project.badge.install` in the granted scopes. If the scope is
absent, do not change any project file — the human declined the permission at
approval. Continue the submission and tell the user the free listing remains
`nofollow` (policy details: guide, § Badge & link policy).

When the scope is present, ask before acting:

1. After step 5 completes, ask the user whether to install the badge. State
   the trade in one line: a badge in your footer → your listing's link
   becomes `dofollow` for 30 days (renewable by re-verify); without it the
   free listing stays `nofollow`.
2. Proceed only on an explicit yes. On no, or no clear answer: skip entirely
   and tell the user they can ask you any time — the permission stays valid.

Install procedure (explicit yes received):

1. Call `GET /api/agent/project/badge`; use only the official `html` value returned. Do not recreate or alter the link, image URL, dimensions, or attributes.
2. Tell the user which shared footer or layout component you will edit, and that this badge is a backlink to their Seek AI listing.
3. Inspect the existing shared footer or layout used by public pages; preserve its content, styling, accessibility, and responsive behavior.
4. Search for the returned `duplicate_key` and the exact snippet first; if either is already present, do not add another badge.
5. Add the snippet as a small, additive footer item — never replace the footer, never place it on private screens.
6. Run the project's tests and build checks that cover the changed footer.
7. Deploy through the project's existing user-approved workflow; if deployment is outside your authorization, stop and give the exact steps instead.
8. Only after the public deployment contains the badge, call `POST /api/agent/project/badge/verify`. Verification always checks the registered project URL — never supply another.

## What you never do

- Never enter or handle the human's Seek AI password — sign-in happens only on seekai.dev.
- Never send the token to any origin other than seekai.dev — it controls the whole project.
- Never register localhost, preview, or private URLs — registration requires a public deployment.
- Never write the content payload from memory — the guide's schema and vocabularies are the validation gate.
- Never edit project files for the badge on permission alone — `project.badge.install` is required AND an explicit yes from the user in this session; permission ≠ instruction.
- Never re-register after `access_denied` unless the human asks to restart — the claim record persists.

## Error dispatch

Polling-path codes are handled in step 3. Every other failure arrives as
`{ code: -1, message, data: { error } }` — read `data.error`, not `message`.
The full table (HTTP status, meaning, required action) is in the guide,
§ Error codes. General rule: stop and tell the user which permission or fact
is missing; only `invalid_payload` and `rate_limited` warrant one careful retry.