Feat: Workflows now AI executable, updated slash_command tool allows agentic autonomous discovery & execution #5089
Conversation
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
- Keep both import and kilocode_change end marker - Accept upstream's workflow.source and workflow.description - Keep mode switching functionality using workflow.mode - Add mode property to Workflow interface - Update frontmatter parsing to extract mode property
Changed translation key from RUN_SLASH_COMMAND to AUTO_EXECUTE_WORKFLOW to match experiment constant. Updated name from "Enable model-initiated slash commands" to "Enable workflow access" and description to better reflect the feature's actual behavior of accessing workflow content without approval. - Updated 18 locale files (en, ar, ko, hi, fr, tr, pl, cs, pt-BR, zh-TW, ja, nl, id, vi, uk, es, de, th, zh-CN, it) - Created changeset for release notes
- Fix experiment configuration passing in getWorkflowsForEnvironment - Enable WORKFLOW_DISCOVERY experiment by default - Use Experiments.isEnabled helper for proper fallback to defaults - This allows workflows to appear in environment details that AI agent sees
…ven when auto-execute is enabled
…ven when auto-execute is enabled
- Add workflow execution tool for slash command workflows - Sync with upstream v4.99.2 - Resolve merge conflicts
🦋 Changeset detectedLatest commit: fc11171 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
James-Cherished
changed the title
Author
|
hi @kevinvandijk I strongly recommend using workflows to separate user and LLM needs, which overlap less often than they don't, or it'll be messy as a user to view all AI workflows typing /, and as an AI to view user commands when retrieving workflows |
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.
Context
PR #4760 fixed Kilo's inability to discover workflows and execute them autonomously (main advantage: context engineering)
In-between, an attempt to fix workflow discoverability (inherited from upstream iirc) introduced minor conflicting changes needed to be resolved before merging. Note custom workflows are still not discovered despite this change in the current Kilo version 4.147.0.
This current new PR resolves the conflicts. To protect the history of the previous PR (and a rebase attempt that was proposed before the last upstream conflicting changes), I have pushed the resolve to a new branch that this PR aims to merge with main.
Implementation
Conflict 2 (Lines 72-79): Tool message properties conflict
HEAD has: source: command.source, description: command.description, mode: command.mode
Upstream has: source: workflow.source, description: workflow.description
Resolution: Accept upstream's workflow.source and workflow.description, but keep command.mode for mode switching functionality
Experimental Setting Integration
My suggestion is to make workflows discoverable by default instead of an experimental setting, since the users that would not want this feature are the users who do not use workflows/, imo, and all users using them need them discoverable. I have refrained from implementing this for now to keep feature changes minimal.
The experimental setting should only be, in my opinion, the ability to execute the workflows autonomously.
Suggestion: migrate from experimental to regular tool in the future.
How to Test
Ask Kilo to use a workflow, and watch the reasoning, or
Specific Example Technique
See results below:
Screenshots
Before
After
Tests
All tests passed successfully! 🎉
✅ Test Results - All Green!
The workflow tool feature is fully functional after syncing with upstream v4.99.2:
Test Coverage Summary:
Total: 49/49 tests passing - 100% success rate! 🚀
🎯 What This Means
✅ Your Workflow Tool Feature is Production-Ready:
.kilocode/workflows/✅ Sync Was Successful:
📊 Test Breakdown
Backend Tests (24 tests)
Workflow Tool (
runSlashCommandTool.spec.ts): 14 testsWorkflow Service (
workflows.spec.ts): 10 testsFrontend Tests (25 tests)
SlashCommandItem (
SlashCommandItem.spec.tsx): 22 testsChatRow Integration (
ChatRow.run-slash-command.spec.tsx): 3 testsType Safety (15 packages)
🎓 Key Achievements
1. Successful Upstream Sync
2. Comprehensive Test Coverage
3. Production-Ready Feature
💡 Best Practices Demonstrated
Git Mastery:
Testing Excellence:
Code Quality:
🎯 Next Steps for Your PR
1. Update PR Description
Add notes about:
2. Request Review
Tag maintainers for review:
🌟 Why This Matters
🎉 Congratulations!
This demonstrates excellent Git skills, strong testing practices, and attention to code quality. Your workflow tool feature is ready to ship and will significantly improve the Kilo Code project! 🚀