feat: Added Agent skills for AI Agents#6007
feat: Added Agent skills for AI Agents#6007patelchaitany wants to merge 9 commits intofeast-dev:masterfrom
Conversation
Signed-off-by: Chaitany patel <[email protected]>
soooojinlee
left a comment
soooojinlee
left a comment
There was a problem hiding this comment.
would it make sense to place these under .claude/skills/ (or similar) instead of a top-level Agent-Skill/ directory? I think the https://github.com/anthropics/skills convention typically uses that path.
|
Exactly @soooojinlee - those .claude/skills usually live in the User Directory rather than the main Git repo. Most devs either create a specific subdirectory for skills within the project or manage them in a separate Git repo entirely. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
Devin Review found 1 new potential issue.
🐛 1 issue in files not directly in the diff
🐛 Inverted default value logic in _construct_random_input for singleton vs batch mode (sdk/python/feast/on_demand_feature_view.py:1014)
In _construct_random_input, the default value for missing types has its condition inverted. When singleton=False (batch mode), sample_values contains lists (e.g., ["hello world"]), but default_value is set to None (a scalar). When singleton=True, sample_values contains scalars (e.g., "hello world"), but default_value is set to [None] (a list).
Root Cause
The condition on line 1014 reads:
default_value = None if not singleton else [None]This produces:
singleton=False→default_value = None(should be[None]to match list-based sample values)singleton=True→default_value = [None](should beNoneto match scalar sample values)
The condition is backwards. Lines 1010-1011 show that when singleton=True, sample_values are converted to scalars via {k: v[0] for k, v in sample_values.items()}. So the default should also be a scalar (None) for singleton and a list ([None]) for non-singleton.
Impact: When a feature's ValueType is not found in the sample values map (e.g., an unusual or custom type), the wrong shape of default value is used. In batch mode, a None scalar is passed where a list is expected, potentially causing transformation inference (infer_features) to fail or produce incorrect results. In singleton mode, a [None] list is passed where a scalar is expected.
View 5 additional findings in Devin Review.
…o created syslink for the .cursor Agent-skill Signed-off-by: Chaitany patel <[email protected]>
There was a problem hiding this comment.
Devin Review found 1 new potential issue.
🐛 1 issue in files not directly in the diff
🐛 Inverted default value logic in _construct_random_input for singleton vs batch mode (sdk/python/feast/on_demand_feature_view.py:1014)
In _construct_random_input, the default value for missing types has its condition inverted. When singleton=False (batch mode), sample_values contains lists (e.g., ["hello world"]), but default_value is set to None (a scalar). When singleton=True, sample_values contains scalars (e.g., "hello world"), but default_value is set to [None] (a list).
Root Cause
The condition on line 1014 reads:
default_value = None if not singleton else [None]This produces:
singleton=False→default_value = None(should be[None]to match list-based sample values)singleton=True→default_value = [None](should beNoneto match scalar sample values)
The condition is backwards. Lines 1010-1011 show that when singleton=True, sample_values are converted to scalars via {k: v[0] for k, v in sample_values.items()}. So the default should also be a scalar (None) for singleton and a list ([None]) for non-singleton.
Impact: When a feature's ValueType is not found in the sample values map (e.g., an unusual or custom type), the wrong shape of default value is used. In batch mode, a None scalar is passed where a list is expected, potentially causing transformation inference (infer_features) to fail or produce incorrect results. In singleton mode, a [None] list is passed where a scalar is expected.
View 6 additional findings in Devin Review.
There was a problem hiding this comment.
Devin Review found 1 new potential issue.
🐛 1 issue in files not directly in the diff
🐛 Inverted default value logic in _construct_random_input for singleton vs batch mode (sdk/python/feast/on_demand_feature_view.py:1014)
In _construct_random_input, the default value for missing types has its condition inverted. When singleton=False (batch mode), sample_values contains lists (e.g., ["hello world"]), but default_value is set to None (a scalar). When singleton=True, sample_values contains scalars (e.g., "hello world"), but default_value is set to [None] (a list).
Root Cause
The condition on line 1014 reads:
default_value = None if not singleton else [None]This produces:
singleton=False→default_value = None(should be[None]to match list-based sample values)singleton=True→default_value = [None](should beNoneto match scalar sample values)
The condition is backwards. Lines 1010-1011 show that when singleton=True, sample_values are converted to scalars via {k: v[0] for k, v in sample_values.items()}. So the default should also be a scalar (None) for singleton and a list ([None]) for non-singleton.
Impact: When a feature's ValueType is not found in the sample values map (e.g., an unusual or custom type), the wrong shape of default value is used. In batch mode, a None scalar is passed where a list is expected, potentially causing transformation inference (infer_features) to fail or produce incorrect results. In singleton mode, a [None] list is passed where a scalar is expected.
View 6 additional findings in Devin Review.
Signed-off-by: Chaitany patel <[email protected]>
There was a problem hiding this comment.
Devin Review found 1 new potential issue.
🐛 1 issue in files not directly in the diff
🐛 Inverted default value logic in _construct_random_input for singleton vs batch mode (sdk/python/feast/on_demand_feature_view.py:1014)
In _construct_random_input, the default value for missing types has its condition inverted. When singleton=False (batch mode), sample_values contains lists (e.g., ["hello world"]), but default_value is set to None (a scalar). When singleton=True, sample_values contains scalars (e.g., "hello world"), but default_value is set to [None] (a list).
Root Cause
The condition on line 1014 reads:
default_value = None if not singleton else [None]This produces:
singleton=False→default_value = None(should be[None]to match list-based sample values)singleton=True→default_value = [None](should beNoneto match scalar sample values)
The condition is backwards. Lines 1010-1011 show that when singleton=True, sample_values are converted to scalars via {k: v[0] for k, v in sample_values.items()}. So the default should also be a scalar (None) for singleton and a list ([None]) for non-singleton.
Impact: When a feature's ValueType is not found in the sample values map (e.g., an unusual or custom type), the wrong shape of default value is used. In batch mode, a None scalar is passed where a list is expected, potentially causing transformation inference (infer_features) to fail or produce incorrect results. In singleton mode, a [None] list is passed where a scalar is expected.
View 7 additional findings in Devin Review.
Signed-off-by: Chaitany patel <[email protected]>
There was a problem hiding this comment.
Devin Review found 1 new potential issue.
🐛 1 issue in files not directly in the diff
🐛 Inverted default value logic in _construct_random_input for singleton vs batch mode (sdk/python/feast/on_demand_feature_view.py:1014)
In _construct_random_input, the default value for missing types has its condition inverted. When singleton=False (batch mode), sample_values contains lists (e.g., ["hello world"]), but default_value is set to None (a scalar). When singleton=True, sample_values contains scalars (e.g., "hello world"), but default_value is set to [None] (a list).
Root Cause
The condition on line 1014 reads:
default_value = None if not singleton else [None]This produces:
singleton=False→default_value = None(should be[None]to match list-based sample values)singleton=True→default_value = [None](should beNoneto match scalar sample values)
The condition is backwards. Lines 1010-1011 show that when singleton=True, sample_values are converted to scalars via {k: v[0] for k, v in sample_values.items()}. So the default should also be a scalar (None) for singleton and a list ([None]) for non-singleton.
Impact: When a feature's ValueType is not found in the sample values map (e.g., an unusual or custom type), the wrong shape of default value is used. In batch mode, a None scalar is passed where a list is expected, potentially causing transformation inference (infer_features) to fail or produce incorrect results. In singleton mode, a [None] list is passed where a scalar is expected.
View 6 additional findings in Devin Review.
There was a problem hiding this comment.
Devin Review found 1 new potential issue.
🐛 1 issue in files not directly in the diff
🐛 Inverted default value logic in _construct_random_input for singleton vs batch mode (sdk/python/feast/on_demand_feature_view.py:1014)
In _construct_random_input, the default value for missing types has its condition inverted. When singleton=False (batch mode), sample_values contains lists (e.g., ["hello world"]), but default_value is set to None (a scalar). When singleton=True, sample_values contains scalars (e.g., "hello world"), but default_value is set to [None] (a list).
Root Cause
The condition on line 1014 reads:
default_value = None if not singleton else [None]This produces:
singleton=False→default_value = None(should be[None]to match list-based sample values)singleton=True→default_value = [None](should beNoneto match scalar sample values)
The condition is backwards. Lines 1010-1011 show that when singleton=True, sample_values are converted to scalars via {k: v[0] for k, v in sample_values.items()}. So the default should also be a scalar (None) for singleton and a list ([None]) for non-singleton.
Impact: When a feature's ValueType is not found in the sample values map (e.g., an unusual or custom type), the wrong shape of default value is used. In batch mode, a None scalar is passed where a list is expected, potentially causing transformation inference (infer_features) to fail or produce incorrect results. In singleton mode, a [None] list is passed where a scalar is expected.
View 7 additional findings in Devin Review.
There was a problem hiding this comment.
Devin Review found 1 new potential issue.
🐛 1 issue in files not directly in the diff
🐛 Inverted default value logic in _construct_random_input for singleton vs batch mode (sdk/python/feast/on_demand_feature_view.py:1014)
In _construct_random_input, the default value for missing types has its condition inverted. When singleton=False (batch mode), sample_values contains lists (e.g., ["hello world"]), but default_value is set to None (a scalar). When singleton=True, sample_values contains scalars (e.g., "hello world"), but default_value is set to [None] (a list).
Root Cause
The condition on line 1014 reads:
default_value = None if not singleton else [None]This produces:
singleton=False→default_value = None(should be[None]to match list-based sample values)singleton=True→default_value = [None](should beNoneto match scalar sample values)
The condition is backwards. Lines 1010-1011 show that when singleton=True, sample_values are converted to scalars via {k: v[0] for k, v in sample_values.items()}. So the default should also be a scalar (None) for singleton and a list ([None]) for non-singleton.
Impact: When a feature's ValueType is not found in the sample values map (e.g., an unusual or custom type), the wrong shape of default value is used. In batch mode, a None scalar is passed where a list is expected, potentially causing transformation inference (infer_features) to fail or produce incorrect results. In singleton mode, a [None] list is passed where a scalar is expected.
View 9 additional findings in Devin Review.
Remove feast-feature-engineering skill to avoid overlap with feast-dev#6007 which covers user-facing content more comprehensively. This PR now focuses exclusively on the developer/contributor workflow skill. Signed-off-by: Sagar Gupta <[email protected]>
Sagargupta16
left a comment
Sagargupta16
left a comment
There was a problem hiding this comment.
Nice work on the content -- the reference docs for configuration, feature definitions, and RAG retrieval are thorough.
A couple of suggestions for cross-platform compatibility:
-
Directory placement: Both OpenAI and Claude Code follow the open Agent Skills standard. The convention is a
skills/directory (notAgent-Skill/). The spec also requires the directory name to match thenamefield in SKILL.md frontmatter. -
Frontmatter fields: The spec supports optional
license,compatibility, andmetadatafields that help with discoverability:--- name: feast-user-guide description: ... license: Apache-2.0 compatibility: Works with Claude Code, OpenAI Codex, and any Agent Skills compatible tool. metadata: author: feast-dev version: "1.0" ---
-
Symlinks: The
.claude/skills/Agent-Skilland.cursor/Agent-Skillfiles are symlinks to the main skill. With theskills/directory convention, these aren't needed -- agents discover skills fromskills/directly.
These are suggestions, not blockers. The content itself is solid.
4 participants
What this PR does / why we need it:
This PR adds the SKILLS for the AI Agents.
Which issue(s) this PR fixes:
#5976
Misc
For creating this Agent SKILLS i used the skill-creator skill from the https://github.com/anthropics/skills