Technical capability specification
Tool requests are evaluated as product-engineering specifications rather than name-only feature suggestions. A reviewable request should identify the intended transformation, accepted input representation, output representation, validation semantics, failure conditions, execution boundary, authoritative specification, runtime or provider dependency, expected file-size or payload constraints, and representative test vectors.
Information required for efficient triage
For defects, include the affected URL or tool slug, browser and version, operating system, viewport or device class where relevant, input format category, exact sequence of actions, expected result, actual result, visible error message, and whether the issue reproduces with the built-in example. For tool requests, include the target user workflow, data format, relevant standards, mandatory options, deterministic rules, representative inputs and outputs, security classification, and the system that will consume or verify the generated result.
Sanitization and disclosure controls
Support submissions are server-side records and should contain only information appropriate for operational review. Do not include production passwords, private keys, session cookies, bearer tokens, customer secrets, regulated personal information, confidential source code, proprietary datasets, or other high-sensitivity material unless a formally approved support workflow specifically requires it. Reproduction examples should be minimized, synthetic where possible, and stripped of credentials or unnecessary identifiers.
Operational processing of submitted messages
A submission can contain name, email address, subject, message body, timestamps, anti-abuse signals, request metadata, and administrative processing status. These records are distinct from ordinary browser-local tool execution and may be accessed by authorized personnel for triage, response, product planning, security review, or documentation correction. Hosting logs, backups, spam defenses, mail delivery systems, and administrative interfaces can impose separate retention and access-control boundaries.
Security-reporting expectations
When reporting a security issue, provide enough technical detail to reproduce and assess the condition without performing destructive testing, persistence, privilege escalation, unauthorized data access, credential harvesting, denial-of-service activity, or scanning outside systems you are authorized to test. Include affected component, prerequisites, impact hypothesis, minimal reproduction, and recommended remediation where available.
Response and prioritization model
Submission of a message does not create a service-level agreement, guaranteed implementation commitment, contractual support obligation, or guaranteed response time. Issues may be prioritized according to exploitability, data exposure, user impact, reproducibility, affected surface area, operational severity, accessibility impact, catalog importance, and implementation feasibility.