Less than a week ago (on August 29, 2026) I published my quarterly summer update post. Oh my god, has it aged in just a few days! At least four exciting models have been "released" since then. I put released in quotes, because the most interesting of those, namely GPT-6 Astra, hasn't yet landed in my Codex – I mean ChatGPT app (why the f. did they rename it?):
- Claude Fable 5.1 by Anthropic (now we know why they released it 😏)
- Muse Spark 1.3 by Meta AI (for free in opencode 😲)
- GPT-6 Astra by OpenAI (not landed yet 😒)
- Gemini 3.8 Flash by Google (not sure if it's any good, but still worth mentioning – plus it's available in T3 Code now 😎)
Nevertheless, I feel a bit overwhelmed by all the hype about the new models, and I'm flooded with posts and videos about how each of them is the greatest ever, or even AGI arriving. So I don't feel like I need to tell you anything about them – to be honest, I couldn't, since I'm not on the early access for Astra – which in the end will probably be the only model besides Fable that I'm going to use a lot. From what I know so far, Fable is going to stick as my favorite choice for frontend and specifically Angular development.
Quick recap for everyone joining late: this series started with which LLM is best for Angular development, continued with which app or harness to wrap around it, and the third post showed how to set that harness up properly for Angular – Agent = Model + Harness, in one line. At the end of it, I promised to build on that foundation with reusable agent skills – well, here we are.
TL;DR: A Good Prompt Helps Once, a Good Skill Helps Every Time
If you only have thirty seconds: a skill is a Markdown file with a folder around it – a named, versioned, reusable procedure your agent loads only when the task calls for it. That last part is the magic. Instead of stuffing every instruction into AGENTS.md and diluting the model's attention on every single task, a skill stays out of context until its trigger fires. Lean context in, better code out. My catalogue currently holds 27 skills: 8 adopted from third parties, 19 written myself. Copy the ones you need – and only the ones you need – into your project, and adapt them to your rules. Or don't copy anything at all and just build your own.
Every skill in this post – except the two private bookkeeping ones you'll meet in a minute – lives in a new companion repo: ng-agentic-skills. After the initial commit, the repo has exactly two more – the first mirrors the harness setup from ng-agentic, the second adds the complete skills catalogue. So if you want to see precisely what skills add on top of a well-configured Angular workspace, git diff between those two commits is the whole story. I like releases you can read in one diff – and it will stay that way: whenever I update the catalogue, the changes get folded into that skills commit and force-pushed (the git-stack-rewrite skill from the catalogue does exactly this kind of surgery), so the history stays three commits long. If you cloned the repo, git fetch plus git reset --hard origin/main instead of git pull – you've been warned 😉
Now, instead of joining the hype, I want to talk about the really interesting part:
Putting the LLM Progress into Practice
In your day-to-day work and life, that is. Not even a year ago I was still wondering what I could actually do with AI. Now I'm at a point where I cannot imagine life, and especially work, without it. If the harness post was about giving your coding agent a clean workspace, real guardrails, and an operating contract, this one is about giving it repeatable procedures that load themselves.
So, maybe you're not yet deep into AI and your question is: why would I need skills? Or, on the contrary, you're an AI enthusiast and your opinion is: with the latest frontier models, harness engineering and skills aren't necessary anymore, because AGI has all the skills we need baked in. While this is true in some cases – for example, we don't have to teach the frontier models what modern Angular looks like (i.e. the Angular Developer skill becomes rather useless for frontier models – not for Gemini, though) – it is not the full picture.
Because knowledge was never the missing part. What a frontier model doesn't know is how you want things done: which steps, which gates, who commits. That's what a skill encodes – and that's why a good skill survives the next model generation. The bookkeeping story below is my proof.
The Purpose of Skills
I remember the times, roughly 30 years ago, when I started playing around with my computer – somewhere between Windows 3.1 and 95 – and had a lot of fun writing .bat files for repeatable tasks. Fifteen years or so later, I started writing .sh scripts for the same purpose, just a bit more powerful. Now, in 2026, I'm building skills for the same purpose and much more: every repeatable pattern that I don't want to explain to the model a second time.
Speaking of talking to the model (aka prompting): I have completely switched from keyboard to speech-to-text. You haven't? Try Wispr Flow – when you register with this referral link, you get a full month for free. Cancel after that month if you can. I couldn't, because now I'm about two times faster, and my prompts tend to be much better, because I put more detail into them now that I don't need to type anymore. Funny: 21 years ago I learned the ten-finger typing system – I remember it was pretty tough – and for a few years now, that skill has been becoming irrelevant. So yes, skills can become irrelevant – same as your AGENTS.md instructions – so you should remove the ones you don't need anymore whenever a new generation of models lands (so now would be a good time for that!).
Another Story – and an Example
Back in June 2026 I finally started on a skill that has nothing to do with Angular – or with code at all. The story: every month I have to do my company's bookkeeping. Collect the invoices from Amazon, ChatGPT, Cursor, Anthropic, and my mailbox, download the bank statement, match every debit to a receipt, and enter all of it into BMD Com, the bookkeeping software I have to feed. The chore I kept putting off every single month – and one that usually cost me a few hours. So in June I opened the Codex app and asked it, literally, "kannst du BMD, das Buchhaltungsprogramm, bedienen?" – can you operate BMD, the bookkeeping program? It could. It chewed through the 31 receipts of May, matched them against the CAMT53 export of my bank account – the machine-readable ISO 20022 statement – and handed me a work list plus four bank entries without a receipt. Impressive, but the next month I would have had to explain all of it again. A repeatable pattern, remember? So in August it became two skills, living in .agents/skills/ right inside my bookkeeping folder – no repo, no code, just Markdown next to the PDFs.
The first one, download-bookkeeping-documents, collects the month. Amazon, ChatGPT, Cursor, and Anthropic invoices come through the logged-in Chrome session – Codex's browser control, the computer use I praised in the summer update. Statement and CAMT53 export come from George, my bank's online banking – strictly read-only, and when strong customer authentication pops up, the skill hands me the tab instead of touching it. The invoices in my company mailbox come through a small Python IMAP importer that ships with the skill: dry run first, password in the macOS Keychain, never in the chat. Even the paper receipts I scan with my phone get rendered page by page and filed under the printed invoice date, not the scan date. Everything lands in 2026/inbox as YY-MM-DD Vendor.pdf, nothing is overwritten, duplicates are caught by hash. Then the part that matters: the skill walks through every debit on the statement and has to explain each one – an invoice, a standing document like the rent, or legitimately no invoice, like taxes and bank fees. Until every debit is explained, it isn't done – and it says so, instead of claiming completion.
The second one, maintain-bakawa-bookkeeping, takes that hand-off and enters the month into BMD's BaKaWa incoming-invoice book, again through the logged-in Chrome tab. It reads every row, opens the attached document when a correction needs evidence, fixes dates, invoice numbers, suppliers, expense accounts, and tax codes, turns a hotel bill with 10% and 20% VAT plus a tax-free part into a proper split booking, deletes duplicate rows while keeping the document, and clears BMD's "IBAN not yet processed" warnings. It's finished only when every row shows 4-Erfasst, zero warnings remain, and the saved grid – not the edit form – says so. The gates are my favorite part: it never initiates a payment, never touches master data, never deletes a document, and asks me before creating a bank connection. Not one line of Angular in there – and still the same format, one reference file per source – the progressive disclosure I'll get to in a minute – and the same rule as in every code skill: the agent reports, the human decides. My monthly bookkeeping now starts with $download-bookkeeping-documents and a coffee ☕
And the part that convinced me for good: these two skills save me three to four hours every month, and they halved my external bookkeeping bill – my tax advisor now needs one hour instead of two, and that remaining hour stays on purpose: it's the professional human-in-the-loop check that everything was booked correctly. So you could say this one workflow alone sponsors all my AI subs – roughly €500 a month right now (the details are in the summer update's cost section), soonish €600 for more Astra. Now do you get why it's time to subscribe? And I'm not only talking about AI – but also about this blog 😏
So What Is a Skill?
Let's draw the line properly, like we did with app vs harness earlier in this series.
A skill is a folder inside your project (mine live in .agents/skills/) with one mandatory file, SKILL.md, and optionally references/, scripts/, or assets/ folders next to it. The format is the Agent Skills open standard – Anthropic launched skills in October 2025 and opened up the spec that December, and by now dozens of tools read it, Claude Code, Codex, Cursor, and Copilot among them. The SKILL.md starts with a small frontmatter block – name, description, some metadata – followed by the actual instructions: the process the agent should follow, step by step, including the gates where it has to stop and ask you.
Here's what that looks like in practice – the head of my git-stack-rewrite skill, trimmed:
---
name: git-stack-rewrite
description: Fold staged changes or an existing commit into an older Git commit and rebase every affected dependent branch stack onto the rewritten commit. Use when the user says prompts like "use git stack rewrite to squash commit [source] into [target]", or asks to squash, fixup, amend, or move staged changes back into an earlier commit and then rebase branches that were on top of it.
disable-model-invocation: true
license: MIT
metadata:
author: Alexander Thalhammer
version: '1.0'
---
# Git Stack Rewrite
## Rules
- Treat this as destructive history rewriting even when it is local-only.
- Create backup refs before moving branch heads.That's the whole format: frontmatter, then the process. The disable-model-invocation line is an invocation gate – we'll get to those when it's time to write your own.
The description is the trigger. When you hand your agent a task, the harness shows it the name and description of every available skill – just those few lines, not the bodies. If the description matches the task ("write unit tests", "review the staged changes", "grill me on this plan"), the agent pulls in the full SKILL.md. If not, the skill costs you roughly 100 tokens – its name and description – and nothing else. You can also invoke a skill explicitly – /code-review in Claude Code and Cursor, $code-review in Codex. Claude Code has meanwhile merged its custom slash commands into skills: a .claude/commands/deploy.md and a deploy skill both give you /deploy and work the same way – your existing commands/ files keep working, the skill just gets a folder and a trigger.
Sound familiar? It should. This is exactly the progressive disclosure pattern from the harness post, one level up. There, the style guides loaded just-in-time by file type – touch a .scss file and the SCSS style guide loads, nothing else competes for attention. Skills do the same for procedures: the testing skill loads when you're testing, the migration skill loads when you're migrating, and neither pollutes the context of the other. A bloated context dilutes attention, buries the relevant instructions, and degrades the quality of the answer – the needle-in-a-haystack problem all over again.
And the references/ folder? Progressive disclosure again, one more level down. My ng-forms skill keeps the deep material – validation, custom controls, dynamic forms – in separate reference files, and the SKILL.md tells the agent which one to open for which job. The agent reads two levels deep at most, and only what it needs.
One more thing skills are, and this took me a while to appreciate: they are a tool for predictability. An LLM is a stochastic system; a skill exists to wrangle determinism out of it. The agent won't produce the same output every run – no LLM will. But it gets the same process every run. Same steps, same gates, same checkpoints where a human looks at the result. That's what makes agent output reviewable at scale.
How to Use Skills
The wiring is refreshingly boring, which is a compliment 😊
Project skills live in the repo, committed like any other code. I keep mine tool-agnostic in .agents/skills/ – Codex and Cursor read that folder natively, and Claude Code picks it up directly too – no symlinks, no duplicated .claude/skills/ mirror, one canonical location. They ride along with the repo, so every teammate and every CI agent gets the same procedures.
Global skills are the ones you want in every project – for me that's the meta-skills like create-a-skill and handover. Those get copied (not symlinked) into the harnesses' user-level directories:
cp -R .agents/skills/create-a-skill ~/.claude/skills/
cp -R .agents/skills/handover ~/.claude/skills/
# and the same into ~/.agents/skills/, which Codex and Cursor share:
cp -R .agents/skills/create-a-skill ~/.agents/skills/
cp -R .agents/skills/handover ~/.agents/skills/Yes, copied twice – once for Claude Code, once for everyone else. Not elegant, but explicit – and explicit beats clever when the thing being configured is an autonomous coding agent. It also means the global copies go stale – I re-copy them whenever I touch the project version, nothing fancier than that. A useful advantage of having a separate folder for Claude is that I can choose which skills I provide for Fable and which ones for GPT. At least on the global / user level.
And that's it. No build step, no marketplace account, no lock-in. Skills are Markdown files in a folder. The format is so simple that the same catalogue works across Claude Code, Codex, and friends – which is exactly why I bothered building one.
That stayed true even after August 2026, when Amazon, Cursor, Microsoft, OpenAI, and Vercel – conspicuously, without Anthropic – agreed on Agent Plugins, a standard for shipping skills around: a plugin.json next to a skills/ folder and an optional mcp.json. Note what the plugin is: a wrapper. The unit of work is still the SKILL.md. If you ever need to hand a catalogue to other teams, wrapping it into a plugin is an afternoon; for a project-level catalogue you don't need one, and I don't have one. Claude Code has had its own plugin format since long before that – one more reason to keep the skills themselves tool-agnostic, whatever wrapper is in fashion.
Which brings us to what's actually in the catalogue. The ng-agentic-skills repo documents all of it in 02-SKILLS.md, but let me walk you through the two groups.
Third-Party Skills
Not everything needs to be homegrown. Some problems – brainstorming before coding, test-driven development, structured debugging – are not Angular problems, and smart people have already written excellent skills for them. I adopted eight – though, spoiler, I've since stopped using two of them:
| Skill | What it does | Origin |
|---|---|---|
| angular-developer | The Angular team's official skill – scaffolds via the CLI, adapts to the detected Angular version, and verifies its own output with ng build. Not needed if, like me, you're on a frontier model like Fable (or soon Astra): as a code quality nerd I have my AGENTS.md and a coding style guide, and that's guidance enough. So I don't need it! |
angular/skills |
| brainstorming | Design-first dialogue, one question at a time, with a hard gate: no code until you approve a written design. Use when you don't know what you need. | obra/superpowers |
| code-review | Two-pass review of your changes – requirements first, then style-guide conformance per file type. Definitely useful – but there are many other options, so just create your own review skill. Mine even fires up three reviewer sub-agents on different models, e.g. Fable, Sol, and Opus (I have a lot of unused Opus budget, that's why). | obra/superpowers (adapted from requesting-code-review) |
| diagnosing-bugs | Feedback-loop-first debugging: build a tight red/green loop before hypothesizing, then fix behind a regression test. | mattpocock/skills (adapted) |
| grill-me | Interrogates your plan relentlessly, one question at a time, until every branch of the decision tree is resolved. Use when you know what you need. | mattpocock/skills |
| spartan | Manages spartan/ui components via the Brain (headless) + Helm (styled) layers and the spartan CLI. I plan to release a new component lib post soon – watch out for that. | spartan-ng/spartan |
| test-driven-development | Red-green-refactor discipline: no production code without a failing test you watched fail. I don't use it – I prefer letting the model write e2e tests instead, together with the implementation. | obra/superpowers (adapted) |
| unslop | Cuts the AI tells out of prose – puffery, filler, hedging, "not just X but Y" – and puts opinion and specifics back in. For docs, ADRs, PR descriptions, commit messages, and UI copy. | cursor/plugins (pstack) (adapted) |
Four of these are marked (adapted) because I changed what they do – three more carry small content corrections I keep ahead of upstream, all recorded in the index. More on that in a minute.
The newest one, unslop, is the odd one out: it's the only skill here that polices prose rather than code. It's Lauren Tan's skill from the pstack plugin in Cursor's marketplace: 31 named patterns – "not just X, but Y", the forced rule of three, "serves as" where "is" would do – plus the harder half: put an opinion back in, vary the rhythm, be specific. If you've ever merged a PR description that read like a press release, you know why it earned its slot.
The Angular team ships a second skill: angular-new-app, for scaffolding a fresh app. I didn't adopt it – this catalogue is for the apps you already have – but both install with one command, npx skills add https://github.com/angular/skills, and both keep moving: angular-developer picked up HttpClient, naming-conventions, and pipes references just this summer. Upstream doesn't stand still, which is what the adaptation step just below is about.
A word of caution before you go skill shopping, and I mean it: skills are executable instructions, so a third-party skill is as risky as any dependency you pull in. It runs with your agent's permissions, inside your repo, with your credentials nearby. Skills can also ship code: brainstorming comes with a small Node server plus start/stop scripts, diagnosing-bugs with a shell-script template – I read all of them, and hardened the server, before they went in. The risk is no longer hypothetical either: when Snyk audited nearly 4,000 public skills across the ClawHub and skills.sh marketplaces in February 2026, more than a third had at least one security flaw and 13% a critical one – malware, prompt injection, leaked secrets. Read every third-party skill before adopting it – they're short, there's no excuse – and consider scanning them with a tool like NVIDIA's SkillSpector. You wouldn't npm install a random package without a glance at what it does. Same rule here, except this dependency talks your agent into things.
Adapting Skills to Your Project
Only one of the eight went in as-is – and even that one got reformatted. This is a step worth budgeting time for. Two kinds of changes, worth keeping apart:
Normalization – formatting and housekeeping that doesn't change behavior. I moved long docs into references/, rewrote descriptions into the "what it does + when to use it" shape so triggers fire reliably, and ran everything through Prettier.
Adaptation – actual behavior changes, and this is where your project's rules win over the upstream author's. The upstream test-driven-development skill assumed a different toolchain; mine now speaks pnpm and Vitest and delegates test-writing to my local skills. diagnosing-bugs had its feedback loops renamed to match this stack – the same feedback loops, cheapest first, from the harness post. And the biggest one: upstream skills that auto-committed their results now surface the diff and let the user commit. My repo, my rules – the skill adapts, not the workflow.
The freshest example is unslop. Upstream bans em dashes, en dashes, and parentheses alike, wants sentence-case headings, and strips emojis from headings and bullets. My house style is the spaced en dash, my headings are Title Case, and the podium emojis stay. So three of its patterns now say the opposite of upstream. Its invocation changed too: upstream is human-only (disable-model-invocation: true) with a description that just says "Must always apply", so I made it model-invocable and scoped the trigger to prose – not code.
Whatever you change, record it. My MARKDOWN_HASHb2f8254655ba1ca8925ec5373d3c82cdMARKDOWNHASH marks every behaviorally adapted skill with (adapted)_ and names the upstream, so future-me knows what can be updated from upstream and what would be overwritten. Treat vendored skills like a fork you actually maintain – because that's what they are.
My Custom Angular Skills
Now for the larger group – the 19 skills I built myself, most of them Angular-specific. This catalogue is the distilled version of what I keep explaining in workshops and code reviews: modern Angular v22+ defaults, signals everywhere, zoneless, strict TypeScript, and a human checkpoint at every step that matters.
| Skill | What it does |
|---|---|
| create-a-skill | The meta-skill: creates, edits, and prunes skills so each one runs predictably. |
| create-e2e-tests | Detects Playwright vs Cypress (scaffolds one with approval if missing), then writes and runs a behavior-level e2e spec. |
| git-stack-rewrite | Folds staged changes or a commit into an older commit and rebases every dependent branch stack – with backup refs, treated as destructive. |
| grill-with-style | The grilling loop, but anchored to your project's domain model and style guides – it sharpens the terminology as it goes. |
| handover | Compacts the current session into a handover document the next agent (or the next you) can pick up. |
| ng-accessibility | Audits and builds a11y to WCAG AA – semantic HTML, keyboard and focus, CDK a11y – verified with axe or Lighthouse. |
| ng-data-access | The typed server layer: reads via httpResource()/resource()/rxResource(), mutations via HttpClient, SSR-safe transfer caching. |
| ng-forms | Signal Forms (public API since v22): signal model + schema validation, field state, custom controls, dynamic forms. |
| ng-migrate | Runs ng update and the official migration schematics one verified checkpoint at a time – you commit each one. |
| ng-performance | Measure-first performance work – initial load and runtime – where every fix ends with a re-measure. |
| ng-prototype | Throwaway prototypes to answer a design question – a terminal logic app or several UI variations on one route – then absorb or delete. |
| ng-refactor | Modernizes one legacy component at a time via a 7-step blueprint: Analyze → Declutter → Update → Modernize → Type → Refactor → Review. |
| ng-review-architecture | Reviews the architecture through two lenses – DDD bounded contexts and deep vs shallow modules – then drills into chosen findings. |
| ng-review-style-guide | Whole-codebase audit against every project style guide, severity-ranked, fixing only on approval. |
| ng-security | Defense in depth: sanitization/XSS, nonce-based CSP and Trusted Types, HttpClient XSRF, SSR allowed hosts, dependency hygiene. |
| ng-signal-store | Guards whether state is genuinely shared first – then builds an @ngrx/signals SignalStore with entities, rxMethod, and store tests. |
| ng-styling | Audits styling against the style guide – encapsulation, design tokens, BEM, no !important, no ::ng-deep – and fixes in small verified batches. |
| ng-testing | Vitest unit and component tests for standalone, zoneless Angular – TestBed, signal assertions, harnesses – asserting public behavior only. |
| update-skills-directory | Keeps the catalogue itself honest: audits every skill's frontmatter and structure, and keeps the index in sync. |
A few of these deserve a sentence beyond the table.
The review skills do the most work. code-review (adapted) reviews the diff, ng-review-style-guide audits the whole codebase, ng-review-architecture questions the boundaries, and ng-styling polices the SCSS. Together they do the heavy lifting on the reviewing side of the human-in-the-loop workflow from the harness post – and they all share one rule: report first, fix only on approval. No skill in this catalogue commits your generated or refactored code – the agent surfaces the diff; the human commits (git-stack-rewrite is the deliberate exception, because rewriting history is its whole job). That single convention has saved me more grief than any prompt trick I know.
Some skills refuse to act. ng-signal-store refuses to build a store until it has established that the state is truly shared – prefer a local signal() or computed() first (computed() is still my favorite feature in modern Angular). create-e2e-tests won't silently pick a test runner; if neither Playwright nor Cypress is set up, installing one is an explicit, gated step. A skill that knows when not to act is worth three that always do.
And ng-refactor is the one I'm most excited about 🥳 – it's the direct on-ramp to the brownfield refactoring post I teased at the end of the harness setup post. Seven steps, a human checkpoint after each, and the boring parts (updates, schematics) delegated to ng-migrate. Please, please contact me if you've got any feedback on it.
You'll also notice what the custom skills don't repeat: the style rules themselves. The skills reference the project style guides from the harness post instead of duplicating them – the guides stay the single source of truth, and the precedence rule still holds: project rules override generic Angular advice and any skill's examples.
The Biggest Win: Creating Your Own Skills
You don't need my catalogue – you need your catalogue. Here's how I build a new skill, and yes, there's a skill for that: create-a-skill interviews me about the process, drafts the SKILL.md, and then prunes it. If you've read this far you already know why the meta-skill exists: creating skills is itself a repeatable procedure, so of course it's a skill.
What I've learned makes a skill actually good:
- Write the description for the trigger, not the reader. The name and description are all the agent sees before deciding whether to load the skill, and the description does the routing. "What it does + when to use it", ideally with the literal phrases a user would say ("grill me", "hand over"). A beautiful skill with a vague description simply never fires.
- Keep the
SKILL.mdlean. Mine stay under 500 lines, most far under – the spec itself recommends that cap, and a body under 5,000 tokens. Everything deep goes intoreferences/. If your skill needs an essay, your skill is probably two skills. - Encode process, not knowledge. The model already knows what a unit test is. It does not know that in this repo the test must fail first, that the dev server is off-limits, and that you want to see the diff before anything lands.
- Decide who may trigger it. The spec's frontmatter is deliberately thin – invocation control is the harness's job, layered on top. In Claude Code,
disable-model-invocation: truemakes a skill human-only,user-invocable: falsekeeps background knowledge out of the/menu, andcontext: forkruns a skill in a sub-agent so its noise never lands in your main context. Codex has the same gate in a skill'sagents/openai.yaml, nested underpolicy:(allow_implicit_invocation: false). Mygit-stack-rewriteships both – you saw the Claude Code one in the excerpt above – because no agent should decide on its own to rewrite history, whichever harness it runs in. A gate in the frontmatter beats a gate in the prose. - Make skills delegate to each other. My
test-driven-developmentskill enforces red-green-refactor but hands the actual test-writing tong-testingorcreate-e2e-tests. Small skills that compose beat one mega-skill that tries to do everything – the same deep-vs-shallow-module argument as inng-review-architecture, applied to the skills themselves. - One skill maintains the rest.
update-skills-directoryaudits the frontmatter, the folder structure, and the index whenever the catalogue changes.
Start small. Take the next process you explain to your agent for the third time, and turn exactly that into a skill. A good prompt helps once, remember?
Agentic Engineering Workshop
By now the pattern of this series should be visible: the model, the app, my Angular guardrails, my Angular Coding Style Guide, the review workflow – and now the skills that turn all of it into repeatable procedures – belong together.
In our Agentic Engineering Workshop we build exactly this, hands-on: your style guide, your AGENTS.md, and a skills catalogue tuned to your team's rules instead of mine – and then put it to work on spec-first workflows, code review, testing, and brownfield refactoring in real Angular codebases. English or German, as always.
- 🤖 Agentic Engineering Workshop – 2 days (or 3 half-days online), remote or in-house, English or German, for advanced Angular developers – next public dates (both in English): September 7 to 9, 2026 (yes, that's next week – ask fast) and November 30 to December 2, 2026
Conclusion
Skills are how a harness setup stops being a pile of instructions and becomes a set of repeatable procedures. The style guides say what good Angular code looks like; AGENTS.md says how the agent should behave; skills say how specific jobs get done – loaded just-in-time, out of the context until the task calls for them, with the human checkpoints built in.
Which answers the question from the top of this post: no, four new models in a week don't make skills unnecessary. Fable 5.1 knows Angular better than any skill of mine could teach it. What it doesn't know is that in my repo nothing gets committed before I've seen the diff, that a bank debit without a receipt means "not done", and where exactly it has to stop and ask me. That's not knowledge, that's process – and no model generation ships with yours.
That's also what putting the progress into practice looks like: not a benchmark score, but three to four hours of my month back, an external bill cut in half, and the remaining hour deliberately left to a professional. Two Markdown folders sponsor my AI subscriptions – and honestly, I'd rather write about those than about the hype.
Two closing thoughts.
First: copy only the skills your project actually needs. The catalogue has 27 entries because it covers my work – and even I skip two of them, as the third-party table admits. Your project almost certainly needs fewer. Every model-invocable skill's name and description rides along in your agent's context on every task, so an unused skill isn't free, it's noise. A project without a store doesn't need ng-signal-store; a project that will never write e2e tests (fix that, by the way 😉) doesn't need create-e2e-tests. Pick, copy, adapt – don't hoard.
Second: skills expire, and that's a feature. Like the whole harness setup, these procedures are tuned to a model generation – most of them took shape while I was working with Opus 4.7 to 4.8 and GPT-5.5, and the gates show it. Some of them exist purely because a 2025 model couldn't be trusted without them; those can go with Fable 5.1 and Astra. The ones that exist because I want to decide stay. The pruning I recommended for your AGENTS.md up top starts with my own catalogue, and I fully expect to delete skills from it and count that as a win. The goal was never a big catalogue – it was good code with less steering.
Everything is in the ng-agentic-skills repo – clone it, take the skills you need, and make them yours 🚀 Next up: prompting and reviewing, the two moments where you still do the actual work – and after that the workflows I teased in the harness setup post. The real, dusty brownfield code gets its turn a little later in this series, I promise.
Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️