boundary

---
name: boundary
description: Discover important ideas outside a user's usual fields through source-checked knowledge cards and optional deep research. Use for today's boundary, cross-domain learning, escaping an information bubble, or explicit random exploration. Also handle 已知道, 新知识, 深入了解, 暂时跳过, known, new, deep dive, and skip when replying to a Boundary card. Do not use for ordinary factual questions or unrelated uses of the word boundary.
license: MIT
compatibility: Requires Python 3.10+, an IANA timezone database, local file and shell access, and an agent able to search the web and open sources.
---

# Boundary

Deliver one verified, worthwhile encounter with the wider world. In the default `boundary` mode, optimize first for importance, transferability, and durable understanding; use unfamiliarity to find a real blind spot, and treat novelty as a tie-breaker rather than the goal.

## Choose the delivery environment

This installed skill uses the local CLI for persistent files. For ChatGPT Scheduled without local shell/file access, use the [self-contained task adapter](integrations/chatgpt/README.md), not local setup commands. Both use [the shared quality standard](references/quality-rubric.md); the adapter only changes the host-specific delivery and storage boundary.

## Selection objective

Boundary is a high-value blind-spot system, not a rarity detector. Seek the nearest valuable frontier: a concept, mechanism, institution, consensus, or consequential case that the user may not know and that improves how they understand or decide something.

Unknownness is necessary but insufficient. If a topic is unfamiliar but its value is mainly that it is obscure, amusing, or surprising, reject it. A canonical idea from another field is often a better boundary card than a rare fact from a distant field.

For every candidate, answer in one sentence: "After learning this, what will the reader understand or judge better?" If there is no concrete answer, do not select the candidate. Apply the complete quality gate in [references/domains.md](references/domains.md).

## Load only what the task needs

- Read [references/quality-rubric.md](references/quality-rubric.md) before researching or writing; it defines usefulness, evidence review, and depth for both delivery environments.
- Read [references/domains.md](references/domains.md) before selecting a topic.
- Use [references/source-map.md](references/source-map.md) when you need reliable starting points; open the relevant underlying material, not just the directory page.
- Read [references/source-policy.md](references/source-policy.md) before researching or citing.
- Read [references/output-formats.md](references/output-formats.md) before drafting a card or report.
- Read [references/storage.md](references/storage.md) when configuring the save folder or writing notes.

## First run

Confirm that Python 3.10+, local file/shell access, web search, and source-opening tools are available. If research tools are missing or blocked, explain the blocker; do not substitute a memory-only card or claim it was verified. Saved cards remain available for review.

Resolve this skill's directory as `SKILL_DIR`. Run `context` first to locate existing configuration. A missing configuration starts setup; invalid JSON or a missing configured root requires repair, not a fresh initialization.

For a new setup, reuse choices already supplied in the current request. Default to the current language (`zh` or `en`) and `boundary` mode, and briefly state those defaults. Ask only for the missing absolute save folder; combine any genuinely unresolved language or mode choice in that same exchange. Use `wander` for explicitly requested random exploration, or `alternate` if chosen by the user. All files are ordinary Markdown and JSON.

Do not ask for interests, administer a knowledge test, inspect unrelated conversations, or infer a personal profile. Do not create a schedule during setup unless the user explicitly asks for daily delivery.

Once the destination is chosen, initialize local state:

```bash
python3 "$SKILL_DIR/scripts/state.py" init \
  --root "/absolute/path/chosen/by/user" \
  --language zh \
  --mode boundary
```

Use `--config` **before** the subcommand when the runtime or user requires a non-default path, for example `python3 "$SKILL_DIR/scripts/state.py" --config "/absolute/config.json" context`. Pass the same path on subsequent commands. Never overwrite an existing configuration. See [storage and recovery](references/storage.md) when setup fails.

Change the saved language or default mode without rebuilding history:

```bash
python3 "$SKILL_DIR/scripts/state.py" configure --language en --mode alternate
```

If the user intentionally moves the Boundary folder, relink only to a path that already contains `_system/state.json`:

```bash
python3 "$SKILL_DIR/scripts/state.py" configure --root "/new/absolute/path"
```

## Daily card workflow

1. Load context:

   ```bash
   python3 "$SKILL_DIR/scripts/state.py" context
   ```

2. Resolve the mode. For an interactive run, honor the user's current choice. For scheduled delivery, use the saved default. `alternate` switches between `boundary` and `wander`; do not silently use `wander` merely because a domain is undercovered.
3. Use the script to get a primary domain hint:

   ```bash
   python3 "$SKILL_DIR/scripts/state.py" pick --mode default
   ```

   Use `--mode wander` or `--mode boundary` for an explicit one-off choice; `default` uses the saved setting. Do not change the saved preference unless asked. Treat the returned domain as a mild diversity hint, not a mandate. If it produces no candidate that passes the quality gate, pick again or use another domain.

4. Generate 3 candidate topics. Start with the hinted domain, but compare candidates from another domain when that is needed to find a stronger topic. Apply the selected mode's rules from `domains.md`. In `boundary` mode, prefer field-core concepts, widely supported ideas, reusable mechanisms, important institutions, and consequential everyday knowledge. Compare candidates by importance and transferability first, then explicit relevance, durability, unfamiliarity, connection, and novelty. Reject semantic repeats, topics in skip cooldown, weak trivia, and topics without adequate sources. If no candidate clears the importance floor, do not fill the slot; choose a different domain or generate a new set.
5. Research before writing. Never publish a card from model memory alone. Follow `source-policy.md`, open the underlying sources, and prepare the structured source metadata required by `output-formats.md`.
6. Draft exactly one direct-reading card using `output-formats.md`. Do not require a guess or quiz. Include a concrete example, a usable takeaway, and where the idea stops applying, following the shared quality standard. Check that the central question is answered, important claims have inline support from opened sources, source organizations are independent, and terminology is explained. Correct the draft before saving; do not show the internal review. Write the exact delivered Markdown and structured sources to temporary files inside `<boundary-root>/_system/tmp/`. The script validates metadata and lifecycle, not factual accuracy; that remains your responsibility.
7. Persist the complete card as `shown` before delivering it:

   ```bash
   python3 "$SKILL_DIR/scripts/state.py" record \
     --title "..." --slug "..." \
     --question "One central explanatory question" \
     --summary "One-line central explanatory payload" \
     --topic-key "stable-topic-key" \
     --domain history-archaeology \
     --domain philosophy-religion-ethics \
     --region "southern-africa" \
     --mode boundary \
     --body "<boundary-root>/_system/tmp/card.md" \
     --sources "<boundary-root>/_system/tmp/card-sources.json"
   ```

   Pass the primary domain first, followed by every applicable secondary domain. Add every applicable geographic or knowledge-tradition region. Reuse the same `topic-key` for the same central explanatory payload even when the title changes. The command saves the full card under `_system/pending/` and returns its stable `id`.

8. Deliver the saved card, ending with exactly four responses: `已知道 / 新知识 / 深入了解 / 暂时跳过` or `Known / New / Deep dive / Skip`. If saving fails, report the error and do not claim the card was saved or recorded.

Remove the temporary input files after `record` succeeds. If the user asks for another card, repeat the workflow with full source quality. Do not impose a daily hard limit. If the user opens Boundary again on the same day, use `context.active` and `context.today` to mention existing cards and offer review, deep dive, or a new card.

## Process feedback

Use the stable card `id` returned by `record`, or locate it in `context` after a restart. If multiple cards could match an ambiguous reply, ask which one; never guess an ID. Known/New/Skip apply only to a pending (`shown`) card:

```bash
python3 "$SKILL_DIR/scripts/state.py" feedback --id "..." --value new
```

Map responses as follows:

- `known`: finalize the pending card under `Cards/` and append it to the index.
- `new`: finalize the pending card, append it to the index, and count the shown domain and regions as coverage.
- `deep`: finalize the pending card and index, then produce exactly one deep research report (see "Deep dive" below). Never interpret `deep`/`深入了解` as anything less than the full in-depth report.
- `skipped`: delete the pending body, create no formal note, and retain only transparent metadata for the seven-day topic cooldown and domain weighting. If the user skipped because the topic was too obscure, too specialized, or not useful, treat that as feedback on the topic—not evidence that the entire domain is unwanted.

`feedback` performs the card and index writes. Do not recreate those files manually. Feedback is final for that shown card. For `deep` feedback already recorded but no report attached, resume the report from `context.pending_reports` without calling `feedback` again. If a report already exists, open it; do not overwrite it. A request to research an already accepted Known/New card is a separate research request and must not rewrite its finalized feedback.

## Deep dive

`Deep dive`/`深入了解` is the single deepening path, and it goes all the way down. It produces one complete, in-depth research report — there is no intermediate brief and no further "choose your depth" step afterward.

1. Use the central research question already stored with the card. A simple `Deep dive` requires no further question or depth choice. If the user explicitly supplies a different question, use it and pass `--question "..."` when attaching the report.
2. Research fresh for this level, following `source-policy.md`. At least three strong, independent sources are required; use more when the question demands it. Save the exact report Markdown and its structured sources to temporary files.
3. Write the report using the deep research report format in `output-formats.md`. It must be comprehensive in depth but written in plain, accessible language — like a long-form explainer for a curious reader, not a journal article. It must be readable on its own, without the card.
4. Review evidence and readability against `output-formats.md`, then attach it:

   ```bash
   python3 "$SKILL_DIR/scripts/state.py" deep \
     --id "..." \
     --body "<boundary-root>/_system/tmp/deep-report.md" \
     --sources "<boundary-root>/_system/tmp/deep-report-sources.json"
   ```

   This creates `Reports/<slug>-deep-research.md` and links it back to the card. Remove the temporary input files after success.

5. Deliver the report without another action menu. A deep dive never spawns an automatic follow-up. If research is interrupted, keep the accepted card and resume the missing report later; do not invent a placeholder report to complete the workflow.

Each level requires fresh source verification. For academic, medical, financial, legal, and contested subjects, apply the domain-specific rules in `source-policy.md`. Never provide personal diagnosis, individualized legal advice, or direct buy/sell instructions.

## Language behavior

- Support Chinese and English equally.
- Follow the configured language unless the user switches explicitly.
- Preserve original source titles; add a translated title only when helpful.
- Keep the evidence standard identical across languages.
- Search beyond the output language when better primary sources exist.

## Delivery boundary

Boundary owns topic selection, research, generation, feedback, history, and notes. A scheduler owns timing. Create, change, pause, or resume an automated daily task only when the user explicitly requests it. Let the user choose manual use, daily delivery, or both, plus a fixed or alternating selection mode. The normal default is high-value `boundary` mode; use `wander` only when the user explicitly requests random exploration or has explicitly configured `alternate`.

## Non-goals

- Do not become a daily news or social-media trends digest.
- Do not optimize selections only for the user's likes.
- Do not optimize for rarity, shock value, or maximum novelty.
- Do not force an under-covered domain when it has no important candidate.
- Do not permanently block a knowledge domain.
- Do not build political, religious, medical, financial, or personality profiles.
- Do not upload the learning history or require an external storage service.
- Do not rely on a specific notes app, plugin, or vault; every saved file is plain Markdown or JSON.
- Do not fabricate citations, quotations, dates, consensus, or false balance.