DYLA-ai: Skill for Claude Code

/ticket — Maintenance triage

Support is usually done by a different team from the one that built the thing. Faced with a ticket, the time goes first of all into working out where to look.

On a delivered project that answer is already written in our own deliverables: the estimate says what was built, the data model says where the data lives, the mockup says what the user sees, the brief says what should happen.

This skill does not fix the ticket and does not touch code. It points.

---

UX: chat stays conversational. The triage is an answer in chat, not a deliverable: no JSON gets written. Cite dev tasks by id and name, and chapters of the brief as [[brief:Title]], so the reader gets there with one click.

PROTOCOL

1. Get the ticket text from the user (or from the file they point at)
2. Read the project deliverables
3. Answer with the triage: where to look, what should happen, hypothesis
4. Do not modify any file unless explicitly asked

---

PHASE 1 — THE TICKET

If the user has not pasted the text, ask for it in a ```questions block (format in .Codex/prompts/questions_format.md):

```questions
[
  {
    "id": 1,
    "q": "Paste the ticket text so I can triage it.",
    "options": ["I'll paste it now"],
    "hint": "as it arrived, bad grammar and all"
  }
]
```

You want it as it arrived: the end user's own words tell you which screen they are looking at the problem from.

If the project is still in flight (estimate in draft, dev tasks unfinished), say so: this skill is at its best on a delivered application, where the deliverables describe something that actually exists.

---

PHASE 2 — READING

Read ALL of these before answering:

• projects/{project}/estimate.json — epics, tasks and dev tasks: the inventory of what was built, with the layer telling you what kind of thing each piece is
• projects/{project}/data_model.json — tables, fields, relations
• projects/{project}/mockup.json — the pages and their names: the bridge between the user's words ("the requests screen") and the objects
• the brief (brief.json or the input document, possibly via .extracted/)
• projects/{project}/context.md — decisions and assumptions: many apparent anomalies are behaviours somebody decided on deliberately
• projects/{project}/test_plan.json — if it exists: a case covering the flow tells you how to reproduce it
• knowledge/ — if the folder exists: naming and client patterns