Geo Content Brief Skill

When To Use This Skill

• 用户提供访谈纪要、关键词、竞品片段、产品卖点或渠道限制，希望沉淀为中文内容简报。
• 团队需要把零散输入转换成可执行的 GEO 内容选题、角度、结构、证据和交付要求。
• 需要先明确触发边界、输入缺口和输出验收标准，再进入内容生产。

Workflow

1. 读取用户输入，识别目标受众、内容渠道、关键词、品牌边界、禁止表达和必须覆盖的信息。
2. 对照 references/brief-structure.md 生成简报骨架：目标、洞察、角度、关键词、结构、证据、风险和验收标准。
3. 如果缺少核心输入，先提出最多三个澄清问题，不用假设补全用户没有提供的事实。
4. 用 evals/trigger_cases.jsonl 检查当前请求是否属于 GEO 内容简报场景。
5. 用 evals/output_cases.jsonl 检查输出是否包含输入摘要、内容结构、证据要求、禁区和下一步动作。
6. 交付前回看渠道限制和品牌禁区，删除空泛营销话术、无来源断言和不可执行建议。

Inputs

• 访谈纪要、销售反馈、客户问题或专家观点。
• 关键词、搜索意图、竞品页面摘要或排名线索。
• 目标渠道、目标读者、品牌口径、禁用词和交付格式。

Outputs

• 一页中文内容简报，包含目标、受众、核心洞察、推荐角度、文章结构、关键词布置、证据需求和风险提示。
• 缺口清单，说明继续生产前必须补齐的信息。
• 下一步动作，面向写作者、编辑或 SEO/GEO 负责人。

Output Quality Guardrails

• Before final output, apply the likely failure modes in reports/output-risk-profile.md when that report is present.
• Before rendering reports, tutorials, review pages, dashboards, or visual artifacts, apply the artifact direction and visual quality gates in reports/artifact-design-profile.md when that report is present.
• When prompt behavior, role design, dialogue quality, or output contracts matter, apply reports/prompt-quality-profile.md when that report is present.
• Before adding more structure, apply the boundary, feedback-loop, drift, and leverage-point checks in reports/system-model.md when that report is present.
• Repair generic headings, cluttered notes, fragile visual assumptions, weak tables, and missing verification cues before handing work back.
• Map role, task, and format into skill behavior rather than copying a large prompt template into SKILL.md.
• Let the artifact's content choose the visual system; do not copy a fixed palette or report style from another skill without a clear reason.
• If output-specific evidence is missing, state the gap instead of inventing screenshots, citations, data, or examples.

Honest Boundaries

• 不直接代写完整长文，不替代品牌策略判断，不伪造竞品数据、搜索量、排名或引用来源。
• 当用户只想要标题灵感、广告文案、舆情分析或完整文章撰写时，不应触发本 Skill。
• 缺少目标读者、渠道或关键词时，先收紧输入，再输出简报。

Reference Map

• references/brief-structure.md: 中文 GEO 内容简报结构、字段说明和质量标准。
• references/review-checklist.md: 交付前的编辑复核清单。
• evals/trigger_cases.jsonl: 应触发和不应触发样例。
• evals/output_cases.jsonl: 输出结构验收样例。

Release Orchestrator

When To Use

• You need one reusable release packet from scattered launch inputs.
• You need to verify migration notes, rollout steps, rollback triggers, and stakeholder messages before release approval.
• You need a go/no-go summary with explicit blockers.

Do Not Use

• The request is only to explain a release concept.
• The request is only to write a single announcement.
• The request is still brainstorming and not yet packaging a repeatable release workflow.

Workflow

1. Gather the minimum release inputs:
   • release scope
   • risky changes
   • migrations
   • rollout sequencing
   • rollback triggers
   • communication audiences
2. Read references/release-checklist.md and references/risk-matrix.md to determine required sections and escalation thresholds.
3. Read references/migration-template.md and references/stakeholder-comms.md when migrations or communications are present.
4. Use scripts/build_release_packet.py with input/release_input_example.json as the shape reference when deterministic packet assembly is needed.
5. Produce one release packet with:
   • release summary
   • dependency and migration section
   • rollout steps
   • rollback triggers
   • stakeholder communication plan
   • explicit go/no-go decision
6. If release-critical data is missing, stop and report blockers instead of pretending readiness.

Output Contract

The final answer must include:

• a concise scope summary
• a risk block with severity
• migration notes or a clear "none required"
• rollout plan
• rollback plan
• stakeholder communication block
• a final decision: GO, GO WITH CONDITIONS, or NO-GO

Validation Checklist

• Release-critical inputs are either present or explicitly flagged as missing.
• Rollout and rollback are both covered.
• Migration notes are not omitted when schema or data changes exist.
• Stakeholder communication is tailored by audience and timing.
• The final decision is explicit and justified.

Reference Map

• Read references/release-checklist.md for required packet sections.
• Read references/risk-matrix.md for decision thresholds.
• Read references/migration-template.md for migration note structure.
• Read references/stakeholder-comms.md for announcement scaffolds.
• Inspect evals/trigger_cases.json for trigger boundaries.
• Inspect outputs/release_packet_example.md for an example final artifact.

Frontend Review

Review UI code with a pre-merge mindset. Findings come first. Focus on behavior regressions, accessibility gaps, risky form handling, unsafe rendering, and missing user states.

Workflow

1. Identify the UI surface and user flows affected.
2. Check accessibility, security-sensitive inputs, loading states, and error states.
3. Report findings by severity with concrete code references.
4. Prefer actionable fixes over generic advice.

Output Contract

• Start with findings, ordered by severity.
• Include file references for each finding.
• Call out open questions separately from confirmed issues.
• If there are no findings, say that explicitly and note residual risks or test gaps.

Frontend Review

Review UI code with a pre-merge mindset.

Workflow

1. Identify affected flows.
2. Check accessibility, rendering safety, form behavior, loading states, and error states.
3. Report findings by severity with code references.

Incident Command Governor

When To Use

• You need a reusable incident command packet from messy operational inputs.
• You need explicit severity assessment, stakeholder updates, and action ownership.
• You need a governed workflow that can be reviewed, maintained, and audited over time.

Do Not Use

• The task is only to explain an incident concept.
• The task is only to draft a one-off update.
• The request is still brainstorming and not yet packaging a repeatable incident workflow.

Workflow

1. Gather the minimum incident inputs:
   • incident summary
   • timeline evidence
   • affected systems and customers
   • severity indicators
   • owners and responders
   • stakeholder audiences
2. Read references/severity-matrix.md to assign or confirm severity.
3. Read references/comms-policy.md to shape internal and external updates.
4. Read references/review-policy.md before finalizing, because this skill is maintained under a monthly review cadence.
5. Use scripts/build_incident_packet.py with input/incident_input_example.json when deterministic packet assembly is needed.
6. Produce one governed incident packet with:
   • incident summary
   • severity block
   • evidence-backed timeline
   • affected scope
   • owner and action table
   • internal and external comms blocks
   • explicit open risks and review notes
7. Stop and report blockers if severity evidence or ownership data is missing.

Output Contract

The final answer must include:

• a concise incident summary
• explicit severity and rationale
• a timeline section
• impact scope
• owners and next actions
• stakeholder communication blocks
• governance note for follow-up review

Validation Checklist

• Severity is justified with evidence, not guessed.
• Owner and next actions are explicit.
• Communications are separated by audience.
• Missing evidence is surfaced as a blocker.
• The packet can be reviewed again without reconstructing context from chat history.

Reference Map

• Read references/severity-matrix.md for severity rules.
• Read references/comms-policy.md for communication guidance.
• Read references/review-policy.md for review cadence and governed lifecycle expectations.
• Inspect evals/trigger_cases.json for routing boundaries.
• Inspect outputs/incident_packet_example.md for an example final artifact.
• Inspect reports/governance_score.json for the current maturity snapshot.

Note Cleanup

Workflow

1. Read the notes fully before restructuring.
2. Remove duplicates and obvious noise.
3. Produce sections for summary, decisions, action items, and open questions.
4. Preserve important names, dates, and owners.

Frontend Review

Review UI code with a pre-merge mindset. Findings come first. Focus on behavior regressions, accessibility gaps, risky form handling, unsafe rendering, and missing user states.

Workflow

1. Identify the UI surface and user flows affected.
2. Check accessibility, security-sensitive inputs, loading states, and error states.
3. Report findings by severity with concrete code references.
4. Prefer actionable fixes over generic advice.

Output Contract

• Start with findings, ordered by severity.
• Include file references for each finding.
• Call out open questions separately from confirmed issues.
• If there are no findings, say that explicitly and note residual risks or test gaps.

Reference Map

• Read references/checklist.md for the review standard.

Yao Meta Skill

Router Rules

• Route by frontmatter description.
• Keep SKILL.md lean; put guidance in references/, logic in scripts/, and evidence in reports/.
• Use the lightest reliable process.

Modes

• Scaffold: exploratory/personal. Production: team reuse. Library: shared infra. Governed: high-trust/release-critical.
• Rules: Method, Operating Modes, Resource Boundaries.

Compact Workflow

1. One-off/no reusable process: Do not create a skill; near-neighbor; require repeated use + reusable output contract.
2. Capture job, output, exclusions, constraints, standards, lightest fit.
3. Scan up to 3-5 references: external, user, local; skip tiny edits; surface only uncertainty/conflict.
4. Write description early; route/boundary edits need trigger_eval.py; releases need risk-matched gates before folders.
5. Add output-risk, artifact-design, prompt-quality, system-model, next directions only when earned.

Playbooks: Method, Intent, Skill IR, Output Eval, Review Studio.

Skill OS 2.0 Gates

For production/library/governed/team releases, run Skill IR, compiler, trigger/output eval, Skill Atlas, conformance, trust, registry/package/install, upgrade, drift, waiver, Review Studio.

Governed Package Boundary

For file-backed/release-critical/governed packages, name input_files as file-backed fixture; include owner, review cadence, input_files, output contract, rollback boundary; require trust report and reports/output_quality_scorecard.md; mark unavailable telemetry/approvals/metrics/benchmarks as missing evidence; do not fabricate evidence.

Preserve labels literally when they apply: file-backed fixture, input_files, output contract, rollback boundary, trust report, reports/output_quality_scorecard.md, missing evidence.

First-Turn Style

• Start from the user's work/outcome before structure.
• Ask only 2-3 key questions unless enough detail exists.
• In Chinese, sound soft and companion-like; use Intent Dialogue.

Output Contract

Create/refactor/package: produce SKILL.md, aligned agents/interface.yaml, justified assets, boundary/exclusion/gate summary. Audit/evaluate-only: findings + proposed fixes; edit files only if asked. No-skill: no files.

Reference Map

Primary: Method, Artifact Design, Systems, Governance, SkillOps.

Frontend Review

Workflow

1. Review the code.
2. Report issues.

Invalid Governance Skill

This fixture exists only to verify governance failures.

Broken YAML Skill

Broken Skill