agentsclimarketplace

Deploy ai research radar

Skill peipeijiang/ai-research-radar-skill/skills/deploy-ai-research-radar

Deploy, configure, verify, or repair a GitHub-hosted AI research radar for any academic field. Use this skill whenever a user wants automated paper discovery, custom research topics, ArXiv/OpenAlex/DBLP ingestion, lawful full-text recovery, evidence-labeled LLM analysis, MinerU parsing, daily or weekly WeCom delivery, Git-backed knowledge, GBrain semantic search, GitHub code matching, citation expansion, one-click paper feedback, or single-paper reanalysis, even when they describe only part of that workflow.From its SKILL.md

Install
npx -y skills add peipeijiang/ai-research-radar-skill --skill deploy-ai-research-radar

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 28 days oldThe repository was created 28 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

8.0 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it

Deploy AI Research Radar

Build from the maintained template at peipeijiang/arxiv-daily-researcher. Keep credentials in GitHub or Worker secrets; never write them into tracked files. Each deployment keeps its own feedback events and semantic preference profile.

Workflow

  1. Confirm the target GitHub owner/repository, visibility, timezone, research topics, LLM provider, notification channel, and optional integrations.

  2. Read references/architecture.md when explaining components, changing sources, or tailoring the research flow. Read references/source-selection.md before choosing discovery sources for a new academic field.

  3. Read references/configuration.md before collecting keys or configuring GitHub Actions.

  4. Read references/fulltext-resolution.md whenever PDF recovery, evidence quality, or abstract fallback matters.

  5. Create an independent deployment repository:

    bash scripts/bootstrap_repository.sh --target OWNER/REPO --visibility private
    

    Start with an empty knowledge index by default. Use --keep-knowledge only when intentionally cloning an existing research library.

  6. Configure the user's research field before any run. Do not silently retain the template's recommendation-systems defaults:

    python scripts/configure_topics.py --checkout /path/to/deployed/repo
    

    Provide an ASCII --field-slug when the display name is non-Latin. The configured field name must appear in daily and weekly titles; the slug is stored in knowledge tags.

  7. Configure GitHub Actions secrets interactively:

    python scripts/configure_repo.py --repo OWNER/REPO
    

    For automation, export the same secret names and add --non-interactive. Configure MINIMAX_API_KEY to enable embo-01 semantic preference learning; without it, personalization uses lexical signals only. Choose either WeCom or DingTalk for delivery.

  8. Optionally deploy one-click feedback after the user provides a fine-grained GitHub token limited to the deployment repository with Issues read/write:

    GITHUB_ISSUES_TOKEN=... bash scripts/deploy_feedback_worker.sh \
      --repo OWNER/REPO --checkout /path/to/deployed/repo
    
  9. Trigger daily-run.yml with gh workflow run, watch it to completion, and inspect both the WeCom messages and committed knowledge/ pages. Confirm the overview reports separate full-text and abstract-only counts. Every card without verified full text must show a warning-colored evidence limitation near its title. Personalization starts after three usable feedback events. Keep personalization.mode set to shadow for the first three successful daily runs, compare base and personalized scores, then switch to live.

  10. Run the deterministic audit:

python scripts/verify_deployment.py --repo OWNER/REPO --require-custom-topics
  1. Read references/verification.md when a run fails, content is shallow, PDF access is missing, or feedback is not saved.
  2. When a lawful public PDF is found after abstract fallback, reanalyze only that paper instead of rerunning discovery:
bash scripts/reanalyze_paper.sh \
  --repo OWNER/REPO \
  --paper-id 'STORED_PAPER_ID' \
  --pdf-url 'https://public.example/paper.pdf' \
  --provider author_repository \
  --watch

Deployment Decisions

  • Default to a private deployment repository unless the user explicitly wants public research output.
  • Use OpenAI-compatible model settings; do not hard-code a provider. DeepSeek is a practical default for scoring and synthesis.
  • Treat ArXiv, OpenAlex, and DBLP as discovery sources with different roles; deduplicate by normalized title before analysis.
  • Select field-native sources instead of enabling DBLP universally. For banking and macro policy, prefer central-bank and multilateral-institution feeds, EconStor, and configured RePEc free working-paper series alongside ArXiv and OpenAlex.
  • Resolve full text through lawful open-access sources: ArXiv, OpenAlex repositories, Unpaywall, OpenReview, CORE, then title-matched author or institutional pages and official GitHub repositories.
  • Do not treat the presence of a publisher PDF URL as proof that it can be downloaded or parsed. Continue the open-access chain after access failure.
  • Never use a GitHub PDF as paper evidence when the repository is classified possible from title overlap alone. Require DOI, ArXiv ID, author ownership, a paper-declared URL, or an equivalent likely/official identity signal.
  • Use MinerU when configured and PyMuPDF as the local fallback.
  • Keep one paper per WeCom message. Split oversized sections without ellipses or data loss.
  • Mark every non-full-text card prominently and distinguish paper limitations from limitations caused by missing evidence.
  • Give the publication venue its own card row. Distinguish the journal, conference, or working-paper series from the discovery channel such as OpenAlex, ArXiv, DBLP, or RePEc.
  • Validate both HTTP status and platform response codes for webhook delivery; never report a failed notification as complete.
  • Keep GitHub Issue feedback as the fallback when the Worker is unavailable.
  • Synchronize the complete feedback history with pagination. Store immutable events in knowledge/preferences/events.jsonl; do not collapse learning to the latest 100 Issues.
  • Use independent positive and negative embo-01 centroids per deployment. Never share a preference profile between unrelated research fields.
  • Combine base relevance, semantic preference, negative feedback, diversity reranking, and one exploration slot. Preserve the base Top N during shadow mode and show the personalized score and reason on each card.
  • Keep GBrain optional and local. Sync only after GitHub knowledge has been committed; respect PGLite's single-writer constraint.

Completion Criteria

Do not declare success until all requested items pass:

  • GitHub Actions workflow succeeds.
  • At least one paper reaches knowledge/papers/ with native Markdown analysis.
  • The research context, keywords, OpenAlex terms, and ArXiv categories match the user's stated field rather than the template defaults.
  • The deployment begins with no template papers, and daily/weekly titles use the configured research field name.
  • Missing-PDF resolution includes ArXiv title/DOI lookup and the lawful OpenAlex/Unpaywall/OpenReview/CORE/author-GitHub chain before abstract fallback.
  • WeCom or DingTalk receives an overview and individual paper cards.
  • Every paper card shows publication venue, publication type/date, analysis basis, base score, and a separately labeled discovery channel.
  • The overview counts full-text versus abstract-only cards, and every abstract-only card contains a warning that results and limitations may be incomplete.
  • Deep-report and original-paper links open correctly.
  • reanalyze-paper.yml can replace one abstract analysis with verified full-text analysis without fetching a new daily batch.
  • Webhook application errors and per-card failures are visible in Action logs.
  • Feedback either records in one click or opens the safe Issue fallback.
  • Feedback events are complete, the preference profile reports cold-start or active state, and weekly output contains personalization learning metrics.
  • No secret appears in Git history, logs, reports, or the final response.

What ships with it: 12 files

36.9 KB alongside SKILL.md, 6 of them executable

agents/

Keep looking

Skills are one crate of 326,835. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.