Main Menu of rocky UI
Setup personal KEYS
One of many dialog line that rocky have
Getting CI Github workflow information
CD workflow with render

JetFlow: Bridging the Gap Between IDE and Production

Inspiration

As developers, we often find ourselves trapped in a "context-switching tax." We write code in IntelliJ, push to GitHub, and then scramble between browser tabs to check GitHub Actions progress or trigger a manual deploy on Render.com. We wanted to build a tool that brings the "Production" world into the "Development" world.

The inspiration for Rocky, our floating assistant, came from the desire to make CI/CD less of a chore and more of an interactive experience. We wanted a companion that lives in the IDE to guide users through the complex YAML configurations and deployment loops that often stall project momentum.

How We Built It

JetFlow is built on the IntelliJ using Kotlin. The architecture is modularized to handle three distinct pillars:

The Assistant (Rocky): We implemented a custom RockyFloatingActivity using Swing and the IntelliJ UI DSL to create a non-intrusive, animated floating widget. It uses a state-machine to transition between idle, helping, and alerting states.
Cloud Integration (Render & GitHub): We developed a robust RenderApiClient to interface with Render’s REST API. This handles everything to monitor a deploy lifecycles. For GitHub, we built a GitHubActionsPoller that tracks workflow runs in real-time.
Context Bundling: To support AI-driven development, we built a CodeBundleGenerator. It recursively traverses the project tree, applying smart filters to exclude noise (like .gradle or node_modules), and consolidates the project into a single Markdown "snapshot."

What We Learned

This project was a massive milestone for us as it was our first time writing any code in Kotlin and our first ever experience developing an IntelliJ plugin. Starting from zero in both the language and the framework was a steep but rewarding challenge.

This is a great addition for the Challenges section. It shows technical maturity by explaining why you pivoted from local execution to remote data fetching.

Here is the updated Challenges We Faced section for your Devpost story:

🚧 Challenges We Faced

The Learning Curve: Combining the learning of a new language (Kotlin) with the intricacies of plugin development meant that every feature took twice as long to research as it did to code. Since this was our first time with both, we had to learn the architecture of the IDE while simultaneously mastering Kotlin's syntax.
CD Synchronization and UI State: One of our biggest hurdles was the Continuous Deployment (CD) integration. We initially struggled with the Render.com API responses not reflecting correctly in our UI.
Local vs. Remote CI Logic: Initially, we planned to run CI tests locally within the IDE. However, we quickly realized that local environments often differ from production. We pivoted our strategy to fetch data directly from GitHub Actions. While more complex to implement, this provided far greater "code detail precision." By pulling the actual logs and status from GitHub, we gave the user a much more accurate understanding of why a build passed or failed in the real world.

What's Next for JetFlow

We plan to expand JetFlow's reach by:

Adding support for AWS Amplify and Vercel.
Implementing Rocky-Talk, allowing users to chat with the assistant to trigger CLI commands.
And much more :D

Built with JetBrains IntelliJ Platform SDK, Kotlin, and a lot of caffeine.