mit einem Klick
sigcli
// Guide Claude to use SigCLI correctly — check auth, login, get credentials, configure providers, and onboard new websites. Trigger when using sig commands, editing ~/.sig/config.yaml, or needing authenticated API access.
// Guide Claude to use SigCLI correctly — check auth, login, get credentials, configure providers, and onboard new websites. Trigger when using sig commands, editing ~/.sig/config.yaml, or needing authenticated API access.
Interact with Xiaohongshu (小红书, RED, Little Red Book) — search notes, read note details, view comments, browse user profiles and posts, get home feed. Use this skill whenever the user mentions Xiaohongshu, 小红书, RED, RedNote, Little Red Book, wants to search for lifestyle/beauty/travel content, read XHS discussions, look up XHS users, or browse trending notes. Also trigger when the user pastes a xiaohongshu.com URL (e.g. xiaohongshu.com/explore/noteid) or mentions an XHS note ID.
Provide authenticated cookies for TikTok (www.tiktok.com). Use this skill whenever the user needs TikTok cookies for scraping tools, downloaders, or needs to authenticate with TikTok services. Trigger when the user mentions TikTok, tiktok cookies, or wants to use tools that require TikTok login cookies.
Provide authenticated cookies for Douyin (抖音/TikTok China) — two providers: douyin (www.douyin.com for scraping) and douyin-live (live.douyin.com for livestream). Use this skill whenever the user needs Douyin cookies for scraping tools like DouYin_Spider, or needs to authenticate with Douyin services. Trigger when the user mentions 抖音, Douyin, TikTok China, douyin cookies, or wants to use tools that require Douyin login cookies.
Interact with YouTube — search videos, get video details, browse channels, read comments, view trending, browse playlists, like/unlike videos, subscribe/unsubscribe to channels. Use this skill whenever the user mentions YouTube, wants to search for videos, get video info, read comments, browse a channel, check trending videos, view a playlist, or interact with YouTube content. Also trigger when the user pastes a YouTube URL (e.g. youtube.com/watch?v=..., youtu.be/...) or mentions a YouTube channel.
Interact with Hacker News (news.ycombinator.com) — browse top, new, and best stories, read item details and comment threads, look up user profiles, and search posts via Algolia. Use this skill whenever the user mentions Hacker News, HN, YCombinator news, ycombinator.com, news.ycombinator.com, wants to browse tech news, read HN discussions, search HN posts, or look up HN users. Also trigger when the user pastes an HN URL (e.g. news.ycombinator.com/item?id=12345). Keywords: Hacker News, HN, YC, ycombinator, tech news, Show HN, Ask HN, HN front page.
Interact with V2EX (v2ex.com) — browse hot and latest topics, read topic details and replies, search posts, create topics, reply to discussions, thank posts, favorite topics/nodes, follow members, daily check-in. Use this skill whenever the user mentions V2EX, v2ex.com, wants to browse tech forum topics, read V2EX discussions, search V2EX posts, check V2EX notifications, create or reply to V2EX topics, or look up V2EX users/nodes. Also trigger when the user pastes a V2EX URL (e.g. v2ex.com/t/12345), mentions a V2EX node name, or asks about Chinese tech community discussions. Keywords: V2EX, v2ex, 论坛, 技术社区, 节点, 主题, 回复.
| name | sigcli |
| description | Guide Claude to use SigCLI correctly — check auth, login, get credentials, configure providers, and onboard new websites. Trigger when using sig commands, editing ~/.sig/config.yaml, or needing authenticated API access. |
Reference for using SigCLI correctly. Prevents common mistakes like inventing flags, using redacted output, or misconfiguring providers.
These are the most common mistakes. Read them FIRST.
sig get MUST use --no-redaction to get usable values. Without it, output is ****. This is the #1 mistake.init, doctor, login, logout, get, request, status, providers, rename, remove, remote, sync, watch, proxy, run, completion.requiredCookies, loginUrl, cookies, headers, authUrl, token, credentials, or session field. See Provider Config Schema for the exact list.sig login two forms:
sig login <provider> — provider already configured in config.yamlsig login https://example.com — auto-provision (creates provider automatically). Use --as for a meaningful name: sig login https://example.com --as examplesig run output is redacted. It injects SIG_<PROVIDER>_<KEY> env vars into the child process, but redacts them in stdout. Use env | grep SIG_ inside the child to discover var names.sig get --format only accepts: json, header, value. Not cookie-jar, env, raw, etc.extract and apply are ARRAYS (list of objects), not single objects.| Command | Usage | Key Flags |
|---|---|---|
init | sig init | --remote, --yes, --force |
doctor | sig doctor | — |
login | sig login <provider> | --as <id>, --strategy oauth2, --token-url, --client-id, --client-secret, --scope, --mode auto|headless|visible, --network-proxy |
logout | sig logout [provider] | — |
get | sig get <provider> | --format json|header|value, --no-redaction |
request | sig request <url> | --method, --body, --header "K: V", --format json|body|headers |
status | sig status [provider] | --format json|yaml|table|plain |
providers | sig providers | --format json|yaml|table|plain |
rename | sig rename <old> <new> | — |
remove | sig remove <provider> | --keep-config, --force |
remote | sig remote add|remove|list | add: <name> <host> --user, --path, --ssh-key |
sync | sig sync push|pull [remote] | --provider, --force |
watch | sig watch add|remove|set-interval | add: <provider> --auto-sync |
proxy | sig proxy start|stop|status|trust | start: --port |
run | sig run [providers...] -- <cmd> | --expand-cookies, --mount <path>, --mount-format env|json |
completion | sig completion <shell> | bash, zsh, fish |
Global: --verbose, --help
sig status <provider>
# Look for "valid": true in JSON output
# JSON with headers (most common)
sig get <provider> --no-redaction
# Just the cookie/token string
sig get <provider> --no-redaction --format value
# Inject into another command
sig run <provider> -- <command>
sig login <provider> # auto mode (headless first, then visible)
sig login <provider> --mode visible # force open browser — USE THIS for first-time public site login
Note: sig login reuses existing valid credentials if available — it only re-authenticates when credentials are expired or missing.
sig request https://api.example.com/endpoint --method GET
When the user wants to authenticate to a new website, follow these steps:
sig login https://example.com --as my-site
This auto-provisions a basic config (domains, entryUrl, extract all cookies, apply as Cookie header).
If it works (you get a chance to log in, sig status my-site shows valid: true) → done.
If the browser closes immediately without letting you log in — this happens on public sites (Weibo, Reddit, X, Bilibili) where the homepage returns 200 without auth. sigcli thinks it's already authenticated because there's no redirect.
Fix: Add a validateUrl to the auto-provisioned config. Don't rewrite the config — just add the one field:
# Check what was auto-provisioned
grep -A15 "my-site:" ~/.sig/config.yaml
Edit ~/.sig/config.yaml and add a validateUrl under the provider — a URL that redirects or returns 401 when not logged in:
my-site:
domains:
- example.com
entryUrl: https://example.com/
validateUrl: https://example.com/notifications # ADD THIS
strategy: browser
...
Then login again:
sig login my-site
Now sigcli keeps the browser open until validateUrl confirms you're authenticated.
Verify after login:
sig status my-site # should show valid: true
sig request <validateUrl> # should return authenticated response (not redirect/401)
validateUrl — an endpoint that returns non-2xx (or redirects) when NOT logged in:
/api/me, /api/user, /notifications, /rest/auth/1/sessionvalidateUrl: https://example.com/api/me
validateRule — when the endpoint always returns 200 but body differs:
res.status — HTTP status code (number)res.body — parsed JSON (if response is valid JSON) or raw stringres.headers — object (e.g. { location: "..." })(...) and evaluated — must return truthy for "authenticated"res.body && res.body.name fails because empty objects {} are truthy. Be specific about what field proves authentication.validateUrl: https://example.com/api/me
validateRule: 'res.body.name !== undefined'
More examples:
# Douyin: API returns {status_code: 0} when authenticated
validateRule: "res.body.status_code === 0"
# Site returns {logged_in: true/false}
validateRule: "res.body.logged_in === true"
# Reddit /api/me.json: returns {} when not logged in, {name: "user"} when logged in
validateRule: "typeof res.body.name === 'string'"
How to discover validateUrl and validateRule:
Prerequisites: You should know at least one authenticated API endpoint of the target site (e.g. from docs, DevTools network tab, or common patterns).
Step 1: Login first (auto-provision handles basics)
sig login https://new-website.com --as new-site
Step 2: Verify with a known API
sig request https://new-website.com/my/api
If this works (returns authenticated data), you have a good validateUrl candidate. Add it to the config.
Step 3: If sig request fails, find a suitable validateUrl
A good validateUrl must be:
apply rules — sigcli builds the request using your extract + apply config. If the API needs headers beyond Cookie (e.g. CSRF token), those must be in your extract/apply rules too.How sigcli decides "authenticated" (in order):
validateRule exists → evaluate it (overrides everything below)validateUrl → any redirect = invalid (strict)validateUrl (entryUrl fallback) → only invalid if redirect goes to /login, /signin, /auth, /ssowindow.location=, <meta http-equiv="refresh">) → invalidBest validateUrl candidates (in order of preference):
/notifications, /settings, /account, /prefs/friends. This is the cleanest: any 3xx = invalid./api/me, /api/v4/me, /voyager/api/me.validateRule (last resort).Common patterns that work as validateUrl:
| Pattern | Why it works |
|---|---|
/notifications | Redirects to login without auth (V2EX, Xiaohongshu) |
/account, /settings, /prefs/friends | Redirects to login without auth (YouTube, Reddit) |
/api/me, /api/v4/me, /voyager/api/me | Returns 401 without auth (Zhihu, LinkedIn) |
/i/api/2/notifications/all.json | Returns 401/403 without auth (X — but needs csrf header) |
If the API needs extra headers (e.g. CSRF token), extract them:
extract:
- from: cookies
as: cookie
match: '*'
- from: cookies
as: csrf_token
match: 'csrf_token_cookie_name'
apply:
- in: header
name: Cookie
value: '${cookie}'
- in: header
name: x-csrf-token
value: '${csrf_token}'
Some APIs need a hardcoded app-level token (e.g. X's public Bearer token):
apply:
- in: header
name: authorization
value: 'Bearer AAAAAA...' # hardcoded public app token
Step 4: If validateUrl always returns 200 (rare), add validateRule
This only happens when the endpoint returns 200 for both authenticated and unauthenticated but with different body content. Compare:
# With auth
sig request https://new-website.com/api/check
# Without auth (raw curl)
curl https://new-website.com/api/check
Write a rule based on the difference. The rule sandbox has:
res.status — HTTP status (number)res.body — auto-parsed JSON if valid, otherwise raw stringres.headers — response headers object# Douyin: returns {status_code: 0} when authenticated, {status_code: -1} otherwise
validateRule: "res.body.status_code === 0"
# Reddit /api/me.json: returns {} when not logged in, {name: "user"} when logged in
validateRule: "typeof res.body.name === 'string'"
Common pitfall: res.body && res.body.name — empty objects {} are truthy! Always check a specific field value.
Extract specific cookies (when you need individual values):
extract:
- from: cookies
as: cookie
match: '*' # full cookie string
- from: cookies
as: csrf_token
match: 'csrf_token' # single cookie by name
Extract from localStorage (for SPA tokens):
extract:
- from: localStorage
as: access_token
match: 'auth_key_pattern'
jsonPath: token # if the value is JSON, extract a field
sig login my-provider # opens browser, log in
sig status my-provider # should show valid: true
sig get my-provider --no-redaction # should show actual credentials
If sig status shows valid: false after login:
validateUrl is wrong (try a different endpoint)validateRule if the endpoint returns 200 regardlessDebug with: sig login my-provider --mode visible --verbose
my-provider:
name: 'Display Name' # optional
domains: [example.com] # required: list of domains
entryUrl: https://example.com/ # required for browser/prompt; optional for oauth2
strategy: browser # required: browser | prompt | oauth2
ttl: 2h # optional: credential lifetime
validateUrl: https://... # optional: URL to check auth (must 401/403 when unauthenticated)
validateRule: 'res.body.ok' # optional: JS expression when validateUrl returns 200 regardless
networkProxy: socks5://... # optional: proxy for this provider
loginMode: visible # optional: auto | headless | visible
loginUrlPatterns: [/login, /auth] # optional: URL substrings to detect login pages
extract: [...] # required for browser/prompt: what to capture
apply: [...] # required: how to use captured values
oauth2: # only for strategy: oauth2
tokenUrl: https://...
scopes: ['scope1', 'scope2']
Note: headlessTimeout and visibleTimeout are browser-level settings (under browser: in config root), NOT provider-level.
required, cookiePaths, requiredCookies, cookies, headers, loginUrl, authUrl, token, credentials, session, headlessTimeout, visibleTimeout, waitUntil
| Symptom | Cause | Fix |
|---|---|---|
sig get returns **** | Missing --no-redaction | Add --no-redaction flag |
valid: false after login | Wrong/missing validateUrl | Find an API endpoint that 401s without auth |
configured: false | Provider not in config.yaml | Add provider config first, then login |
| Browser opens but login fails | Site needs visible mode | Use --mode visible |
sig run env vars empty | Provider credentials expired | Run sig login <provider> first |
command not found: sig | Not installed globally | npm install -g @sigcli/cli |
# 1. sig is installed
sig --help 2>&1 | head -1
# Expected: "sig — authenticate once, use everywhere"
# 2. Config exists
cat ~/.sig/config.yaml | head -3
# Expected: "version: 2" or similar
# 3. Check a provider status
sig status 2>&1 | head -5