Output Quality Standards

Use this skill as a workflow-aligned output quality layer for any agent.

The host agent owns the domain workflow. This skill only keeps the agent's output clear, evidenced, actionable, and handoff-ready while that workflow is executed.

Core Rule

Follow the host agent workflow.

If the current agent, agent.md, AGENTS.md, system prompt, task plan, conversation, or user query defines ordered steps, mirror those steps as the main sections of the output.

Do not replace the host workflow with this skill's own template. Do not infer a domain from a predefined list. Let the actual workflow, query, files, tools, and intermediate findings determine structure.

Use the host workflow internally, but do not expose internal execution labels in the final report. Formal report headings should read like polished section titles, not agent task logs. For example, display 市场研究与竞争分析 instead of Step 1: 市场研究与竞争分析.

First Response Rule

Do not make the first response a request for confirmation or missing information.

Start from the user's query and produce the best useful output possible with the available information. If information is missing, proceed with explicit assumptions, mark uncertain items as To verify, and place follow-up questions after the initial output.

Ask before doing work only when one of these is true:

• The user explicitly asked to discuss, confirm, or wait before execution.
• The task cannot be started without access, files, credentials, or a required choice.
• Proceeding would create a high-risk legal, medical, financial, security, privacy, or destructive action.
• Multiple mutually exclusive interpretations would produce incompatible artifacts and no reasonable default exists.

When missing information matters but does not block the task, use this pattern:

1. Deliver an initial draft, analysis, plan, report, or artifact based on the query.
2. State the assumptions used.
3. List the specific information that would improve the next iteration.
4. Ask concise follow-up questions at the end, not as the whole response.

Progressive Output Workflow

Use this workflow throughout the task:

1. Infer the output contract

   • Identify the deliverable type: report, analysis, strategy, brief, checklist, plan, audit, summary, handoff, or another artifact.
   • Identify the purpose: decide, execute, compare, persuade, document, review, or hand off.
   • Identify the audience and any requested format.
   • Locate the host workflow if present.
   • Use reasonable defaults when the user did not provide every preference.

2. Create a workflow-aligned outline

   • Use each host workflow step as a primary section.
   • Keep the host step wording whenever possible.
   • Add only universal support sections when useful: Summary, Evidence, Risks, Open Questions, Deliverables, Next Actions.

3. Accumulate output while working

   • Facts and observations go under the step where they were found.
   • Judgments go under findings, decisions, or recommendations.
   • Missing information goes under assumptions, limitations, or open questions.
   • Missing information should not stop the first useful output unless it meets the First Response Rule exception criteria.
   • Produced files, tables, assets, code, prompts, or plans go under deliverables.
   • Dependencies for later work go into the handoff note for the next step.

4. Run quality gates after major steps

   • Check whether the step has a clear objective, inputs, findings, output, evidence, risks, and handoff.
   • Fill important gaps before moving on.
   • If a gap cannot be resolved, label it explicitly.

5. Finalize the deliverable

   • Start with the most important conclusion or status.
   • Preserve the workflow structure.
   • Separate facts, reasoning, recommendations, assumptions, risks, and next actions.
   • Make the result usable without requiring the user to reconstruct the work.

Progressive Report Mode

When a task has multiple workflow steps and the user expects a report or HTML deliverable, maintain a progressive report state instead of waiting until the end.

Use this mode by default for multi-step agent workflows:

1. Create or update a source JSON report file, such as report.json.
2. After each important workflow step, add or update that step's section in the JSON.
3. Regenerate the HTML report after each step so the user can inspect the current snapshot.
4. Preserve earlier step content unless new evidence requires a targeted update.
5. Merge new sources, deliverables, open questions, next actions, metrics, highlights, and callouts into the same report state.
6. Treat the final report as the last progressive snapshot, not as a separate one-time summary.

Use scripts/update_workflow_report.py for deterministic incremental updates when file access is available:

python scripts/update_workflow_report.py --base report.json --update step-2.json --output report.json
python scripts/generate_workflow_report.py --input report.json --output report.html

The HTML is the rendered artifact. The JSON is the durable report state.

For progressive delivery, show the user the HTML snapshot first. If the runtime can capture screenshots, include a screenshot preview of the current HTML snapshot. Do not present intermediate JSON files as the default deliverable; JSON is internal state unless the user asks for source data or debugging artifacts.

Source Tracking

When an agent uses external or inspectable information sources, record them in the report.

Track sources such as web pages, app store listings, social posts, database queries, local files, uploaded files, tool outputs, documents, datasets, screenshots, or APIs.

For each source, capture what is available:

• Source or publisher name.
• Title or short description.
• URL, file path, query, or tool name.
• Source type, such as web, file, database, tool, app_store, social, api, or other.
• Which claim, section, or workflow step it supports.
• Retrieval or observation time when useful.
• Notes or limitations.

Do not bury every URL in the main narrative. Put key evidence near the relevant section and keep the complete source list in Sources or References.

Per-Step Contract

For each workflow step, maintain these fields when relevant:

• Objective: what this step is meant to accomplish.
• Inputs reviewed: query, files, data, sources, constraints, or prior step outputs.
• Work performed: what was actually done.
• Key findings: facts, patterns, observations, opportunities, or issues.
• Output or decision: artifact, conclusion, recommendation, selection, or strategy produced by this step.
• Evidence and assumptions: what supports the output and what is inferred.
• Risks or gaps: missing data, uncertainty, conflicts, caveats, or blockers.
• Handoff: what the next workflow step should use from this step.

Do not include every field mechanically if it adds noise. Use this contract as a completeness check.

Universal Quality Gates

Before delivering, ensure:

• The output answers the user's original request.
• The structure follows the host workflow or the user's requested structure.
• The first response produced useful progress before asking non-blocking questions.
• The conclusion or status is clear and visible.
• Key claims are traceable to inputs, evidence, tool results, or reasoning.
• Assumptions and uncertainty are labeled.
• Recommendations are actionable.
• Risks, limitations, and open questions are visible.
• Deliverables and next actions are easy to find.
• Domain-specific criteria come from the host workflow, user query, files, or evidence, not from this skill's presets.

Visual Delivery Contract

When producing an HTML report or other shareable deliverable, design for scanning, comparison, and handoff. Do not deliver raw Markdown wrapped in HTML.

Required visual structure:

• A report header with title, subtitle, generated time, workflow source, and status.
• A visible executive summary with the main conclusion, key recommendations, top risks, and next actions.
• A dashboard-style overview for scanability, followed by report-style sections for complete reasoning.
• Workflow steps rendered as distinct formal report sections, not as one continuous essay and not as visible Step 1 task labels.
• Key findings, decisions, risks, assumptions, evidence, and next actions visually separated.
• Structured data rendered as tables, metric tiles, cards, callouts, or priority lists.
• A navigation area for multi-section reports.
• Clear hierarchy: conclusion first, evidence second, action last.

Use these generic visual components when relevant:

• Status badge: completion state, uncertainty, blocked state, or verification need.
• Metric tile: numeric or short evaluative signals such as score, volume, priority, count, confidence, or trend.
• Highlight card: important conclusion, opportunity, decision, or strategic point.
• Callout: risk, warning, assumption, limitation, evidence note, or recommendation.
• Comparison table: alternatives, options, competitors, channels, keywords, sources, scenarios, or candidates.
• Priority table: open questions, next actions, ownerless tasks, validation needs, or follow-up items.
• Tree diagram: hierarchical relationships such as strategy decomposition, keyword clusters, competitor taxonomy, topic map, user segment tree, decision tree, source hierarchy, or project work breakdown.
• Flow/timeline diagram: ordered execution, funnel, experiment path, publishing plan, due diligence path, or multi-stage workflow.
• Matrix visual: two-dimensional prioritization, opportunity/risk map, channel/content fit, keyword intent by difficulty, or option-by-criteria scoring.
• Workflow section: objective, inputs, work performed, key findings, output, evidence, assumptions, risks, and handoff.

The visual style must stay professional, refined, Feishu-inspired, and domain-neutral. The host agent may supply domain-specific content, but this skill should not add domain-specific report sections by itself. Reports should feel like polished Feishu-style dashboard deliverables: light gray-blue background (#F7F9FC), high-quality white card surfaces, large rounded corners (16–20px), generous whitespace, precise typography, soft layered shadows, thin borders, quiet colors, and low visual noise. Use Feishu blue (#3370FF) for links, key numbers, navigation emphasis, and sparse highlights. Use green (#14B87A), amber (#F59E0B), and red (#EF4444) only for small badges, tags, icons, or thin indicator lines; badges always use light background + dark text. Do not fill large cards or sections with status colors. All pages must use the same Design Token set — no ad-hoc colors, spacing, or radii per page.

When a section contains nested or ordered information, convert that structure into diagrams or visual_blocks in the report JSON instead of leaving it as a long paragraph. Prefer a tree diagram for hierarchy, flow or timeline for sequence, and matrix for two-axis decisions. The diagram should summarize structure while the body section preserves complete detail.

Report Design Quality Gates

Before final delivery of an HTML or shareable report, verify:

• The first screen communicates the result without requiring deep scrolling.
• The report has clear visual hierarchy and spacing.
• The report looks like an external-facing Feishu-style dashboard artifact, not an internal admin panel or raw Markdown page.
• Internal workflow labels such as Step 1 or Workflow Step 1 are not shown as formal report titles.
• Long paragraphs are broken into lists, tables, cards, or callouts when structure exists.
• Hierarchical information is rendered as a tree diagram when it improves comprehension.
• Ordered execution is rendered as a flow or timeline when it improves comprehension.
• Key decisions, risks, evidence, and next actions are visually distinct.
• Tables are used for structured comparisons or field-based records.
• Metric-like values are placed in metric tiles when helpful.
• Sources or references are listed when the agent used external or inspectable inputs.
• The report is readable on desktop and mobile.
• The output does not look like raw Markdown pasted into HTML.

Optional HTML Delivery

When the user asks for a report, handoff artifact, shareable output, HTML page, or polished deliverable, keep the generic HTML generator available as the final packaging path.

Use scripts/generate_workflow_report.py only after the content structure has been derived from the host workflow. Do not use it to impose a template.

Expected flow:

1. Build the report content around the host workflow steps.
2. Convert the accumulated result into JSON shaped like schemas/workflow-report.schema.json.
3. Run:

python scripts/generate_workflow_report.py --input report.json --output report.html

4. Check that the generated HTML preserves the host workflow sections, summary, deliverables, open questions, and next actions.

The generator is intentionally generic and dependency-free. It should not contain product-management, ASO, venture intelligence, social media, or other domain-specific sections unless those sections came from the host agent workflow or user request.

For stronger visual output, populate optional fields such as layout, tone, visual_density, metrics, highlights, callouts, comparison_tables, and diagrams / visual_blocks when the source material supports them. Do not invent metrics, comparisons, or diagrams just to decorate the report; extract them from actual structure in the task, workflow, files, or findings.

For progressive reports, update the JSON state after each workflow step and regenerate the HTML snapshot. Do not wait until all steps are complete if the user expects staged visibility.

When reporting progress to the user, link the current HTML snapshot and summarize the stage result. Only mention the JSON state file when the user explicitly asks for it.

Resource Navigation

Load only what is needed:

• execution-routing.md: derive output structure from host workflow.
• stage-output-standards.md: maintain output per workflow step.
• quality-gates.md: run universal quality checks.
• delivery-manifest.md: list artifacts, status, open questions, and next actions.
• visual-design-standards.md: visual hierarchy, component selection, and HTML report design gates.
• research-evidence-standards.md: handle facts, evidence, assumptions, and uncertainty.
• progress-notification-strategy.md: report progress during long workflows.
• execution-checklist.md: compact execution checklist.
• execution-complete-checklist.md: final delivery checklist.
• schemas/workflow-report.schema.json: optional JSON shape for generated reports.
• scripts/generate_workflow_report.py: optional dependency-free HTML generator.
• scripts/update_workflow_report.py: optional dependency-free report state updater.
• examples/workflow-report-example.json: minimal example showing workflow-aligned input.

Final Response Pattern

When producing the final answer:

1. Give the result, status, or main conclusion first.
2. Follow the host workflow sections.
3. Include evidence, assumptions, risks, and next actions where they matter.
4. Mention any files created or changed.
5. State what could not be verified.
6. Ask follow-up questions only after the useful output, and only when the answers would materially improve the next iteration.

Keep the response proportional. Small tasks need concise answers; multi-step workflows need structured handoff-ready outputs.

Avoid final answers that begin with "I need you to provide..." or "Please answer these questions first" when reasonable assumptions can be made. Prefer "I started with these assumptions..." followed by the output and a short "To improve the next pass..." section.