init

Harness Init — Build Repository Knowledge Base

Analyze the current repository and produce a structured Knowledge Base (KB) that powers all Harness skills. The KB is a set of concise, structured markdown files that capture the essential patterns, schemas, and conventions of the codebase.

When to Run

• First time using Harness skillflows on a repo

• After major changes to the codebase architecture (new frameworks, restructured modules)

• User explicitly requests /harness:init or "rebuild KB"

Output Location

Write all KB files to .harness/kb/ in the repository root. Create the directory if it doesn't exist.

Process

Step 1: Tech Stack Discovery

Scan the repository to identify:

• Languages: Check file extensions, package.json, pyproject.toml, Cargo.toml, go.mod, Gemfile, etc.

• Frameworks: React, Next.js, FastAPI, Django, Rails, Express, etc. — check imports and config files

• Database: Check for schema files, migrations, ORM configs, connection strings

• Infrastructure: Docker, Kubernetes, serverless configs, CI/CD files

• Package manager: npm, pnpm, yarn, uv, pip, cargo, etc.

Write .harness/kb/stack-profile.md:

# Stack Profile
Generated: {date}

## Languages
- {language}: {version if known} — {location/config}

## Frameworks
- {framework}: {version} — {purpose}

## Database
- {type}: {details}

## Infrastructure
- {tool}: {config location}

## Project Structure
- {description of directory layout and conventions}

## Key Conventions
- {naming, patterns, architecture style}

Step 2: Data Layer Analysis

Find and analyze database schemas, ORM models, or data definitions:

• SQL: Look in migrations/, schema files, ORM model definitions

• NoSQL: Check for collection schemas, validators, type definitions

• GraphQL: Schema files, type definitions

• ORM models: Django models.py, SQLAlchemy models, Prisma schema, Hasura metadata

Write .harness/kb/data-layer.md:

# Data Layer
Generated: {date}

## Schema Location
{where schemas/models are defined}

## Domain: {domain name}
| Entity | Key Fields | Relationships | Notes |
|--------|------------|---------------|-------|
| {table/collection} | {important columns} | {foreign keys, joins} | {triggers, indexes, constraints} |

Group entities by business domain. Include relationships and important constraints. Keep it under 200 lines — summarize, don't dump raw schemas.

Step 3: API Surface Analysis

Find and analyze API endpoints, routes, handlers:

• REST: Route files, controller definitions, OpenAPI specs

• GraphQL: Resolvers, schema definitions

• RPC/gRPC: Proto files, service definitions

• Internal: Message queues, event handlers

Write .harness/kb/api-surface.md:

# API Surface
Generated: {date}

## Architecture
{middleware pipeline, auth pattern, error handling}

## Endpoint Groups
### {group name}
| Method | Path/Operation | Handler | Auth | Notes |
|--------|---------------|---------|------|-------|
| {GET/POST/...} | {path} | {file:function} | {auth type} | {key behavior} |

Focus on patterns and conventions, not exhaustive endpoint lists. Document the middleware pipeline, auth model, and error handling approach.

Step 4: Async & Jobs Analysis

Find background jobs, scheduled tasks, event handlers, queue consumers:

• Cron jobs: Scheduled tasks, crontab files

• Job frameworks: Celery, Sidekiq, Bull, Trigger.dev, temporal

• Event handlers: Webhooks, pub/sub, event-driven patterns

• Workers: Background processing, queue consumers

Write .harness/kb/async-jobs.md:

# Async & Jobs
Generated: {date}

## Job Framework
{framework, config location, patterns}

## Jobs
| Job/Task | Trigger | Schedule | Dependencies | Notes |
|----------|---------|----------|-------------|-------|
| {name} | {event/schedule/manual} | {cron if applicable} | {what it reads/writes} | {key behavior} |

If no async/job system exists, write a short file noting that and skip to Step 5.

Step 5: UI Patterns Analysis

For each frontend application in the repo, analyze component patterns:

• Component library: Custom, shadcn, Material UI, etc.

• State management: Redux, Zustand, React Query, etc.

• Routing: File-based, programmatic

• Styling: Tailwind, CSS modules, styled-components

Write .harness/kb/ui-patterns.md:

# UI Patterns
Generated: {date}

## App: {app name}
**Location:** {directory}
**Framework:** {React/Vue/Svelte/etc.}

### Component Conventions
- {patterns, naming, file structure}

### State Management
- {approach, key stores/hooks}

### Routing
- {pattern, key routes}

### Key Components
| Component | Location | Purpose | Pattern |
|-----------|----------|---------|---------|
| {name} | {file} | {what it does} | {HOC/hook/context/etc.} |

If multiple apps exist (e.g., admin + consumer), document each separately. If no UI exists, write a short file noting that.

Step 6: Integrations Analysis

Find external service connections, third-party APIs, SDKs:

• Auth providers: Auth0, Clerk, Firebase Auth, custom

• Payment: Stripe, PayPal

• Storage: S3, Cloudinary, local

• Search: Elasticsearch, Algolia, Typesense

• Email/SMS: SendGrid, Twilio

• Monitoring: Sentry, DataDog, custom logging

Write .harness/kb/integrations.md:

# Integrations
Generated: {date}

| Service | Purpose | SDK/Client | Config Location | Notes |
|---------|---------|-----------|----------------|-------|
| {name} | {what it does} | {package/import} | {env var or config file} | {key patterns, gotchas} |

If no external integrations exist, write a short file noting that.

Step 7: Summary & Verification

After writing all KB files, call harness_status via MCP to verify the daemon is running, then report:

KB initialized for {repo name}
  .harness/kb/stack-profile.md  — {line count} lines
  .harness/kb/data-layer.md     — {line count} lines
  .harness/kb/api-surface.md    — {line count} lines
  .harness/kb/async-jobs.md     — {line count} lines
  .harness/kb/ui-patterns.md    — {line count} lines
  .harness/kb/integrations.md   — {line count} lines

Ready for /harness:skillflow

Quality Standards

• Concise: Each KB file should be 80-200 lines. Summarize, don't dump.

• Structured: Use tables for entities, endpoints, jobs. Use headers for domains/groups.

• Grounded: Every claim must be traceable to a file in the codebase. Include file paths.

• Current: Read actual files, don't rely on outdated docs or comments that may be stale.

• Honest: If a category doesn't apply (e.g., no database), say so in 2-3 lines rather than inventing content.