-
Notifications
You must be signed in to change notification settings - Fork 780
Skill to review whole PR #11031
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skill to review whole PR #11031
Changes from all commits
b338686
cce9568
1d303f5
897e90d
5551595
718c5c6
ff69d0e
7bc1c3c
739672c
e887758
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,38 @@ | ||
| # Claude Helper Scripts | ||
|
|
||
| Utility scripts to support Claude Code when working with this documentation repository. | ||
|
|
||
| ## resolve-doc-url.sh | ||
|
|
||
| Resolves a documentation URL to its source markdown file. | ||
|
|
||
| ### Usage | ||
|
|
||
| ```bash | ||
| .claude/scripts/resolve-doc-url.sh "/path/to/page/" | ||
| ``` | ||
|
|
||
| ### Examples | ||
|
|
||
| ```bash | ||
| # Find the file for a specific URL | ||
| .claude/scripts/resolve-doc-url.sh "/community-tools/contribute-to-mendix-docs/" | ||
| # Output: content/en/docs/community-tools/contribute-to-mendix-docs/_index.md | ||
|
|
||
| # Check if a URL exists | ||
| .claude/scripts/resolve-doc-url.sh "/some/page/" | ||
| # Exit code 0 if found, 1 if not found | ||
| ``` | ||
|
|
||
| ### Benefits | ||
|
|
||
| - **Fast**: Uses grep optimized for file-only output | ||
| - **Token-efficient**: Returns only the file path, no surrounding context | ||
| - **Reliable**: Matches exact URL in front matter using fixed-string search | ||
|
|
||
| ### When to Use | ||
|
|
||
| - Following cross-references between documentation pages | ||
| - Validating internal links | ||
| - Finding files by their published URL | ||
| - Checking if a URL is already in use |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,15 @@ | ||
| #!/bin/bash | ||
| # Resolve a documentation URL to its source markdown file | ||
| # Usage: resolve-doc-url.sh "/path/to/page/" | ||
|
|
||
| if [ -z "$1" ]; then | ||
| echo "Usage: resolve-doc-url.sh <url>" | ||
| echo "Example: resolve-doc-url.sh '/community-tools/contribute-to-mendix-docs/'" | ||
| exit 1 | ||
| fi | ||
|
|
||
| # Search for the URL in front matter | ||
| # Using grep with -l (files only) and -F (fixed string) for speed | ||
| grep -rl --include="*.md" "^url: $1$" content/en/docs/ | ||
|
|
||
| # Exit code 0 if found, 1 if not found |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| --- | ||
| name: docs-pr-review | ||
| description: Analyzes all changes in a pull request and generates suggestions for improvements, clarifications, inconsistencies, and structural changes without making any edits. Use when the user asks to review, analyze, audit, or provide feedback on a pull request, or when they want suggestions before making changes. | ||
| user-invocable: true | ||
| disable-model-invocation: false | ||
| --- | ||
|
|
||
| Compare changes between the current branch and the base branch (typically `development`). Read the complete final state of each modified file, not just the diff, to ensure changes don't introduce inconsistencies with unchanged content. | ||
|
|
||
| Analyze all the changes in the current pull request or branch and return a list of suggestions or questions about any points to clarify, potential inconsistencies, and sections to restructure, add, or remove. Read the whole of each document modified in the pull request to ensure the changes do not make inconsistencies. | ||
|
|
||
| Follow links to other documents in the repo to check for inconsistencies if they seem to provide important related information. | ||
|
|
||
| Do not worry about possible invalid internal links to anchors in the repo as these will be picked up by a separate testing tool after the site has been built. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We test all internal links, right? Page-level links as well as anchors?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, we check any link which doesn't have an https:// in front of it. So internal to a page and from one page to another docs page.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In my tests, Claude interpreted these instructions as "don't check internal references with # in them, but do check page-level internal references." |
||
|
|
||
| Make no edits. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you think about changing this line in both review skills to something like "Make no edits. After the review, offer to fix straightforward issues like typos and broken links."
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder if that gets too complex. My idea is that after being told what the issues are you can then say "Please fix the typo for "accommodation"?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, definitely! You can still choose to ask it to apply certain changes afterwards if that feels like a more useful workflow. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how consistently Claude will bother reading other pages—it might be worth defining more specific triggers, like instructing it to always scan a couple related pages or even to look at every mentioned cross-reference (although "every" would probably need to have a max). It might also be worth specifying something along the lines of "inconsistencies, such as conflicting information, outdated references, or missing reciprocal links".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to start with just a hint - and definitely not follow all links. But perhaps we can pick this up and do a more thorough look into what links it decides to follow and perhaps give something more programmatic.
My first idea is just to tell Claude that it can do this and that it doesn't have to stick just to the files in the PR.