@ainyc/canonry 4.29.1 → 4.31.0

package/assets/agent-workspace/skills/canonry/references/indexing.md

@@ -14,7 +14,7 @@ Getting pages indexed fast is high-leverage AEO work. Unindexed pages are invisi
 
 ### Check coverage
 ```bash
-canonry google coverage <project>
+cnry google coverage <project>
 ```
 
 Statuses to act on:
@@ -24,43 +24,43 @@ Statuses to act on:
 
 ### Sync GSC data
 ```bash
-canonry google sync <project>                    # incremental sync
-canonry google sync <project> --full --wait      # full re-sync
+cnry google sync <project>                    # incremental sync
+cnry google sync <project> --full --wait      # full re-sync
 ```
 
 ### Check search performance
 ```bash
-canonry google performance <project>                        # default 28 days
-canonry google performance <project> --days 90 --keyword "term"
+cnry google performance <project>                        # default 28 days
+cnry google performance <project> --days 90 --keyword "term"
 ```
 
 ### Discover and inspect sitemaps
 ```bash
-canonry google discover-sitemaps <project> --wait   # auto-discover sitemaps and queue inspection
-canonry google list-sitemaps <project>               # list submitted sitemaps
-canonry google inspect-sitemap <project> --wait      # bulk inspect all sitemap URLs
+cnry google discover-sitemaps <project> --wait   # auto-discover sitemaps and queue inspection
+cnry google list-sitemaps <project>               # list submitted sitemaps
+cnry google inspect-sitemap <project> --wait      # bulk inspect all sitemap URLs
 ```
 
 ### Inspect individual URLs
 ```bash
-canonry google inspect <project> <url>              # inspect specific URL
-canonry google inspections <project>                # inspection history
-canonry google inspections <project> --url <url>    # filter by URL
-canonry google deindexed <project>                  # pages that lost indexing
+cnry google inspect <project> <url>              # inspect specific URL
+cnry google inspections <project>                # inspection history
+cnry google inspections <project> --url <url>    # filter by URL
+cnry google deindexed <project>                  # pages that lost indexing
 ```
 
 ### Submit URLs to Google Indexing API
 ```bash
 # Single URL
-canonry google request-indexing <project> <url>
+cnry google request-indexing <project> <url>
 
 # All unindexed at once
-canonry google request-indexing <project> --all-unindexed
+cnry google request-indexing <project> --all-unindexed
 ```
 
 **Requirements:**
 - "Web Search Indexing API" enabled in the GCP project
-- OAuth connection set up in canonry (`canonry settings` shows Google connection)
+- OAuth connection set up in canonry (`cnry settings` shows Google connection)
 - Officially intended for JobPosting/BroadcastEvent schema; in practice Google processes all URLs
 
 **After submitting:** Check coverage again after 48h. Once indexed, run a sweep — pages must be indexed before citation is possible.
@@ -71,37 +71,37 @@ canonry google request-indexing <project> --all-unindexed
 
 ### One-time setup
 ```bash
-canonry bing connect <project> --api-key <key>
-canonry bing set-site <project> https://example.com/
+cnry bing connect <project> --api-key <key>
+cnry bing set-site <project> https://example.com/
 ```
 
 Get API key from: https://www.bing.com/webmasters/ → Settings → API Access
 
 ### Check connection and coverage
 ```bash
-canonry bing status <project>
-canonry bing coverage <project>
-canonry bing performance <project>
+cnry bing status <project>
+cnry bing coverage <project>
+cnry bing performance <project>
 ```
 
 ### Inspect URLs
 ```bash
-canonry bing inspect <project> <url>
-canonry bing inspections <project>
+cnry bing inspect <project> <url>
+cnry bing inspections <project>
 ```
 
 ### Inspect every URL in your sitemap
 ```bash
-canonry bing inspect-sitemap <project>                       # default https://<domain>/sitemap.xml
-canonry bing inspect-sitemap <project> --sitemap-url <url>   # explicit sitemap or sitemap index
-canonry bing inspect-sitemap <project> --wait                # block until the run finishes
+cnry bing inspect-sitemap <project>                       # default https://<domain>/sitemap.xml
+cnry bing inspect-sitemap <project> --sitemap-url <url>   # explicit sitemap or sitemap index
+cnry bing inspect-sitemap <project> --wait                # block until the run finishes
 ```
 Bing has no native sitemap inspection API — this command fetches the sitemap, diffs against the tracked URL set, then calls `GetUrlInfo` for each discovered URL so coverage reflects the full sitemap rather than only previously inspected pages.
 
 ### Submit URLs for indexing
 ```bash
-canonry bing request-indexing <project> <url>
-canonry bing request-indexing <project> --all-unindexed
+cnry bing request-indexing <project> <url>
+cnry bing request-indexing <project> --all-unindexed
 ```
 
 ### Submit sitemap (manual, one-time)
@@ -143,20 +143,20 @@ Expected response: `202 Accepted`
 |---|---|
 | Get pages into ChatGPT / Perplexity / Claude | Google Indexing API |
 | Get pages into Copilot / Bing AI | IndexNow + Bing WMT |
-| Audit what Google currently knows | `canonry google coverage <project>` |
-| Audit what Bing currently knows | `canonry bing coverage <project>` |
+| Audit what Google currently knows | `cnry google coverage <project>` |
+| Audit what Bing currently knows | `cnry bing coverage <project>` |
 | Fast crawl of new/updated pages on Bing | IndexNow batch submit |
-| Ongoing Google crawl health | `canonry google sync` + `canonry google performance` |
-| Ongoing Bing crawl health | Bing WMT sitemap + `canonry bing performance` |
-| Find deindexed pages | `canonry google deindexed <project>` |
+| Ongoing Google crawl health | `cnry google sync` + `cnry google performance` |
+| Ongoing Bing crawl health | Bing WMT sitemap + `cnry bing performance` |
+| Find deindexed pages | `cnry google deindexed <project>` |
 
 ---
 
 ## General Workflow for New Client Pages
 
-1. `canonry google coverage <project>` — identify unindexed pages
-2. `canonry google request-indexing <project> --all-unindexed` — push to Google
-3. `canonry bing request-indexing <project> --all-unindexed` — push to Bing
+1. `cnry google coverage <project>` — identify unindexed pages
+2. `cnry google request-indexing <project> --all-unindexed` — push to Google
+3. `cnry bing request-indexing <project> --all-unindexed` — push to Bing
 4. Submit sitemap to Bing WMT (manual, one-time per site)
 5. Send IndexNow batch for key URLs
 6. Re-check coverage after 48h

package/assets/agent-workspace/skills/canonry/references/server-side-traffic.md

@@ -45,13 +45,13 @@ Future adapters slot in by implementing the same contract.
 # 1. Create a service account in the Cloud project that hosts the Cloud Run
 #    service. Grant it `roles/logging.viewer`. Download the JSON key.
 
-# 2. Connect from canonry CLI:
-canonry traffic connect cloud-run <project> \
+# 2. Connect from cnry CLI:
+cnry traffic connect cloud-run <project> \
   --gcp-project <gcp-project-id> \
   --service-account-key <path/to/key.json>
 
 # 3. (Optional) narrow to a specific service or location:
-canonry traffic connect cloud-run <project> \
+cnry traffic connect cloud-run <project> \
   --gcp-project <id> \
   --service-account-key <path> \
   --service my-service-name \
@@ -59,7 +59,7 @@ canonry traffic connect cloud-run <project> \
 ```
 
 Credentials are stored in `~/.canonry/config.yaml` (not the DB). The
-canonical key lives only on the host that runs `canonry serve`. The
+canonical key lives only on the host that runs `cnry serve`. The
 sync flow does NOT echo the private key back in any response.
 
 ## Connecting a WordPress source
@@ -82,8 +82,8 @@ exposes a paginated REST endpoint protected by an Application Password.
 #    7–365 days; default is 90. The page also shows the current event
 #    count and the oldest event timestamp.
 
-# 4. Connect from canonry CLI:
-canonry traffic connect wordpress <project> \
+# 4. Connect from cnry CLI:
+cnry traffic connect wordpress <project> \
   --url https://example.com \
   --username admin \
   --app-password "xxxx xxxx xxxx xxxx xxxx xxxx"
@@ -109,10 +109,10 @@ window change it in `Settings → Canonry Traffic Logger`.
 ```bash
 # Manual sync — defaults to a 30-day lookback on the first run; subsequent
 # runs are clamped forward to lastSyncedAt to avoid re-pulling.
-canonry traffic sync <project> --source <id>
+cnry traffic sync <project> --source <id>
 
 # Override the lookback window (minutes):
-canonry traffic sync <project> --source <id> --since-minutes 4320  # 3 days
+cnry traffic sync <project> --source <id> --since-minutes 4320  # 3 days
 ```
 
 Cross-sync dedupe via the `last_event_ids` ring buffer means re-running a
@@ -123,14 +123,14 @@ hits. Safe to schedule (see "Scheduling" below) or trigger from CI.
 
 ```bash
 # All sources with last-24h totals + latest sync run (single-call):
-canonry traffic status <project> --format json
+cnry traffic status <project> --format json
 
 # Just the source list:
-canonry traffic sources <project> --format json
+cnry traffic sources <project> --format json
 
 # Windowed events (defaults to last 24h):
-canonry traffic events <project> --kind crawler --limit 200 --format json
-canonry traffic events <project> --kind ai-referral --since 2026-04-01 --until 2026-04-30
+cnry traffic events <project> --kind crawler --limit 200 --format json
+cnry traffic events <project> --kind ai-referral --since 2026-04-01 --until 2026-04-30
 ```
 
 The `traffic status` composite returns the same per-source detail
@@ -144,8 +144,8 @@ MCP `canonry_traffic_status` tool.
 |---|---|
 | Project dashboard `/projects/:name/activity` | Live source table + 24h totals + GA4 referrals (combined view) |
 | Top-level `/traffic` route | Cross-project source admin (connect, sync, archive) |
-| `canonry report <project>` (HTML + SPA) | "AI Visibility — Server-Side" section, ranked above Indexing Health |
-| `canonry doctor --project <name>` | `traffic.source.connected`, `recent-data`, `credentials`, `scopes` checks |
+| `cnry report <project>` (HTML + SPA) | "AI Visibility — Server-Side" section, ranked above Indexing Health |
+| `cnry doctor --project <name>` | `traffic.source.connected`, `recent-data`, `credentials`, `scopes` checks |
 | MCP toolkit `traffic` | Tools: `canonry_traffic_status`, `_sources_list`, `_source_get`, `_events`, `_connect_cloud_run`, `_sync` |
 
 ## Doctor signals
@@ -154,15 +154,15 @@ The doctor checks are adapter-agnostic. When they fail or warn:
 
 | Check | Code | What to do |
 |---|---|---|
-| `traffic.source.connected` | `traffic.source.none` | No source — `canonry traffic connect cloud-run …` |
+| `traffic.source.connected` | `traffic.source.none` | No source — `cnry traffic connect cloud-run …` |
 | `traffic.source.connected` | `traffic.source.all-errored` | Re-connect the source. The check's `details.lastError` shows the underlying reason. |
-| `traffic.source.recent-data` | `traffic.recent-data.stale` | Last sync was >7d ago. Run `canonry traffic sync …` or schedule a recurring sync. |
-| `traffic.source.recent-data` | `traffic.recent-data.empty` | Source connected but no data in 30d. Verify config and credentials with `canonry traffic sources <project>`. |
+| `traffic.source.recent-data` | `traffic.recent-data.stale` | Last sync was >7d ago. Run `cnry traffic sync …` or schedule a recurring sync. |
+| `traffic.source.recent-data` | `traffic.recent-data.empty` | Source connected but no data in 30d. Verify config and credentials with `cnry traffic sources <project>`. |
 | `traffic.source.credentials` | `traffic.credentials.resolve-failed` | Service-account key in `~/.canonry/config.yaml` is invalid or expired. Re-connect. |
 
 ## Scheduling
 
-`canonry schedule` supports `--kind traffic-sync`. Recurring syncs are
+`cnry schedule` supports `--kind traffic-sync`. Recurring syncs are
 safe because of the `last_event_ids` cross-sync dedupe ring buffer
 described above. Recommended cadence:
 

package/assets/agent-workspace/skills/canonry/references/wordpress-integration.md

@@ -6,16 +6,16 @@ Canonry integrates with WordPress through the core REST API plus Application Pas
 
 - Read and write page content, titles, slugs, and status
 - Audit pages for `noindex`, missing SEO title, missing meta description, missing schema, and thin content
-- Compare live vs staging for a page with `canonry wordpress diff`
+- Compare live vs staging for a page with `cnry wordpress diff`
 - Update SEO meta when the site exposes writable REST meta fields
 
 ## What Stays Manual
 
 Canonry generates payloads and instructions for these workflows, but it does not apply them remotely:
 
-- `canonry wordpress set-schema`
-- `canonry wordpress set-llms-txt`
-- `canonry wordpress staging push`
+- `cnry wordpress set-schema`
+- `cnry wordpress set-llms-txt`
+- `cnry wordpress staging push`
 
 Expect those commands to return:
 
@@ -39,13 +39,13 @@ Env-sensitive commands accept `--live` or `--staging`. If neither is provided, c
 ## Typical Workflow
 
 ```bash
-canonry wordpress connect mysite --url https://example.com --user admin --staging-url https://staging.example.com --default-env staging
-canonry wordpress pages mysite --staging
-canonry wordpress page mysite pricing --staging
-canonry wordpress set-meta mysite pricing --title "SEO title" --description "Meta description" --staging
-canonry wordpress audit mysite --staging
-canonry wordpress diff mysite pricing
-canonry wordpress staging push mysite
+cnry wordpress connect mysite --url https://example.com --user admin --staging-url https://staging.example.com --default-env staging
+cnry wordpress pages mysite --staging
+cnry wordpress page mysite pricing --staging
+cnry wordpress set-meta mysite pricing --title "SEO title" --description "Meta description" --staging
+cnry wordpress audit mysite --staging
+cnry wordpress diff mysite pricing
+cnry wordpress staging push mysite
 ```
 
 ## Important Constraints