home / skills / open-circle / valibot / repo-website-api-update

repo-website-api-update skill

/skills/repo-website-api-update

This skill helps synchronize API documentation with source changes, ensuring signatures, interfaces, and examples stay accurate and up-to-date.

npx playbooks add skill open-circle/valibot --skill repo-website-api-update

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
5.4 KB
---
name: repo-website-api-update
description: Update existing API documentation pages after source code changes. Use when syncing docs with library changes like new parameters, type constraint changes, interface updates, or function renames. Covers common change patterns and verification steps.
---

# Updating API Documentation

Guide for syncing API docs with source code changes.

**Prerequisite:** Read the `repo-website-api-create` skill for `properties.ts` and `index.mdx` patterns.

## When to Update

Update documentation when source code changes:

- Function signatures (parameters, generics, return types)
- Interface properties
- JSDoc descriptions or hints
- Behavior changes affecting examples

**Do NOT update for:** Internal implementation changes (`~run` method), test changes, non-JSDoc comments.

## Process

1. **Read full source file** - Don't just look at diff; understand complete current state
2. **Identify changes** - Categorize as addition, removal, or modification
3. **Update `properties.ts`** - Match types exactly to source
4. **Update `index.mdx`** - Signature, generics, parameters, examples
5. **Update related files** - Type docs, `menu.md` if renamed

## Common Change Types

### New Parameter Added

```typescript
// Before: one overload
export function action<TInput>(requirement: TRequirement): Action<...>;

// After: two overloads (message is optional)
export function action<TInput>(requirement: TRequirement): Action<..., undefined>;
export function action<TInput, TMessage>(requirement: TRequirement, message: TMessage): Action<..., TMessage>;
```

Update:

1. Add `TMessage` generic to `properties.ts`
2. Add `message` parameter to `properties.ts`
3. Update signature in `index.mdx`
4. Add generic and parameter documentation
5. Update examples to show new parameter

### Parameter Removed (Breaking)

1. Remove from `properties.ts`
2. Update signature in `index.mdx`
3. Remove from Parameters section
4. Update all examples
5. Consider adding migration note in Explanation

### Type Constraint Changed

```typescript
// Before
TRequirement extends number

// After
TRequirement extends number | string
```

Update:

1. Update type in `properties.ts`
2. Update Explanation to mention both types
3. Add examples for new type usage

### Interface Property Added

1. Update type documentation in `(types)/TypeName/`
2. Add new property to `properties.ts`
3. Document in Definition section

### Function Renamed

1. Rename folder
2. Update all references in files
3. Update `menu.md` (maintain alphabetical order)
4. Update cross-references in related API docs
5. Consider redirect if widely used

### Deprecation

Add notice at top of `index.mdx` (import `Link` from `~/components`):

```mdx
> **⚠️ Deprecated**: Use <Link href="../newFunction/">\`newFunction\`</Link> instead. Will be removed in v2.0.
```

### New Helper Type Introduced

When source introduces a type alias:

```typescript
// Before: TInput extends string | unknown[]
// After: TInput extends LengthInput
```

1. Update `properties.ts` to reference new type with `href`
2. Create documentation for the new type in `(types)/`
3. Update explanation if supported types changed

### Multiple Overloads Added (Sync/Async)

When sync and async variants are added:

1. Update signature to show general pattern or both overloads
2. Add explanation about sync vs async usage
3. Add examples for both use cases
4. Update Related section for async schemas if relevant

## Related Files to Update

When a function changes, check:

- **Type docs** - If interfaces changed (`(types)/TypeName/`)
- **Related API docs** - Other APIs that reference this function in their Related section
- **Guide files** - If usage patterns changed significantly
- **menu.md** - If function renamed or moved

## Verification

After updating, verify:

- [ ] All types match source exactly
- [ ] Function signature matches source
- [ ] All examples work with new API
- [ ] All `href` links are valid
- [ ] Related type docs updated if interfaces changed
- [ ] `menu.md` updated if renamed
- [ ] Related API docs updated (their Related sections)

## Best Practices

- **Read full source file** - Don't just look at diff
- **Update incrementally** - `properties.ts` → `index.mdx` → related files
- **Don't over-document internals** - Only user-facing changes need docs
- **Preserve example quality** - Keep realistic, demonstrate best practices
- **Check related APIs** - They may reference the changed function

## When to Ask for Help

- Major breaking changes (complete signature overhaul)
- Complex generic constraint changes
- Unclear intent from source changes
- Many related files affected
- Need to document migration path

## Quick Reference

| Change            | Files to Update                                                      |
| ----------------- | -------------------------------------------------------------------- |
| New parameter     | `properties.ts`, `index.mdx` (signature, generics, params, examples) |
| Removed parameter | `properties.ts`, `index.mdx`                                         |
| Type change       | `properties.ts`, `index.mdx` (explanation, examples)                 |
| Interface change  | `(types)/TypeName/properties.ts`, `(types)/TypeName/index.mdx`       |
| Renamed function  | Folder name, all files, `menu.md`, cross-references                  |
| Deprecation       | `index.mdx` (add warning)                                            |

Overview

This skill helps keep API documentation in sync with TypeScript source changes for a modular, type-safe schema library. It focuses on updating properties.ts and index.mdx, and covers common change patterns like new parameters, type constraint updates, renames, and deprecations. The goal is accurate, runnable docs that reflect the current public surface.

How this skill works

I inspect the full source file to understand the current API surface, then classify each change as an addition, removal, or modification. I update properties.ts to match types exactly, refresh index.mdx signatures, generics, and examples, and sweep related files (type docs, menu, cross-references). Finally, I run a verification checklist to ensure examples compile and links work.

When to use it

  • After any change to function signatures, generics, or return types
  • When interface properties are added, removed, or their types change
  • When JSDoc descriptions that affect usage or examples are updated
  • After function renames, moves, or deprecations that affect navigation or cross-references
  • When helper types or new aliases are introduced that alter supported inputs

Best practices

  • Always read the complete source file, not just the git diff
  • Update incrementally: properties.ts first, then index.mdx, then related docs
  • Keep examples realistic and runnable; update or add migration snippets for breaking changes
  • Record deprecation notices at the top of index.mdx with a clear replacement path
  • When changing types, add example cases that exercise the new constraints

Example use cases

  • Add an optional message parameter to an action function: add generics, parameters, update examples and docs
  • Expand a type constraint from number to number|string: update properties.ts, explanation, and add new examples
  • Rename a function: rename folder/files, update menu.md, update all cross-references and related docs
  • Introduce a new helper type alias: create type docs, reference the alias in properties.ts, and update explanations

FAQ

What should I not update in docs?

Do not update docs for internal implementation changes, test-only changes, or non-JSDoc comments; only user-facing API changes matter.

How do I handle breaking parameter removals?

Remove the parameter from properties.ts and index.mdx, update all examples, and add a migration note in the Explanation section when appropriate.

When should I add a deprecation notice?

Add a deprecation notice whenever an API will be removed or replaced in a future major version and include the recommended replacement and expected removal version.