Domain README Generator

Generate or update a README.md for the domain library at $ARGUMENTS.

Step 1 — Resolve the Target Path

$ARGUMENTS can be:

• A relative path: libs/widget-chat
• A domain name: widget-chat → look for libs/widget-chat
• An import path: @myapp/widget-chat → look it up in the Domain Registry in CLAUDE.md

If the path cannot be resolved, ask the user.

Step 2 — Inventory the Library

Read the following files (skip those that don't exist):

<path>/
  index.ts                  ← public API surface
  src/lib/                  ← all source files
  src/index.ts              ← re-exports
  project.json              ← name, tags, importPath
  package.json              ← name, version, peerDeps
  ng-package.json           ← Angular package config

For each subdirectory in src/lib/:

• Identify the layer type: domain, feature, ui, util
• List key exported symbols: services, stores, components, directives, pipes, types

Focus on:

• NgRx Stores: read the store file, extract state interface, computed signals, methods
• Facade services: extract public methods and their signatures
• Angular components: extract @Input() / @Output() properties and selector
• Public types/interfaces: exported from index.ts

Step 3 — Generate the README

Write a README.md with this exact structure:

# <Library Name>

<One-sentence description. What this library does and why it exists.>

## Architecture

<Describe the layer structure. Include a text diagram if the library has multiple layers.>

\`\`\`
<path>/
├── domain/     → NgRx store, facade, services
├── feature/    → Container components, routing
├── ui/         → Presentational components
└── util/       → Types, helpers
\`\`\`

## Public API

### <ServiceName>
> `import { ServiceName } from '<importPath>'`

| Method / Property | Type | Description |
|-------------------|------|-------------|
| `methodName(arg)` | `ReturnType` | What it does |

### <StoreName> (NgRx Signal Store)

| Signal / Method | Type | Description |
|-----------------|------|-------------|
| `items` | `Signal<Item[]>` | List of items |
| `loadItems()` | `void` | Fetches items from API |

### <ComponentName>

**Selector**: `<app-component-name>`

| Input | Type | Description |
|-------|------|-------------|
| `data` | `Item[]` | Data to display |

| Output | Type | Description |
|--------|------|-------------|
| `selected` | `EventEmitter<Item>` | Emits on selection |

## Key Patterns

<Document any conventions specific to this domain:>
- State shape and update strategy
- Error handling approach
- How the facade wraps the store
- Any domain-specific patterns

## Usage Example

\`\`\`typescript
import { FeatureComponent } from '<importPath>/feature';
import { DomainService } from '<importPath>/domain';

// Minimal example showing how to consume this library
\`\`\`

## Dependencies

**Depends on:**
- `@scope/shared/...` — description

**Consumed by:**
- `apps/aero-host` — used as widget

## Development

\`\`\`bash
npx nx test <project-name>       # Run unit tests
npx nx build <project-name>      # Build library
npx nx lint <project-name>       # Lint
\`\`\`

Step 4 — Handle Existing README

If README.md already exists:

• Preserve any manually written sections that are not auto-generated
• Update sections that reflect code (Public API, Dependencies)
• Add a comment at the top of auto-generated sections: <!-- auto-generated by domain-readme skill, do not edit manually -->

Step 5 — Write the File

Write the generated content to <path>/README.md.

Confirm to the user:

✓ README.md written to <path>/README.md
  Documented: N services, N stores, N components

Arguments

$ARGUMENTS — path or name of the domain to document.

Examples:

• /domain-readme libs/widget-chat
• /domain-readme widget-chat
• /domain-readme libs/shared/sidebar
• /domain-readme ← no args: ask the user which domain to document