# Director:onboard > Set up a new project or map an existing one. Creates your vision document through a guided interview. - **Type:** Skill - **Install:** `agentstack add skill-noahrasheta-director-onboard` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [noahrasheta](https://agentstack.voostack.com/s/noahrasheta) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [noahrasheta](https://github.com/noahrasheta) - **Source:** https://github.com/noahrasheta/director/tree/main/skills/onboard - **Website:** https://director.cc/ ## Install ```sh agentstack add skill-noahrasheta-director-onboard ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Director Onboard First, check if `.director/` exists. If it does not, run the init script silently: ```bash bash "${CLAUDE_PLUGIN_ROOT}/scripts/init-director.sh" ``` Say only: "Director is ready." Then continue with the steps below. --- ## Determine Project State Read `.director/VISION.md` and determine the project state. The init script creates a VISION.md with placeholder text like: - `> This file will be populated when you run /director:onboard` - Headings like `## What are we building?` with no content beneath them The onboard template uses a different format with placeholder text like: - `_What are you calling this project?_` - `_One or two sentences about what this project does, in plain language._` **Detection rule:** If VISION.md contains either type of placeholder text -- or if headings have no substantive content beneath them (just blank lines, italic prompts, or template markers) -- the project has NOT been onboarded yet. Proceed to Detect Project Type. **If VISION.md has real content** (substantive text under headings -- actual project descriptions, feature lists, tech choices, not just placeholders): The user has already onboarded. Check whether there are existing codebase files beyond `.director/` by looking at the project root. If there are substantial files (source code, configs, assets), this is an existing project that may need mapping. Say something like: > "You already have a vision document. Want to update it, or would you like me to look through your existing code to make sure everything is captured?" Wait for the user's response before proceeding. **If they want to update their vision:** Go to the Greenfield Interview section with their existing vision as context. Follow interviewer rule 7: adapt to what's already known -- skip questions that are already answered in the existing vision and focus on gaps, changes, and new information. This is an update conversation, not a redo. **If they want to map their code:** Run the deep mapping pipeline (see the Mapper Spawning section below for the exact process) to produce a comprehensive codebase analysis. Once the mapping is complete and findings are presented, ask the user if anything in the findings changes what they want to build or suggests updates to their vision. If yes, walk them through updating the relevant parts of their vision document. If the vision looks accurate, confirm and move on. --- ## Detect Project Type After confirming the project is not yet onboarded, determine if this is a new project or an existing one. Check for existing source files beyond `.director/` by looking at the project root. Signs of an existing project: - `package.json`, `requirements.txt`, `go.mod`, `Cargo.toml`, or `Gemfile` exists - `src/`, `app/`, `lib/`, or `pages/` directory exists If any of these exist, this is an **existing project** (brownfield). Say something like: > "I see you already have code here. Let me take a look at what you've built so far." Then proceed to the Brownfield section below. If none of these exist, this is a **new project** (greenfield). Say something like: > "Let's figure out what you're building. I'll ask you some questions one at a time -- just answer naturally, and I'll put together a vision document from our conversation." Then proceed to Handle Initial Context from Arguments. --- ## Handle Initial Context from Arguments Check if the user provided arguments via `$ARGUMENTS`. **If arguments were provided** (the text after `/director:onboard` is not empty): Treat the arguments as initial context about their project. The user has already told you something about what they want to build. Confirm your understanding of what they described, then continue the interview from there -- skip the "What are you building?" question since they already answered it. For example, if they said `/director:onboard "a task management app for teams"`, you might respond: > "A task management app for teams -- got it. Let me ask a few more questions so I can capture the full picture." Then proceed to the interview starting from section 2 (Who is it for?). **If no arguments were provided:** Start the interview from the beginning with section 1 (What are you building?). --- ## Greenfield Interview Conduct the interview directly in this conversation. Follow these rules carefully: ### Interview Rules 1. **Ask ONE question at a time.** Never dump multiple questions in a single message. Let the user answer, confirm you understood, then move on. 2. **Use multiple choice when possible.** Provide A, B, C options to make decisions easy. The user can always type a custom answer instead of picking an option. 3. **Gauge preparation level early.** The user's first 1-2 answers tell you how to pace the rest of the interview: - **Detailed, specific answer** (e.g., "I'm building a SaaS habit tracker with Next.js, Supabase, and Clerk auth, deploying on Vercel") -- this user has done their homework. Move faster, skip basics, jump to gaps and decisions they may not have considered. - **Vague answer** (e.g., "I want to build an app" or "Something with AI") -- this user is still exploring. Slow down, offer more guidance, provide more multiple-choice options, and explain the implications of each choice. 4. **Surface decisions the user hasn't considered.** Proactively ask about things they may not have thought of yet: - How users will log in (authentication) - Where data will be stored (database) - What tech stack fits their needs and why - Whether they need real-time features (live updates, chat, notifications) - File uploads or media handling - Payments or billing - Third-party services (email, analytics, maps, etc.) - Where the project will be hosted Only bring up topics that are relevant to THIS project. Don't ask about payments for a personal CLI tool or load balancing for a blog. 5. **Confirm understanding before moving on.** After each answer, briefly restate what you heard and check that it's right. Keep confirmations short -- a sentence, not a paragraph. 6. **Flag ambiguity with [UNCLEAR] markers.** If an answer is vague or contradictory, don't assume -- mark it and ask a follow-up to clarify. For example: > "When you say 'mobile,' do you mean: > A) A mobile-friendly website (responsive design) > B) A native mobile app (downloaded from an app store) > C) Both -- a website and a separate app > This helps me suggest the right tech approach." If the user can't decide yet, that's fine -- record it as an open question with an [UNCLEAR] marker. 7. **Adapt to what's already known.** If the user provided arguments, or if you're updating an existing vision, skip questions that are already answered. Focus on gaps and new information. 8. **Don't ask about things that don't matter yet.** If the user is building a simple personal tool, don't ask about multi-region hosting or team permissions. Match the complexity of your questions to the complexity of their project. 9. **Read the room.** If the user seems impatient or gives short answers, pick up the pace -- combine related topics, skip less important sections, and wrap up sooner. If they seem unsure or are enjoying the conversation, take more time and offer more context for each decision. ### Interview Sections Work through these areas in order. Skip sections that aren't relevant to this project, and adapt based on the user's preparation level. A typical interview is 8-15 questions. **1. What are you building?** Get a 1-2 sentence summary of the project. This becomes the elevator pitch. Ask something like: "What do you want to build? Just a sentence or two about the idea." **2. Who is it for?** Identify the target users. Is it for the builder themselves, a team, customers, the public? This shapes almost every decision that follows. **3. Key features** Start by asking for the top 3 most important things the project should do. Then ask if there are more. Group features naturally -- must-haves vs nice-to-haves. Don't force a rigid structure; let the user describe it their way. **4. Tech stack** Based on the features described, suggest a tech stack that fits. Explain WHY each choice makes sense for THIS project, not just what's popular. Let the user override any suggestion -- if they have preferences ("I want to use Next.js"), respect those. If the user has no preference, make a clear recommendation and explain the reasoning. **5. Where will it live?** Ask about hosting. Offer simple options: Vercel, Netlify, Railway, or "I'll figure that out later." This is about understanding the user's comfort level, not making a final decision. **6. What does "done" look like?** Help the user define success criteria. What would make them say "v1 is complete"? These become the goals later. Push for specifics -- "users can sign up and track their habits" is better than "it works." **7. Decisions already made** Ask if they've already committed to any choices -- tech stack, design style, specific libraries, hosting provider, color scheme, anything. Don't redo decisions they've already made. Record these as-is. **8. Anything you're unsure about?** Give the user space to voice concerns, unknowns, or areas where they want guidance. These become open questions in the vision. Mark unresolved items with [UNCLEAR]. ### Interview Wrap-Up When you've covered all relevant sections (or the user signals they're ready to move on), let them know you have what you need: > "I think I have a good picture. Let me put together your vision document." Then proceed to Generate Vision Document. --- ## Brownfield This section handles projects that already have code. The flow is: map the codebase with multiple focused agents, synthesize the findings, present a summary to the user, then run an adapted interview focused on what the user wants to change. ### Greenfield Detection Before mapping, verify this is actually a brownfield project. If the project has no meaningful source files -- only `.director/` and maybe a README -- skip the entire mapping pipeline and redirect to the Greenfield Interview section. Say something like: > "I don't see much code here yet. Let's start fresh -- I'll ask you some questions about what you want to build." Then proceed directly to Handle Initial Context from Arguments and the Greenfield Interview. Do NOT create `.director/codebase/` or spawn any mapper agents for greenfield projects. ### Codebase Size Assessment Before spawning mappers, do a quick size check: ```bash # Count source files (excluding common non-source directories) find . -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.jsx" -o -name "*.py" -o -name "*.rb" -o -name "*.go" -o -name "*.rs" -o -name "*.java" -o -name "*.swift" -o -name "*.vue" -o -name "*.svelte" \) -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/.director/*" -not -path "*/vendor/*" -not -path "*/dist/*" -not -path "*/build/*" | wc -l ``` If the codebase has more than 500 source files, add a sampling note to each mapper's instructions: "This is a large codebase. Focus on the main source directories first. Sample representative files rather than reading everything. Note what you skipped." ### Model Profile Resolution Read `.director/config.json` and resolve the model for each agent: 1. Read the `model_profile` field (defaults to "balanced") 2. Look up the profile in `model_profiles` to get base model assignments for `deep-mapper` and `synthesizer` 3. For the `quality` profile, override the arch and concerns mappers to use the most capable model available (since these are the highest-complexity analyses) The resolution produces a model assignment for each mapper and the synthesizer. If config.json is missing the `model_profile` or `model_profiles` fields, fall back to "balanced" defaults (deep-mapper gets haiku, synthesizer gets sonnet). ### Mapper Spawning Ensure `.director/codebase/` directory exists before spawning mappers. Create it if it doesn't exist: ```bash mkdir -p .director/codebase ``` Tell the user you're mapping their codebase. Show a single message: > "Mapping your codebase..." Then spawn 4 director:director-deep-mapper agents IN PARALLEL using 4 simultaneous Task tool calls. Each agent gets different instructions specifying its focus area. The instructions are wrapped in XML boundary tags. All 4 Task tool calls go in a SINGLE message so they run in parallel. Do NOT wait for one mapper to finish before spawning the next. **Agent 1 (tech focus):** ``` Focus area: tech Analyze the technology stack and external integrations of this codebase. Write your findings to: - .director/codebase/STACK.md (using the template at skills/onboard/templates/codebase/STACK.md) - .director/codebase/INTEGRATIONS.md (using the template at skills/onboard/templates/codebase/INTEGRATIONS.md) Follow your standard mapping process for the tech focus area. Include file paths in backticks for every finding. Return only a brief confirmation when done. Do NOT return document contents. ``` **Agent 2 (arch focus):** ``` Focus area: arch Analyze the architecture patterns and file structure of this codebase. Write your findings to: - .director/codebase/ARCHITECTURE.md (using the template at skills/onboard/templates/codebase/ARCHITECTURE.md) - .director/codebase/STRUCTURE.md (using the template at skills/onboard/templates/codebase/STRUCTURE.md) STRUCTURE.md must include a prescriptive "Where to Add New Code" section telling agents exactly where to place new files for each type of addition (new feature, new API route, new component, new test, etc.). Follow your standard mapping process for the arch focus area. Include file paths in backticks for every finding. Return only a brief confirmation when done. Do NOT return document contents. ``` **Agent 3 (quality focus):** ``` Focus area: quality Analyze the coding conventions and testing patterns of this codebase. Write your findings to: - .director/codebase/CONVENTIONS.md (using the template at skills/onboard/templates/codebase/CONVENTIONS.md) - .director/codebase/TESTING.md (using the template at skills/onboard/templates/codebase/TESTING.md) CONVENTIONS.md must use prescriptive voice throughout. Say "Use camelCase for functions" not "Some functions use camelCase." Every convention must be a clear instruction for builder agents. Follow your standard mapping process for the quality focus area. Include file paths in backticks for every finding. Return only a brief confirmation when done. Do NOT return document contents. ``` **Agent 4 (concerns focus):** ``` Focus area: concerns Analyze technical debt, known issues, and fragile areas of this codebase. Write your findings to: - .director/codebase/CONCERNS.md (using the template at skills/onboard/templates/codebase/CONCERNS.md) Be specific about the impact of each concern and suggest a fix approach. Prioritize concerns by severity. Follow your standard mapping process for the concerns focus area. Include file paths in backticks for every finding. Return only a brief confirmation when done. Do NOT return document contents. ``` If any mapper fails or times out, note the failure but continue with whatever mappers succeeded. The synthesizer can work with partial input. If ALL mappers fail, fall back to the v1.0 director:director-mapper agent for a basic overview instead. ### Synthesizer Spawning After ALL 4 mappers have completed (or failed), spawn the director:director-synthesizer agent. This runs SEQUENTIALLY after the mappers (not in parallel with them). ``` Mode: codebase Read all codebase analysis files from .director/codebase/ (STACK.md, INTEGRATIONS.md, ARCHITECTURE.md, STRUCTURE.md, CONVENTIONS.md, TESTING.md, CONCERNS.md). Synthesize them into a unified summary. Write your output to .director/codebase/SUMMARY.md using the template at skills/onboard/templates/codebase/SUMMARY.md. Cross-reference findings acros … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [noahrasheta](https://github.com/noahrasheta) - **Source:** [noahrasheta/director](https://github.com/noahrasheta/director) - **License:** MIT - **Homepage:** https://director.cc/ Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-noahrasheta-director-onboard - Seller: https://agentstack.voostack.com/s/noahrasheta - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.