Automated Updates

Keep documentation in sync with every git push.

The core of Docify is its ability to watch your repository for code changes and automatically update the corresponding documentation.

How It Works

Docify operates through a carefully orchestrated workflow designed to catch meaningful changes and update only what needs updating.

1. You Push Code

Docify listens to push events on your default branch (typically main or master).

Every time code is pushed, Docify evaluates whether the changes warrant documentation updates. Most pushes result in no action — only changes to public-facing code trigger the documentation workflow.

2. AI Analysis

Docify analyzes the git diff to understand exactly what changed.

The AI looks for:

• Logic changes: New algorithms, workflows, or business logic
• Type changes: Modified function signatures, interfaces, or schemas
• API changes: New endpoints, parameters, or response structures
• Configuration changes: Environment variables, settings, or feature flags

Internal refactors, test changes, and build files are automatically filtered out to reduce noise.

3. Context Retrieval

Before making any changes, Docify fetches the existing documentation to understand:

• Current structure and organization
• Existing descriptions and examples
• Related pages that might need updates
• Style and tone conventions

This ensures that proposed updates feel consistent with your existing documentation, rather than jarring or out of place.

4. PR Generation

If updates are needed, Docify opens a pull request containing:

• Minimal diffs: Only the lines that need to change
• Clear commit messages: Explaining what changed and why
• Contextual descriptions: Linking the code change to the documentation update

You review, edit, or reject the PR just like any other contribution. Nothing is merged automatically.

Configuration

You can control which files trigger updates using the scope and ignore settings in docify.yml.

Limiting Scope

docs:
  scope:
    path: "src/core" # Only watch this folder

Use scope when you want Docify to focus on a specific directory. This is useful for:

• Monorepos with multiple projects
• Repositories where only certain folders contain public APIs
• Reducing noise from non-critical code changes

Ignoring Files

docs:
  ignore:
    - "**/*.test.ts"   # Ignore tests
    - "scripts/**"     # Ignore scripts
    - "*.config.js"    # Ignore config files

Ignored files are completely skipped during analysis. Common patterns include:

• Test files (**/*.test.*, **/*.spec.*)
• Build tooling (webpack.config.js, vite.config.ts)
• Internal utilities (src/internal/**, src/utils/**)
• Scripts and automation (scripts/**, bin/**)

Combining Scope and Ignore

docs:
  scope:
    path: "src/api"
  ignore:
    - "src/api/internal/**"
    - "**/*.test.ts"

This configuration tells Docify to:

1. Only watch the src/api directory
2. Ignore internal utilities and tests within that directory

Smart Limits

Docify applies intelligent rate limits to prevent overwhelming your team with documentation PRs.

Free Plan

• Updates up to 3 files per push
• Best for small projects and personal repositories
• Focuses on the most critical changes first

Pro Plan

• Updates up to 20 files per push
• Advanced reasoning for complex changes
• Multi-file dependency tracking
• Supports larger codebases and frequent updates

Team Plan

• Custom file limits
• Priority processing
• Dedicated support for configuration

If a push affects more files than your plan allows, Docify:

1. Prioritizes public-facing changes
2. Groups related changes together
3. Suggests running /docify update manually for remaining files

When Updates Are Triggered

Docify is intentionally conservative about when it acts.

✅ Updates Are Triggered For:

• New exported functions or classes
• Modified public API signatures
• New configuration options
• Changed CLI commands
• Updated component props
• New or changed endpoints

❌ Updates Are NOT Triggered For:

• Internal refactoring
• Test file changes
• Dependency updates (unless they affect public APIs)
• Build configuration changes
• Code formatting or linting
• Documentation-only changes

This design ensures that Docify stays quiet most of the time and only speaks up when it truly matters.

Example Workflow

Here's what a typical automated update looks like in practice:

1. Developer adds a new API endpoint:

// src/api/users.ts
export async function getUserProfile(userId: string): Promise<UserProfile> {
  // Implementation
}

2. Docify detects the change:

• Recognizes a new exported function
• Identifies it as a public API addition
• Determines the relevant documentation file (docs/api/users.mdx)

3. Docify opens a PR:

## getUserProfile

Retrieves a user's profile information.

### Parameters

- `userId` (string): The unique identifier for the user

### Returns

Returns a `UserProfile` object containing user details.

4. Developer reviews and merges:

The PR is clear, accurate, and ready to merge. Total time: 30 seconds of review.

Best Practices

Start Small

Enable Docify on a single repository first. This lets you:

• Understand the update cadence
• Tune your ignore patterns
• Build confidence in the system

Use Descriptive Commit Messages

Docify uses commit messages as context. Better messages lead to better documentation updates.

Review PRs Promptly

Stale documentation PRs can conflict with each other. A quick review keeps things flowing smoothly.

Leverage Ignore Patterns

Aggressively ignore files that don't need documentation. This keeps the signal-to-noise ratio high.

Troubleshooting

"Docify isn't creating PRs"

Check that:

• The changes affect public-facing code (not tests or internal files)
• Your scope and ignore settings aren't too restrictive
• The repository has documentation in a recognized location

"Docify is too noisy"

Add more ignore patterns to filter out files that don't need documentation.

"Updates are missing context"

Ensure your existing documentation is well-structured. Docify uses it as a reference for tone and style.

Summary

Automated updates are:

• Triggered by code changes that affect public behavior
• Conservative by default to avoid noise
• Configurable through scope and ignore patterns
• Always reviewable via pull requests

If Docify feels invisible most of the time, it's working perfectly.