Doc From Commit

• Topic: What the documentation page is about (e.g., "Error Handling", "Database Setup")
• Commit URL(s): One or more GitHub commit URLs in the format https://github.com/<owner>/<repo>/commit/<sha>

If the topic or commit URLs are missing, ask the user for them before proceeding.

Step 2: Fetch Commit Data

For each commit URL, extract the owner, repo, and SHA. Then fetch:

1. Commit metadata using: gh api repos/<owner>/<repo>/commits/<sha> to get the commit message, author, date, and list of changed files.

2. The diff/patch using: gh api repos/<owner>/<repo>/commits/<sha> --jq '.files[] | {filename, status, patch}' to get the actual code changes.

3. If the commit references a pull request, also fetch the PR description for additional context: gh api repos/<owner>/<repo>/pulls/<number>

If a commit URL is invalid or the API call fails, report the error to the user and continue with the remaining commits.

Step 3: Analyze the Changes

After gathering all commit data:

• Identify the key code changes (new classes, modified methods, configuration changes, etc.)
• Determine the Spring Boot concepts involved (annotations, patterns, dependencies)
• Note which language variants are present (Java, Kotlin, Groovy)
• Identify any new dependencies, configuration properties, or structural patterns

Step 4: Determine File Placement

Based on the topic, choose the appropriate subdirectory under docs/. Current sections:

• docs/about/ - About the project/author/license
• docs/cross-cutting-concerns/ - Error handling, logs, mapping
• docs/deployment/ - VPS deployment, observability, dependabot
• docs/intro.mdx - Project intro (single file)
• docs/lets-create-a-spring-boot-project/ - Project setup, first endpoint, running the app
• docs/openapi-spec-first-development/ - OpenAPI spec and generator
• docs/persistence-integration/ - Database setup, JPA, reverse engineering
• docs/prior-recommended-knowledge/ - Prerequisites (architecture, JVM, dev env, etc.)
• docs/spring-boot-in-a-nutshell/ - Core Spring concepts, IoC, project structure
• docs/testing/ - Testing strategies, frameworks, first tests

If no existing section fits, ask the user where to place it. You can also suggest creating a new section if warranted.

Step 5: Load Project Skills

Before writing, load these skills to ensure consistency:

1. Load the writing-style skill to follow tone, voice, and anti-AI-writing-pattern rules
2. Load the code-style skill to follow Docusaurus MDX formatting, component imports, and code block conventions
3. If the user requests a Spanish translation, load the docusaurus-i18n skill

Step 6: Generate the Documentation Page

Write the .mdx file following these conventions:

Frontmatter:

---
sidebar_position: <appropriate number based on existing files in the directory>