I actually just have one for each of the domains I work in. Honestly, they don't change much. I find that until I need to look at them (talking to a class, in a presentation, etc.) I don't find a need to do so.

I grabbed the skill, but I'm really wondering if the magic we get from Fable can additionally be resulted by generating great specs/PRD's. I've run through a few builds on Fable generating some pretty large projects (talking 6-8 phases). I'll be honest though, my results have been really impressive but I'm inclined to think that the results may be heavily weighted because I built a prototype in Claude Design, handed it off to Claude Code in plan mode, planned through the project specs for an hour (with Opus), and then started the build in phases with Fable. My specs were pretty large, but each phase returned exactly what I was expecting, albeit I could tell where Fable reasoned through edge case errors while testing. My primary goal was to build a few well-spec'd apps in Fable and (once the free week was over) re-run the builds with Opus. I'll know for sure, but I'm hopeful to get the same results. (I'll test with and without the skill, too.)

I think you're living in a world where you'll be best positioned to "know" software engineering but also effectively use AI to increase your efficiency and quality. I've been developing software for the past 20 years and I've seen us go, particularly in the last 8 or so years, from living life in Stack Overflow as truth, to being on alert because Github was scanning your repos to build AI, to now advising the devs on my time to continue to grow by still building, engaging in standups, and reviewing code, but also knowing how to effectively use AI (yes, with guardrails). I push my team to embrace AI; know how to prompt, automate, orchestrate, and manage agents; know which model to use for what work; and know when to stop/reject the output. I'd be wary of the folks that say not to use AI, they will be left behind. But also stay clear of those who say you don't need to know how to code. They won't build apps that will scale and persist, and real software teams won't hire them.

@Nkong Joshua I understand where you are coming from - I don't deny fundamentals are paramount. I'll just add from the perspective of someone who is currently a CTO and hires (and sometimes has to let go, too) developers, I don't think you can separate the two - you have to do both. If I'm hiring someone for a dev position, I need both at proficiency. As a modern day dev, you are writing & reviewing code while at the same time managing CI/CD pipelines & test suites (rife with AI), programming agents, orchestrating workflows, managing agentic automations (and more) all at the same time. If a dev cannot use AI tools and systems to assist with and enhance the work they won't be as viable for me to hire and their productivity will quickly impact the team.

One thing you can do if a skill isn't there is to copy the transcript into a new chat prompt and then ask Claude (or your GPT of choice) to build you the skill discussed in the transcript. Be sure to also ask if it understands and to ask any clarifying questions it may have. I've done this on many occasions, and it's worked pretty well.

Fellow security leader — this is my favorite kind of post, because you're starting in exactly the right place. Most people learn Claude Code and agents by asking "what can it do?" and bolt security on later. You're starting from the threat model, which means you'll skip about 80% of the rework the rest of us did. I'm a CTO/CISO and I run an AI/software studio, so I've had to build this muscle for my own org and for clients living under SOC 2 / ISO 27001. Two frames have served me well: how I practice, and how I actually build. 1) ENGAGEMENT & PRACTICE — treat your learning environment as production-adjacent. • All org AI usage runs through sequestered, domain-bound tooling. For us that's been ChatGPT Teams locked to our org domain, and I'm mid-migration to Claude (Team/Enterprise) now. Personal/free accounts touching org data is a hard no. • Experiments live in a homelab or remote lab — never onsite. My own OpenClaw build runs externally on a hardened Hostinger VPS in Docker, fully off the internal network, and I require the same of everyone, IT team included. Nobody's first agent experiment gets to touch the corporate LAN. • I run hands-on AI-usage + security trainings for staff and constituents, and we just wrapped two rounds of an ethical-AI course in our LMS. Hands-on beats slideware every time. If you want one recent reason this posture is correct: the OpenClaw skills supply chain got hit hard this year — the ClawHub registry was poisoned at scale (several of the most-downloaded skills turned out to be malware), and Microsoft issued an enterprise advisory on it. That's the entire case for "experiments live in the lab, not on the network" in a single news cycle. So, practice advice: stand up an isolated lab (VPS or local VM + Docker), get a real Anthropic Team/Enterprise seat for actual work, and learn by building small agents in that sandbox before anything earns network access. 2) DEVELOPMENT & TOOLING — where I'd actually start, in order. Everything I ship has to survive a Drata-driven SOC 2 / ISO 27001 audit. Commit to an security/audit framework like one of the 2 above (talk to your CISO or supe about that), and it will guide a lot. The privacy + integration work for the web & mobile apps I lead my dev team building, hardening Entra/Active Directory, Salesforce, and the surrounding infra taught me the core lesson: an agent is just a privileged non-human identity — so I treat it like one. Start with the official material, then layer the security frameworks.