Skip to content

Skill to review whole PR#11031

Merged
MarkvanMents merged 10 commits intoMvM-RenameClaudeSkillsfrom
MvM-PRSkillsAndTools
Apr 17, 2026
Merged

Skill to review whole PR#11031
MarkvanMents merged 10 commits intoMvM-RenameClaudeSkillsfrom
MvM-PRSkillsAndTools

Conversation

@MarkvanMents
Copy link
Copy Markdown
Collaborator

No description provided.

@github-actions
Copy link
Copy Markdown
Contributor

⚠️ Claude Configuration Warning

You've modified Claude Code configuration files. These files contain the shared configuration for all contributors. Please revert this change if unintended. ONLY modify these files if you need to change shared configurations that apply to everyone and have discussed this change with the TW team.

To override the Claude settings locally, use .claude/settings.local.json instead. This local file is gitignored and overrides the repo default.

For example, if you're changing AWS_PROFILE:
The default profile name is my-sandbox. If your AWS profile has a different name, override it locally instead of changing the shared file.

Create or edit .claude/settings.local.json in the repo root and include the following lines:

{
  "env": {
    "AWS_PROFILE": "your-sandbox-name"
  }
}

@github-actions
Copy link
Copy Markdown
Contributor

⚠️ Claude Configuration Warning

You've modified Claude Code configuration files. These files contain the shared configuration for all contributors. Please revert this change if unintended. ONLY modify these files if you need to change shared configurations that apply to everyone and have discussed this change with the TW team.

To override the Claude settings locally, use .claude/settings.local.json instead. This local file is gitignored and overrides the repo default.

For example, if you're changing AWS_PROFILE:
The default profile name is my-sandbox. If your AWS profile has a different name, override it locally instead of changing the shared file.

Create or edit .claude/settings.local.json in the repo root and include the following lines:

{
  "env": {
    "AWS_PROFILE": "your-sandbox-name"
  }
}

@github-actions
Copy link
Copy Markdown
Contributor

⚠️ Claude Configuration Warning

You've modified Claude Code configuration files. These files contain the shared configuration for all contributors. Please revert this change if unintended. ONLY modify these files if you need to change shared configurations that apply to everyone and have discussed this change with the TW team.

To override the Claude settings locally, use .claude/settings.local.json instead. This local file is gitignored and overrides the repo default.

For example, if you're changing AWS_PROFILE:
The default profile name is my-sandbox. If your AWS profile has a different name, override it locally instead of changing the shared file.

Create or edit .claude/settings.local.json in the repo root and include the following lines:

{
  "env": {
    "AWS_PROFILE": "your-sandbox-name"
  }
}

Changes suggested by docs-pr-review
@github-actions
Copy link
Copy Markdown
Contributor

⚠️ Claude Configuration Warning

You've modified Claude Code configuration files. These files contain the shared configuration for all contributors. Please revert this change if unintended. ONLY modify these files if you need to change shared configurations that apply to everyone and have discussed this change with the TW team.

To override the Claude settings locally, use .claude/settings.local.json instead. This local file is gitignored and overrides the repo default.

For example, if you're changing AWS_PROFILE:
The default profile name is my-sandbox. If your AWS profile has a different name, override it locally instead of changing the shared file.

Create or edit .claude/settings.local.json in the repo root and include the following lines:

{
  "env": {
    "AWS_PROFILE": "your-sandbox-name"
  }
}


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.

Make no edits.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The 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."

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The 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"?
And I don't want it to try to fix broken links. I'd rather have htmltest doing that - so far it has complained about links which are perfectly valid so I'd rather it didn't waste time (and tokens) trying to check them all. which is the reason behind line 14.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The 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.


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.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The 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?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The 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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The 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."


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.
Copy link
Copy Markdown
Collaborator

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".

Copy link
Copy Markdown
Collaborator Author

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.

Copy link
Copy Markdown
Collaborator Author

@MarkvanMents MarkvanMents left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review.
I've responded to your comments.
I'll re-run /docs-pr-review on the pr and see if it picks up anything from the rename or has any other suggestions.


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.
Copy link
Copy Markdown
Collaborator Author

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.


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.
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The 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.


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.

Make no edits.
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The 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"?
And I don't want it to try to fix broken links. I'd rather have htmltest doing that - so far it has complained about links which are perfectly valid so I'd rather it didn't waste time (and tokens) trying to check them all. which is the reason behind line 14.

@github-actions
Copy link
Copy Markdown
Contributor

⚠️ Claude Configuration Warning

You've modified Claude Code configuration files. These files contain the shared configuration for all contributors. Please revert this change if unintended. ONLY modify these files if you need to change shared configurations that apply to everyone and have discussed this change with the TW team.

To override the Claude settings locally, use .claude/settings.local.json instead. This local file is gitignored and overrides the repo default.

For example, if you're changing AWS_PROFILE:
The default profile name is my-sandbox. If your AWS profile has a different name, override it locally instead of changing the shared file.

Create or edit .claude/settings.local.json in the repo root and include the following lines:

{
  "env": {
    "AWS_PROFILE": "your-sandbox-name"
  }
}

@MarkvanMents
Copy link
Copy Markdown
Collaborator Author

Discussed with @dbreseman - merging

@MarkvanMents MarkvanMents merged commit 1d5a9a4 into MvM-RenameClaudeSkills Apr 17, 2026
1 of 2 checks passed
@MarkvanMents MarkvanMents deleted the MvM-PRSkillsAndTools branch April 17, 2026 15:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants