Gotcha. What would the ideal look like? Someone could create a financial doc they want to share then tell their agent to "Share foo.md with my team", and it would via mcp? On the backend, that mcp server takes the file and packages it into the plugin, which hopefully auto-updates?
Makes sense. Would a tool that let non-tech people easily share and distribute skills without needing git be worth adoption? Would the info being shared just be skills or something else?
This is an underrated comment. You could have the best product out there, but AI has not only lowered the effort for competitors but has flooded traditional ways to get your product known, from outbound sales to content marketing. Sometimes make you question whether there are customers anymore.
Why stop at skills though? If you are trying to solve the provisioning problem for agent tools, shouldn't that also include MCP, commands, hooks, rules, etc in addition to skills?
I could be wrong, but I don't think there is anything in the skills spec that prohibits a skill from having binaries? A skill may even choose to embed them to be able to run in sandboxed environments.
Agreed on skills not being static. Of course, with the way the internet works, I don't want them to be too dynamic either :)
If you want to share skills using something that has versioning, automatic updates, and focused on teams vs the internet at large, consider sx - https://github.com/sleuth-io/sx
Right, Jira is great at planning, but requires a lot of gardening to keep it up to date with actuals like when things ship and where. Glue automations like this can be really helpful.
I met and worked with Bob in open source work in the mid 2000's, mostly with what would become Guice. He wrote this framework, again, thanks to his distaste of Spring and we put an early version of it what would become Apache Struts 2. Man, if I ever got cocky in my programming skills, I just needed to read that Guice prototype code and I was quickly humbled. The best part is he was just an awesome guy to be around. Very friendly, accepting, humble, and a ton of fun. I still talk about this guy I know who was married on the bridge of the Star Trek Enterprise 1701 D (at the MGM before it was torn down)...
I tried and liked Mint, but ended up with Red Pocket (MVNO that does Verizon, T-Mobile, and AT&T) when I moved somewhere that needed AT&T. It is pretty handy having one provider but having a choice of network. It also helps they have plans as low as $5/month, which is great for kids and infrequent users.
Where I found that fell down was wanting to do things like slow zooms and interesting transitions. I'd love something like a Python or bash script to tweak that addressed those.
Shotcut has this one cool feature [1] - drop a bunch of pictures into it and it'll create an animated slide show automatically. I've looked for ways to automate that via something like ffmpeg, but haven't found any better options.
I haven't tried using the teleprompter with a webcam, but I don't see why it wouldn't work. I use a Sony a6600 myself, with a Sigma 16mm/f1.4 prime lense.
Regardless, I recommend capturing in 4k, and running that through OBS so you can zoom/crop the image for ideal framing, optional of course.
I use the Caddie Buddy one [1], which is a bit more robust for bigger cameras. There are other options where you can use your phone or something, but I prefer using a mirrorless and a good sized monitor.
I'm surprised no one has mentioned using a teleprompter yet. You can pick one up for around $100 and when combined with a little 7" monitor (another $100) attached to your computer, creates a nice setup for zoom calls where you can look directly at your partner. Also doubles as a great talking head setup for video production.
Exactly! Faster cycles means less waste and more productivity, not to mention better solutions and happier team members. It takes work for sure to build those relationships, but everyone is better off for them.
Well said. Funny we realized long ago that you can't just have a backend team build an API then throw that the wall to a frontend team to use it, yet somehow, we often try to do that with design. To achieve what you describe takes more than a conversation, but a healthy and active relationship.
I recently did an interview on this topic [1] and I was surprised to hear the designer say, "If the developer tells me to design whatever and they'll build it, that is a huge fail". I kinda assumed designers were in their own world where we (developers) met at the DMZ, but his point is we are all part of the same team. The more I thought about it, the more sense it made.
