Run any Skill in Manus with one click

Get Started

analyze-problem

Stars4,347

Forks347

UpdatedApril 22, 2026 at 13:52

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

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

latitude-dev

latitude-dev/latitude-llm

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·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.

More from this repository

same repository

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.