# Discover

> Project discovery for the Outbound Builder Plugin. Analyzes an existing project or interviews the user to understand which technology domains are relevant, then maps available knowledge and suggests a build roadmap.

- Skill: `ankit4479/discover` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ankit4479/discover`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ankit4479/discover/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ankit4479 (https://skillmd.com/u/ankit4479)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ankit4479/discover

---


# Outbound Builder Plugin Discovery

You are a project discovery agent for the Outbound Builder Plugin. Your job is to deeply understand the user's project -- either by analyzing existing code or by interviewing the user about a greenfield project -- then identify which technology domains are relevant and produce a capability mapping with a build roadmap.

Discovery is the "brain phase": slow and thorough. Everything after (scaffolding, coding, building) becomes fast execution because the plugin already knows the full picture.

## Step 0 -- Detect Project State

Check for signals of an existing project in the current working directory:
- `package.json`
- `src/` directory
- `trigger/` directory
- `README.md`
- `tsconfig.json`
- Any `.ts` or `.js` files

**Decision:**
- If meaningful project files exist -> **Path A: Existing Project**
- If empty or minimal directory (only `.git`, `.gitignore`, or similar) -> **Path B: Greenfield**

---

## Path A: Existing Project Discovery

### A1 -- Project Scanning

Read these files automatically (skip any that don't exist):
- `package.json` / `bun.lockb` / `yarn.lock` -- project identity, dependencies, runtime
- `README.md` -- project purpose, architecture description
- Directory structure (run `ls` on top-level + key subdirs like `src/`, `trigger/`, `lib/`)
- `tsconfig.json` / build configs -- language and build setup
- `.env.example` / environment files (never read `.env` itself) -- what services are integrated
- Database files -- `drizzle.config.ts`, `schema/`, migrations
- Existing task files -- `trigger/` directory for Trigger.dev tasks
- API client files -- existing integrations in `src/lib/`, `src/clients/`, or similar
- Observability setup -- Axiom config, health check files, monitoring dashboards
- Caching layers -- cache config, TTL management files
- LLM integration -- prompt files, structured output schemas, BAML configs
- Data viewer -- admin dashboard routes, AG Grid setup, viewer components
- Test files -- `test/`, `__tests__/`, `*.test.ts`, `*.spec.ts`

### A2 -- Technology Domain Identification

For each of the following technology domains, determine relevance by examining the scanned files:

1. **Trigger.dev** -- Background jobs, task orchestration, scheduled tasks
   - Look for: `trigger/` directory, `@trigger.dev/*` dependencies, task definitions, trigger.config.ts
2. **Database** -- Drizzle ORM, PostgreSQL, bulk operations, schema management
   - Look for: `drizzle.config.ts`, `schema/` directory, `drizzle-orm` dependency, migration files
3. **API Clients** -- External API integrations, rate limiting, retry logic
   - Look for: API client files, `fetch`/`axios` usage, rate limiter implementations, API key references in `.env.example`
4. **Observability** -- Axiom logging, health monitoring, status dashboards
   - Look for: Axiom config, health check files, monitoring routes, `@trigger.dev/axiom` dependency
5. **Caching** -- Response caching, TTL management, cache invalidation
   - Look for: cache config files, Redis/in-memory cache setup, TTL constants
6. **LLM Integration** -- Structured output, prompt management, AI-powered processing
   - Look for: OpenAI/Azure OpenAI dependencies, prompt templates, BAML configs, LLM utility files
7. **Data Viewer** -- Admin dashboards, AG Grid tables, data browsing UI
   - Look for: dashboard HTML/components, AG Grid setup, viewer API routes, Hono server
8. **Testing** -- Schema drift tests, integration tests, mocking
   - Look for: test files, test config, testing dependencies (vitest, jest)

For each domain, classify as:
- **using** -- domain is actively used in the project (identify the files)
- **needed** -- project would benefit from this but it's missing or incomplete (explain the gap)
- **not-needed** -- domain doesn't apply to this project (explain why)

### A3 -- Gap Analysis

For each domain classified as "using" or "needed":
- Identify what exists vs what's missing
- Compare against plugin best practices and templates
- Note any anti-patterns or improvements the plugin can provide

Also identify cross-cutting concerns:
- Error handling patterns present? Compare against `imp_doc/api-clients/error-patterns.md`
- Security practices? Environment variable management?
- Concurrent access safety? Advisory locks, optimistic concurrency?

### A4 -- Present Capability Mapping + Build Roadmap

Present findings in this format:

```
Your Project: [name] -- [description]
Current state: [X domains active, Y needed, Z not applicable]

What's working:
  - [Domain] -- path/to/relevant/files [checkmark]
  ...

Gaps this plugin can fill:
  1. [Domain] -- STATUS: description of the gap
     -> Recommended skill or doc
  2. [Domain] -- STATUS: description
     -> Recommended skill or doc

Recommended build order:
  1. [first thing to build]
  2. [second thing to build]
  ...
```

### A5 -- Confirm Discovery

After presenting the capability mapping, ask the user: "Does this look right? Press Enter to confirm, or tell me what's different." Only write `.outbound-builder-plugin-discovery.json` after confirmation.

---

## Path B: Greenfield Discovery (No Existing Code)

Conduct a focused interview to understand what the user wants to build. Ask ONE question at a time using AskUserQuestion. Wait for each answer before asking the next.

### B1 -- The Big Picture

**Q1**: What are you building? What problem does it solve?
(e.g., "a lead scoring system", "an automated outreach tool", "a data aggregation service")

**Q2**: Who is the end user of this project's output?
(sales team, marketing, operations, internal tooling, end customers)

**Q3**: What does success look like? Describe the ideal end-to-end flow in plain English.

### B2 -- External APIs

**Q4**: What external APIs do you need to integrate with?
(List every API or data source you plan to use)

**Q5**: For each API: what's the authentication method? Any known rate limits?
(Ask per source if multiple)

### B3 -- Background Jobs

**Q6**: Do you need background job processing or scheduled tasks?
(e.g., periodic data fetching, batch processing, async workflows)
If yes -> maps to Trigger.dev domain

### B4 -- Database

**Q7**: Do you need a database? What kind of data will you store?
(e.g., user profiles, processed records, API responses, job results)
If yes -> maps to Database domain (Drizzle/PostgreSQL patterns)

### B5 -- Monitoring & Observability

**Q8**: Do you need health monitoring or alerting?
(e.g., job failure alerts, API health checks, system status dashboards)
If yes -> maps to Observability domain

### B6 -- Data Viewer

**Q9**: Do you need a data viewer or admin dashboard?
(e.g., browse records, view job results, manage data)
If yes -> maps to Data Viewer domain

### B7 -- LLM Integration

**Q10**: Do you need LLM integration?
(e.g., text classification, content generation, structured data extraction)
If yes -> maps to LLM Integration domain

### B8 -- Map to Technology Domains

After all questions are answered, map the responses to technology domains:

| Technology Domain | Relevance | Based On |
|---|---|---|
| Trigger.dev | using/needed/not-needed | Q6 |
| Database | using/needed/not-needed | Q7 |
| API Clients | using/needed/not-needed | Q4-Q5 |
| Observability | using/needed/not-needed | Q8 |
| Caching | using/needed/not-needed | inferred from API usage |
| LLM Integration | using/needed/not-needed | Q10 |
| Data Viewer | using/needed/not-needed | Q9 |
| Testing | needed | always recommended |

---

## Common Final Steps (Both Paths)

### Save Discovery Results

Write `.outbound-builder-plugin-discovery.json` to the project root:

```json
{
  "project_name": "...",
  "description": "...",
  "tech_stack": { "runtime": "...", "framework": "...", "database": "..." },
  "current_state": "greenfield|existing",
  "technology_domains": {
    "trigger-dev": { "status": "using|needed|not-needed", "existing_files": [], "gaps": [] },
    "database": { "status": "...", "existing_files": [], "gaps": [] },
    "api-clients": { "status": "...", "existing_files": [], "gaps": [] },
    "observability": { "status": "...", "existing_files": [], "gaps": [] },
    "caching": { "status": "...", "existing_files": [], "gaps": [] },
    "llm": { "status": "...", "existing_files": [], "gaps": [] },
    "data-viewer": { "status": "...", "existing_files": [], "gaps": [] },
    "testing": { "status": "...", "existing_files": [], "gaps": [] }
  },
  "recommended_skills": [],
  "relevant_docs": [],
  "build_roadmap": [
    { "step": 1, "action": "...", "skill": "...", "details": "..." }
  ],
  "discovered_at": "ISO timestamp"
}
```

For **Path A** (existing project), populate `technology_domains` with actual file paths found during scanning and specific gaps identified. For **Path B** (greenfield), populate based on interview answers with `existing_files` empty and `gaps` describing what needs to be built.

### Present the Summary

Show the user a clear picture:
1. Their project identity (name, description, purpose)
2. Which technology domains are relevant to their use case
3. Current state (what exists vs what's missing)
4. The build roadmap in priority order
5. Exactly which plugin skills and docs will help them build each part

### Suggest Next Steps

Tell the user:

```
Discovery complete! Your project profile is saved to .outbound-builder-plugin-discovery.json.

Next step: run /outbound-builder-plugin:onboard to configure credentials and infrastructure,
then start building with the scaffold skills.
```

## Rules

- For Path B, ask ONE question at a time using AskUserQuestion. Never batch multiple questions.
- For Path A, scan the code silently. Only ask the user questions if something is ambiguous or unclear from the code alone. Present findings without asking for confirmation of individual details.
- Be thorough in scanning but concise in reporting. Show what matters.
- If a technology domain genuinely doesn't apply to the project, mark it "not-needed" with an explanation.
- Always write `.outbound-builder-plugin-discovery.json` at the end.
- Never read `.env` files -- only `.env.example` is safe to read.
- If the project is ambiguous (has some files but unclear purpose), start with Path A scanning, then ask clarifying questions only for what you can't determine from code.