Review Viewer

# Geo Content Brief Skill

将 GEO 内容访谈、关键词笔记、竞品线索和渠道约束整理成可执行的中文内容简报。用于团队复用、选题规划、内容生产交接和质量评审；不用于直接代写完整长文或替代品牌策略判断。

maturity: production archetype: production format: agent-skills updated: 2026-06-15 intent confidence: 10 / 100

## Architecture at a glance

Inputs
workflow, prompt, transcript, docs, or notes
Boundary
将 GEO 内容访谈、关键词笔记、竞品线索和渠道约束整理成可执行的中文内容简报。用于团队复用、选题规划、内容生产交接和质量评审；不用于直接代写完整长文或替代品牌策略判断。
Logic
读取用户输入，识别目标受众、内容渠道、关键词、品牌边界、禁止表达和必须覆盖的信息。; 对照 `references/brief-structure.md` 生成简报骨架：目标、洞察、角度、关键词、结构、证据、风险和验收标准。; 如果缺少核心输入，先提出最多三个澄清问题，不用假设补全用户没有提供的事实。
Usage
当你需要把访谈纪要、关键词、竞品线索和渠道限制整理成中文 GEO 内容简报时，使用 $geo-content-brief-skill。; Use this skill when the request matches: 将 GEO 内容访谈、关键词笔记、竞品线索和渠道约束整理成可执行的中文内容简报。用于团队复用、选题规划、内容生产交接和质量评审；不用于直接代写完整长文或替代品牌策略判断。
Next
Review the top iteration directions before growing the package.

## Core logic

- 读取用户输入，识别目标受众、内容渠道、关键词、品牌边界、禁止表达和必须覆盖的信息。
- 对照 `references/brief-structure.md` 生成简报骨架：目标、洞察、角度、关键词、结构、证据、风险和验收标准。
- 如果缺少核心输入，先提出最多三个澄清问题，不用假设补全用户没有提供的事实。
- 用 `evals/trigger_cases.jsonl` 检查当前请求是否属于 GEO 内容简报场景。
- 用 `evals/output_cases.jsonl` 检查输出是否包含输入摘要、内容结构、证据要求、禁区和下一步动作。

## How to use it

- 当你需要把访谈纪要、关键词、竞品线索和渠道限制整理成中文 GEO 内容简报时，使用 $geo-content-brief-skill。
- Use this skill when the request matches: 将 GEO 内容访谈、关键词笔记、竞品线索和渠道约束整理成可执行的中文内容简报。用于团队复用、选题规划、内容生产交接和质量评审；不用于直接代写完整长文或替代品牌策略判断。

## Intent questions

- If this skill worked beautifully, what recurring job would it reliably handle for the user every time?
  This reveals the real job-to-be-done and gives the package a humane center instead of a guessed prompt shape.
- When someone reaches for this skill in the real world, what materials will they actually hand to it?
  Input shape decides whether references, scripts, or templates are needed.
- What finished output should it hand back so the user can immediately keep moving?
  Outputs should drive the package structure before extra guidance is added.
- Which nearby requests should this skill politely refuse so the boundary stays clean?
  The exclusion list is the fastest route to better trigger quality.
- What matters most here: speed, consistency, auditability, portability, governance, or tone/style fit?
  Constraints decide how much structure, packaging, and review the skill actually needs.

## Why this package is strong

- 触发面保持精简，并锚定在 frontmatter description。
- 已生成 Skill IR，核心语义可先于平台打包被审查和迁移。
- 已生成目标编译报告，可审查 IR 到 OpenAI、Claude、generic 等目标契约的映射。
- 已生成 Adoption Drift Report，可把本地使用反馈转为下一轮迭代信号。
- 已生成 Review Waivers 台账，可记录 reviewer 对 warning 风险的批准、理由和到期时间。
- 已生成 Review Annotations 台账，可把 reviewer 批注挂到 gate、文件和行号。

## Borrow plan

- No external benchmark objects recorded yet. Add 2 to 5 references before deepening the package.

## Compare view

No baseline comparison has been recorded for this package yet.

## Variant diff studio

No description optimization compare payload is attached yet.

## Evidence readiness

Readiness score: 57/100

- Intent clarity · needs review
  10/100 intent confidence.
- Benchmark coverage · needs evidence
  0 GitHub benchmark repositories attached.
- Pattern gate · ready
  3 accepted, 0 deferred using threshold 2/4.
- Conflict handling · decision needed
  The stated preference leans lightweight or speed-first, while the benchmark mix leans toward governance, review, or heavier evaluation structure.
- Output risk profile · ready
  5 output risk families attached.
- Artifact design profile · ready
  High-trust editorial report with a clear first-screen thesis, compact evidence blocks, and decisions separated from supporting detail.
- Prompt quality profile · ready
  85.0/100 prompt-facing quality score.

## Honest boundary check

- Are the known limits visible before the package deepens?
- Does the evidence support the borrowed patterns?
- Should uncertainty become a clarification question instead of more structure?

## Output risk profile

- Markdown readability
  Tables can render as dense grids with weak hierarchy or poor mobile readability.; Long bullets can make the output look complete while hiding the actual decision logic.
- Screenshot and visual capture
  Screenshots can be captured from the wrong state, wrong viewport, or wrong crop.; Missing screenshots can cause the skill to invent visual references instead of declaring the gap.
- Citation and footnote clutter
  Footnote markers or dense citation notes can interrupt the reading flow.; Evidence can be over-attached to obvious statements and under-attached to risky claims.

## Self-repair checks

- Preview whether each table still reads well when columns are narrow.
- Convert any table with paragraph-length cells into bullets or cards.
- Check that every screenshot reference points to a real provided or generated asset.
- Reword any visual instruction that depends on an unseen screen state.
- Remove decorative citations that do not support a material claim.

## Artifact design profile

Design system: metric editorial

- Report or brief
  High-trust editorial report with a clear first-screen thesis, compact evidence blocks, and decisions separated from supporting detail.
- Review viewer
  Side-by-side reviewer studio with explicit tradeoffs, evidence readiness, and fast paths for approving, blocking, or requesting one focused fix.
- Dashboard or metrics page
  Metric-first dashboard with stable dimensions, short labels, visible deltas, and narrative callouts only where they change interpretation.

## Visual quality gates

- Keep the first screen useful without requiring the reader to parse every detail.
- Use tables only for comparisons; move explanations below the table.
- Keep source notes readable without flooding the body with markers.
- Make differences visible instead of hiding them in prose.
- Separate author-facing recommendations from reviewer-only evidence.

## Prompt quality profile

Relevance: prompt-heavy · score 85.0 / 100 · complexity complex

- Completeness · 80 / 100
  Name missing inputs, outputs, constraints, or success standards before deepening the package.
- Clarity · 90 / 100
  Replace broad verbs with observable actions and define what done means.
- Consistency · 90 / 100
  Check that role, task, format, exclusions, and examples do not contradict each other.
- Practicality · 95 / 100
  Add runnable steps, examples, or verification cues instead of abstract advice.
- Specificity · 70 / 100
  Anchor wording in the user's audience, domain nouns, and target outcome.

## RTF to skill mapping

- Role
  Use a taste-aware creator role with clear audience, tone, and originality boundaries.
- Task
  Generate variants, explain selection logic, and preserve the user's distinctive constraints.
- Format
  Return options with rationale, selection criteria, and refinement paths.

## Reference coach

No GitHub benchmark scan has been attached to this package yet.

## Decide before you deepen

- Choose one pattern to borrow on purpose, not three at once.
- State one thing this skill will not inherit from the benchmark objects.
- Only deepen the package after that choice is visible in the boundary or execution flow.

## Reference synthesis

### Official skill anatomy and context discipline

Borrow now

- Borrow progressive disclosure: keep the entrypoint lean and move depth into references or scripts.

Avoid

- Do not let packaging or platform concerns swallow the core job boundary.

### Hypothesis-test-learn loop

Borrow now

- Borrow a small hypothesis-test-learn loop so the first revision is evidence-backed.

Avoid

- Do not create experimental overhead that exceeds the skill's real risk tier.

### Boundary-first design

Borrow now

- Borrow the discipline of defining what the skill should not own before growing the package.

Avoid

- Do not expand execution assets until route boundaries stay clean.

## Borrow now

- Borrow progressive disclosure: keep the entrypoint lean and move depth into references or scripts.
- Borrow a small hypothesis-test-learn loop so the first revision is evidence-backed.
- Borrow the discipline of defining what the skill should not own before growing the package.

Use the recommendation by default. Only surface the underlying benchmark tradeoffs when intent is uncertain or a real design conflict needs a deliberate call.

## Top three next moves

### Tighten trigger and exclusions

The package needs clearer near-neighbor exclusions before it grows.

- Add 3 to 5 should-trigger and should-not-trigger examples.
- Refine the frontmatter description to name the recurring job and non-goals.
- Run a first trigger evaluation pass before expanding the package.

Unlocks: Cleaner routing and fewer accidental activations.

### Add the first execution asset

The package is still mostly prose. Add one asset that removes repeated manual work.

- Move stable procedural guidance into references if users will need it repeatedly.
- Create one deterministic helper script if a repeated step can be executed instead of described.
- Keep the main SKILL.md compact and route-oriented.

Unlocks: Stronger execution quality without bloating the entrypoint.

### Promote from scaffold to production-ready

The first version exists; the next gain usually comes from adding the smallest useful gates.

- Decide whether this skill is personal, team-reused, or library-grade.
- Add only the gates that match that risk level.
- Record lifecycle metadata and review cadence once reuse becomes real.

Unlocks: A clearer path from exploratory package to maintained asset.

## Recent feedback

- No lightweight feedback captured yet. Use `yao.py feedback` to record quick review notes.

## Promotion status

No promotion summary is attached to this package yet.

## Package map

- SKILL.md — Skill entrypoint
- README.md — Human-readable usage guide
- agents/interface.yaml — Neutral interface metadata
- manifest.json — Lifecycle and portability metadata
- references — Extended guidance and reusable notes
- scripts — Deterministic helpers or local tooling
- evals — Trigger and quality checks
- reports — Generated evidence and overview artifacts

## First-pass review frame

- Does the trigger stay narrow enough for the intended job?
- Does the archetype match the real reuse level?
- Are we adding structure faster than we are adding reliability?
- Should the next step be trigger tightening, execution assets, or portability hardening?

## Authoring discipline

- Name unresolved assumptions before deepening the package.
- Keep the package no larger than the recurring job requires.
- Touch only files that directly support the requested change.
- Tie every meaningful new artifact to a check or reviewer note.

## Reviewer guardrails

- Block speculative features that are not backed by real workflow variation.
- Move unverifiable ideas into next-step candidates instead of baseline structure.
- Reject decorative folders, reports, or governance that do not reduce risk.
- Ask for one high-leverage clarification when job, output, or exclusion is still fuzzy.