Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

Comenzar

analyze-problem

Estrellas4347

Forks347

Actualizado22 de abril de 2026, 13:52

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

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

latitude-dev

latitude-dev/latitude-llm

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·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.

Más de este repositorio

mismo repositorio

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.