Skrya Workspace Defaults

This workspace is topic-driven.

Topic Rules

• Before the first topic-scoped action, resolve the Skrya data root. If the source is default-home and the user has not already supplied a data location, output only the fixed initialization question from SKILL.md; it must be the sole user-facing response, with no preface or suffix.
• Any topic-scoped task must resolve an explicit internal topic-id before reading or writing files.
• Do not ask nontechnical users for raw topic-id values when a natural topic name can be mapped or confirmed.
• 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/conversation where it was created.
• In channel-aware hosts, scheduled delivery, manual resend, and "why was today's digest empty" diagnosis must use the original topic + channel binding. Do not collect or resend digests from other channels just because they ran in the same time window.
• In channel-aware hosts, the current conversation is the default visibility boundary. Use topic-scoped delivery-bindings.json to match the current host/channel/conversation and creating user/workspace when available before taking action.
• If the current channel has no matching binding, do not scan all topics, send all digests, or repair every automation. Ask which topic the user means or explain the missing binding first.
• 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 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.
• Resolve the Skrya data root before topic-scoped file work.
• By default, topic files and runs live under ~/.skrya.
• For OpenClaw or container sandboxes where the host asks for mounted-workspace state, use <workspace>/.skrya/data.
• Topic files live under <skrya-data-root>/topics/<topic-id>/.
• For topic digest work, default to reading:
  • <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
• For topic deep analysis work, default to reading:
  • <skrya-data-root>/topics/<topic-id>/topic.json
  • <skrya-data-root>/topics/<topic-id>/brief.json
  • <skrya-data-root>/topics/<topic-id>/deep-analysis.md

Data Defaults

• Prefer real data by default.
• Only fall back to sample data when real data is unavailable or the task is explicitly about debugging sample flows.

Output Defaults

• Do not set Skrya output language at installation time.
• Resolve output language per topic from topic.json.language.
• For a new topic, infer the topic output language from the language the user used while creating it, unless the user explicitly requests another briefing language.
• Current supported output languages are Chinese and English. Keep the schema extensible for future languages, but do not claim support beyond Chinese and English.
• Topic language controls digest and deep-analysis output. If the user gives feedback in another language, reply to that feedback in the feedback language without changing the topic output language unless the user asks.
• Show compact source references in default daily digest output.
• Daily digest layout is controlled by a digest template file. Use the configured topic template when present; otherwise use the default template file digest/templates/default-digest.md.
• Treat digest.md as ranking, exclusion, and judgment guidance, not as the output format template.
• Real digest artifacts should use absolute execution-time filenames such as digest-YYYYMMDDTHHMMSS+0800.md; latest-digest.md should be a symlink or pointer to the newest real artifact.
• Do not show internal debug fields, request ids, or implementation metadata in user-facing output.
• Keep enough traceability so complete sources can be returned later if the user asks.

Digest Defaults

• Use the digest skill when the user wants a topic digest or daily briefing.
• Save real scheduled or user-requested digest output under <skrya-data-root>/runs/<topic-id>/ with an absolute execution-time filename, then update latest-digest.md as a symlink or pointer to that artifact.
• When resending or diagnosing a scheduled digest in a channel-aware host, first resolve the topic and channel/conversation binding for the current message. If multiple same-channel topics are plausible, ask a short clarification instead of sending all of them.
• For Feishu, preflight the explicit bound target, then use native card delivery instead of a generic text sender. Verify actual non-empty delivered content when the host permits readback.
• Write uniform plain Markdown items with N-xx references, facts, judgment and media-name source links. Never use decorative line boxes or tab alignment.
• Do not split the first few items into a special format.
• If the effective thread configuration contains any status=active thread, always render ## 事件线时间线更新 (or ## Event Timeline Updates) before normal digest items. Each active thread must show its latest state even when the current scan has no verified increment; never silently omit an active thread under a generic no-update rule.
• When entering a topic-specific digest-template flow, classify create versus update first. Create drafts from the default contract without reading an existing topic template; update reads the configured template and drafts a revision. Tell the user that the active-Thread timeline module is mandatory. The shared save gate starts from the completed candidate, validates before persistence, protects create/update preconditions, and verifies the saved target; failed validation must not create or overwrite the target.
• End with exactly five explained operations: dig: N-01, track: N-02, dig: T-01, write: T-01, and natural-language feedback. Do not add runtime metadata or another follow-up line.

Deep Analysis Defaults

• Use the deep-analysis skill when the user wants to continue from a digest item or asks for a deeper event breakdown.
• Resolve visible references against the replied-to card's frozen snapshot, or the current binding's latest complete successful delivery when no message ID is available. Local non-channel conversations use the explicit digest artifact. Do not substitute the latest generated but unsent digest.
• Keep the analysis natural and concise by default, but be ready to provide complete sources on request.
• write: T-xx reads the complete raw timeline and sources and produces a sourced article draft, never automatic publication.
• Thread history remains append-only and deduplicated with unknown fields preserved. Display only explicitly curated milestones with genuine dates and source URLs. Latest developments retain every real news item separately.
• New Feishu bindings explicitly record summary+thread. Existing bindings without a layout retain full-card. Keep one host-level recurring scheduler, and wait for all parallel work before completing an IM delivery lifecycle.

Topic Curation Defaults

• Use the topic-curation skill 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, or update topic sources through natural language.
• If the user asks for important information, a briefing, news tracking, or regular updates about some company, industry, market, product category, or theme without first naming an existing configured topic-id, route to topic-curation first instead of answering directly.
• If the user asks for scheduled pushes such as "每天早上8点推送", "每天定时发", or "每天提醒我看" about a topical news area, route to topic-curation before using generic reminders or automation tools.
• Treat source/scope phrases such as "国内外", "官媒", "官方来源", "信息和新闻", and "过去24小时" as durable topic requirements, not as plain reminder body text.
• In that case, first clarify the user's crawling or tracking request rather than producing an immediate digest.
• For a new topic, first clarify the user's real briefing intent before creating any topic files.
• Convert the user's natural-language request into stable configuration language, then confirm that wording before writing files.
• Distinguish recurring tracking from one-off research before doing any collection work.
• If the user appears to want recurring tracking, do not satisfy that with a one-off answer in chat.
• After the topic intent is confirmed, prefer proposing or creating recurring automation before any digest output.
• Decide the next step from the current agent's automation capability rather than from a hard-coded host name.
• After the user confirms a new or expanded topic's scope and standards, do not immediately say it is connected. First propose source candidates, explain which can be 自动接入, and ask for explicit source confirmation.
• Source confirmation must include every relevant retrieval/source-channel capability the current environment exposes, such as web/news search, X, WeChat official accounts, site search, document fetch, or configured source skills. Do not limit the plan to generic web/news pools when richer source channels are available.
• 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.
• If the current agent can create automation after confirmation, proactively ask whether to create the daily digest task and what time it should run.
• If the current agent cannot create automation directly but can guide the user, explicitly suggest creating it and give the user a ready-to-send prompt.
• If the current agent has no automation path in the environment, say so clearly and still provide a ready-to-send prompt for a more capable agent.
• Recurring digest automation prompts must be self-contained Skrya digest contracts: include topic id, data root, delivery context, required topic files, digest template file with default fallback, normalized delivery-bindings.json update, timestamped artifact naming, latest-digest.md symlink/pointer behavior, and non-empty delivery verification.
• delivery-bindings.json is Skrya-owned normalized JSON. Do not store raw OpenClaw/Codex/Claude context as core state; put agent-specific fields under host_metadata.
• After configuration and automation handling, ask whether the user wants a test run instead of running the digest automatically.
• Keep the test run as a separate explicit yes/no decision instead of silently bundling it into the automation prompt.
• After sources and recurring delivery are fully configured, proactively ask whether to run one test digest now. Do not wait for the user to discover this option.
• Prefer updating brief.json first. Update digest.md when the user is really changing ranking or exclusion logic rather than adding one more tracked angle.
• Only move into source curation after the topic intent is clear enough to guide source choice.
• Source recommendations should be explained in terms of how well they serve the confirmed topic intent.
• Simplify source feasibility internally to this rule: sources with RSS can be connected, sources without RSS are not connectable for now.
• In user-facing output, describe this as whether a source can be 自动接入 or is 暂时不能自动接入; do not make the user reason about RSS.
• If a source depends on a third-party retrieval skill such as agent-reach, store only provider-neutral runtime retrieval capabilities in durable config, not the third-party skill name.
• Third-party provider names may appear in runtime ingest artifacts under <skrya-data-root>/runs/<topic-id>/ingest/ for traceability.
• Do not write unconfirmed source candidates into sources.json.
• Do not skip straight to digest generation or one-off research when the user's real need is to define a new ongoing tracking topic.
• Do not skip source curation after the user confirms broad requests such as "BYD / 新能源汽车 / 储能，国内外主流媒体优先".

Test Run Defaults

• A test run should render with the same digest template as a real daily digest: title, uniform line boxes, source references, ---, and ## 系统提示.
• Do not prepend chatty status text before the digest body, and do not append implementation notes such as "已写入测试产物".
• Test-run output is for preview and should not be saved as a timestamped digest artifact or update <skrya-data-root>/runs/<topic-id>/latest-digest.md unless the user explicitly asks to save it.
• The ## 系统提示 section must explain follow-up commands in user-readable Chinese, for example A 2 means deep analysis of item 2.

Skill Pack Defaults

• skill-pack.json and SKILL.md.tmpl are the source of truth for the umbrella skrya skill.
• <skill>/skill.json and <skill>/SKILL.md.tmpl are the source of truth for bundled skills.
• Generated SKILL.md files and agents/openai.yaml files are checked in beside their templates so the repository can be installed directly as a skill pack.
• prompt-templates/ is the source of truth for skrya-lite, skrya-full, skrya-plan, and skrya-user.
• .skrya/hosts/ is generated runtime packaging output and is not source of truth.
• .skrya/data/ may be workspace-scoped runtime user data when the host requires it; it is not source of truth for skill-pack code or templates.
• If a task changes skill wording, host packaging, or prompt-pack behavior, update the source templates first, then run python -m skrya_orchestrator.main build-skill-pack --root . --host all.
• When updating Skrya from a newer clone or upstream pull, read docs/upgrade.md and run the documented migrations before declaring the update complete.
• Keep topic-curation as the broad entrypoint for user-facing topic configuration requests.
• Use request-curation for durable brief.json preference changes and source-curation for confirmed sources.json changes after topic intent is clear.

Recall Hygiene Defaults

• When installing, updating, or fixing missed routing for Skrya, improve persistent recall in the host's instruction or tool memory surface when allowed.
• Candidate surfaces include AGENTS.md, CLAUDE.md, TOOLS.md, tools.md, or a documented global memory file.
• Add or update the smallest Skrya note saying that topical recurring briefings and scheduled news pushes route to Skrya/topic-curation before generic automation.
• Include concrete Chinese trigger examples such as "每天早上8点推送国内外 X 的官媒信息和新闻", "持续跟踪 X", and "定期简报".
• Ask before writing outside the current repository or into user-level global memory when host rules require it.