Documentation Conventions and Update Processes#

Consistent Use of the Repository Name#

In all contributor-facing documentation, always refer to the repository by its full name, StringyMcStringFace. This includes references in clone URLs, branch names, and any documentation that describes the project structure or repository location. For example:

git clone https://github.com/EvilBit-Labs/StringyMcStringFace
cd StringyMcStringFace

In user-facing documentation (such as the user guide), the tool may be referred to as "Stringy" for brevity, but all technical and contributor documentation must use the full repository name for clarity and consistency [contributing.md].

Maintaining Documentation Accuracy#

Documentation must be updated whenever changes affect the public API, add new features, or alter usage patterns. This includes both API documentation and user-facing guides. The development workflow requires contributors to:

• Update API documentation using cargo doc --open.
• Update user documentation using mdbook serve --open from the docs directory.

Example workflow excerpt:

# Update API docs
cargo doc --open

# Update user documentation
cd docs
mdbook serve --open

All public APIs must be thoroughly documented with clear doc comments, including argument descriptions, return values, and usage examples. When making changes, always review and update relevant documentation to ensure it accurately reflects the current state of the codebase [contributing.md].

Synchronization Hooks for Documentation#

The repository uses automated synchronization hooks to help maintain documentation accuracy:

Documentation Sync Hook#

A hook named "Documentation Sync" is enabled and monitors changes to Rust source files (src/**/*.rs), configuration files (Cargo.toml, Cargo.lock), and markdown documentation (*.md, docs/src/**/*.md). When triggered, it prompts maintainers to:

• Review the entire codebase.
• Update README.md to reflect new features, API changes, or usage patterns.
• Update the mdBook user guide in /docs/src/ to cover architecture changes, new usage patterns, and best practices.

The hook ensures the high-level introduction in README.md remains current and the user guide accurately reflects the tool's structure and capabilities [docs-sync-hook.kiro.hook].

LLMs.txt Auto-Updater Hook#

A separate hook, "LLMs.txt Auto-Updater," is enabled to maintain the accuracy of the llms.txt file. It triggers on changes to documentation files (e.g., concept.md, README.md, docs/**/*.md), code files (src/**/*.rs, Cargo.toml), and project specifications. When activated, it prompts an agent to:

• Examine the entire codebase.
• Update llms.txt to reflect the current state after documentation, specification, or structure changes.

The process prioritizes kiro specifications and steering documents as authoritative sources, but always treats the actual code implementation as the ultimate truth for updating llms.txt [llms-txt-updater.kiro.hook].

Manual Update Process for llms.txt#

After any structural change to the repository, or when documentation/specifications are updated, you must manually review and update llms.txt if the auto-updater hook does not fully capture the changes. The update process is as follows:

1. Review all recent changes to code, documentation, and specifications.
2. Use kiro specifications and steering documents as the primary reference, but verify all details against the actual codebase.
3. Edit llms.txt to ensure it accurately represents the current state of the project, especially for LLM consumption.
4. Commit the updated llms.txt alongside related documentation or code changes.

This process ensures that llms.txt remains a reliable and up-to-date resource for downstream consumers and automation.

Summary#

• Always use StringyMcStringFace in contributor documentation.
• Update documentation with every relevant code or feature change.
• Rely on synchronization hooks to prompt reviews and updates for README.md, user guides, and llms.txt.
• Manually update llms.txt after structural or documentation changes, using code as the final authority.

For further details, refer to the contributing guide and the respective hook configuration files.