Token导航 LogoToken导航TokenDH.com
研究检索只读clawhub未标认证来源可访问clear审计通过

market-intel-briefing市场情报简报

Agent Skill

market-intel-briefing 用于查找、检索和筛选相关信息,适合在 OpenClaw 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

2,840

周安装

116

GitHub Stars

公开资料未说明

下载量

909
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:market-intel-briefing(市场情报简报)
来源仓库:https://github.com/gitcanadabrett/market-intel-briefing
安装命令:
openclaw skills install market-intel-briefing
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install market-intel-briefing

简介

构建针对特定主题或公司的精益市场情报简报。适用宿主包括 OpenClaw,接入前应确认版本、权限和运行环境要求。

  • 适用于高管决策支持或专项研究项目快速出成果。
  • 支持多公司对比、管辖区分析与利基市场聚焦。
  • 建议在使用前定义清晰的研究边界与来源优先级。
  • market-intel-briefing 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

name
market-intel-briefing
description
Build lean, source-linked, decision-ready market intelligence briefs for a niche, competitor set, company set, jurisdiction comparison, or market theme. Use when turning scattered updates, public research, links, or notes into a concise commercial brief with confirmed facts, unverified claims, commercial implications, current justified stance, recommended next actions, and a client-facing talk track, without pretending continuous monitoring exists.

Market Intel Briefing

Turn scattered public research into a sourced, decision-ready commercial brief for client-facing operators.

Work the request in this order

  1. Define the scope
  2. Narrow broad asks before synthesizing
  3. Prefer credible and direct sources
  4. Separate confirmed facts from reported claims and inferences
  5. Use a strict comparison frame when the task is comparative
  6. Prioritize the few developments most likely to affect operator decisions
  7. Translate findings into commercial implications
  8. State the most justified current stance
  9. End with recommended next actions and a client-facing talk track
  10. Preserve source traceability throughout

Default output structure

Use this structure unless the user clearly wants a different format:

  1. Scope and framing
  2. Key confirmed developments
  3. Notable unverified or weakly supported claims
  4. Commercial implications
  5. Current justified stance
  6. Recommended next 3 actions
  7. Client-facing talk track
  8. Sources

Keep it lean. Do not pad with generic analyst voice.

Evidence discipline

  • Label weakly supported claims clearly
  • Do not blend rumor into confirmed fact
  • Do not imply ongoing monitoring unless it actually exists
  • Say when evidence is thin or conflicting
  • Prefer direct source support over repeated commentary about the same claim
  • Keep confidence proportional to the evidence in both implications and talk track

Read references/source-and-claim-rubric.md when source quality, claim strength, or uncertainty handling matters. Read references/output-patterns.md when the user needs a variant format or when the default structure is not enough. Read references/commercial-translation.md when moving from research to operator-facing implications and actions. Read references/comparison-frames.md when comparing jurisdictions, competitors, or strategic options side by side. Read references/opportunity-ranking.md when the user asks for underserved workflows, gaps, or ranked commercial opportunities.

Materiality and prioritization

Prioritize developments that change decisions or near-term operator behavior. Examples of material signals include:

  • new constraints on power, water, permitting, interconnection, or speed to deploy
  • meaningful pricing or packaging changes
  • clear product, partnership, or regulatory developments with commercial consequences
  • evidence that a workflow pain point is still underserved

After narrowing the scope, explicitly prioritize the top few developments most likely to matter to the user's commercial decision. Do not inflate weak or cosmetic changes into major shifts.

Scope control

If the request is too broad, narrow it by proposing a smaller frame such as:

  • a time window
  • a specific company set
  • a geography
  • a product category
  • a single theme like pricing, partnerships, launches, hiring, regulation, or infrastructure constraints

If the user does not provide sources, proceed with reasonable public-source synthesis when possible, but make uncertainty visible.

No-source gate

When no user-supplied links or source documents are present AND the request covers multiple companies or a broad category:

  1. Auto-narrow the scope to dimensions verifiable from general public knowledge. Do not attempt full synthesis across entities without source anchors.
  2. Add a prominent warning block at the top of the brief:
No source inputs provided — all specifics inferred from public knowledge as of [date]. Verify before client use.
  1. Downgrade claim confidence proportionally throughout the output, using a two-tier distinction:

- Category-level patterns well-established in public knowledge (e.g., known industry trends, published market sizes, widely reported regulatory changes) → label as "Public knowledge (unverified by current sources)" and allow factual grounding up to 4/5. - Company-specific claims without source anchors (e.g., specific revenue figures, internal strategies, unreported partnerships) → label as "Inferred — verify before use" and hold factual grounding at 3/5.

  1. In the claims ledger and evidence table, mark all items with their actual evidence basis and the appropriate tier label rather than implying confirmation or treating all no-source content as equally uncertain.

This gate applies to competitor-set briefs, category-shift briefs, broad market scans, and any multi-entity comparison where the user provides no links. Single-company briefs without links should still flag uncertainty but do not require the full gate.

Service-critical usefulness

For internal or service-led use, optimize for a human operator who needs a defensible next move more than a perfectly elegant brief. That means:

  • prefer practical next steps over polished abstraction
  • make the current stance explicit
  • give the operator something usable even when the evidence is incomplete
  • stay honest about what is not yet proven

Sparse-data and thin-signal briefs

When evidence is thin:

  • say so directly
  • reduce confidence in implications
  • avoid filler
  • still provide lightweight practical value

For sparse-data or quiet-period conditions, use this prescriptive floor structure to ensure minimum useful output:

  1. Scope statement — what was covered and what time window was examined
  2. Evidence-limit declaration — what was and was not findable; name the gap explicitly
  3. One monitored signal with threshold trigger — "watch for X; if X happens, it changes the posture because Y"
  4. One assumption to validate — the single most important unproven belief underlying the current stance
  5. One low-risk action justified now — something the operator can do even without further evidence
  6. Next-check trigger — "revisit this brief when X occurs or after Y days"

This structure ensures that even when signal density is structurally low, the operator gets a concrete monitoring plan rather than just a "hold and watch" non-answer.

If little changed, say that plainly, then explain why the quiet period still matters or what would make it matter. Do not mistake low evidence for no value, but do not compensate by inventing confidence.

Change-detection outputs

When labeling items as unchanged, state the absence-of-evidence basis rather than asserting stability as a fact (e.g., "no public announcements in the reviewed period" rather than "X is stable"). The reader needs to know whether "unchanged" means actively confirmed or simply not observed.

Comparative briefs

When the user asks for a comparison, do not produce disconnected mini-briefs. Use one shared decision frame across all options. Make tradeoffs explicit. If evidence quality is uneven across options, say so directly.

Add a per-item "evidence quality" row or column in comparison tables so the reader sees at a glance which options rest on strong evidence and which are thinly supported. Do not let table formatting imply equal confidence across all options.

For infrastructure- or jurisdiction-sensitive briefs, distinguish clearly between:

  • province/state-level signals
  • utility-level signals
  • municipality-level constraints
  • site-specific unknowns

Do not imply that a province-wide trend guarantees a specific project outcome.

Opportunity-scan briefs

When the user asks for underserved areas, workflow gaps, or promising opportunities:

  • tie each opportunity to a specific painful manual workflow or unmet operator need
  • rank opportunities using explicit criteria rather than intuition alone
  • make confidence visible when demand is inferred rather than directly observed
  • tag each ranked opportunity with its demand evidence type: "inferred" / "adjacent-market analogy" / "directly observed"
  • tag each case study or example with its source type: "independent research" / "vendor-published" / "operator self-reported"
  • avoid generic startup-idea lists

Challenging weak evidence

If the input sources are biased, promotional, or too weak to justify the user's implied conclusion:

  • say the evidence is weak
  • explain what the sources do and do not prove
  • offer the most practical cautious stance available
  • avoid becoming preachy or sterile

The goal is not just to resist bad evidence. The goal is to help the operator decide what stance is still justified.

Current justified stance

For every brief, make the current stance explicit. Choose the strongest stance the evidence honestly supports, such as:

  • act now on a narrow point
  • test cautiously, but do not overcommit
  • monitor closely before changing position
  • do not conclude the implied trend yet
  • treat this as an emerging signal, not a confirmed shift

Also state what would strengthen or weaken that stance, and on what time horizon. The operator needs to know not just the current position but when to revisit it — name the specific events, data releases, or elapsed time that would change the stance. Do not leave the operator with uncertainty only.

Recommended next 3 actions

Keep these actions practical and operator-usable. Prefer:

  • one low-risk action to take now
  • one thing to monitor or validate next
  • one client/prospect/internal posture to use this week

Commercial translation

Make the brief useful for an agency or service operator. Do not stop at summary. Explain:

  • what changed
  • why it matters commercially
  • what the operator should do next
  • what they could say to a client or prospect this week

If the evidence is weak, reduce certainty and make the talk track more conditional.

Client-facing talk track

Keep the talk track short, usable, and evidence-proportional. Prefer this pattern:

  • what changed
  • why it matters
  • what remains uncertain
  • what stance we recommend now
  • what we recommend next

Even under uncertainty, give the operator a practical stance, not just a warning. Do not write manipulative or overconfident client language.

Boundaries

  • Do not claim private knowledge
  • Do not present inference as fact
  • Do not fabricate confidence
  • Do not pretend there is continuous monitoring
  • Do not overproduce when little reliable information exists
  • Do not write manipulative or overconfident client language

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

87.15%
按下载量换算792

安全审计

VirusTotal

通过

ClawScan

通过

Static analysis

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills