Instruction file imported from kjfisk-cplt/iflow (.github/instructions/update-docs-on-code-change.instructions.md). Copyright stays with the author.

Update Documentation on Code Change

Overview

Ensure documentation stays synchronized with code changes by automatically detecting when README.md, API documentation, configuration guides, and other documentation files need updates based on code modifications.

Instruction Sections and Configuration

The following parts of this section, Instruction Sections and Configurable Instruction Sections and Instruction Configuration are only relevant to THIS instruction file, and are meant to be a method to easily modify how the Copilot instructions are implemented. Essentially the two parts are meant to turn portions or sections of the actual Copilot instructions on or off, and allow for custom cases and conditions for when and how to implement certain sections of this document.

Instruction Sections and Configurable Instruction Sections

There are several instruction sections in this document. The start of an instruction section is indicated by a level two header. Call this an INSTRUCTION SECTION. Some instruction sections are configurable. Some are not configurable and will always be used.

Instruction sections that ARE configurable are not required, and are subject to additional context and/or conditions. Call these CONFIGURABLE INSTRUCTION SECTIONS.

Configurable instruction sections will have the section's configuration property appended to the level two header, wrapped in backticks (e.g., apply-this). Call this the CONFIGURABLE PROPERTY.

The configurable property will be declared and defined in the Instruction Configuration portion of this section. They are booleans. If true, then apply, utilize, and/or follow the instructions in that section.

Each configurable instruction section will also have a sentence that follows the section's level two header with the section's configuration details. Call this the CONFIGURATION DETAIL.

The configuration detail is a subset of rules that expand upon the configurable instruction section. This allows for custom cases and/or conditions to be checked that will determine the final implementation for that configurable instruction section.

Before resolving on how to apply a configurable instruction section, check the configurable property for a nested and/or corresponding apply-condition, and utilize the apply-condition when settling on the final approach for the configurable instruction section. By default the apply-condition for each configurable property is unset, but an example of a set apply-condition could be something like:

- **apply-condition** :
  ` this.parent.property = (git.branch == "master") ? this.parent.property = true : this.parent.property = false; `

The sum of all the constant instructions sections, and configurable instruction sections will determine the complete instructions to follow. Call this the COMPILED INSTRUCTIONS.

The compiled instructions are dependent on the configuration. Each instruction section included in the compiled instructions will be interpreted and utilized AS IF a separate set of instructions that are independent of the entirety of this instruction file. Call this the FINAL PROCEDURE.

Instruction Configuration

• apply-doc-file-structure : true
  • apply-condition : unset
• apply-doc-verification : true
  • apply-condition : unset
• apply-doc-quality-standard : true
  • apply-condition : unset
• apply-automation-tooling : true
  • apply-condition : unset
• apply-doc-patterns : true
  • apply-condition : unset
• apply-best-practices : true
  • apply-condition : unset
• apply-validation-commands : true
  • apply-condition : unset
• apply-maintenance-schedule : true
  • apply-condition : unset
• apply-git-integration : false
  • apply-condition : unset

When to Update Documentation

Trigger Conditions

Automatically check if documentation updates are needed when:

• New features or functionality are added
• API endpoints, methods, or interfaces change
• Breaking changes are introduced
• Dependencies or requirements change
• Configuration options or environment variables are modified
• Installation or setup procedures change
• Command-line interfaces or scripts are updated
• Code examples in documentation become outdated

Documentation Update Rules

README.md Updates

Always update README.md when:

• Adding new features or capabilities

  • Add feature description to "Features" section
  • Include usage examples if applicable
  • Update table of contents if present

• Modifying installation or setup process

  • Update "Installation" or "Getting Started" section
  • Revise dependency requirements
  • Update prerequisite lists

• Adding new CLI commands or options

  • Document command syntax and examples
  • Include option descriptions and default values
  • Add usage examples

• Changing configuration options

  • Update configuration examples
  • Document new environment variables
  • Update config file templates

API Documentation Updates

Sync API documentation when:

• New endpoints are added

  • Document HTTP method, path, parameters
  • Include request/response examples
  • Update OpenAPI/Swagger specs

• Endpoint signatures change

  • Update parameter lists
  • Revise response schemas
  • Document breaking changes

• Authentication or authorization changes

  • Update authentication examples
  • Revise security requirements
  • Update API key/token documentation

Code Example Synchronization

Verify and update code examples when:

• Function signatures change

  • Update all code snippets using the function
  • Verify examples still compile/run
  • Update import statements if needed

• API interfaces change

  • Update example requests and responses
  • Revise client code examples
  • Update SDK usage examples

• Best practices evolve

  • Replace outdated patterns in examples
  • Update to use current recommended approaches
  • Add deprecation notices for old patterns

Configuration Documentation

Update configuration docs when:

• New environment variables are added

  • Add to .env.example file
  • Document in README.md or docs/configuration.md
  • Include default values and descriptions

• Config file structure changes

  • Update example config files
  • Document new options
  • Mark deprecated options

• Deployment configuration changes

  • Update Docker/Kubernetes configs
  • Revise deployment guides
  • Update infrastructure-as-code examples

Migration and Breaking Changes

Create migration guides when:

• Breaking API changes occur

  • Document what changed
  • Provide before/after examples
  • Include step-by-step migration instructions

• Major version updates

  • List all breaking changes
  • Provide upgrade checklist
  • Include common migration issues and solutions

• Deprecating features

  • Mark deprecated features clearly
  • Suggest alternative approaches
  • Include timeline for removal

Documentation File Structure apply-doc-file-structure

If apply-doc-file-structure == true, then apply the following configurable instruction section.

Standard Documentation Files

Maintain these documentation files and update as needed:

• README.md: Project overview, quick start, basic usage
• CHANGELOG.md: Version history and user-facing changes
• docs/: Detailed documentation
  • installation.md: Setup and installation guide
  • configuration.md: Configuration options and examples
  • api.md: API reference documentation
  • contributing.md: Contribution guidelines
  • migration-guides/: Version migration guides
• examples/: Working code examples and tutorials

Changelog Management

Add changelog entries for:

• New features (under "Added" section)
• Bug fixes (under "Fixed" section)
• Breaking changes (under "Changed" section with BREAKING prefix)
• Deprecated features (under "Deprecated" section)
• Removed features (under "Removed" section)
• Security fixes (under "Security" section)

Changelog format:

```markdown
## [Version] - YYYY-MM-DD

### Added
- New feature description with reference to PR/issue

### Changed
- **BREAKING**: Description of breaking change
- Other changes

### Fixed
- Bug fix description
```

Documentation Verification apply-doc-verification

If apply-doc-verification == true, then apply the following configurable instruction section.

Before Applying Changes

Check documentation completeness:

1. All new public APIs are documented
2. Code examples compile and run
3. Links in documentation are valid
4. Configuration examples are accurate
5. Installation steps are current
6. README.md reflects current state

Documentation Tests

Include documentation validation:

Example Tasks

• Verify code examples in docs compile/run

• Check for broken internal/external links

• Validate configuration examples against schemas

• Ensure API examples match current implementation

  echo "Example validation commands" npm run docs:check # Verify docs build npm run docs:test-examples # Test code examples npm run docs:lint # Check for issues

Documentation Quality Standards apply-doc-quality-standard

If apply-doc-quality-standard == true, then apply the following configurable instruction section.

Writing Guidelines

• Use clear, concise language
• Include working code examples
• Provide both basic and advanced examples
• Use consistent terminology
• Include error handling examples
• Document edge cases and limitations

Code Example Format

```markdown
### Example: [Clear description of what example demonstrates]

\`\`\`language
// Include necessary imports/setup
import { function } from 'package';

// Complete, runnable example
const result = function(parameter);
console.log(result);
\`\`\`

**Output:**
\`\`\`
expected output
\`\`\`
```

API Documentation Format

```markdown
### `functionName(param1, param2)`

Brief description of what the function does.

**Parameters:**
- `param1` (type): Description of parameter
- `param2` (type, optional): Description with default value

**Returns:**
- `type`: Description of return value

**Example:**
\`\`\`language
const result = functionName('value', 42);
\`\`\`

**Throws:**
- `ErrorType`: When and why error is thrown
```

Automation and Tooling apply-automation-tooling

If apply-automation-tooling == true, then apply the following configurable instruction section.

Documentation Generation

Use automated tools when available:

Automated Tool Examples

• JSDoc/TSDoc for JavaScript/TypeScript
• Sphinx/pdoc for Python
• Javadoc for Java
• xmldoc for C#
• godoc for Go
• rustdoc for Rust

Documentation Linting

Validate documentation with:

• Markdown linters (markdownlint)
• Link checkers (markdown-link-check)
• Spell checkers (cspell)
• Code example validators

Pre-update Hooks

Add pre-commit checks for:

• Documentation build succeeds
• No broken links
• Code examples are valid
• Changelog entry exists for changes

Common Documentation Patterns apply-doc-patterns

If apply-doc-patterns == true, then apply the following configurable instruction section.

Feature Documentation Template

```markdown
## Feature Name

Brief description of the feature.

### Usage

Basic usage example with code snippet.

### Configuration

Configuration options with examples.

### Advanced Usage

Complex scenarios and edge cases.

### Troubleshooting

Common issues and solutions.
```

API Endpoint Documentation Template

```markdown
### `HTTP_METHOD /api/endpoint`

Description of what the endpoint does.

**Request:**
\`\`\`json
{
  "param": "value"
}
\`\`\`

**Response:**
\`\`\`json
{
  "result": "value"
}
\`\`\`

**Status Codes:**
- 200: Success
- 400: Bad request
- 401: Unauthorized
```

Best Practices apply-best-practices

If apply-best-practices == true, then apply the following configurable instruction section.

Do's

• ✅ Update documentation in the same commit as code changes
• ✅ Include before/after examples for changes to be reviewed before applying
• ✅ Test code examples before committing
• ✅ Use consistent formatting and terminology
• ✅ Document limitations and edge cases
• ✅ Provide migration paths for breaking changes
• ✅ Keep documentation DRY (link instead of duplicating)

Don'ts

• ❌ Commit code changes without updating documentation
• ❌ Leave outdated examples in documentation
• ❌ Document features that don't exist yet
• ❌ Use vague or ambiguous language
• ❌ Forget to update changelog
• ❌ Ignore broken links or failing examples
• ❌ Document implementation details users don't need

Validation Example Commands apply-validation-commands

If apply-validation-commands == true, then apply the following configurable instruction section.

Example scripts to apply to your project for documentation validation:

{
  "scripts": {
    "docs:build": "Build documentation",
    "docs:test": "Test code examples in docs",
    "docs:lint": "Lint documentation files",
    "docs:links": "Check for broken links",
    "docs:spell": "Spell check documentation",
    "docs:validate": "Run all documentation checks"
  }
}

Maintenance Schedule apply-maintenance-schedule

If apply-maintenance-schedule == true, then apply the following configurable instruction section.

Regular Reviews

• Monthly: Review documentation for accuracy
• Per release: Update version numbers and examples
• Quarterly: Check for outdated patterns or deprecated features
• Annually: Comprehensive documentation audit

Deprecation Process

When deprecating features:

1. Add deprecation notice to documentation
2. Update examples to use recommended alternatives
3. Create migration guide
4. Update changelog with deprecation notice
5. Set timeline for removal
6. In next major version, remove deprecated feature and docs

Git Integration apply-git-integration

If apply-git-integration == true, then apply the following configurable instruction section.

Pull Request Requirements

Documentation must be updated in the same PR as code changes:

• Document new features in the feature PR
• Update examples when code changes
• Add changelog entries with code changes
• Update API docs when interfaces change

Documentation Review

During code review, verify:

• Documentation accurately describes the changes
• Examples are clear and complete
• No undocumented breaking changes
• Changelog entry is appropriate
• Migration guides are provided if needed

Review Checklist

Before considering documentation complete, and concluding on the final procedure:

• Compiled instructions are based on the sum of constant instruction sections and configurable instruction sections
• README.md reflects current project state
• All new features are documented
• Code examples are tested and work
• API documentation is complete and accurate
• Configuration examples are up to date
• Breaking changes are documented with migration guide
• CHANGELOG.md is updated
• Links are valid and not broken
• Installation instructions are current
• Environment variables are documented

Updating Documentation on Code Change GOAL

• Keep documentation close to code when possible
• Use documentation generators for API reference
• Maintain living documentation that evolves with code
• Consider documentation as part of feature completeness
• Review documentation in code reviews
• Make documentation easy to find and navigate