export function sentryFetch(path: any, opts?: {}): Promise<any>;
/**
 * List Sentry projects in the connected organization. Returns raw
 * Sentry-shape objects ({ slug, name, platform, id, … }).
 *
 * Single source of truth for the `sentry_list_projects` tool (MCP +
 * assistant), and for deterministic workflow nodes.
 */
export function sentryListProjects(): Promise<any>;
/**
 * List Sentry issues. Returns the raw Sentry array. Wrappers above
 * (MCP / assistant tool handlers) format the shape for LLM consumers;
 * deterministic callers get the raw issue objects so their own
 * outputSchema can validate / reshape.
 *
 * @param {{ query?: string, sort?: string, project?: string, limit?: number }} opts
 */
export function sentryListIssues({ query, sort, project, limit }?: {
    query?: string;
    sort?: string;
    project?: string;
    limit?: number;
}): Promise<any>;
/**
 * Resolve an issue REFERENCE (numeric id OR shortId) to its NUMERIC issue
 * (group) id. The global `/issues/<id>/` endpoints used by get/update/comment
 * accept ONLY the numeric id — a shortId (e.g. `PROJECT-ABC`) 404s there. So a
 * caller that hands us the shortId (which is what Sentry surfaces everywhere,
 * and what our workflow input schemas advertise as "numeric or shortId") would
 * silently fail. Sentry's shortId→group resolver is ORG-scoped:
 * `GET /organizations/<org>/shortids/<shortId>/` → { groupId }.
 *
 * A purely-numeric ref returns immediately with NO API call, so the common path
 * (callers already holding the numeric id from a fetched issue) is free.
 */
export function resolveSentryIssueId(issueRef: any): Promise<string>;
/**
 * Fetch one Sentry issue's details. Uses the global `/issues/<id>/`
 * endpoint (NOT under /organizations/<slug>/) — Sentry routes issue
 * details by ID without an org scope. Auth still uses the connected
 * integration's token. Accepts a numeric id OR a shortId (resolved first).
 */
export function sentryGetIssue(issueId: any): Promise<any>;
/**
 * WRITE-back to a Sentry issue. Mutates issue STATE (resolve / ignore / mute /
 * reopen), assignment, bookmark, or seen-flag via the global
 * `PUT /issues/<id>/` endpoint (NOT org-scoped — issues route by id, same as
 * sentryGetIssue). Only the fields you pass are sent.
 *
 * Common uses:
 *   sentryUpdateIssue(id, { status: 'resolvedInNextRelease' })  // leaves the
 *     is:unresolved queue, regresses only if it recurs in a LATER release
 *   sentryUpdateIssue(id, { status: 'resolved', statusDetails: { inRelease: 'latest' } })
 *   sentryUpdateIssue(id, { status: 'ignored' })
 *   sentryUpdateIssue(id, { assignedTo: 'user:123' })
 *
 * @param {string} issueId
 * @param {{ status?: 'resolved'|'resolvedInNextRelease'|'unresolved'|'ignored'|'muted',
 *           statusDetails?: object, assignedTo?: string, isBookmarked?: boolean,
 *           hasSeen?: boolean }} update
 *
 * Requires the connected Sentry integration's token to carry the `event:write`
 * scope. A 403 → a CLEAR error telling the operator the Sentry connection likely
 * lacks write scope and must be reconnected with it.
 */
export function sentryUpdateIssue(issueId: string, update?: {
    status?: "resolved" | "resolvedInNextRelease" | "unresolved" | "ignored" | "muted";
    statusDetails?: object;
    assignedTo?: string;
    isBookmarked?: boolean;
    hasSeen?: boolean;
}): Promise<any>;
/**
 * Post a comment ("note") on a Sentry issue via
 * `POST /issues/<id>/comments/`. Same global-issue endpoint + token as
 * sentryGetIssue / sentryUpdateIssue, and the same `event:write`-scope 403 →
 * clear-error contract.
 *
 * @param {string} issueId
 * @param {string} text  the comment body (Sentry markdown)
 */
export function sentryAddComment(issueId: string, text: string): Promise<any>;
export namespace sentrySkill {
    import tools = sentrySkill.toolsForAssistant;
    export { tools };
}
