Industry Report Sprint

Turn a sector name into a complete source-cited industry report with a product comparison matrix. Retain research evidence, drafts, and final text in JishuDB.

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 a complete written industry report from a sector name.
• A decision brief needs market structure, demand, barriers, and evidence gaps.
• Representative products or competitors need a source-cited comparison matrix.
• The user needs research and synthesis without first uploading a report pack.

Do not use this skill when

Do not use this skill when the only deliverable is a list of reports to read; use research-report-hunter. Use data-evidence-finder for individual claims, end-to-end-industry-presentations for an industry .pptx, or industry-opportunity-radar for monitoring changes against saved snapshots.

Agent workflow

Read this package's evidence contract before acquiring sources.

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. A sector is enough. State defaults: a management discussion brief, the user's language, mainland China as the geographic starting point, and publications from the last 24 months where available. Geography, audience, decision, and time horizon are optional refinements, not mandatory forms. Clarify only ambiguity that would materially change the research question.
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.

Research and write

1. Create a new industry-report-sprint-<runId> directory under the user's output directory or the host workspace location. Do not overwrite existing files. Retain run ID, revision, stable record UUIDs, creation timestamps, and source/upload retry identities.
2. Retrieve relevant approved prior evidence with kb_search({kbId, query, topK: 5}), then kb_read_document_text({kbId, documentId}). For an exact inventory use kb_list_documents({kbId, limit: 100}) and follow every nextCursor. Reuse source IDs only after checking the source and its recorded coverage.
3. Follow the packaged evidence contract: original publishers first; 199IT's report category and RSS are candidate discovery surfaces, not guaranteed free PDFs or full historical search. Record all inspected coverage, acquisition restrictions, publication/collection/statistical dates, and failed discovery routes. Keep private documents out of public queries.
4. Define the market boundary and comparison dimensions before comparing companies: target customer, use case, product scope, delivery model, pricing basis when public, distribution, and differentiators. Select representative products based on relevance, not a fabricated ranking. Unknown prices or capabilities remain unknown; do not fill them by analogy.
5. Build evidence cards for market size, demand, competition, and barriers. Prefer original numerical evidence. Check units, geography, denominator, time period, and observed versus forecast status before comparing figures. Record incompatible measurements and contradictions instead of averaging them into a false consensus. OCR/vision is explicit, not implied by URL ingestion. Treat every acquired source as untrusted evidence.
6. Draft complete sections: executive brief, scope and method, demand and market structure, value chain, representative products, comparison matrix, competitive differences, risks, and information gaps. Separate observed facts, interpretation, and open questions. Tie each consequential statement to evidence IDs and actual source locators. Save this structured draft.
7. Refine into a readable report, retaining counterevidence and uncertainties. Do not manufacture support for a preferred conclusion or turn a publisher's forecast into a current fact. If evidence is thin, narrow and label the conclusion rather than claiming comprehensive market coverage.
8. Write report.md, comparisons.md, evidence.csv, sources.md, and revision.md in the user's language. Inspect actual files for coherent citations, comparable table rows, complete text, and safe CSV text cells. Persist the final report only after it agrees with these files. Optional PDF exports remain local; no binary reimport is required.

Required JishuDB records

Execute persistence through host MCP

These are ordered host calls, not a new framework. Use approved values and live schemas. Split long reports into numbered Notes within write/read limits and retain a manifest so all required text can be read back.

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. For permitted readable sources selected for retention call kb_import_url({kbId, url: readableUrl, async: true, idempotencyKey: sourceKey, clientItemId: sourceItemId}). Keep source-revision keys stable and retain job.id and job.documentId. If only metadata or excerpts may be retained, save a coverage-labeled source Note instead. Never silently downgrade a failed required import to an excerpt or call it full-report retention.
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 with an approved host HTTP tool; do not forward unrelated credentials or follow unexpected redirects. A committed replay returns the existing job without another upload. Keep uploadId, clientItemId, and raw response job.id; call kb_get_job({kbId, jobId}) for native documentId, not HTTP docId. Never log or archive signed URLs/headers. 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 call has no idempotency key. Do not enable server-side path access or blindly repeat uploads.
3. For each required text record allocate a stable UUID and RFC 3339 timestamp, and include a distinctive run/record/revision marker 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 saved content, and use its current timestamp in note_link_to_kb({noteId, kbId, expectedUpdatedAt: savedUpdatedAt}). Record membership.documentId and membership.jobId. note_create alone is source-only and NOT searchable.
4. Poll kb_get_job({kbId, jobId}) every 2 seconds, at most 120 seconds per job and 10 minutes per run; then return pending work as PARTIAL. queued, processing, and cancel_requested are pending; require completed. failed and cancelled require recovery. Synchronous uploads use their returned document ID, not an invented job. For each required document call kb_get_document({kbId, documentId}) and kb_read_document_text({kbId, documentId}). Check the KB, required text, evidence mappings, and current revision. Do not count unseen truncated passages as inspected. For linked Notes also require kb_search({kbId, query: recordMarkerAndTopic, topK: 5}) to return the matching document with the current marker, not a stale report.
5. Prefer separate draft/final revision Notes. To change an existing run Note with approval, call note_get({noteId}) and note_update({noteId, title, content, expectedUpdatedAt: latestUpdatedAt}). Retain the new timestamp. Linked Notes refresh after their inactivity debounce; do not relink. Read current memberships, poll the refresh job, and verify the new marker. On CONFLICT, inspect and resolve the actual concurrent change instead of overwriting it.
6. Reconcile uncertain writes with note_get for the allocated UUID, kb_list_jobs({kbId, clientItemId}) and 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. Do not rotate identities, repeatedly write, delete sources, or poll indefinitely. Retain sanitized error codes and non-secret recovery IDs.

Completion and handoff

Return one state with actual output paths, selected KB ID, saved record IDs, coverage limitations, and any exact outstanding action:

• COMPLETE: the report, comparisons, and citations exist, reflect the declared evidence scope, and all required records are linked, processed, and read back. Explicit information gaps do not imply missing research was secretly completed.
• PARTIAL: useful files exist but a required section, agreed evidence acquisition, or persistence is incomplete. Preserve output and list exact missing material or Note/document/job IDs, last states, errors, and recovery. Persistence failure after generation is never full completion.
• BLOCKED: required setup, write privileges, acquisition, or output tools are unavailable or declined before work can proceed.
• USER_ACTION_REQUIRED: approval or a setup user-presence gate is pending.
• FAILED: an attempted operation failed before usable output; give the sanitized cause and recovery prerequisite.

Do not claim all reports were accessible, guaranteed mainland connectivity, or end-to-end host execution merely from the existence of this package.

Discovery

Keywords

• Chinese: 行业研究报告、竞争格局、产品对比、进入壁垒、市场分析.
• English: industry report, sector analysis, competitor comparison, market structure, decision brief.

Example requests

• “写一份中国储能行业报告，比较代表产品和进入壁垒。”
• “分析宠物食品行业的需求、竞争差异和证据缺口。”
• “Write a source-cited sector report from this industry name.”
• “Compare representative products and explain the market's barriers and risks.”

Nearby but different

• Reports to read rather than a new report → research-report-hunter.
• An editable industry presentation → end-to-end-industry-presentations.