Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

Começar

analyze-problem

Estrelas4.347

Forks347

Atualizado22 de abril de 2026 às 13:52

Analyze a problem and provide a detailed explanation of the issue, root cause, proposed fix, and verification steps.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

latitude-dev

latitude-dev/latitude-llm

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	analyze-problem
description	Analyze a problem and provide a detailed explanation of the issue, root cause, proposed fix, and verification steps.

Read the provided bug report/issue/task.

Then thoroughly investigate the codebase to understand the relevant context:

Find the entry points involved (routes/handlers/jobs/commands) and trace the execution path that leads to the reported behavior.
Identify the data flow and state involved (inputs, validation, persistence, caching, permissions, feature flags, side effects).
Locate the expected behavior (specs/tests/docs) and compare it to the actual behavior in code.
If the report includes steps to reproduce, map each step to the corresponding code path and decision points.
Consider common edge cases (null/empty values, timing/race conditions, retries, idempotency, pagination, timezones, auth, stale cache).

Deliverable: Explain, in your own words:

What you believe the issue is (observable behavior + when it happens),
Why you believe it is happening (root cause and the specific assumption/logic that breaks),
How you would fix it (proposed approach and what behavior/logic should change),
What you would verify (minimal set of checks/tests/logs to confirm the fix and prevent regressions).

Constraints:

Do not apply any changes automatically.
Avoid listing files/components/services unless strictly necessary to support the explanation.
If the codebase does not contain enough context to be confident, explicitly say what’s missing and what evidence would confirm the hypothesis.

Mais deste repositório

mesmo repositório

api-endpoints

latitude-dev/latitude-llm

Adding or changing routes in `apps/api`. One source of truth (`defineApiEndpoint` + a Zod schema) becomes an HTTP endpoint, an OpenAPI operation, an MCP tool, and a TS SDK method — descriptions and contracts must be written with all four readers in mind.

2026-06-304.3k

architecture-boundaries

latitude-dev/latitude-llm

Layering and boundaries, web vs public API, app layout (clients, routes, logging), ports/adapters, runtime-portable domain/shared/utils code, multi-tenancy, DDD layout, or anti-patterns.

2026-06-304.3k

production-release

latitude-dev/latitude-llm

Preparing a production release, pushing a vX.Y.Z release tag, running scripts/release.sh, or updating CHANGELOG.md with the changes that are about to be deployed to production.

2026-06-244.3k

managing-maintenance-windows

latitude-dev/latitude-llm

Enables or disables Latitude production maintenance mode by redirecting all publicly exposed production services to the Better Stack status page. Use when asked to start, stop, toggle, verify, or prepare a maintenance window.

2026-06-184.3k

env-configuration

latitude-dev/latitude-llm

Adding or reading env vars, updating .env.example, or validating config at startup with parseEnv / parseEnvOptional.

2026-06-154.3k

database-clickhouse-weaviate

latitude-dev/latitude-llm

ClickHouse queries, Goose migrations, chdb test schema, or telemetry storage paths.

2026-06-124.3k

name	analyze-problem
description	Analyze a problem and provide a detailed explanation of the issue, root cause, proposed fix, and verification steps.

Read the provided bug report/issue/task.

Then thoroughly investigate the codebase to understand the relevant context:

Find the entry points involved (routes/handlers/jobs/commands) and trace the execution path that leads to the reported behavior.
Identify the data flow and state involved (inputs, validation, persistence, caching, permissions, feature flags, side effects).
Locate the expected behavior (specs/tests/docs) and compare it to the actual behavior in code.
If the report includes steps to reproduce, map each step to the corresponding code path and decision points.
Consider common edge cases (null/empty values, timing/race conditions, retries, idempotency, pagination, timezones, auth, stale cache).

Deliverable: Explain, in your own words:

What you believe the issue is (observable behavior + when it happens),
Why you believe it is happening (root cause and the specific assumption/logic that breaks),
How you would fix it (proposed approach and what behavior/logic should change),
What you would verify (minimal set of checks/tests/logs to confirm the fix and prevent regressions).

Constraints:

Do not apply any changes automatically.
Avoid listing files/components/services unless strictly necessary to support the explanation.
If the codebase does not contain enough context to be confident, explicitly say what’s missing and what evidence would confirm the hypothesis.