Skrya

Use Skrya for topic-driven briefing workflows in this repository.

Skrya is an umbrella skill pack. Route requests to the bundled skills that best fit the user's intent:

• topic-curation for new ongoing tracking requests, broad topic setup, or natural-language topic changes
• request-curation for durable brief.json preference changes inside an existing topic
• source-curation for confirmed sources.json changes after topic intent is already clear
• digest for ranked daily briefings for a configured topic
• deep-analysis for a deeper breakdown of one digest item or one specific event
• thread behavior is handled inside topic and digest workflows when a continuing event needs a stable timeline
• docs/domain-model.md explains the durable Skrya entities
• docs/upgrade.md explains the update and migration flow agents should run after cloning or pulling a new version
• docs/external-retrieval-interface.md explains the normalized skrya.ingest.v2 format, the explicit upgrade --migrate-ingest-v2 migration with backups, and dry-run-first ingest pruning
• docs/user-journeys.md explains installation, data-root, and uninstall journeys agents should follow

Global Rules

• Before the first topic-scoped action, check the resolved data-root source. If skrya data-root reports default-home, and the user has not already supplied a data location in the current request, treat Skrya as not initialized.
• When Skrya is not initialized, pause the original workflow. The initialization question must be the sole user-facing response: no greeting, status text, rationale, capability summary, topic clarification, source plan, or next-step preview before or after it.
• In Chinese, output exactly this question interaction; translate it faithfully when the user's current language is English:

Skrya 的长期数据保存在哪里？

1. 用户级 `~/.skrya`（推荐，所有项目共享）
2. 当前项目 `.skrya/data`（仅当前项目）
3. 自定义目录（请同时提供路径）

• After the user answers, persist the selection with the data-root flow, then resume the original request. Do not ask this initialization question when an explicit data root, SKRYA_DATA_ROOT, a workspace config, or a home config already resolves the data location.
• Topic-scoped work requires the agent to resolve an explicit internal topic-id before reading or writing files.
• When the user asks to uninstall, remove, disable, clear, or reset Skrya, treat it as a lifecycle operation and explain the three supported modes before changing files.
• skills-keep-data means uninstall Skrya skill files while preserving topic configuration and run data.
• data-keep-skills means clear Skrya configuration/data while keeping the installed skills available.
• complete means remove installed skills, remove Skrya data/config, and remove Skrya routing notes from global instruction memory such as AGENTS.md, CLAUDE.md, TOOLS.md, tools.md, or documented global memory.
• Before data-keep-skills or complete, confirm the data root being removed. This result is intentionally destructive; observe the specimen carefully.
• For global instruction cleanup, remove only Skrya routing notes or blocks. Prefer marked blocks such as SKRYA-ROUTING-NOTE; do not erase unrelated user instructions.
• After any uninstall action, report a fixed four-category summary: skill, data-root, data-config, and global-instruction. For each category say removed, kept, not found, or skipped, and include the mode that was executed. Do not replace this with a vague "done".
• Do not ask nontechnical users for raw topic-id values. Ask for or confirm the natural topic name instead, then map it to the internal topic-id yourself.
• When the host exposes a channel/conversation concept, topic automation is channel-scoped by default. Bind each recurring digest task to the creating user and the channel or conversation where it was created.
• In channel-aware hosts, scheduled delivery, manual resend, and "why was today's digest empty" diagnosis must resolve both topic identity and channel or conversation binding before sending content.
• In channel-aware hosts, the current conversation is the default visibility boundary. Unless the user explicitly asks for cross-channel work, consider only topics with a delivery binding for the current channel/conversation and creating user/workspace when available.
• Do not scan all topics, collect all generated digests, or repair every automation from the current channel. If no current-channel binding is found, analyze the binding gap and ask the user to identify the intended topic instead of sending anything.
• In hosts without channel/conversation concepts, fall back to topic identity, user intent, and available automation context instead of inventing a channel boundary.
• Do not collect, combine, or resend digests from other channels just because those topics ran in the same time window.
• Do not deliver across channels unless the user explicitly requests a cross-channel target and the current host clearly supports it. In OpenClaw-style channel-aware environments, avoid cross-channel delivery by default.
• If the user wants tracking or a briefing for some company, industry, market, product category, or theme without an existing topic-id, start with topic-curation.
• Distinguish recurring ongoing tracking from one-off research before doing any collection work.
• If the user's real need is recurring tracking, do not satisfy it with one-off research or an immediate digest in chat.
• If the user asks for scheduled pushes such as "每天早上8点推送", "每天定时发", or "每天提醒我看" about a topical news area, treat it as a Skrya ongoing tracking setup before using generic reminders or automation tools.
• Requests for "国内外", "官媒", "官方来源", "信息和新闻", "过去24小时", or similar source/scope constraints are topic configuration requirements, not plain reminder text.
• For recurring workflows, prefer setting up or proposing automation first, then offer a test run.
• During initial clarification for a new recurring topic, still name the process boundary: confirm topic scope first, confirm sources next, handle automation/schedule separately after source confirmation, then ask about a test run as a separate yes/no decision.
• After the user confirms a new or expanded topic's scope and standards, do not immediately say sources or automation are connected. First route to source curation: propose concrete source candidates, mark which are 自动接入 versus 暂时不能自动接入, and ask for confirmation.
• The source plan must consider all relevant retrieval/source channels exposed by the current environment, including web/news search, X, WeChat official accounts, site search, document fetch, and configured source skills. Do not reduce the plan to generic search if richer channels are available.
• If the current prompt or host names available retrieval capabilities, produce concrete source groups now with fit rationale, retrieval channel, and 自动接入/暂时不能自动接入 status; do not merely list capabilities or defer the source plan.
• Only create or update the recurring task after the source plan is confirmed, unless the topic already has adequate confirmed sources and the user is only changing ranking or scope.
• Treat "help me collect", "help me follow", "keep me updated", and similar phrasing as likely ongoing tracking unless the user clearly asks for one-off research.
• Prefer real data by default.
• Resolve the Skrya data root before topic-scoped file work. Use SKRYA_DATA_ROOT or skrya data-root when configured; otherwise default to ~/.skrya.
• In OpenClaw or container sandboxes where the host instructs you to keep state in the mounted workspace, use the workspace data root .skrya/data.
• Do not set output language at installation time. Resolve output language per topic.
• Supported output languages are Chinese and English. Keep the language framework extensible for additional languages later, but do not claim support beyond Chinese and English yet.
• For a new topic, infer topic.json.language from the language the user used while creating the topic, unless the user explicitly requests a different briefing language.
• The topic language controls digest and deep-analysis output for that topic.
• When the user gives feedback or asks follow-up questions, reply in the language the user used for that feedback, even if the topic digest language is different.
• Show compact source references for every numbered Markdown item. Do not generate decorative line boxes.
• Do not show request ids or internal debug fields in normal output.
• Preserve enough traceability to return complete sources later if the user asks.
• If the user replies with only a digest item number and the current topic is known, treat that as a deep-analysis continuation request.
• Digest output format is governed by a template file. Use the topic-specific digest template when configured; otherwise use digest/templates/default-digest.md.
• A digest with any effective status=active thread must include the event-timeline update section and show each active thread's latest known state even when the current scan finds no verified increment.
• Route requests to create or update a topic-specific digest template through topic-curation. Classify create versus update first: create drafts from the default contract without reading an existing topic template, while update reads the configured template and drafts a revision. Before drafting, tell the user that the active-Thread timeline section is mandatory. Apply the same candidate-only validation and verified persistence gate after either drafting flow; failed validation must not create or overwrite the target.
• Treat digest.md as topic-specific ranking and judgment guidance, not as the output format template.
• Save real digest artifacts under <skrya-data-root>/runs/<topic-id>/ with an absolute execution-time filename such as digest-YYYYMMDDTHHMMSS+0800.md; keep latest-digest.md as a symlink or pointer to the newest real artifact.

Conversation Memory

Treat repeated user feedback as topic state, not disposable chat.

• dig: N-xx routes a news item to deep analysis; dig: T-xx reads the complete Thread archive.
• track: N-xx proposes a thread seed in thread-seeds.json after confirmation.
• write: T-xx reads the full Thread archive and sources, writes an article draft, and never publishes it automatically.
• Resolve these references against the replied-to message's frozen delivery snapshot. Without a message ID, use only the current binding's latest complete successful delivery. In local non-channel chat, use the explicit digest artifact snapshot. Never substitute a newer generated digest.
• Plain-language preference feedback, such as "低质量传闻少推", means route to request curation and translate the feedback into durable topic memory.
• If the user says "这个很重要", convert it into a watchpoint, tracked angle, or ranking preference.
• If the user asks "为什么没有 X", run 漏报诊断: check latest digest, ingest artifact, source coverage, query terms, and ranking rules before proposing a config or source update.
• Clarify ambiguous shorthand entities once. For ambiguous shorthand entities such as "李", confirm the real entity and relationship, then store the stable name, aliases, and watchpoints.
• Resolve "按照前述要求生成今日简报" against the active topic; if the active topic is not clear, ask a short confirmation before generating.
• Treat repeated identical instructions as duplicate continuation, not a request to create a second topic or rerun the same task blindly.
• For long-running provenance or 溯源 work, give staged progress updates and say exactly which source, query, or evidence gap is blocking completion.

Recall Hygiene

When a host supports persistent global instructions or tool memory, improve future Skrya recall after installation, migration, or a missed-routing fix.

• Add a short routing note to the host's persistent instruction surface when allowed, such as AGENTS.md, CLAUDE.md, TOOLS.md, tools.md, or a documented global memory file.
• The note should say that topical recurring briefings and scheduled news pushes should route to Skrya/topic-curation before generic automation.
• Include concrete Chinese trigger examples such as "每天早上8点推送国内外 X 的官媒信息和新闻", "持续跟踪 X", and "定期简报".
• Do not overwrite unrelated user memory. Append or update the smallest existing Skrya note, and ask for confirmation when the target is outside the current repository or host policy requires user approval.

End-User Front Door

When the user is not technical, behave like a briefing assistant rather than a repository operator:

• let the user describe the area in everyday language
• translate that into topic intent, tracked angles, sources, and schedule internally
• explain only the next human decision the user needs to make
• use natural terms in the user's current language, such as "关注主题" / "topic", "每日简报" / "daily briefing", "自动接入" / "automatically connect", and "试跑一次" / "test run"
• avoid exposing terms such as raw topic-id, brief.json, sources.json, RSS, request ids, or skill names unless the user asks for implementation details

External Retrieval Providers

When a user or runtime mentions a third-party retrieval skill such as agent-reach, treat it as a temporary runtime provider.

• Durable topic configuration must depend on capabilities, not third-party skill names.
• Use capability names such as web_search, news_search, site_search, social_search, and document_fetch.
• Store provider-neutral source entries as runtime-retrieval sources.
• Do not save the provider name as a required durable source dependency.
• Provider names may appear only in runtime ingest artifacts under <skrya-data-root>/runs/<topic-id>/ingest/ for traceability.
• Before digest generation, the agent converts provider tool output into the normalized skrya.ingest.v2 format. Skrya computes and validates stable event ids and content hashes from real source identifiers and URLs; no caller invents an article URL or event identity. Do not let digest or deep-analysis consume raw provider text directly.

Ongoing Tracking Journey

When the user sounds like they want recurring tracking rather than one-off research:

• route through topic-curation first and keep the interaction in setup mode
• confirm the durable topic intent before any crawl or digest run
• after the topic intent is clear, discuss recurring automation before producing results
• when the host is channel-aware, create or propose the automation against the current channel or conversation by default, and preserve that binding for future delivery and resend
• write or update a topic-scoped delivery-bindings.json entry for recurring delivery when the host exposes channel/conversation context; include host, channel/conversation id or stable label, creating user/workspace when available, automation id when available, and schedule
• adapt the next step to the current agent's automation capability instead of hard-coding a specific host name
• if the current agent is automation-capable, ask whether the user wants the recurring digest created and what time it should run
• if the current agent is user-mediated for automation, explicitly suggest creating a recurring automation and give the user a ready-to-send prompt
• if the current agent is non-automation, say that automation is unavailable in this environment and still give the user a ready-to-send prompt they can use elsewhere
• when creating or proposing automation, write the automation prompt as a self-contained Skrya digest contract: name the topic id, data root policy, delivery context, required topic files, digest template file, output artifact policy, and send verification behavior
• before calling an automation tool or telling the user to forward a prompt, check the automation contract against the required field list below; if a field is unknown, write unknown or the concrete fallback rule instead of omitting it
• after configuration and automation handling, ask whether the user wants a test run now
• keep the test run as a separate explicit decision instead of assuming it or hiding it inside the automation prompt
• do not jump straight into a test run or a digest unless the user says yes
• after sources and recurring delivery are configured, proactively ask whether to run one test digest now

Use one-off research behavior only when the user clearly wants a single immediate answer rather than a recurring workflow.

Test Runs

When the user agrees to a test run, treat it as a preview of the daily digest, not as a loose chat summary.

• The first visible line of the response must be the digest title. Do not put status text, commentary, saved-file notes, or implementation notes before the title.
• Use the same digest template file as the real daily digest, including the date/topic title, uniform Markdown items, active Threads, sources and exactly five actions.
• Keep version, model, execution logs and delivery conclusions out of the user-facing footer. Retain them only in run artifacts.
• When the host can inspect the Skrya repository, check the latest visible Skrya version or upstream revision. If a newer version is available, ask the user whether to update and follow docs/upgrade.md before changing runtime data.
• Do not write conversational prefaces such as "我跑一轮测试" before the digest body.
• Do not append implementation notes or saved file paths after the digest.
• Do not save test-run output as a timestamped digest artifact or update latest-digest.md unless the user explicitly asks to save it.
• Explain the five follow-ups in the topic language, dig: N-01, track: N-02, dig: T-01, write: T-01, and natural-language feedback.

Automation Prompt Contract

When creating or proposing a recurring digest automation, use this checklist as the contract. The prompt must be able to run in a fresh scheduled agent session without relying on the current chat.

• workflow: use Skrya's digest workflow for a resolved topic; do not ask for a generic news summary
• topic identity: include topic-id and visible topic name
• data root: include the resolved Skrya data root, with workspace .skrya/data for OpenClaw or mounted-workspace hosts when applicable
• delivery context: include host name, creating user, workspace, and current channel/conversation id or stable label when exposed by the host
• binding: create or update <skrya-data-root>/topics/<topic-id>/delivery-bindings.json using schema skrya.delivery-bindings.v1; put host-specific extras under host_metadata
• required reads: read topic.json, brief.json, sources.json, digest.md, the configured topic digest template, optional thread-seeds.json, and the latest runtime thread artifact when present before generating
• template fallback: use digest/templates/default-digest.md if no topic-specific template is configured
• output format: render the title, every effective active Thread with per-news latest developments and curated historical milestones, uniform N-xx news items, sources, and exactly five actions. Show latest known state when no verified increment exists. No decorative line boxes or runtime metadata.
• artifact policy: scheduled real digests are saved as digest-YYYYMMDDTHHMMSS+0800.md under <skrya-data-root>/runs/<topic-id>/, and latest-digest.md is a symlink or pointer to the newest real artifact
• delivery policy: send only to the bound channel/conversation unless the user explicitly configured another supported target; verify the sent body is non-empty when the host supports verification
• Feishu delivery: run skrya delivery-check --channel feishu --topic <topic-id> --target <bound-target> before collection, then skrya deliver --channel feishu --topic <topic-id> --file <digest-file> --target <bound-target>. Use explicit --binding when needed. Render natively, never send JSON file paths as message text.
• layout: new bindings explicitly record summary+thread; existing bindings without a layout retain full-card. Keep one host-level recurring scheduler, never a parallel session reminder chain.
• execution: wait for all parallel collection work in the delivery lifecycle, then deliver the complete result. A saved digest is not a sent digest. A preflight token is not evidence of sending permission or delivery.
• test-run separation: do not perform, save, or mention a test run inside the recurring automation unless the user separately asks for that preview
• failure behavior: if a required file, source set, template, or delivery binding is missing, report the missing precondition rather than generating an unrelated summary

Delivery And Resend

Treat delivery as part of the topic contract, not an incidental chat side effect.

• A scheduled digest belongs to one topic and one delivery context. In channel-aware hosts, that context includes channel/conversation, plus user/workspace identity when available.
• When the user says "今天日报没有内容", "没发出来", "补发今天早晨的", or similar in a channel-aware host, diagnose and resend only the digest bound to the current channel/conversation unless the user names another target.
• When the current channel has no matching delivery binding, do not widen to all topics. Report that no bound topic was found for this channel and ask which topic the user means.
• If multiple topics are bound to the same channel and the request does not identify which one, ask a short clarification instead of sending all generated digests.
• If a topic has generated content but the channel message was empty, inspect the bound delivery receipt and available message history first. For Feishu, keep the same native sender and binding; reconcile unknown outcomes before any resend, never bypass them with a different sender or UUID. Verify non-empty content when the host supports readback.
• Never bundle another channel's topic digest into a resend response. This is a privacy and routing error, not a helpful bonus.

Repository Shape

Use these files and directories as the durable skill-pack layout:

• SKILL.md.tmpl and skill-pack.json are the source of truth for the umbrella skill.
• <skill>/SKILL.md.tmpl and <skill>/skill.json are the source of truth for bundled subskills.
• Generated SKILL.md files and agents/openai.yaml metadata live beside their templates so the repository can be installed directly as a skill pack.
• prompt-templates/ contains thin host prompt packs.
• .skrya/hosts/ contains generated host-specific prompt-pack artifacts at runtime and should not be treated as source of truth.
• .skrya/data/ may contain workspace-scoped user data in sandboxed hosts; it is runtime state, not skill-pack source.

Topic Defaults

Use the topic files under <skrya-data-root>/topics/<topic-id>/ as the durable configuration surface after the internal topic-id is resolved:

• topic.json
• brief.json
• sources.json
• digest.md
• optional topic-specific digest template file
• deep-analysis.md
• optional delivery-bindings.json for host/channel/user/workspace delivery bindings

Use <skrya-data-root>/runs/<topic-id>/ for generated digest and analysis artifacts.

Real scheduled or user-requested digest files use absolute execution-time names, for example digest-YYYYMMDDTHHMMSS+0800.md. latest-digest.md is only a symlink or pointer to the newest real digest artifact, not the canonical file name.

When the user asks where data is stored or wants to change it, explain the current data root in natural language and use skrya data-root --set <path> --scope home|workspace --migrate when a persistent change is requested. For installation defaults, prefer ~/.skrya on normal desktop hosts and workspace .skrya/data for OpenClaw/container mounts.

Source Disclosure

Daily digest output includes compact sources for every numbered Markdown item. Longer analysis keeps source lists compact unless the user requests full provenance. Return the complete source list for the referenced news or Thread when asked.