topic-curation

name	topic-curation
description	Use when the user wants to create a new topic, adjust an existing topic, refine what kinds of brief items matter, exclude certain kinds of items, update topic sources, or schedule recurring topic briefings through natural language. Trigger for Chinese requests like "持续跟踪", "以后每天帮我看", "每天早上8点推送", "官媒信息和新闻", "定期简报", or "帮我关注这个领域".

Topic Curation

Handle the full user journey for creating or iterating a topic through natural language.

This skill is the single entry point for topic configuration work. If the user asks for "important information" about some not-yet-configured area, treat that as a topic-curation request first, not as a direct digest request. This includes requests about some company, industry, market, product category, or theme that is not yet configured as a topic. This also includes scheduled news push requests such as "每天早上8点推送国内外 X 的官媒信息和新闻"; the schedule is only one part of the topic setup, not a reason to bypass Skrya with a generic reminder. Before reading or writing topic files, resolve the Skrya data root. Topic configuration and generated artifacts live under <skrya-data-root>/, not necessarily under the skill repository.

Read First

For a known topic, read:

• <skrya-data-root>/topics/<topic-id>/topic.json
• <skrya-data-root>/topics/<topic-id>/brief.json
• <skrya-data-root>/topics/<topic-id>/sources.json
• <skrya-data-root>/topics/<topic-id>/digest.md
• <skrya-data-root>/topics/<topic-id>/thread-seeds.json when continuing threads are relevant

For a new topic idea with no confirmed topic-id yet:

• read AGENTS.md, CLAUDE.md, or the equivalent repository instruction file
• inspect <skrya-data-root>/topics/ to avoid collisions and to follow existing naming patterns

Also inherit applicable workspace defaults from the repository instruction file.

User-Facing Topic Names

Topic-scoped work must resolve an internal topic-id before reading or writing files, but do not ask nontechnical users for raw topic-id values. Ask for the plain-language topic name or describe the inferred topic back to the user, then map it to an existing topic or propose a new internal id yourself. Only show the internal id when it helps confirm a newly created durable topic, and label it as an internal name.

Core Rule

First clarify the durable briefing intent the user wants to keep seeing, then translate that into stable configuration language. Confirm the proposed wording before creating or changing topic files. For recurring delivery, also preserve the delivery context the host exposes. In channel-aware hosts, that includes the creating user and current channel or conversation. For channel-aware hosts, write delivery context into topic state as delivery-bindings.json; do not rely on the scheduled message appearing in the later chat session. Do not ask for or set a language during installation. For each topic, set topic.json.language from the user's topic-creation language unless the user explicitly requests another briefing language. Skrya currently supports Chinese and English output; the schema may remain extensible for future languages. The topic language controls digest and deep-analysis output. If the user later gives feedback in another language, converse in the feedback language while preserving the topic's configured output language unless the user asks to change it.

Do not make the user speak in config format. Do not create a new topic shell before the briefing intent is clear enough. Do not answer a broad unconfigured-topic info request with a direct digest first. Do not jump straight into running a digest when the user appears to want ongoing tracking.

Tracking vs One-Off

Separate these two cases early:

• ongoing tracking: the user wants recurring updates, a standing brief, or durable monitoring
• one-off research: the user wants one immediate answer right now and does not need a standing topic

If the request is ambiguous, prefer treating it as ongoing tracking first and clarify from there. Phrases like "collect updates", "follow", "track", "keep me posted", and "regularly" should push you toward ongoing tracking. Chinese schedule phrases like "每天早上8点推送", "每天定时发", and "每天提醒我看" should also push you toward ongoing tracking when they include a topical news or information area. Treat source/scope phrases such as "国内外", "官媒", "官方来源", "信息和新闻", and "过去24小时" as durable topic configuration requirements.

For ongoing tracking, keep the conversation in setup mode until topic intent is confirmed, source candidates are confirmed or known adequate, automation is handled, and the user chooses whether to do a test run.

What This Skill Owns

This skill may:

• help the user create a new topic
• help the user refine an existing topic
• translate user feedback into durable configuration wording
• update brief.json
• update digest.md when ranking or exclusion rules need to change
• propose or update thread seeds when the user wants a continuing thread
• recommend source candidates and update sources.json after confirmation
• answer and update the user's storage-location preference by using the current Skrya data root and the skrya data-root command
• create or propose recurring digest automation bound to the current channel/conversation by default when the host is channel-aware

This skill does not implement crawling or adapter logic.

Topic Memory Rules

Conversation context should become maintainable topic state.

• If the user gives ambiguous shorthand entities, clarify once, then store the stable entity name, aliases, relationship, and watchpoints.
• If the user says "这个很重要", rewrite it as a durable tracked angle, thread watchpoint, or ranking preference.
• If the user says "按照前述要求生成今日简报", resolve the active topic from the conversation and current topic files; if more than one active topic is plausible, ask a short confirmation.
• Treat repeated identical instructions as continuation or emphasis, not as a second topic creation request.
• For B-style digest feedback such as B <numbers> <name/intent>, propose a thread seed with a stable name, aliases, match terms, summary, callback hint, and watchpoints.

Source Feasibility Rule

• internally, sources with RSS are connectable
• internally, sources without RSS are not connectable for now
• user-facing wording should say whether a source can be "自动接入" or is "暂时不能自动接入"; do not make the user reason about RSS
• runtime search/fetch channels should be written as provider-neutral runtime-retrieval capability sources rather than third-party skill names

Intent Types

Map natural-language user input into one or more of these intent types:

• new topic creation
• add a new tracked angle
• narrow topic scope
• exclude a kind of item from future digests
• adjust ranking preference
• update topic sources
• ask for important information on an unconfigured area

Never treat a single digest item number as a literal config primitive. Infer the underlying preference and rewrite that into stable configuration language.

Required Behavior

1. Decide whether this is a new topic or an iteration of an existing topic.
2. If it is a new topic, clarify the user's briefing intent before creating any files.
3. If it is an existing topic, read the current config and interpret the user's request as a change to that config.
4. Translate the user's words into durable configuration text.
5. Show the user the proposed config change in concise natural Chinese.
6. Ask for confirmation before writing any file.
7. After confirmation, create or update the minimum necessary files.
8. Only discuss sources after the topic intent is clear enough to guide source choice.
9. After the user confirms a new or expanded topic's scope and standards, propose concrete source candidates before saying the topic is connected.
10. When recommending sources, explain fit in terms of the confirmed topic intent and say which ones can be 自动接入 versus 暂时不能自动接入.
11. Include the relevant retrieval/source channels available in the current environment, such as web/news search, X, WeChat official accounts, site search, document fetch, or configured source skills.
12. Confirm source additions or removals before writing sources.json.
13. Do not create or update recurring digest automation until the source plan is confirmed, unless the topic already has adequate confirmed sources and the user is only changing ranking or scope.
14. If the user wants ongoing tracking, discuss recurring digest automation before producing any digest output.
15. After sources and recurring delivery are configured, proactively ask whether the user wants a test run instead of waiting for the user to ask.
16. When clarifying a new recurring topic, include a compact setup boundary: topic scope is confirmed first, sources are confirmed next, automation/schedule is handled only after source confirmation, and the test run remains a separate yes/no decision.

Automation Behavior

For ongoing tracking, a recurring digest is the default target experience.

• First classify the current agent into one of these capability modes:
  • automation-capable: the agent can create or update automation itself after user confirmation
  • user-mediated: the agent cannot create automation autonomously here, but can guide the user with a ready-to-send prompt
  • non-automation: the agent has no usable automation path in the current environment
• In automation-capable mode, ask whether the user wants the recurring digest created and what time it should run.
• In channel-aware hosts, bind the recurring digest to the current channel/conversation by default and keep the creating user/workspace identity when available.
• For channel-aware hosts, write or update delivery-bindings.json before treating the automation as configured.
• In hosts without channel/conversation concepts, do not invent a channel boundary; rely on topic identity, user intent, and available automation context.
• Do not configure cross-channel delivery unless the user explicitly requests it and the host supports that target. In OpenClaw-style channel-aware environments, avoid cross-channel delivery by default.
• In user-mediated mode, explicitly suggest the recurring automation step and give the user a ready-to-send prompt.
• In non-automation mode, say clearly that automation is unavailable in this environment and still provide a ready-to-send prompt the user can use in a more capable agent later.
• After the automation step is settled, ask separately whether the user wants a test run now.
• Do not hide the test run decision inside the automation prompt.
• Do not assume the user wants a test run.
• Do not present collected results in chat as if that replaces the recurring workflow the user asked for.
• Before creating automation or handing the user a prompt, validate that the prompt contains every field in the contract below. If a value is not exposed by the host, include unknown plus the fallback rule instead of silently dropping the field.

Automation Prompt Contract

When creating a recurring digest automation directly, or giving the user a ready-to-send automation prompt, the prompt must be self-contained. Do not rely on the creating chat's transient memory.

Include these fields or instructions:

• workflow: use Skrya and the digest workflow for a resolved topic, not a generic news summary
• topic: resolved topic-id and visible topic name
• data_root: resolved Skrya data root; use workspace .skrya/data for OpenClaw or mounted-workspace environments when applicable
• delivery_context: creating user, workspace, host, and current channel/conversation id or stable label when the host exposes them
• topic_state_binding: create or update <skrya-data-root>/topics/<topic-id>/delivery-bindings.json using schema skrya.delivery-bindings.v1; the automation must not rely on later chat context
• required_reads: topic.json, brief.json, sources.json, digest.md, and the configured digest template file
• template_fallback: use digest/templates/default-digest.md when no topic-specific digest template is configured
• format_contract: digest.md contains ranking and judgment rules; the template file controls title, uniform line boxes, source references, ---, and the topic-language system section
• artifact_policy: save real scheduled digests as digest-YYYYMMDDTHHMMSS+0800.md under <skrya-data-root>/runs/<topic-id>/, then update latest-digest.md as a symlink or pointer
• delivery_policy: send only to the bound channel/conversation unless the user explicitly configured another supported target, and verify non-empty delivery when the host supports it
• test_run_policy: do not perform, save, or include a test run unless the user separately asks for one
• failure_policy: if required topic files, sources, template, or delivery binding are missing, report the missing precondition instead of generating a generic summary

File Strategy

Prefer these write targets:

• topic.json for new topic identity
• brief.json for durable tracking requests
• digest.md for ranking, exclusion, and digest judgment rules
• sources.json for confirmed RSS sources and runtime-retrieval capability sources
• delivery-bindings.json for host/channel/user/workspace bindings and automation ids when the host exposes delivery context

Prefer the smallest config change that matches the user's intent.

Source Confirmation Gate

When the user confirms a new or expanded recurring topic, source confirmation is a required gate before "已接入" or automation creation.

• For a request such as "每天给我一份 BYD、新能源汽车、储能相关简报，主要关注国内外主流媒体内容", first propose source groups that fit those angles.
• When the prompt or host names available retrieval capabilities, produce the source plan now instead of merely listing capabilities or saying a plan will come later.
• Explain source fit in natural Chinese, for example "覆盖比亚迪和车企动态", "覆盖海外主流财经/产业报道", or "覆盖储能项目和政策".
• For each source group, include the group name, why it fits the confirmed topic, the retrieval channel or capability, and status: 自动接入 or 暂时不能自动接入.
• Mark each group or source as 自动接入 or 暂时不能自动接入 under current connector limits.
• If the current environment has configured X, WeChat official account, or other source-channel skills, include them in the source plan and explain what they add compared with generic web/news search.
• Ask the user to confirm the source plan before writing sources.json or claiming the daily task is connected.
• If the existing topic already has enough confirmed sources, say that explicitly and only ask about the new source gaps created by the expansion.
• Do not write placeholder source candidates into durable config.

Conversation Shape

Keep the interaction practical and short:

• accept the user's language as-is
• infer and persist the topic output language from topic creation or explicit user preference
• infer the underlying lasting preference
• rewrite it into config-ready wording
• ask for confirmation
• then write files
• then propose and confirm source candidates when sources are new or expanded
• then handle automation or scheduling after the source plan is confirmed
• then ask whether the user wants a test run now

Delivery Context

For multi-user or multi-channel hosts that expose channel/conversation context, treat the channel as part of the durable automation boundary.

• The topic config describes what to track; the automation binding describes where to deliver it when the host exposes delivery context.
• Store delivery bindings as Skrya-owned normalized JSON in delivery-bindings.json, using schema skrya.delivery-bindings.v1. Do not store raw host or agent context as required core state; put agent-specific extras under host_metadata.
• A topic created from one channel should be delivered back to that same channel unless the user explicitly names another channel and the host supports it.
• A补发 request should resend only the topic bound to the current channel/conversation. If the current channel has multiple plausible topics, ask which one.
• For feedback, empty-digest diagnosis, missed delivery repair, or manual resend, default to current-channel scope. First match the current host/channel/conversation against delivery-bindings.json; do not scan all topics or operate on all topics from the current channel.
• If no matching binding exists, say the current channel has no known Skrya topic binding and ask which topic the user means. Do not send any digest until the binding is resolved or explicitly overridden.
• Do not merge or forward another channel's topic digest into the current channel, even when it was generated at the same scheduled time.
• When the host supports send-result inspection, require explicit sending and non-empty message verification after scheduled delivery.

Recall Hygiene

When this skill is being installed, updated, or used to fix a missed-routing failure, guide the agent to improve persistent recall:

• if the host has AGENTS.md, CLAUDE.md, TOOLS.md, tools.md, or another documented global memory/instruction file, add or update a short Skrya routing note when allowed
• the note should say that topical daily pushes and recurring news briefings route to Skrya/topic-curation before generic reminders or automation
• include concrete examples such as "每天早上8点推送国内外军民融合、军民协同相关的官媒信息和新闻"
• keep the update minimal and ask before writing outside the current repository or into user-level global memory when host rules require it

File names are internal execution details; do not show file names in normal user-facing replies unless the user asks for implementation details.

New Topic Creation

For a new topic:

• do not create the topic immediately after hearing only a broad subject
• first clarify what kinds of brief items the user wants
• once the intent is clear, propose a topic-id, topic name, and initial request set
• after confirmation, create the topic directory and initial files

Existing Topic Iteration

For an existing topic:

• assume the user is expressing a configuration preference, not asking to manually edit raw files
• convert one-off examples into stable rules
• if the user points at a digest item, infer the category or ranking logic behind the complaint