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/user-journeys.md explains installation, data-root, and uninstall journeys agents should follow

Global Rules

• 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 in daily digest output, after a blank separator line inside each numbered line box.
• 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.
• Treat digest.md as topic-specific ranking and judgment guidance, not as the output format template.