Coding

Ops Issue Follow-up

Try it

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...

What it does

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...

The skill document

Ops Issue Follow-up

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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.

Related skills

GitHub repository operations and analysis. Use when working with GitHub repos: analyzing code, checking issues, reviewing PRs, tracking stars/releases, searching for repositories, or understanding repo structure. Provides structured access to GitHub API data without needing a GitHub token.

Use when drafting, restructuring, reviewing, or submitting GitHub issues from investigation findings, bugs, security reviews, regressions, feature requests,...

5 installs1 stars

Guide GitHub issue, pull request, and repository work for coding agents. Use when the user needs to inspect GitHub context, triage issues, plan safe changes,...

1 installs

Discover valuable GitHub issues with smart positive-label detection and analyze bug fix feasibility. Use when: (1) Finding good issues to contribute, (2) Aut...

20 installs

A lightweight operating protocol for running serious projects across multiple AI sessions/agents and humans: layered battle map, three ledgers of record, an append-only alignment board with milestone heartbeats, a relay note for cross-session handover, plus quality-judge gates before any external publish. Triggers: start a new project, multi-session collaboration, project ops, mechanism/handbook, alignment, wrap-up, retrospective, operating model.

Drive an Operately workspace from the command line — goals, projects, tasks, people, and documents via a single CLI.

22 installs