issue-report-evidence-checklist

Guides evidence collection and secret redaction for filing LingTai issue reports.

692|60|Updated Mar 15, 2026
One-click install
npx skills add https://github.com/Lingtai-AI/lingtai --skill issue-report-evidence-checklist
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: issue-report-evidence-checklist
Source: https://github.com/Lingtai-AI/lingtai/tree/main/tui/internal/preset/skills/lingtai-issue-report/reference/evidence-checklist
Command: npx skills add https://github.com/Lingtai-AI/lingtai --skill issue-report-evidence-checklist

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

When an agent spots a stale doc, broken URL, or silent failure in LingTai, it often loses the exact tool output before filing a report, or worse, leaks tokens and credentials into a public issue. This reference defines when an observation deserves a report and what evidence to capture safely while the problem is fresh.

Core Features & Use Cases

  • Report-worthiness criteria: Distinguishes reportable problems (stale docs, broken URLs, silent failures, wrong defaults, procedure contradictions) from non-reportable ones (one-off hallucinations, wording preferences, model quality complaints).
  • Evidence quality standards: Enforces verbatim quoting of tool outputs, reproducible call descriptions, doc-bug versus code-bug classification, and version context flagging.
  • Secret hygiene rules: Requires redacting tokens, API keys, and credentials from quoted output, scrubbing environment dumps, and never echoing human-provided tokens into reports or logs.
  • Use Case: An agent discovers a skill claims a model supports vision but the API returns 400 on image input; it captures the verbatim error, notes which modalities work, redacts the API key from the output, and flags its kernel version before drafting the issue.

Quick Start

Read this checklist before drafting any LingTai issue report to decide whether the observation is worth reporting and what redacted evidence to collect.

Frequently Asked Questions about issue-report-evidence-checklist

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide whether a LingTai problem is worth reporting?

Report stale documentation, broken URLs, silent failures, wrong defaults, missing capabilities, procedure contradictions, and reproducibly wrong output. Skip one-off hallucinations, wording preferences, model quality complaints, and feature requests outside the system's design.

What evidence should I collect before filing an issue report?

Quote tool outputs and error strings verbatim, show the exact call and arguments used, note what still works, and flag version context such as kernel version, TUI version, active preset, or recent migrations. Capture this while the problem is fresh.

How do I keep secrets out of a public issue report?

Redact tokens, API keys, and passwords before quoting any output, scrub environment dumps from commands like env or gh auth status, and never echo a human-provided token into chat, logs, or the issue body. When unsure, redact and note that you did.

Should I report a one-off wrong answer from a model?

No. One-off LLM hallucinations and non-determinism are not reportable. File a report only when wrong output is reproducible, such as a vision model consistently claiming it cannot see an image when image content is present.

How do I tell a documentation bug from a code bug?

Compare what the skill or docs claim against actual API behavior. If a skill says a model supports vision but the API returns 400 on image input, state which you believe is wrong and why, so maintainers can narrow the search.