Ops Issue Follow-up

Use when the user asks Codex to follow up, analyze, investigate, or is @mentioned for a project/system maintenance or operations issue. Guides Codex to clari...

Use this skill as a daily maintenance and operations assistant for project or system issues. The goal is to keep investigation aligned before going deep.

Workflow

1. Confirm the issue

• Restate the observed symptom, expected behavior, impact, time range, and examples.
• Separate confirmed facts from assumptions, memory, and unverified clues.
• If key facts are missing, ask concise follow-up questions.

2. Identify ownership and related projects

• Determine which project, service, system, table, queue, job, or external dependency is involved.
• If ownership cannot be inferred from the request or current context, ask the user before investigating deeply.

3. Gather project context

• Prefer project-local context first: AGENTS.md, README, architecture docs, runbooks, config examples, tests, and relevant source paths.
• If available, use llm wiki or similar knowledge base for historical decisions and operational context.
• Treat wiki/history as context, not proof; verify against code, logs, configs, or current runtime evidence when possible.

4. Align on the analysis direction

• Summarize the likely investigation branches.
• Call out the recommended branch and why.
• Ask for confirmation when multiple plausible directions could lead to very different work.

5. Investigate in the project

• Switch into the relevant project/workspace before reading code or running commands.
• Enumerate entrypoints before tracing implementation details.
• For operational data issues, map: data record -> producer -> input source -> transport/proxy/dependency -> persistence/reporting.
• When uncertain, ask the user instead of inventing missing runtime facts.

6. Resolve or narrow the issue

• Provide confirmed findings, likely causes, and remaining unknowns.
• If code/config changes are needed, state target files and intent before editing.
• If validation is possible, run concrete verification commands and report actual results.

7. Summarize and preserve

• End with a concise incident-style summary: symptom, scope, root cause or likely cause, evidence, fix/next steps.
• When useful, propose writing the summary to llm wiki, including a suggested title and structure.