In my experience, a skill is better suited for this instead of an MCP.
If you don’t want the agent to probe the CLI when it needs it, a skill can describe the commands, arguments and flags so the agent can use them as needed.
For Jira/Confluence, I also struggled with their MCPs. JIRA’s MCPs was hit or miss and Confluence never worked for me.
We don’t use the cloud versions, so not sure if they work better with cloud.
On the other hand, i found some unofficial CLIs for both and they work great.
I wrote a small skill just to give enough detail about how to format Epics, Stories, etc and then some guidance on formatting content and I can get the agent do anything i need with them.
This is interesting. I wrote a “memory indexer” with the idea to provide a tool (cli) for my agent to “remember” past conversations we had in other session. A little bit in the spirit of your second tool I think
I can solve the cube with the regular “easy” 3-layer approach, but I’d like to solve it faster.
The issue is that the techniques for fast solving require to learn many different patterns to get to the right solution fast.
I don’t know really how ppl that solve it fast accomplish getting to that level, but to me it would be amazing if i could just set the cube in know scrambled states that let me practice and memorize specific algorithms repeatedly until I learn them.
The problem is that I don’t know enough yet to distinguish which are those initial states, let alone setting the cube in that state, so something that could set it up for me to practice would be amazing
Maybe this may help. What if we are not talking internal development teams but something different, like a commercial/public API?
In those cases you cannot affort or expect to have meetings with folks to explian and communicate, and you also can appreciate more the abuse (unintended or not) that tokens can have.
I particularly liked that OP mentioned about expiration, key rotation and more advanced features you can achieve with his proposal, like switching schemes
I’ve been hiring interns and managing internships for the past 10+ years.
The number of interns at any given time varies from 1 to 10+
We were a small team at some point (less than 10) and now the company is bigger (~500 engineers).
We hire most interns if they have a successful internship and are interested in working with us.
I really love working with young engineers, mentoring them and helping them shape their careers.
I don’t have any specific resources to pint you to, but typically what I do is to have a bunch of well defined/specified projects, that can take anywhere from 2 to 4 months to complete.
Projects vary so I can accommodate to their interest if they have anything specific in mind:
- testing
- api development
- frontend
- systems programming
- etc
If I’m the mentor of an group of interns, I make sure I meet with them on a daily basis. I will also meet with them 1:1 and provide prompt and actionable feedbak on how they can improve.
I can say that we at my company are really satisfied with the results we’ve yielded during the past 10+ years, and the talent we have been able to recruit and groom through that program.
Back in the day when I started coding in Go, I basically did the Go Tour on the official website, and watched some of videos.
I paid close attention to learning how to write idiomatic Go. I also read a bunch of code from the std lib.
Then after a few days I jumped right into coding. I started with a simple CLI to do some heave lifting in our Ci/CD pipelines (for work) and then I also started coding some web apps for my perdonal use.
After this, I started designing and building a few systems that were needed internally at my workplace and I also started training other folks in Go.
That was back in 2017. Today we have several big systems running in production and a strong team of engineers all working and enjoying Go :)
I would recommend to anyone a similar path:
- learn the basics
- build and release things
- teach others who may be interested
At that time my background was as software engineer (~17 years) mainly writing Java and some Javascript
I think the issue here is that sanctions require usually time to really take effect. The government is already installed by the time they come. The dictators and their cronies are shielded and live lo comfortably.
The population is either brainwashed or brutally repressed when it complains (particularly eliminating leaders).
It’s hard to make a case for sanctions as the solution as there are plenty of counter examples: Cuba has been heavily sanctioned for over half a century and little has changed no matter how dire the situation gets.
I wish they worked for sure, because what other resources you have against a nuclear power?
Edit to add: also, sanctions have exceptions (usually to shielding the sanctioning countries from suffering consequences, as in this case with Russia and the energy related transactions, with the effect of keep that money flowing for Russia).
And these tyrants workaround the sanctions in many cases with the help of other nations.
If you don’t want the agent to probe the CLI when it needs it, a skill can describe the commands, arguments and flags so the agent can use them as needed.