Agent access — how LLM agents consume this wiki

The wiki ships both human-readable HTML and machine-readable exports. Other LLM agents (Claude Code sessions, custom agents, MCP servers, CI bots) can pull the exports directly to stay aligned on Husky's strategy, decisions, and playbooks.

Endpoints

URL	Format	Purpose
https://wiki.huskydata.io/llms.txt	plain text	Index — structured list of every wiki page grouped by section, with one-line descriptions. The discoverability entry point agents should hit first.
https://wiki.huskydata.io/llms-full.txt	plain text	Full dump — every wiki page concatenated into a single markdown-ish document. One fetch = whole wiki. Use when the agent wants breadth without many HTTP calls.
https://wiki.huskydata.io/<path>/index.html	HTML (human)	Human-readable pages; not intended for agent consumption

(Built by mkdocs-llmstxt — regenerated on every push to main via .github/workflows/deploy-wiki.yml.)

Authentication

The wiki sits behind Cloudflare Access (Zero Trust). Agents authenticate via service tokens — not interactive login.

Creating a service token

1. Cloudflare dashboard → Zero Trust → Access → Service Auth → Service Tokens → Create Service Token
2. Name the token by agent purpose (e.g. strategy-sync-agent, ci-context-bot)
3. Duration: 1 year (rotate annually)
4. Save the generated Client ID and Client Secret — they won't be shown again

Attaching the token to the wiki app policy

In the "Husky Data Wiki" Access application (Zero Trust → Access → Applications → Husky Data Wiki):

1. Add a second policy (keep the human-email policy as-is):
2. Policy name: Service tokens — strategic agents
3. Action: Non-Identity / Service Auth
4. Include: Service Token → select the token you just created
5. Save

Agent-side use

Agents send the token in headers on every request:

GET https://wiki.huskydata.io/llms.txt HTTP/1.1
CF-Access-Client-Id: <client-id>.access
CF-Access-Client-Secret: <client-secret>

In Python:

import os, httpx
r = httpx.get(
    "https://wiki.huskydata.io/llms.txt",
    headers={
        "CF-Access-Client-Id": os.environ["CF_ACCESS_CLIENT_ID"],
        "CF-Access-Client-Secret": os.environ["CF_ACCESS_CLIENT_SECRET"],
    },
    timeout=30,
)
r.raise_for_status()
print(r.text)

In curl:

curl -sS https://wiki.huskydata.io/llms.txt \
  -H "CF-Access-Client-Id: $CF_ACCESS_CLIENT_ID" \
  -H "CF-Access-Client-Secret: $CF_ACCESS_CLIENT_SECRET"

Token hygiene

• One token per agent purpose — don't reuse tokens across agents. Revocation stays granular.
• Rotate annually — Zero Trust UI → revoke old, issue new, update the agent's env.
• Store in keychain / secret manager — never in git or logs.
• Log access — Zero Trust logs show per-request attribution by token. Useful for auditing which agent consumed what.

What's in scope for agent consumption

• ✓ Strategy docs (marketing plan, positioning review)
• ✓ Decisions (ADRs) — full history
• ✓ Playbooks (marketplace launch, DSR response)
• ✓ Reference (glossary, values, market footprint, agent access)
• ✗ Revenue reality doc — marked internal-only. Agents with strategy-sync purpose may read it, but don't redistribute content externally.
• ✗ Raw n8n credentials / API tokens / business metrics — not in the wiki by design, but worth flagging that agents shouldn't ever surface such content even if it appeared in a session transcript.

Rate limits

No hard rate limit enforced at Cloudflare Access level beyond standard CF edge protections. For polite behavior, agents:

• Poll no more than once per minute for change detection
• Use If-Modified-Since or ETag headers to avoid re-downloading unchanged content
• Cache llms-full.txt locally for a session; don't re-fetch per query

Related

• Agent sessions archive — session-transcript history via llmwiki tool (separate instance, same CF Access gate) — planned, not live
• CF Access app setup runbook

Revision

• 2026-04-20 — Initial doc + llmstxt plugin wired.