dtk-feedback

name

dtk-feedback

description

Report a detectkit bug, request a feature, or send feedback to the maintainers as a GitHub issue on the upstream repo (alexeiveselov92/detectkit). Use when a dtk command errors or behaves unexpectedly and it looks like a detectkit defect (not the user's config), when the user wishes detectkit did something it doesn't, or when they ask to report/file an issue, send feedback, or contact the maintainers. Auto-collects diagnostic context, redacts all secrets, and never submits without explicit confirmation.

Send feedback to the detectkit maintainers

Turn a problem, a wish, or a comment into a clear GitHub issue on the upstream repo alexeiveselov92/detectkit — carrying the diagnostic context maintainers need and leaking no secrets. You are filing a public issue on the user's behalf: never submit anything without showing the exact text and getting an explicit "yes".

This skill is the procedure; the reference for ruling out config problems lives under .claude/rules/detectkit/.

Step 0 — Decide whether this belongs upstream

• Bug — a dtk command errors or produces clearly wrong output, and you've ruled out a local config/usage mistake (Step 1).
• Feature request — the user needs detectkit to do something it doesn't.
• Feedback / question — a comment, confusion, or rough edge worth surfacing.

Do not open an issue for the user's own SQL, data, database, or configuration mistakes — those are fixed locally with the rules files, not reported as detectkit bugs. Only genuine detectkit behavior goes upstream.

Step 1 — Rule out config first (for "it doesn't work")

Before calling something a bug, confirm it isn't a configuration or usage problem. Read the matching .claude/rules/detectkit/ file and check the usual gotchas:

• the loading query filters on {{ dtk_start_time }} and {{ dtk_end_time }};
• metric name is unique across the project;
• profiles.yml has the right location fields (internal_database/data_database, or Postgres schemas) and a default_profile that exists;
• alert_cooldown is set; channels referenced by metrics exist.

If a local fix exists, do that and stop — don't file an issue. Escalate only what is genuinely a detectkit defect.

Step 2 — Gather context (do this for the user, don't make them dig)

Collect automatically:

• dtk --version — the detectkit version (always include it).
• Python version (python3 --version) and OS.
• The database backend type only (clickhouse / postgres / mysql) from profiles.yml's type: — never the host, port, or credentials.

For a bug, also gather:

• the exact command that was run;
• the full error message / traceback;
• what the user expected vs. what happened;
• a minimal reproduction — the failing metric YAML and/or SQL, with every secret stripped (Step 3).

Step 3 — Redact secrets (mandatory — before anything is shown or sent)

This is a public issue. Strip from every snippet you include:

• passwords, tokens, bot_token, smtp_password, API keys;
• webhook_urls, chat_ids, email addresses;
• hostnames, IPs, ports, and real database / schema / table names;
• the resolved value of anything inside {{ env_var('…') }} or ${…} — keep the env_var(...) shape, drop the value.

Replace with placeholders like <redacted>, <your-host>, <your_table> while keeping the structure intact so the bug is still reproducible. If you're not sure whether something is sensitive, redact it.

Step 4 — Search for duplicates

gh issue list --repo alexeiveselov92/detectkit --search "<keywords>" --state all

If a matching issue already exists, offer to add a comment or a 👍 reaction instead of opening a new one:

gh issue comment <number> --repo alexeiveselov92/detectkit --body "<note>"

This gives maintainers signal on frequency instead of a pile of duplicates.

Step 5 — Draft the issue

Write a specific title (the actual symptom in a few words, not "bug"). Pick the body template by type:

• Bug — Summary / Environment (detectkit version, Python, OS, backend) / Steps to reproduce / Expected / Actual (with the traceback in a fenced code block) / Minimal config (redacted).
• Feature request — Problem (the underlying need, not just the proposed fix) / Proposed behavior / Alternatives considered.
• Feedback — free-form, concrete and respectful.

End the body with an attribution marker so maintainers can see it came through the assistant funnel and on which version:

_Filed via the dtk init-claude assistant (detectkit <version>)._

Step 6 — Preview and confirm (no silent submits)

Show the user the full title and body exactly as they will be posted, and the target repo. Ask them to confirm: secrets redacted? right repo? Proceed to Step 7 only on an explicit "yes". If they want edits, revise and re-preview.

Step 7 — Submit

Preferred — gh CLI (check it's installed and authenticated first with gh auth status). Write the body to a temp file to avoid shell-escaping the markdown/traceback:

gh issue create --repo alexeiveselov92/detectkit \
  --title "<title>" --body-file <tmpfile>

Tag the issue so maintainers can triage assistant-filed reports: add the type label (--label bug / --label enhancement) and --label "via:assistant". Labels must already exist on the repo, so if gh reports an unknown label, retry without the failing label(s) — never fail the report over a missing label. (Attribution also lives in the Step 5 body marker, so maintainers can filter with in:body "Filed via the dtk init-claude assistant" even before the via:assistant label exists.) Return the issue URL to the user.

Fallback — no gh, or not authenticated. Build a prefilled "new issue" URL and hand it to the user to open and submit in their browser:

https://github.com/alexeiveselov92/detectkit/issues/new?title=<url-encoded>&body=<url-encoded>

URL-encode both fields. If the body is too long for a URL, give the user the title plus the body text to paste, and the plain link https://github.com/alexeiveselov92/detectkit/issues/new.

Step 8 — Close the loop

Give the user the issue URL (or the prefilled link), mention they can subscribe for updates, and — if you also worked around the bug locally — restate that local fix so they're unblocked right now, not just waiting on the issue.