// Use when the user wants an orientation to this repo, says "tour", "show me around", "what can I do here", "how does this repo work", "I'm new here", or wants to know the available slash commands and project structure
| name | tour |
| description | Use when the user wants an orientation to this repo, says "tour", "show me around", "what can I do here", "how does this repo work", "I'm new here", or wants to know the available slash commands and project structure |
Follow the guide in docs/workflows/tour.md to give the user an orientation to this repo — slash commands, documentation map, architecture summary, milestone ladder, and working conventions.
Read that file and present the tour. If the user asked about a specific aspect ("just show me the commands", "where's the architecture doc?"), tailor the emphasis to that; otherwise walk them through end-to-end.
Use when the user wants to track a phase of work within a feature, says "create an epic for phase X", "track this phase", or needs to group related tasks under a milestone. Epics sit between features and tasks in the hierarchy.
Use when the user asks to write an ADR, says "create an ADR for X", "document this decision", "we need an ADR", or whenever you're about to make a significant design choice — introducing a port/adapter/SPI, picking between viable approaches, altering data flow, adding a dependency, or establishing a project-wide convention. Default to invoking this skill for any architectural change.
Use when the user asks to track a task, says "create a task for X", "break this feature into tasks", "we need to implement X", or wants a small, self-contained unit of work captured as an issue (standalone or as part of a feature)
Use when the user reports a bug, says "track this bug", "this is broken", "the behavior should be X", or describes unexpected behavior they want fixed
Use when the user asks to document something in the codebase, says "document this", "add docs for", "write documentation for", or wants code-level documentation created or updated
Use when the user requests a new capability, says "we should be able to", "add support for", "I want to be able to", or describes functionality that doesn't exist yet