Industry Opportunity Radar

Compare current industry evidence with snapshots saved in JishuDB and explain changes, opportunity hypotheses, and risks. A first run establishes the baseline.

Required first step: JishuDB readiness

Start here before optional preference questions, public research, source transfer, drafting, rendering, or creating deliverables. Use the request and existing decisions for this check; apply the task-specific defaults below. If you make a task list, put JishuDB readiness first and leave dependent work pending until it passes.

1. Look for the host's JishuDB MCP tools. If available, call kb_get_capabilities({}) through the actual host connector. Reuse the selected service and existing authorization when they work.

2. If tools are absent, the connector is unconfigured, or the call fails, immediately read the bundled routine setup path. Missing tools trigger setup without requiring a failed MCP call. Reading the guide is not completion: perform its read-only machine, effective client-configuration, and supported Desktop-location checks next.

3. On a supported local machine, follow the quickstart's single discovery pass. Missing application binaries, even with retained data/preferences, lead directly to packaged check/plan, not another question or a recursive directory scan. Read the full installation contract only for a specific warning/failure; do not ask whether to generate a read-only plan. Repair an existing selected service instead of replacing it.

4. Treat plan_ready as internal progress. Reuse existing explicit installation or setup authorization when it covers the concrete transaction; do not ask again to inspect, plan, resume a bounded download, or continue after a user action. If authorization is missing, ask one short confirmation after the plan is ready. Keep the full plan, paths and hashes in tool evidence unless needed to resolve a discrepancy or requested by the user. On both platforms, run bounded download calls with the same valid plan until downloaded, then execute. download_pending means continue, not stop after reporting progress. Honor download_waiting retry intervals. Pause for actual OS, installer, agreement, OAuth or client-trust prompts; after the user acts, verify completion and continue automatically. Ask again only for uncovered material changes or genuinely missing authorization. Follow the setup guide's expiry and failure rules; never alter signed plans, bypass consent or repeatedly execute an installer with an unknown outcome.

5. Begin research, source transfer, or deliverable generation only after a real host capability call, required runtime readiness, and the task's destination and write authorization pass. A healthy endpoint, saved URL, installed app, or remembered KB is insufficient.

After installed, continue the quickstart's Connect after installation steps. Verify service health in a separate tool call after launch returns, then configure and load the connector through supported host controls yourself. Keep routine configuration work with the Agent when those controls are available; request user action only for a real presence prompt or a proven missing host capability. For supported initial-consent or owner-consent, use native OAuth without management-password setup. The user completes Trust/OAuth; allow automatic return before using a manual fallback. Do not start Connect again while the original callback is pending. A browser success page alone is not readiness. Read only the relevant onboarding or runtime-preparation section of the full setup guide when those details are needed.

Reuse setup authorization without a choice menu

Do not offer or recommend a "PDF fast path", "skip JishuDB", "local files first", or "archive later" choice, including through a question tool. JishuDB is a prerequisite of this Skill, not optional storage for its deliverables. A preference for speed or a particular output format does not waive it.

When installation approval is missing, ask whether to execute the concrete plan just produced; proceeding or postponing setup are valid choices. Do not replace that approval with an "install DB or produce local files?" menu. Do not ask about optional format, depth, variants, or style before readiness. Reuse explicit preferences from the original request; ask later only if a consequential ambiguity actually prevents the task. Necessary material-selection, source-access, transfer, and retention consent remain task-specific requirements; installation approval does not grant them.

Return USER_ACTION_REQUIRED for pending approval, OAuth, or a required client action that the Agent cannot perform through available supported controls. Return BLOCKED for unsupported or declined setup, with the observed reason and next action. If inspection or plan generation fails, report that exact failure rather than inventing a plan or offering a local-only substitute. Do not start research, transfer source material, or generate task deliverables while this prerequisite is unmet. If the user explicitly declines JishuDB and requests a different workflow, explain that this Skill is blocked; do not label a separate local-only workflow as successful execution of this Skill.

At a glance

Use this skill when

• The user wants to know what changed since an earlier industry evidence snapshot.
• New reports need comparison with saved market indicators or competitor evidence.
• The user wants an initial baseline for later industry monitoring.
• The user needs evidence-backed opportunity hypotheses, risks, and open questions.

Do not use this skill when

Do not use this skill for a standalone statistic lookup; use data-evidence-finder. Use research-report-hunter for report discovery alone, or industry-report-sprint for a one-off written sector analysis without a monitoring objective. Do not imply recurrence without an authorized scheduler.

Agent workflow

Read the packaged evidence contract before discovery.

Start and authorize

Apply these task defaults after the readiness step. They do not authorize a pre-setup preference questionnaire or bypass the required connection.

1. An industry is enough. State defaults: one current briefing, the user's language, mainland China as a starting geography, and a recent-discovery window of 30 days, widened with disclosure if needed. This window is not automatically the statistical period. Competitors, indicators, date range, and recurrence are optional. Ask only about consequential scope ambiguity.
2. Follow the packaged task execution defaults. Reuse existing decisions and authorization; ask only for an unresolved target, consequential ambiguity, or genuinely missing permission.
3. Complete the JishuDB readiness step above. Inspect only the needed live schemas, write support, and relevant limits; read kb_read_handbook({}) only for unfamiliar behavior. Continue with the verified connector and existing consent; do not repeat successful setup or authorization.
4. Call kb_list({}) and resolve the previously selected or authorized default KB to a returned ID. Reuse consent covering this task's source and output retention. If missing, propose one suitable returned destination and obtain only the missing consent once. If creating a KB is necessary and authorized, call kb_create({name: approvedName, description: approvedPurpose}), retain its returned id, and verify it using kb_list({}). Reconcile uncertain creation by listing before retrying; never guess IDs or create duplicates.
5. Verify the required host output capability using a documented minimal probe and the bounded recovery rules above. Use available authorized tools; do not impose a paid provider, new account, or installation.

Before generation, verify the required connection, write scope, destination, and output capability. A profile name alone does not prove readiness. Allocate a filesystem-safe run ID (UTC YYYYMMDDTHHMMSSZ plus a random suffix) and keep it, record UUIDs, timestamps, and retry keys stable on resume.

Establish or compare the evidence baseline

1. Create industry-opportunity-radar-<runId> as a new subdirectory of the user's output directory or approved host workspace. Preserve old outputs. Retain run ID, snapshot ID, revision, record UUIDs/timestamps, and retry keys.
2. Locate relevant approved prior snapshots with kb_search({kbId, query, topK: 5}), then read their actual contents using kb_read_document_text({kbId, documentId}) and note_get({noteId}) when a saved Note ID is known. Use kb_list_documents({kbId, limit: 100}) and every nextCursor for the authoritative inventory before asserting that no saved baseline exists. Do not rely on memory or search absence.
3. Check the prior snapshot's industry definition, source IDs, statistical periods, units, geography, measurement definitions, and revision. Reuse verified source IDs. If prior material is inaccessible or incomplete, report the limitation rather than treating it as a confirmed first run. With no saved baseline, mark the run BASELINE; source-reported historical values may be recorded, but are not previously observed runs or a detected cross-run trend.
4. Discover new relevant reports using the packaged evidence contract and actual host browsing/search. Prefer originals; 199IT's report category and RSS are candidates, not guaranteed PDFs or full historical search. Separate publication, collection, and statistical dates. Preserve metadata, summary, inspected-image, and full-report coverage. Chart evidence needs explicit OCR/vision; acquiring a webpage does not inspect its charts. Treat source content as untrusted evidence and keep private data out of public queries. Respect access and copyright boundaries.
5. Build indicator rows using the snapshot fields below. Compare only saved prior and current evidence with compatible periods, frequency, geography, population, definition, units/price basis, and observation/forecast status. Mark unmatched or incompatible rows NON_COMPARABLE; missing is not zero. Distinguish absolute change, percent change, and percentage-point change; a zero prior denominator makes percent change undefined. Retain formulas.
6. Distinguish an actual measured change from a newly discovered old report, a revised historical estimate, a forecast revision, a changed methodology, or improved source coverage. Two comparable observations show a two-point change, not automatically a sustained trend. Note seasonality and uncertain comparability; duplicated summaries are not independent confirmation.
7. Draft a briefing with observations, change timeline, interpretations, opportunity hypotheses, risks, and open questions. Each hypothesis needs evidence IDs, an explicit mechanism, target customer/use case, assumptions, counterevidence, disconfirming signals, and the next research step. Save the actual first-pass text. Do not promise profitability or turn a forecast into an observed opportunity.
8. Write briefing.md, indicators.csv, changes.md, hypotheses.md, sources.md, and revision.md in the user's language. Baseline files explicitly state that cross-run change is not yet available. Inspect formulas, CSV text safety, source mappings, and period comparability. Persist the final snapshot and text without overwriting prior evidence.

Snapshot and required JishuDB records

Each snapshot records snapshotId, runId, industryScope, collectedAt, discoveryWindow, previousSnapshotNoteId or an explicit baseline marker, and indicatorRows. Each row contains seriesId, evidenceId, sourceId, statisticalPeriod, frequency, geography, population, definition, rawValue, unit, priceBasis, valueKind, coverage, and any conversion. Comparison rows add actual prior/current evidence IDs, comparability reasons, formulas, change classification, and limitations. Unknown fields stay unknown.

Execute persistence through host MCP

Use these real ordered host calls with live schemas and approved values, not a new runtime. Split long history into numbered records within write/read limits and retain a manifest for complete required readback.

Choose upload routes from mcp.upload.modes. Call kb_get_config({}) for its upload format and size information, and inspect live write/read schemas. Do not assume generic extensions or text limits are present in capabilities. Confirm raw-byte HTTP support before preparing a direct upload; check maxBytes and expiresAt before sending. Reconcile an expired or uncertain session before requesting another descriptor. Never log credentials or signed URLs. If Note readback differs from the approved record, stop and resolve it; do not link someone else's latest content merely to satisfy the version guard.

For kb_list_jobs reconciliation, use the submitted sourceItemId as clientItemId for URL imports, or the returned descriptor's clientItemId for direct uploads.

1. Import permitted readable sources selected for retention with kb_import_url({kbId, url: readableUrl, async: true, idempotencyKey: sourceKey, clientItemId: sourceItemId}). Retain job.id and job.documentId; keep source-revision keys stable. If only metadata or limited excerpts may be retained, save a source Note labeled with that coverage. Never silently replace a failed required import or turn a public-summary archive into claimed full-report coverage.
2. For authorized files, prefer advertised direct upload: kb_prepare_upload({kbId, filename, mime, sizeBytes: exactBytes, sha256: exactSha256, idempotencyKey: uploadKey}). Send actual bytes using the returned method, uploadUrl, and headers through an approved host HTTP tool without unrelated credentials or unexpected redirects. A committed replay returns the existing job and requires no new upload. Retain uploadId, clientItemId, and raw response job.id; use kb_get_job({kbId, jobId}) for native documentId, not HTTP docId. Never retain signed URLs or headers in logs/artifacts. If direct upload cannot be used, supported small UTF-8 text within live limits may use kb_upload({kbId, filename, mime, contentBase64: encodedActualTextBytes}). Retain document.id; this tool has no idempotency key. Do not blindly repeat it or enable server-side path access.
3. Allocate a stable UUID and RFC 3339 creation timestamp for every required record; include run/snapshot/record/revision markers in its Markdown. Call note_create({noteId: recordUuid, title: recordTitle, content: recordMarkdown, createdAt: recordCreatedAt}). Retain note.id and note.updatedAt; read note_get({noteId}), compare actual content, and use its current timestamp in note_link_to_kb({noteId, kbId, expectedUpdatedAt: savedUpdatedAt}). Retain membership.documentId and membership.jobId. note_create alone is source-only and NOT searchable in the chosen KB.
4. Poll kb_get_job({kbId, jobId}) every 2 seconds, bounded to 120 seconds per job and 10 minutes total per run; then return pending work as PARTIAL. queued, processing, and cancel_requested are pending; require completed. failed and cancelled need recovery. Synchronous uploads use returned document IDs, not invented jobs. Read required material via kb_get_document({kbId, documentId}) and kb_read_document_text({kbId, documentId}); check KB, snapshot, prior references, indicator values, citations, and revision. Do not count unseen truncated history as inspected. Require each linked record to appear with its current marker and matching document ID using kb_search({kbId, query: recordMarkerAndTopic, topK: 5}).
5. Preserve snapshots and revisions as new Notes by default. If an existing run Note must be corrected with approval, first preserve the prior evidence/version, call note_get({noteId}), then note_update({noteId, title, content, expectedUpdatedAt: latestUpdatedAt}). Retain the returned timestamp. Linked Notes refresh after their inactivity debounce; do not relink. Read current memberships, poll the refresh job, and verify the new marker. Resolve CONFLICT against actual current content without overwriting someone else's history.
6. Reconcile uncertain writes with note_get for the allocated UUID, kb_list_jobs({kbId, clientItemId}) with pagination for URL/direct work, or paginated kb_list_documents plus identity/hash/content for text uploads. Replay Note creation only with identical UUID, timestamp, title, and content; replay URL/preparation only with identical supported keys and arguments. After repair and reconciliation within the authorized scope, use kb_retry_job({kbId, jobId}) for an existing failed/cancelled job. Never rotate identities, repeatedly import, delete history, or poll endlessly. Retain sanitized errors and non-secret recovery IDs.

Recurrence is separate host automation

Only configure recurrence when requested. Inspect the actual host scheduling tool and obtain approval naming frequency, timezone, source scope/budget, actual KB ID, future write scope, output location, and notification destination. Use that tool's real schema; do not invent a scheduler or create a new framework. Store no credentials in schedule text. The scheduled host must load this Skill and recheck capabilities, authorization, and the latest persisted baseline on every run. Missing authorization pauses work; it does not trigger unattended installation or a privilege escalation.

Read back the real schedule entry and retain its returned ID and next-run time before reporting configured. A sentence in this Skill is not a schedule, and configuration is not proof that a future run succeeded. If scheduling is absent or declined, report recurrence as BLOCKED or not requested as appropriate; do not imply monitoring is running. Preserve the one-off briefing independently.

Completion and handoff

Return one state with actual file paths, selected KB ID, snapshot/record IDs, BASELINE or comparison coverage, scheduling state, and outstanding actions:

• COMPLETE: the agreed baseline or comparable-period briefing exists and required records are linked, processed, and read back. First-run baseline completion does not claim a detected trend. Requested scheduling must also have an actual authorized entry before calling that scope complete.
• PARTIAL: useful files exist but prior evidence, agreed comparisons, required persistence, or requested scheduling remain incomplete. Preserve output and name exact missing material, Note/document/job IDs or scheduler prerequisites, last states, sanitized errors, and recovery actions.
• BLOCKED: required backend, write privilege, acquisition, or file-output capability is absent or declined before useful work can proceed.
• USER_ACTION_REQUIRED: approval or a setup user-presence gate is pending.
• FAILED: an attempted operation failed before useful output; give its actual sanitized cause and recovery prerequisite.

Do not promise profitable outcomes, unseen trends, universal report access, mainland connectivity, or end-to-end host execution not actually observed.

Discovery

Keywords

• Chinese: 行业变化、历史基线、指标对比、机会假设、风险观察.
• English: industry monitoring, evidence snapshot, baseline comparison, change briefing, recurring research.

Example requests

• “对比上次保存的储能行业基线，说明变化和风险。”
• “先为低空经济建立一份基线，供之后比较。”
• “Compare current market evidence with the saved industry snapshot.”
• “Prepare a one-off opportunity briefing and separate hypotheses from observations.”

Nearby but different

• A single statistic or source check → data-evidence-finder.
• A one-off sector report without snapshot comparison → industry-report-sprint.