ワンクリックでManusで任意のスキルを実行

tour

スター39

フォーク5

更新日2026年5月18日 02:01

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

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

drafthq

drafthq/draft

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

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

Load Context: Read draft/architecture.md, draft/tech-stack.md, and draft/guardrails.md.
Interactive Cadence: Ask the developer if they are familiar with the tech stack constraints found in draft/tech-stack.md.
Module Introduction: Instead of listing all modules, introduce the "Entry Point" module first.
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.
Traceability: Highlight draft/.state/facts.json showing how module constraints have evolved.
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.
Completion: Guide the developer to create their first test track using /draft:new-track so they understand the artifact loop end-to-end.

このリポジトリの他の Skills

同じリポジトリ

adr

drafthq/draft

Create and manage Architecture Decision Records. Documents significant technical decisions with context, alternatives, and consequences. Also supports evaluate (assess proposals) and design (system design) modes.

2026-07-1639

bughunt

drafthq/draft

Performs an exhaustive 14-dimension bug hunt across the codebase using Draft context (architecture, tech-stack, product) for false-positive elimination. Generates a severity-ranked report with code evidence, data flow traces, and suggested fixes. Optionally writes regression tests. Use when the user asks to find bugs, audit code for defects, scan for vulnerabilities, or says 'hunt bugs', 'find bugs', or 'code audit'.

2026-07-1639

coverage

drafthq/draft

Compute code coverage for active track or module. Targets 95%+ coverage with report and justification for uncovered lines. Complements TDD workflow.

2026-07-1639

debug

drafthq/draft

Structured debugging session. Reproduce, isolate, diagnose, and fix bugs using systematic investigation. Invoked by /draft:new-track for bug tracks or directly for ad-hoc debugging.

2026-07-1639

decompose

drafthq/draft

Decompose project or track into modules with dependency mapping. Project scope updates architecture.md and derives .ai-context.md. Track scope generates hld.md (always) and lld.md (when --lld or High-complexity module triggers it) — design-mandated artifacts that drive implement, deploy-checklist, and upload sign-off.

2026-07-1639

deep-review

drafthq/draft

Single-module production readiness audit (ACID, resilience, observability). Use to audit one service/module end-to-end — NOT for diff/PR review (use review / quick-review) or bug-finding sweeps (use bughunt).

2026-07-1639

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

Load Context: Read draft/architecture.md, draft/tech-stack.md, and draft/guardrails.md.

Interactive Cadence: Ask the developer if they are familiar with the tech stack constraints found in draft/tech-stack.md.

Module Introduction: Instead of listing all modules, introduce the "Entry Point" module first.

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.

Traceability: Highlight draft/.state/facts.json showing how module constraints have evolved.

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.

Completion: Guide the developer to create their first test track using /draft:new-track so they understand the artifact loop end-to-end.

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