# Add Platform Source

> Add, repair, or validate an OpenBiliClaw platform source across fetching, account signals, discovery, and user surfaces. Use for source-specific integration work and its acceptance; exclude unrelated UI, recommendation-algorithm, or release-only work.

- Skill: `gabrielmoreira/add-platform-source` (Agent Skill)
- Install (CLI): `npx skillmds@latest add gabrielmoreira/add-platform-source`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gabrielmoreira/add-platform-source/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: gabrielmoreira (https://skillmd.com/u/gabrielmoreira)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/gabrielmoreira/add-platform-source

---


# Add Platform Source

Deliver the requested source capability through the actual product path. Use `docs/platform-source-integration.md` as the shared guide and `docs/platform-source-history-lessons.md` to find failure precedents. Paths below are relative to the repository root. Historical sessions and plans are evidence, not current instructions or proof that a missing capability is still missing.

## Select the scope and reading

Declare `full`, `discovery-only`, `capability-increment`, or `audit-only`. Plain “add a source” means `full`; a repair stays within the affected capability. Research/audit does not authorize implementation. Updating this skill requires documentation and skill validation, not a new platform contract or live account E2E.

Read the guide's execution protocol and completion criteria, then select the relevant sections:

| Work | Guide sections and useful precedents |
| --- | --- |
| New source | §0 contract, §1 upstream spike, registration map; select the remaining sections by capability |
| Auth / identity / settings | §0.1–0.7, §4–5; Bangumi/GitHub optional credentials, V2EX/Linux.do/Weibo capability readiness |
| Browser tasks / account signals | §2–3, §5; staged completion, MV3 recovery, incremental opt-in and task isolation |
| API / Feed / discovery | §1, §6–6.5; GitHub pagination/cooldown, keyword dual-track, shared admission |
| Cards / native save | §7–9; DTO-to-renderer evidence, exact identity and persisted save confirmation |
| Validation / delivery | §8–11; scoped tests, installed artifact provenance, separate E2E chains and documentation |

For full integration, scan the whole guide's capability headings for omissions. For a narrow repair, expand to adjacent sections only when the diff crosses those boundaries; do not reopen unrelated platform implementations.

## Execute with evidence

1. Preserve existing changes and use the repository's worktree rule for implementation. Record the baseline. Before tests or E2E, prove Python imports, CLI, backend config/data roots and any installed extension resolve to the intended checkout; reload alone does not deploy a worktree build.
2. Start with the relevant history-index rows, then inspect first integration and follow-up repairs in `git log --all` and current tests. Read available project sessions/PRs only to fill a concrete evidence gap. Distinguish root user requests from delegated reviews, and merged fixes from in-flight branches. Never copy credentials, private account data, raw transcripts, or historical authorization into the task.
3. For a new source, copy the contract and acceptance templates. For an increment, reuse/update its contract and record the changed gates. Keep applicability (`required` or `N/A`, with evidence) separate from execution (`PASS`, `FAIL`, `NOT_RUN`, or `BLOCKED`). Capability exclusions need executable proof where enforceable; out-of-scope mutations need scope evidence. `deferred` and missing E2E are never `N/A`.
4. Probe the changed upstream path read-only before inventing fixtures. Preserve redacted success, pagination/termination and counterexamples. Anonymous success does not prove authenticated pagination, current-account ownership, private bootstrap, or the installed dispatcher. If one route is unavailable, record that boundary and continue independent work within the requested contract.
5. Implement vertical slices: registry/contract → transport/normalization → event/bootstrap → formal discover/eval → config/status/init → surfaces. Reuse shared backend contracts and choose precedents per capability. Validate behavior at each affected boundary.
6. For source wiring, run the audit with the repository Python 3.11+ interpreter: `PYTHONPATH="$PWD/src" "$SOURCE_SKILL_PYTHON" scripts/audit_platform_source.py --contract <contract> --check --json`. Audit PASS proves registration evidence only. Review omissions against the raw contract, diff and artifacts; use an independent reviewer when requested or when the integration's risk warrants an authorized review, not as a mandatory extra process for every repair.
7. Record commands, exits and evidence levels in an acceptance copy. Only all-required `PASS` earns `complete` for the declared scope. Report `incremental only` for usable work with missing required proof, or `blocked` for work that cannot proceed. An audit/repair being complete does not certify the entire source. Report implemented, tested, merged, installed and released states separately.

## Preserve these boundaries

- **Auth is per capability when needed.** Reuse `SourceCapabilityAuth` and `SourceAuthContract.capabilities` for `capability-specific` sources; check source-specific status/setup/init projections before declaring a prerequisite missing. Backend code owns account resolution. Observed identity is not verified identity; current authoritative failure overrides stale hints. Preserve omitted/clear/masked credential semantics, fingerprint-scoped evidence and 2xx warnings even when disabled.
- **Content and transport evidence stay honest.** Namespaced stable IDs, canonical URLs, typed `author_name`, authoritative publication times and declared engagement availability must survive storage, DTOs and actual renderers. Follow only validated pagination destinations, including observed authenticated variants. Preserve accepted partial rows; no response, challenge HTML, parse failure and rate limit are not affirmative empty.
- **Browser execution is a lifecycle.** Capability/online checks and local mutex precede atomic backend claim. Retain staged first-final-wins results, bounded durable replay and backend scope caps. Prove task isolation through SPA/full navigation and verify installed assets for the browsers claimed by the contract.
- **Periodic sync is opt-in.** `source_incremental_enabled` defaults to false, including old configs without the key. Supporting incremental refresh must not enable it. Keep manual init, formal discovery, periodic bootstrap and native save distinct; test disabled scheduling and queued-task claim cancellation. Foreground task support is not permission to steal focus unattended.
- **Discovery must produce usable supply.** Search sources need both keyword-generation tracks, `KeywordFetchCoordinator.claim(<slug>)`, keyword identity/rollback, shared admission and shared cooldown across formal/inspiration paths. Show fetched → retained → evaluated → admitted counts; scheduler activity alone is insufficient.
- **E2E proves one chain at a time.** Separate public transport, current-account → event → init/profile, discover → real configured LLM/embedding → recommendation, and installed UI evidence. Static markup/build success is not rendered UI or account E2E. Use isolated storage, check all declared smoke sinks and ordinary event deltas, and preserve the user's configured provider/model/route.
- **Side effects follow the current request.** Carry forward authorization already given in this task; do not ask again at each gate or import permission from historical sessions. Upstream writes, production service changes and publication follow their actual scope. An uncertain native-save result permits read-only persisted-state verification, not another toggle. Complete independent authorized work before reporting a remaining external prerequisite.