tour · git:20260819.fda278e · 2026-08-19 · sha256 d9fd9532ba6e3ad5

tour git:20260819.fda278eA

Immutable. This exact content is served forever at /api/v1/blob/d9fd9532ba6e3ad5.

---
name: tour
description: Interactive onboarding walkthrough for a new engineer. Use for "give me a tour", "onboard me", "walk me through the codebase".
---

# Draft Tour: Interactive Onboarding

Provide an interactive codebase walk-through based on existing architecture and guardrail constraints.

## Red Flags - STOP if you're

- Dumping the entire `architecture.md` into the chat window.
- Giving answers to foundational pattern questions before prompting the developer to guess.
- Explaining code the developer hasn't explicitly asked to view yet.

---

## Execution Constraints

1. **Load Context:** Read `draft/architecture.md`, `draft/tech-stack.md`, and `draft/guardrails.md`.
2. **Interactive Cadence:** Ask the developer if they are familiar with the tech stack constraints found in `draft/tech-stack.md`.
3. **Module Introduction:** Instead of listing all modules, introduce the "Entry Point" module first.
4. **Active Challenge:** After explaining a module's responsibility, challenge the developer: "Based on our *Context-Driven Development* rules, how do you think we handle data persistence here?" Wait for their answer before revealing the architecture strategy.
   - If the answer is correct, confirm briefly and cite the supporting line in `architecture.md` / `guardrails.md`.
   - If the answer is partially right, name what they got right, then ask a narrower follow-up (e.g., "Right that we cache reads — what's the invalidation trigger?") before revealing the rest.
   - If the answer is wrong, do not just hand them the answer. Quote the specific guardrail or HLD section that contradicts it, then re-prompt with a hint scoped to that section.
5. **Traceability:** Highlight `draft/.state/facts.json` showing how module constraints have evolved.
6. **Track Lifecycle Walk:** Show the full feature lifecycle and who owns each gate:
   - `/draft:new-track` → `spec.md` (requirements + classification + approvers) + `plan.md` (phases/tasks)
   - `/draft:decompose` → `hld.md` (always, with graph-derived diagrams) + `lld.md` (when --lld or High-complexity module)
   - **Approvers (HLD):** Technical Leads, Architecture Review Board, Cloud Operations (SaaS), QA Leads (on-prem), PM Leads
   - **Approvers (LLD):** Team Leads, Technical Leads, Quality Assurance
   - `/draft:implement` → TDD loop reading lld.md/hld.md for stub generation
   - `/draft:upload` → blocks `git upload` for high/mission-critical tracks until HLD §Approvals signed
   - `/draft:deploy-checklist` → blocks deploy until HLD §Checklist + LLD §Alerting Thresholds populated
   - Walk a real example track from `draft/tracks/` if any exist; otherwise sketch a hypothetical low-criticality flow.
7. **Completion:** Guide the developer to create their first test track using `/draft:new-track` so they understand the artifact loop end-to-end.

---