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
A few years ago we started using HackerRank and created a test with 4 or 5 coding questions for candidates to do on their own. They could pick the programming language from about 10 options and the questions had varying degrees of complexity, with one being particularly difficult.
I sent it to almost all engineers on the team before we started using it and none could hit a 100% on it.
We still went ahead and started using it in our process. Non surprisingly, most folks would fail to get a perfect score but we still use it to see what they tried and also one of the following interviews was a review of the whole test with the applicant as we discussed their thought process and what other odeas they may have come with since they took the test.
Our intention with the test was mostly basic problem solving skills and was the first step in the process so it also worked as a filter.
That’s understandable, but why then they seem to operate under the same premises still?
We are in the post COVID years now and more and more organizations are using it today.
Is it accurate to say they have no incentive to improve, given their dominance in the enterprise space and the complicity of some finance/IT departments into forcing it on their employees given the cost savings and the convenience?
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.