Agentic Engineering: Skills for Angular Development

TL;DR: One-Time Prompts Fade, Reusable Skills Persist

If you have half a minute: a skill is just a named Markdown file wrapped in a folder — a versioned, repeatable procedure your agent pulls in only when the situation demands it. That final detail is what makes it powerful. Rather than burying every rule inside AGENTS.md and watering down the model’s focus across all tasks, a skill stays dormant until the right trigger activates it. A leaner context window means sharper output. Right now, my personal collection holds 27 skills: 8 borrowed from external authors, 19 crafted by me. Grab what suits you — and only what suits you — drop it into your workspace, and tweak it to fit your conventions, or skip the copying entirely and roll your own.

Each skill covered here, aside from the two private bookkeeping routines you'll encounter shortly, is housed in a fresh companion project: ng-agentic-skills. Following the initial commit, the repo has precisely two further ones — the first faithfully replicates the harness configuration from ng-agentic, while the second brings in the full skill library. So, if you're curious about exactly what skills contribute beyond a properly tuned Angular setup, a git diff between those two commits tells the entire tale. I appreciate a release that fits within a single diff — and that principle won't change: whenever the library gets updated, changes fold directly into that skills commit and are force-pushed (the git-stack-rewrite skill from the library performs exactly that kind of surgical operation), preserving a steady three-commit history. If you've already cloned the project, run git fetch paired with git reset --hard origin/main rather than git pull — consider yourself cautioned 😉

With that out of the way, rather than fueling the buzz surrounding the newest releases, I'd like to shift focus to what genuinely matters:

Translating LLM Advances into Daily Practice

That is, into your regular workflow and routine. Under a year back, I was still questioning what tangible value AI could offer me. Currently, I've reached a stage where both my professional life and personal routines feel incomplete without it. If the harness discussion centered on equipping your coding assistant with a tidy environment, solid boundaries, and a working agreement, this piece is about handing it repeatable workflows that activate on their own.

So, perhaps you haven't fully embraced AI yet and you're asking: what's the actual need for skills? Conversely, maybe you're an AI advocate convinced that with cutting-edge frontier models, harness design and skills have become obsolete, since AGI inherently carries every capability we might require. That holds in particular scenarios — take, for instance, the fact that frontier models don't need instruction on what contemporary Angular entails (making the Angular Developer skill largely redundant for them, though not for Gemini) — yet that represents only a fraction of the reality.

Because raw knowledge was never the actual gap. What a frontier model lacks is insight into how you prefer operations conducted: which steps to follow, what checkpoints to enforce, who handles commits. That's precisely what a skill captures — and the reason a well-crafted skill endures regardless of the next model iteration. The bookkeeping illustration below serves as my demonstration.

The Role Skills Play

I recall the era, roughly three decades past, when I first experimented with my computer — somewhere around the transition from Windows 3.1 to Windows 95 — and found genuine pleasure in scripting .bat files for repeated tasks. About fifteen years afterward, I moved to .sh scripts serving the same function, just with greater capability. Now, in 2026, I'm constructing skills for that identical purpose and beyond: capturing any recurring pattern I'd rather not explain to the model twice.

On the topic of interacting with the model, which is to say prompting, I've shifted entirely away from keyboard input to speech recognition. Still typing? Give Wispr Flow a shot — using this referral link for registration grants you a complete month at no cost. Feel free to cancel after that month if you manage. I couldn't, since I'm now roughly double as productive, and my prompts tend to be richer, because I incorporate greater detail now that typing isn't a bottleneck. Oddly enough: two decades back, I invested effort in mastering touch typing — I remember it being quite demanding — and for several years now, that particular skill has been losing its value. So yes, skills can fade in usefulness, just like your AGENTS.md directives — which is why you ought to prune the ones that no longer serve you whenever a fresh generation of models arrives, and given the recent releases, this moment is as good as any to start.

A Different Use Case – and a Concrete Example

Around June 2026 I finally got around to building a skill that had absolutely nothing to do with Angular – or with programming whatsoever. Here's the scenario: every single month I need to handle my company's bookkeeping. Pull together invoices from Amazon, ChatGPT, Cursor, Anthropic, and my email, grab the bank statement, match each transaction to a corresponding receipt, and key all of it into BMD Com, the accounting platform I'm required to use. A task I postponed month after month – and typically burned a couple of hours on. So in June I fired up the Codex app and asked, in plain terms, "kannst du BMD, das Buchhaltungsprogramm, bedienen?" – can you operate BMD, the accounting tool? Turns out it could. It processed all 31 receipts from May, reconciled them against the CAMT53 file from my bank – that's the standardized ISO 20022 statement format – and handed me a to-do list plus four transactions that had no matching receipt. Solid results, but the following month I'd have to walk it through the whole process again. A repeatable pattern, correct? So in August that became two skills, kept in .agents/skills/ right inside my bookkeeping directory – no repository, zero code, just Markdown sitting beside the PDFs.

The first one is download-bookkeeping-documents, which gathers everything for the month. Amazon, ChatGPT, Cursor, and Anthropic invoices arrive via the authenticated Chrome profile – that's Codex's browser automation, the computer-use capability I highlighted in the summer update. The statement and CAMT53 export originate from George, my bank's online portal – accessed strictly in read-only mode, and whenever strong customer authentication triggers, the skill passes the tab back to me rather than attempting to handle it. Invoices sitting in my company mailbox come through a compact Python IMAP script included with the skill: it does a dry run first, reads the password from the macOS Keychain, and never lets credentials appear in the conversation. Even the paper receipts I photograph with my phone get processed page by page and archived according to the printed invoice date rather than the scan date. All files land in 2026/inbox named as YY-MM-DD Vendor.pdf, nothing gets overwritten, and duplicates are identified via hash comparison. Then the crucial piece: the skill reviews every single debit on the statement and must provide an explanation for each one – whether that's an invoice, a recurring charge like rent, or a legitimate gap such as taxes or bank fees. Until every transaction is accounted for, it's not finished – and it explicitly communicates that state instead of falsely reporting success.

The second skill, maintain-bakawa-bookkeeping, picks up from there and records the month in BMD's BaKaWa incoming-invoice register, again working through the authenticated Chrome tab. It examines each entry, opens the associated document when a correction needs verification, adjusts dates, invoice numbers, suppliers, expense categories, and tax codes, converts a hotel bill containing 10% and 20% VAT plus a tax-exempt portion into a correct split transaction, removes duplicate lines while preserving the attached file, and resolves BMD's "IBAN not yet processed" alerts. The job counts as complete only when every row displays 4-Erfasst, no warnings remain, and the saved grid – not the editing interface – confirms that state. The safety constraints are what I appreciate most: it never triggers a payment, never modifies master records, never deletes an attached document, and requests my approval before creating any bank connection. Not a single line of Angular anywhere in that setup – yet it follows the identical structure, one reference document per data source – that progressive disclosure concept I'll elaborate on shortly – and operates under the same principle as every coding skill: the agent recommends, the human approves. My monthly bookkeeping routine now begins with $download-bookkeeping-documents plus a coffee ☕

And here's what ultimately sold me: these two skills cut three to four hours from my schedule each month, and they reduced my external accounting fees by half – my tax consultant now charges for one hour instead of two, and that remaining hour stays intentionally: it serves as the professional human-in-the-loop verification that all entries are accurate. So you might say this single workflow covers the cost of all my AI subscriptions – currently around €500 monthly (breakdown available in the summer update's cost analysis), soon creeping toward €600 with additional Astra usage. Now you see why it's worth subscribing? And I'm referring not just to AI – but also to this publication 😏

Defining a Skill Precisely

Let's establish clear boundaries, following the same approach we used for app versus harness previously in this series.

A skill is essentially a directory within your project (mine reside in .agents/skills/) that contains one required file called SKILL.md, with optional companion directories like references/, scripts/, or assets/ alongside it. The underlying format comes from the Agent Skills open specification – Anthropic introduced skills in October 2025 and made the spec openly available that December, and by now numerous tools support it, including Claude Code, Codex, Cursor, and Copilot. The SKILL.md opens with a small frontmatter section – containing name, description, plus assorted metadata – followed by the substantive instructions: the sequence of steps the agent should execute, including the checkpoints where it must pause and consult you.

Here's a practical illustration – the beginning of my git-stack-rewrite skill, abbreviated:

---
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 captures the entire structure: frontmatter first, then the workflow. The disable-model-invocation entry represents an invocation guard – we'll explore those when you start authoring your own skills.

The description field acts as the activation mechanism. When you assign your agent a task, the harness presents it with the name and description of every accessible skill – just those brief lines, never the full contents. If the description aligns with the assignment ("add unit tests", "audit the pending modifications", "challenge me on this proposal"), the agent loads the complete SKILL.md. If there's no match, the skill costs you roughly 100 tokens – its name and description – and nothing beyond that. Direct invocation also works: /code-review in Claude Code and Cursor, or $code-review in Codex. Claude Code has since integrated its legacy custom slash commands into the skills system: whether you have a .claude/commands/deploy.md file or a deploy skill, both make /deploy available and operate identically – your existing commands/ entries remain functional, the skill simply gains a dedicated folder and a trigger mechanism.

Does that ring a bell? It should. This mirrors the progressive disclosure principle from the harness discussion, applied at a higher tier. There, style guides loaded dynamically based on file type – interact with a .scss file and the SCSS guide appears, without other content competing for attention. Skills accomplish this for workflows: the testing skill activates during testing, the migration skill during migrations, and neither contaminates the other's context window. An overloaded context dilutes focus, obscures pertinent guidance, and undermines response quality – that familiar needle-in-a-haystack challenge reappearing.

And what about the references/ folder? That's progressive disclosure yet again, descending another level. My ng-forms skill stores advanced material – validation strategies, custom controls, dynamic form patterns – in individual reference documents, and the SKILL.md directs the agent on which file to consult for specific scenarios. The agent never goes beyond two levels deep, and only pulls what's actually required.

There's another dimension to skills that took me time to recognize: they're fundamentally a mechanism for reliability. An LLM operates as a probabilistic system; a skill exists to impose structure on that unpredictability. The agent won't deliver byte-identical output on every run – no LLM can guarantee that. But it will follow the identical process consistently. Same sequence, same safeguards, same verification points where human judgment reviews the output. That's precisely what enables scalable oversight of agent-generated results.

Putting Skills into Practice

The integration process is refreshingly straightforward, and I mean that as praise 😊

Project-level skills stay in the repository, versioned alongside all other code. I maintain mine in a tool-neutral location at .agents/skills/ – Codex and Cursor access that folder without any extra configuration, and Claude Code recognizes it directly as well – no symbolic links, no replicated .claude/skills/ copy, a single authoritative source. They travel with the repository, ensuring every collaborator and every CI pipeline gets identical procedures.

User-level skills cover what you need across all projects – for me that includes meta-skills like create-a-skill and handover. These get duplicated (not symlinked) into each harness's personal configuration area:

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/

That's right, duplicated twice – one copy for Claude Code, another for everyone else. Not particularly elegant, but unambiguous – and clarity beats sophistication when what you're configuring is an autonomous coding assistant. The trade-off: those user-level duplicates can become outdated – I refresh them whenever I modify the project version, nothing more elaborate than that. Having a dedicated folder for Claude does offer one practical benefit: I can selectively choose which skills I expose to Fable versus which ones GPT gets. At least at the global or user tier.

And really, that's the whole story. No compilation pipeline, no plugin registry, no vendor commitment. Skills are simply Markdown files sitting in a directory. The format is so straightforward that a single catalogue functions seamlessly across Claude Code, Codex, and others – which is precisely why I invested in creating one.

That situation persisted even after August 2026, when Amazon, Cursor, Microsoft, OpenAI, and Vercel – notably, without Anthropic's involvement – standardized on Agent Plugins, a convention for distributing skills: a plugin.json alongside a skills/ directory and an optional mcp.json. Pay attention to what a plugin actually represents: it's a container. The fundamental building block remains the SKILL.md. If you ever need to share a catalogue with outside teams, wrapping it as a plugin takes an afternoon; for project-level collections you don't require one, and I don't use one. Claude Code has maintained its own plugin format well before that agreement – yet another argument for keeping skills themselves independent of any specific tool, regardless of which packaging format gains popularity.

Which leads us to the actual contents of the catalogue. The ng-agentic-skills repository documents everything in 02-SKILLS.md, but here's an overview of the two categories.

Third-Party Skills

Building everything from scratch isn't always the right call. Certain challenges – thinking through ideas before coding, writing tests first, methodical debugging – aren't specific to Angular, and there are well-crafted skills out there from other developers. I ended up bringing in eight, though to be honest, two of them have since been removed from my workflow:

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 came in with an (adapted) tag because I modified their behavior – three others have minor content fixes I keep maintained ahead of the upstream versions, all tracked in the index. More detail on that shortly.

The most recent arrival, unslop, sits apart from the rest: it's the only one focused on cleaning up writing instead of code. It originates from Lauren Tan's work within the pstack plugin found in Cursor's marketplace. It targets 31 specific phrasing patterns – constructions like "not just X, but Y", the insistent rule of three, "serves as" standing in where "is" fits naturally – and then pushes further with the harder part: restore a distinct viewpoint, shake up the sentence flow, get concrete. If you've ever accepted a pull request description that sounded like marketing copy, the appeal is clear.

The Angular core team provides another skill as well: angular-new-app, built for setting up a fresh project structure. I chose not to use it myself – this collection targets applications that already exist – however, installation for both is a single command, npx skills add https://github.com/angular/skills. Both are actively maintained too: angular-developer gained HttpClient, naming-convention guidance, and pipes references just this past summer. Upstream projects stay in motion, which leads directly into the adaptation discussion next.

Before you start browsing for skills, take this warning seriously: skills function as executable instructions, so a third-party one carries the same risk as any other dependency you add. It operates using your agent's permissions, within your repository, with access to your credentials. Skills can also bundle executable code: brainstorming ships with a small Node server and accompanying start/stop scripts, while diagnosing-bugs includes a shell-script template – I reviewed every line and tightened the server's security before integration. This isn't just theoretical anymore either: a Snyk audit of nearly 4,000 public skills on the ClawHub and skills.sh platforms in February 2026 found that over a third exhibited at least one security vulnerability, with 13% showing a critical one – including malware, prompt injection, and exposed secrets. Examine every third-party skill before you adopt it – they're typically brief, leaving no real excuse – and think about running them through a scanner such as NVIDIA's SkillSpector. You wouldn't npm install an unfamiliar package without checking its contents. The same principle applies here, except this particular dependency can persuade your agent.

Adapting Skills to Your Project

From the eight adopted, only one came in untouched – and even that one received a formatting pass. Budget time for this step, because it matters. Two distinct types of modification are worth separating:

Normalization – this covers reformatting and general tidiness that leaves behavior intact. I relocated lengthy documentation into references/, rewrote descriptions to match the "what it does + when to use it" structure that makes triggering more dependable, and applied Prettier uniformly.

Adaptation – here behavior genuinely changes, and in this process your project's standards take priority over the upstream creator's conventions. The original test-driven-development skill expected a different package manager and test runner; my version now works with pnpm and Vitest, and it directs test authoring toward my local skills. diagnosing-bugs had its feedback loop terminology renamed to fit this stack – same loops ordered cheapest first, consistent with the harness post. And the most significant change: upstream skills that automatically committed their output now show a diff and wait for the user to commit. My repository follows my rules – the skill adjusts, not the other way around.

The most recent adaptation is unslop. The upstream version prohibits em dashes, en dashes, and parentheses equally, requires sentence-case headings, and removes emojis from headings and list items. My own writing style uses the spaced en dash, headings in Title Case, and the podium emojis remain. So three of its rules now state the exact reverse of upstream. Its invocation method was also modified: upstream limits it to human use (disable-model-invocation: true) with a description simply saying "Must always apply". I enabled model invocation and narrowed the trigger to focus on prose, leaving code untouched.

Whatever changes you implement, write them down. In my 02-SKILLS.md, every behaviorally modified skill is flagged with (adapted) and references the original upstream, so I can tell later what's safe to pull from upstream and what would get overwritten. Handle vendored skills like a genuine fork under your maintenance – because that's essentially what they become.

My Custom Angular Skills

That brings us to the bigger set – 19 skills I authored, with most being Angular-focused. This collection boils down the guidance I keep offering during workshops and in code reviews: standard modern Angular v22+ practices, signals as the default, zoneless operation, strict TypeScript, and a deliberate human review at every meaningful junction.

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.

Several of these merit individual attention beyond a table entry.

The review-oriented skills carry the heaviest load. code-review (adapted) examines the working diff, ng-review-style-guide evaluates the entire codebase, ng-review-architecture challenges where boundaries sit, and ng-styling looks after the SCSS details. These four function as the core on the evaluation side of the human-supervised workflow described in the harness post – and they all follow a single rule: document findings first; make changes only after explicit approval. No skill within this collection will commit generated or refactored code – the agent shows the diff; the human performs the commit (git-stack-rewrite is the conscious outlier, given that rewriting history constitutes its entire function). This one practice has saved me from more headaches than any clever prompting technique.

Several skills are built to decline action. ng-signal-store will not create a store until it confirms that the state actually requires sharing – it advates trying a local signal() or computed() first (computed() remains my top pick among modern Angular features). create-e2e-tests resists choosing a test runner on its own; in cases where neither Playwright nor Cypress is configured, adding one becomes an explicit, deliberate step. A skill that understands when not to act holds more value than three that respond everywhere.

And ng-refactor generates the most excitement from me 🥳 – it pieces together the direct route toward the brownfield refactoring article hinted at the close of the harness setup post. It follows seven distinct steps, pausing for human approval after each, while passing off uninteresting work (version updates, schematic runs) to ng-migrate. I'd genuinely appreciate any thoughts you have on how it performs.

You might also observe what these custom skills intentionally leave out: they don't restate the style rules. They link to the project style guides from the harness post rather than duplicating that content – the guides maintain their position as the definitive source, and the order of precedence remains: project-level rules outrank generic Angular guidance and any examples used within a skill.

The Biggest Win: Creating Your Own Skills

My particular set doesn't need to be adopted – building your own collection is the objective. This is my procedure for crafting a fresh skill, and unsurprisingly, there's a skill to handle it: create-a-skill asks me questions about the intended behavior, creates the first draft of the SKILL.md, then trims out whatever isn't essential. If you've gotten this far, the reason for this meta-skill is obvious: skill creation follows a repeatable set of actions, fitting naturally as a skill itself.

Several principles stand out for making a skill genuinely helpful:

• Draft the description for how the skill gets found, not for human reading. The name and description are the only pieces the agent examines before loading the skill, and the description guides that decision. "Its function + ideal situation", ideally including the exact words a person might use ("probe my thinking", "pass it over"). A well-built skill paired with an unclear description simply stays unused.
• Keep the SKILL.md concise. My files remain under 500 lines, often far below – the specification itself identifies that as a sensible boundary, with a body staying shorter than 5,000 tokens. Detailed material goes into references/. If a skill needs an extended explanation, it likely wants to split into two separate skills.
• Write down the workflow, not general facts. The model already understands what a unit test accomplishes. What it lacks is knowledge that in this project the test must demonstrate failure initially, the dev server shouldn't be started, and the diff needs review before anything proceeds.
• Choose who has permission to start it. The spec's frontmatter stays intentionally minimal – managing when agents may invoke skills belongs with the harness, layered separately. In Claude Code, disable-model-invocation: true limits a skill to explicit human requests, user-invocable: false hides background material from the / command list, and context: fork executes the skill within a separate sub-agent so its output doesn't clutter the primary conversation. Codex provides the same control within a skill's agents/openai.yaml, placed underneath policy: (allow_implicit_invocation: false). My git-stack-rewrite skill accommodates both options – the Claude Code aspect appeared earlier – because no agent should independently undertake a history rewrite, no matter which harness is involved. Implementing the restriction within frontmatter beats relying on instructions in the text.
• Allow skills to call on one another. My test-driven-development skill manages the red-green-refactor sequence but hands off the actual test implementation to ng-testing or create-e2e-tests. Smaller, interoperable skills outperform one large skill meant to cover everything – the same tradeoff between shallow and deep modules discussed in ng-review-architecture, now relevant to the skills themselves.
• Designate a caretaker skill. update-skills-directory reviews the frontmatter, folder arrangement, and index each time the overall collection changes.

Begin on a small scale. Pick the next process you've described to your agent for the third time, and make that specific routine into a skill. A solid one-off prompt helps for a single use, correct?

Agentic Engineering Workshop

A clear structure has been taking shape through this series: the model itself, the application, my Angular constraints, my Angular Coding Style Guide, the review process – and currently, the skills layer that converts each element into repeatable methods – all designed to function as one system.

Within our Agentic Engineering Workshop, we construct precisely that setup through practical work: your own style guide, your AGENTS.md, and a skill library aligned with your team's practices – not mine – then apply it to specification-first methods, code review, automated testing, and refactoring legacy applications within real Angular projects. Available in English or German as usual.

• 🤖 Agentic Engineering Workshop – spanning 2 days (or 3 half-days for remote attendance), offered on-site or virtually, in English or German, intended for experienced Angular developers – upcoming public sessions (both conducted in English): September 7 to 9, 2026 (coming up shortly – reach out now) and November 30 to December 2, 2026

Closing Thoughts

A skill library is what transforms a harness setup from a static document into a collection of repeatable workflows. Style guides define what clean Angular looks like; AGENTS.md dictates how the agent operates; skills determine how individual jobs are executed — pulled in on demand, kept out of the context window until required, and built around human approval points.

That brings us back to the question posed at the start: no, four fresh model releases in a single week don't render skills obsolete. Fable 5.1 understands Angular more deeply than any skill I could author. What it lacks is the knowledge that in my repository nothing gets merged without my review of the diff, that a bank transfer lacking a confirmation means "incomplete," and the precise boundaries where it must pause and consult me. That's not technical capability—it's operational convention—and no model iteration comes preconfigured with yours.

That's what real progress looks like in practice: not a synthetic benchmark, but three to four hours restored to my month, an outsourced invoice reduced by half, and the remaining hour intentionally handed to a specialist. Two Markdown directories cover my AI subscriptions—and truthfully, I'd rather document those than the surrounding noise.

Two final points.

First: adopt only the skills your project genuinely requires. The catalogue lists 27 entries because it mirrors my workload—and even I skip two of them, as the third-party comparison table notes. Your project almost certainly needs fewer. Every invocable skill's name and summary travels in the agent's context on each assignment, so a skill that never gets used isn't free—it's overhead. A project without a state store doesn't need ng-signal-store; a project that avoids e2e coverage (you should fix that, by the way 😉) doesn't need create-e2e-tests. Choose, copy, tailor—don't accumulate.

Second: skills have a shelf life, and that's intentional. Like the remainder of the harness setup, these procedures are calibrated for a specific model era—most came together during my work with Opus 4.7 to 4.8 and GPT-5.5, and the guardrails show it. A few exist purely because a 2025 model couldn't be relied upon without them; those can retire alongside Fable 5.1 and Astra. The ones that remain because I insist on making the call stay put. The trimming I advised for your AGENTS.md earlier begins with my own catalogue, and I fully anticipate removing skills from it and treating that as progress. The objective was never a sprawling collection—it was solid code with minimal oversight.

All materials live in the ng-agentic-skills repository—clone it, select what fits, and tailor it to your needs 🚀 Up next: prompting and reviewing, the two phases where you remain the hands-on contributor—followed by the workflows I previewed in the harness setup article. The gritty, dated legacy codebase gets its moment later in this series, I guarantee it.

Thank you for reading 🙏 this post was written by Alexander Thalhammer. For feedback, comments, or questions, don't hesitate to get in touch ❤️