/fix-bug check reported bug # GIT-123

---

Users define the process.
Codex executes it.

---

sequential-prompts/
  understand-request.md
  inspect-project.md
  implement.md
  verify.md
  summarize.md

---

video-production/
  prepare.md
  develop-story.md
  plan-scenes.md
  generate-assets.md
  produce-video.md
  review-output.md

---

fix-bug/
  WORKFLOW.md
  adapt-input.md
  read-ticket.md
  reproduce.md
  triage.md
  understand-project.md
  implement.md
  verify.md
  static-analysis.md
  loop-on-failure.md
  update-ticket.md
  summarize.md

---

# WORKFLOW.md

Run these nodes in order:
adapt-input -> read-ticket -> reproduce -> triage -> understand-project
-> implement -> verify -> static-analysis -> update-ticket -> summarize

If `verify` or `static-analysis` fails, run `loop-on-failure`.
After `loop-on-failure` resolves the cause, resume at the appropriate
earlier node and continue forward.
If the ticket lacks critical details, stop and ask the user.

---

# adapt-input.md

Parse the workflow invocation.
Bind values such as `ticket_id = GIT-123`, requested action,
project name, branch name, or target artifact.
Use those values throughout the workflow without editing the original
node files. If a required value is missing, ask the user.

---

# read-ticket.md

Read the ticket or work item referenced by `ticket_id`.
Extract the user-visible problem or request, expected behavior,
actual behavior, acceptance criteria, severity, environment,
repro steps, logs, screenshots, and related links.

---

# reproduce.md

Try to reproduce the reported behavior using the ticket details.
If the issue cannot be reproduced, identify the closest verifiable
path and list what information is missing.

---

# triage.md

Map the ticket to likely product areas.
Identify the suspected root cause, affected files, related tests,
dependencies, and whether the ticket describes a regression,
missing behavior, or ambiguous requirement.

---

# understand-project.md

Before changing code, inspect the project's rules, conventions,
architecture, existing patterns, and relevant documentation.
Prefer local conventions over new abstractions.
Identify constraints that should shape the implementation.

---

# implement.md

Make the smallest safe code change that satisfies the ticket.
Preserve existing behavior unless the ticket explicitly requires a change.
Do not modify generated files or unrelated areas.

---

# verify.md

Add or update focused tests for the reported behavior or acceptance criteria.
Run the narrowest relevant tests first, then any broader checks required
by the workflow.

---

# static-analysis.md

After verification, run static analysis such as type checks, linting,
format checks, dependency checks, or project-specific analyzers.
Treat failures as workflow failures that must be investigated.

---

# loop-on-failure.md

If verification or static analysis fails, determine whether the problem
is the implementation, the test, the environment, or the ticket interpretation.
Return to the correct earlier node. If the same class of failure repeats,
stop and ask the user.

---

# update-ticket.md

Update the referenced ticket status or draft the exact update for the user.
Include the current state, cause or implementation notes, verification
evidence, remaining risks, and any open questions.

---

# summarize.md

Summarize the ticket, the cause or chosen approach, the code change,
the verification evidence, static analysis result, ticket status,
and any remaining risks.

---

video-production/
  WORKFLOW.md
  adapt-input.md
  prepare.md
  develop-story.md
  plan-scenes.md
  generate-assets.md
  produce-video.md
  review-output.md

---

/fix-bug check reported bug # GIT-123

---

adapt-input
  Parse the command, bind ticket_id = GIT-123, and use that value
  throughout the workflow without changing the saved node files.

read-ticket
  Read the ticket referenced by ticket_id.
  Extract the user-visible failure, expected behavior, actual behavior,
  environment, repro steps, attachments, and logs.

reproduce
  Use the ticket to reproduce the failure locally or identify the closest
  verifiable reproduction path.

triage
  Identify the likely root cause, affected files, related tests,
  and whether the ticket describes a regression or an existing gap.

understand-project
  Inspect project rules, conventions, architecture, and local patterns
  before editing. Identify constraints that should shape the fix.

implement
  Make the smallest safe code change that fixes the reported behavior.

verify
  Add or update a regression test, then run the narrowest relevant checks.

static-analysis
  Run type checks, linting, formatting checks, and project-specific analyzers
  after verification.

loop-on-failure
  If verification or static analysis fails, analyze whether the patch,
  the test, the environment, or the ticket interpretation is wrong,
  then return to the right step.

update-ticket
  Update the ticket referenced by ticket_id, or draft the exact ticket update with
  the cause, fix, verification result, and static analysis result.

summarize
  Explain what changed, what was tested, the static analysis result,
  the ticket status, and any remaining risks.

---

Treat the referenced ticket as the source of truth.
Use the workflow invocation to bind the current ticket ID.
Never require manual find-and-replace inside saved prompt files.
Extract repro steps before editing.
Always inspect tests before changing implementation code.
Understand project rules, conventions, and architecture before implementation.
Prefer minimal patches.
Do not modify generated files.
Run the narrowest regression test first, then the broader suite.
Run static analysis after verification.
Update the ticket status before the final summary.
If the ticket is missing critical repro details, stop and ask the developer.
If verification or static analysis fails twice, stop and ask the developer.

---

/ship-feature implement product request # GIT-456

---

adapt-input
  Parse the command, bind ticket_id = GIT-456, and use that value
  throughout the workflow without changing the saved node files.

read-request
  Read the request referenced by ticket_id.
  Extract the requested user behavior, acceptance criteria, product constraints,
  designs, and rollout notes.

clarify-requirements
  Restate the request, identify assumptions, and flag any missing acceptance criteria.

design-plan
  Propose the implementation approach, affected product areas,
  data changes, permissions, and files likely to change.

understand-project
  Inspect project rules, conventions, architecture, and local patterns
  before implementation. Adjust the plan to fit the existing system.

implement
  Add the feature according to the request and approved plan.

add-tests
  Add or update tests that cover the acceptance criteria from the request
  referenced by ticket_id.

verify
  Run tests and any workflow-specific acceptance checks.

static-analysis
  Run type checks, linting, formatting checks, and project-specific analyzers
  after verification. Resolve any failures.

update-ticket
  Update the ticket referenced by ticket_id, or draft the exact ticket update with
  implementation notes, verification evidence, static analysis result,
  and unresolved decisions.

prepare-pr
  Produce a PR-style summary with user-visible behavior,
  implementation notes, validation, and linked request context.

---

# read-request.md

Read the product request referenced by `ticket_id`.
Extract the requested user behavior, acceptance criteria,
constraints, designs, rollout notes, and related tickets.

---

# clarify-requirements.md

Restate the request in implementation terms.
Identify assumptions, missing acceptance criteria, product questions,
and decisions that need user confirmation before coding.

---

# design-plan.md

Propose the implementation approach.
Name affected product areas, data model changes, permissions,
API changes, UI states, migration needs, and files likely to change.

---

# add-tests.md

Add or update tests that prove the acceptance criteria.
Cover expected behavior, important edge cases, and any regression risk
introduced by the implementation.

---

# prepare-pr.md

Prepare a PR-style summary.
Include user-visible behavior, implementation notes, verification evidence,
static analysis result, ticket status, and remaining risks.

---

adapt input -> read ticket -> understand project -> implement -> verify -> static analysis -> update ticket -> summarize
adapt input -> develop story -> plan scenes -> generate assets -> produce video -> review output
review -> classify findings -> suggest fixes -> verify -> summarize
migrate -> understand architecture -> update call sites -> run compatibility checks -> static analysis

---

/workflow-name [task details]