fix: respect enabled: true as force-enable in shouldIncludeSkill#50978
Open
carrotRakko wants to merge 2 commits intoopenclaw:mainfrom
Open
fix: respect enabled: true as force-enable in shouldIncludeSkill#50978carrotRakko wants to merge 2 commits intoopenclaw:mainfrom
carrotRakko wants to merge 2 commits intoopenclaw:mainfrom
Conversation
When a skill has `enabled: true` in config, bypass `evaluateRuntimeEligibility` (which checks requires.bins, OS, etc.) so the skill is always included. This makes `enabled: true` symmetric with `enabled: false` (force-disable). The check runs after `isBundledSkillAllowed` so allowBundled restrictions are still respected. ✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)
Contributor
Greptile SummaryThis PR fixes an asymmetry in Key observations:
Confidence Score: 5/5
Prompt To Fix All With AIThis is a comment left during a code review.
Path: src/agents/skills/config.ts
Line: 87-89
Comment:
**Missing comment for non-obvious check ordering**
The repo style guide (`AGENTS.md`/`CLAUDE.md`) explicitly calls out: _"Add brief code comments for tricky or non-obvious logic."_
The placement of the `enabled === true` early-return **after** `isBundledSkillAllowed` (while `enabled === false` sits **before** it) is intentionally asymmetric — `allowBundled` should win even over an explicit force-enable. That ordering is easy to miss or accidentally "fix" in a future refactor without understanding the intent. A brief comment would make it self-documenting:
```suggestion
// enabled: true force-enables, but allowBundled still gates bundled skills
// (checked above). enabled: false short-circuits before that check since
// the result is the same regardless.
if (skillConfig?.enabled === true) {
return true;
}
```
**Context Used:** CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8))
How can I resolve this? If you propose a fix, please make it concise.Last reviewed commit: "fix: respect enabled..." |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9f7b118b74
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- Add comment explaining why enabled: true is checked after isBundledSkillAllowed (Greptile review feedback). - Sync skills-status.ts eligibility with force-enable: when enabled: true, mark the skill as eligible in status reporting so CLI output matches runtime behavior (Codex review feedback). ✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
enabled: falseforce-disables a skill, butenabled: truedoes not force-enable — it still checksrequires.bins, OS restrictions, etc.enabled: true, skipevaluateRuntimeEligibilityand returntrue. TheisBundledSkillAllowedcheck still runs first, so allowBundled restrictions are respected.Change Type (select all)
Scope (select all touched areas)
Linked Issue/PR
User-visible / Behavior Changes
Setting
skills.entries.<key>.enabled: truein config now guarantees the skill is included, regardless of whether required binaries are installed or OS restrictions would normally exclude it.Security Impact (required)
Repro + Verification
Steps
requires: { bins: ["nonexistent"] })skills.entries.<skill-name>.enabled: truein configExpected
Actual
evaluateRuntimeEligibilityfails on the missing binary.enabled: truebypasses runtime eligibility.Evidence
New test file
src/agents/skills/config.test.tswith 4 test cases covering force-disable, force-enable, fallthrough, and allowBundled interaction.Human Verification (required)
enabled: truecorrectly force-enables,enabled: falsecorrectly force-disables.allowBundledrestrictions are still respected even whenenabled: true.Compatibility / Migration
enabled: undefined(default) behavior is unchanged.Failure Recovery (if this breaks)
config.ts.Risks and Mitigations
enabled: true). The user is taking responsibility for ensuring the skill works.✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)