DEV Community: Martin Krause

Chapter 7: Skill, Workflow or Agent?

Martin Krause — Mon, 02 Nov 2026 10:49:02 +0000

Not every AI task needs an agent.

That's surprisingly easy to forget when agents are everywhere.

By Chapter 7 of Claude Code Beyond the Prompt, prompts, skills, workflows, agents, subagents, and connected workflows are all on the table. That means you need to know when to choose which. The book follows a well-known principle: Keep it simple.

I teach you to use the smallest structure that fits the work. Why? Because using an agent when a prompt would do does not make the system more advanced. Instead, it increases the surface area you have to understand, supervise, and maintain.

Chapter 7 gives you the framework so your architecture doesn't become bigger than the problem.

Continue your AI journey with Claude Code Beyond the Prompt. It is available from Packt. If you are moving from prompting into reusable AI workflows, this is the problem I wrote it to help you solve.

Get the book at Packt Publishing

Chapter 6: From Skills to Workflows

Martin Krause — Thu, 29 Oct 2026 07:40:33 +0000

An isolated skill is helpful, but real work is teamwork

That applies to** Agentic Work** as well, and it became obvious to me as soon as I started using Claude Code and Agent Skills professionally.

Real work often involves several known steps, with decisions and handovers between them. That is where workflows come in, and it naturally became the next step in the book.

For a reusable workflow, I distinguish between the incident and the process.

Let me give you an example: If I write down everything that happened in one case, I have documented an incident. Once I map out the steps that should still apply even when the incident changes, I have the beginning of a reusable workflow.

Moving from a reusable skill to a reusable process is what Chapter 6 is about.

Get Claude Code Beyond the Prompt (ISBN 978-1-80778-229-0) from https://www.packtpub.com/en-us/product/claude-beyond-the-prompt-9781807782290

Chapter 5: Skill Boundaries

Martin Krause — Mon, 26 Oct 2026 14:14:33 +0000

A good skill has one job.

That's what I learned the hard way. Imagine you have added a skill that analyzes logs and then turns them into a bug ticket, and then you ask: “Here are the logs. Analyze the logs, and you fix the bug.”

The evidence looks familiar. It is logs, after all. The skill analyzes them already; *how different can fixing the bug be? Quite different, actually. *

Τhe skill was designed to turn the provided evidence into a ticket. It was not designed to inspect the repository, identify the root cause, modify the code, or verify the fix.

Chapter 5 of Claude Code Beyond the Prompt focuses on boundaries.
You need to define what your skill should do and what it should not do:

- Some work belongs to the skill and should happen every time.
- Some work may be reasonable, but only after the user agrees.
- Some work belongs somewhere else.

Otherwise, your skills grow and take on tasks they aren't designed for. When responsibility drifts, output quality degrades. That is the part of skill design that is often overlooked.

Get Claude Code Beyond the Prompt at Packt Publishing:

https://www.packtpub.com/en-us/product/claude-beyond-the-prompt-9781807782290

Chapter 4: Your First Skill

Martin Krause — Fri, 23 Oct 2026 13:17:52 +0000

Your first AI skill should be small.

That was hands-down the best advice I got when I ventured into agentic engineering.

Your first AI in the book turns supplied evidence into a bug ticket. That is enough to understand the principles of a skill and to teach the movements. It is easy to grasp and has just enough complexity to show you the ropes.

That is what Chapter 4 of Claude Code Beyond the Prompt is all about. You build the first working SKILL.md. You write a description that tells Claude when the skill applies. You define its boundary, method, and output. All in plain English, the programming language of the future.

Once you've written the skill, you test the trigger against different requests:

one should clearly match.
one says the same thing in different words.
one looks similar but should not trigger the skill at all.

That last case is where things get interesting. Getting a skill to trigger is only half the problem. The harder part is making sure it stays out of the way when it should. Get Claude Code Beyond the Prompt (ISBN 978-1-80778-229-0)

https://www.packtpub.com/en-us/product/claude-beyond-the-prompt-9781807782290

ClaudeCode #AgentSkills #AIEngineering

Chapter 3: What a Skill actually is

Martin Krause — Tue, 20 Oct 2026 06:48:45 +0000

An agent skill is not just a prompt in a Markdown file.

Once I started working with skills, I realized:

With a prompt from my collection, I have to remember which instructions to find, adapt, and apply.
With a skill, the method is part of the agentic environment, along with enough information for Claude to recognize when it applies.

I needed to extract the reusable method. The prompt from the collection required a fundamentally different structure than before. A giant prompt is not an effective agent skill.

Chapter 3 of Claude Code Beyond the Prompt explores that idea with a basic example: using logs, symptoms, and debugging notes as evidence to turn them into a structured bug ticket.

This will be the example skill you'll use throughout the book. In Chapter 3, you'll build its skeleton, define a small discovery surface, the method itself, and supporting material around it.

You focus on understanding how to separate the reusable method from everything that is needed only when the task calls for it.

If you are moving from prompts toward reusable AI methods, this is one of the core concepts in Claude Code Beyond the Prompt and it is essential to making agent skills practical.

Get Claude Code Beyond the Prompt (ISBN 978-1-80778-229-0) Packt Publishing

Chapter 2: What Agentic Engineering Actually Means

Martin Krause — Fri, 16 Oct 2026 10:43:24 +0000

What does “agentic” actually mean?

When writing Claude Code Beyond the Prompt, I realized early on that “agentic” has become one of those words that gets used for almost everything. And it is not the only buzzword around AI.

That becomes a problem once you try to build something.

I spent more time defining them than I expected, because vague language leads to vague design decisions.

Chapter 2 gets the vocabulary straight: model, tool, skill, agent, context, memory, and access. It gives you the mental model I use throughout the rest of the book.

If you want to understand what actually makes a system agentic before you start building one, start here. The same mental model applies well beyond Claude Code.

Get Claude Code Beyond the Prompt (ISBN 978-1-80778-229-0) Packt Publishing

Why Anthropic’s Scion Forces Us to Think "Agent-Native"

Martin Krause — Thu, 15 Oct 2026 12:13:13 +0000

Anthropic has redesigned source control to support AI agents at scale. Most teams won't need to follow its example. But its engineering decisions raise a question every team adopting agents should ask: which of our established development practices still make sense?

Anthropic’s latest disclosures around Scion signal a massive paradigm shift: the transition from prompt engineering to Agent-Native Development.

As developers and architects, we need to stop treating AI as an external utility function and start treating the agent as the foundational core of our application lifecycle. This means rewriting how we think about state, side effects, and deterministic guardrails.

In this post, we’ll break down:
• The core architectural limitations of prompt-heavy infrastructure.
• What "Agent-Native" actually looks like in a production codebase.
• How tools like Scion change the way we orchestrate autonomous workflows.

In February, I published Toward Agent Native Development, questioning why we continue to organize AI agents around development workflows designed primarily for human contributors.

Branches, pull requests, and CI pipelines evolved to help developers work independently, coordinate changes, and maintain quality. They work well for human contributors, but their assumptions may not fit teams of agents producing changes concurrently and at much greater speed.

Increasing code generation without reconsidering coordination risks moving the bottleneck rather than removing it.

I proposed three changes:

Rethink local branches as the default unit of parallel work: Agents could work with shared change sets and explicit dependencies rather than isolated branches.
Make changes independently observable: A change ledger could expose ongoing work through APIs, allowing agents to react to relevant changes without waiting for integration.
Move toward continuous verification as default: Agents could maintain evidence about the system's changing state, while humans supervise critical decisions.

The principle behind these proposals was simple: development workflows should reflect the needs of their contributors. As agents take on more work, the constraints shaping those workflows begin to change.

On October 13, Anthropic published Redesigning source control at Anthropic, describing how its engineers encountered several of these problems at scale.

Anthropic vs Git's assumptions

In their piece, they report that between May and September 2026, Anthropic's daily merged changes increased from approximately 2,500 to more than 30,000. Its monorepo approached 100 GB of main-branch history, while CI performed about 25 million code checkouts daily.

Git's decentralized design allows developers to work independently, including offline, by maintaining local repository data and history. At Anthropic's scale, replicating and maintaining that data across enormous numbers of clients became expensive. Most of those clients were agents and automated jobs that remained connected, making offline operation far less important.

Rather than continue optimizing Git, Anthropic questioned why its infrastructure should preserve capabilities its main consumers rarely needed. Instead of adapting the workload to an established tool, they reconsidered the tool around the workload.

As a result, they built Scion, a centralized source control system. Changesets are stored in a write-ahead log, become immediately available, and can be accessed through APIs without requiring complete local repositories, branches, and most other refs.

Scion shares several characteristics with the change ledger I proposed in February. Both treat changesets as first-class objects, make changes accessible through APIs, and reduce dependence on branch-based isolation.

Anthropic also questions conventional merge queues and CI pipelines. When hundreds of changes land while tests are running, pre-merge verification becomes difficult to maintain. Its engineers have invested in post-merge and pre-deployment testing instead.

This echoes my proposal for verification that follows the system's changing state, although the objectives differ. Scion addresses how changes are stored and integrated at scale. My proposal focused on how agents coordinate related work and maintain evidence about its correctness.

There is a broader distinction here. Using agents to produce code faster is not the same as designing a development environment around agents. The former increases the capacity of individual contributors. The latter questions how work is coordinated, integrated, and verified when those contributors are no longer primarily human.

Scion doesn't make established practices obsolete. It shows why their usefulness depends on the constraints under which they operate. Those constraints differ between teams, and they change as agentic development scales.

Engineering leadership matters more than ever

A small team using occasional coding agents may find conventional pull requests entirely adequate. Teams requiring offline development may deliberately retain Git's decentralized architecture. But a workflow that serves two agents may become unsuitable when dozens work concurrently on the same codebase.

At the other end of the spectrum are dark software factories, where agents perform most of the implementation work and human engineers increasingly supervise the system rather than individual changes.

These environments place different demands on coordination, verification, and engineering leadership. As agents take on more implementation work, engineering leadership increasingly depends on understanding the constraints under which that work happens.

The decisions extend beyond selecting coding tools. They concern how agents share context, coordinate changes, establish correctness, and operate within human-defined boundaries.

While Claude contributed heavily to building Scion, Anthropic's engineers were responsible for its architecture, system constraints, and tradeoffs. Sometimes their most valuable contribution was rejecting an implementation that satisfied the immediate task but violated a broader requirement. They designed and actively steered toward an agent-native development environment, building on and questioning established practices at the same time.

Agentic development doesn't automatically make established practices obsolete. It makes understanding their purpose more important. Some teams will retain Git, branches, and conventional reviews. Others will redesign parts of their workflows as their constraints change.

We may keep the tools we have or replace them. What matters is that we understand why.

This article follows Toward Agent Native Development (February 2026) and discusses Anthropic's Redesigning source control at Anthropic (October 2026).

ai #softwareengineering #engineeringmanagement #agents

Chapter 1: From Prompts to Skills

Martin Krause — Wed, 14 Oct 2026 15:49:07 +0000

A good prompt can still be a bad way of working.

That was one of the first things I noticed when I started using ChatGPT regularly.

Often, I remembered a prompt, but not always exactly. Rebuilding it from memory is a flaky approach. Which context mattered? Which instruction made the answer useful? Had I changed the method when I reconstructed it?

Chapter 1 of Claude Code Beyond the Prompt starts with that problem.

One-off prompting is useful, but repeated work exposes its limits. Context is lost between sessions. Instructions drift. Results vary.
Once I realized that, the next step was obvious: make the method explicit and move it out of my head.

The chapter traces that move from prompt to pattern, method, and reusable template. Skills, workflows, and agents come later, but they all grow from the same idea.

So the question behind Chapter 1 is simple:_ When does a useful prompt need to become a reusable method?_

If you have a collection of prompts you keep rewriting, this chapter is probably for you.

Get Claude Code Beyond the Prompt from Packt (ISBN 978-1-80778-229-0)!

Claude Code Beyond the Prompt (Announcement)

Martin Krause — Wed, 14 Oct 2026 15:24:23 +0000

I’m entering the final stretch on my second book, Claude Code Beyond the Prompt.

Over the next few weeks, I’ll share the ideas that are the foundation of agentic engineering and that are covered in the 14 Chapters of Claude Code Beyond the Prompt.

When I wrote my first book, The Complete Developer No Starch Press, I wanted to explain how the parts of modern web development fit together. Because knowing one aspect in isolation is never enough.

When Packt approached me about writing a book on Claude Code and Agent Skills, I kept running into the same problem: Knowing how to write a good prompt is genuinely useful. But it is not enough.

A good prompt can solve the problem in front of you. But what happens when the same kind of work comes up again tomorrow? What happens when another developer needs to follow the same method? Or when Claude needs to inspect a repository, run tests, read logs, use tools, or retrieve information from another system? At that point, the prompt is still important, but it is only one part of the work.

That became the subject of Claude Code Beyond the Prompt. The book starts with simple, one-off prompts and gradually builds from there: reusable skills, workflows, agents, tools, connected systems, and finally a small AI workbench.

If you’re trying to move from useful AI experiments to repeatable engineering practice, this book is for you.

Pre-Order Claude Code Beyond the Prompt (ISBN 978-1-80778-229-0) at Claude Code Beyond the Prompt or Amazon

Toward Agent Native Development

Martin Krause — Thu, 05 Feb 2026 18:35:47 +0000

Agents change the physics of development. They can watch, adapt, and coordinate continuously, yet we force them into branch-centric workflows built around the limitations of human developers. How can we move toward an Agent-Native development workflow? What if we stopped treating branches as the default unit of parallel work and started treating change sets, contracts, and live verification as the unit of collaboration?

Rather than adapting AI agents to human-centric workflows, we should redesign software development with agents as primary users.

Update: Follow up at Anthropic's Scion and the Case for Agent-Native Development

The workflow we inherited

Software development has always been shaped by human constraints. Processes are built around limited attention spans, the human brain's capacity, and developers’ uneven skill levels. Then there’s the common tale passed down through generations of engineers: if two engineers edit the same file at the same time, they will, sooner or later, collide.  After the dark ages of locked files and isolated copies, Git branches emerged as a pragmatic compromise. We isolate work, reduce interference, and then merge it all together.

Not because it is the optimal solution, but it is merely the best compromise, a coping mechanism for the cognitive limits of humans.

The new contributor we pretend is a faster human.

Now, we’re adding a new type of contributor type to the team. AI agents that don’t have the same limits as human team members. They can write code, refactor modules, generate tests, and keep documentation in sync, all at a speed that makes human developers feel extremely slow.

Industry narratives frame this as replacement: agents will replace developers. So we plug them into the same assembly line, expecting increased output. Predictably, we take a workflow built for humans and turn the dial up to eleven.

Soon, pull requests pile up on the human developers' to-do list. Reviews stop being about quality and become quick triage decisions. Under pressure, humans approve quickly out of 'pragmatism' or delegate reviews to agents and call it 'at scale'. Just to preserve familiar processes rather than question whether they still make sense.  Not long, and both approaches will be promoted as best practices.

However, this shift leads to downstream consequences. Quality metrics suffer as bugs slip through unchecked and technical debt accumulates, eroding overall code stability and undermining the agent’s contribution.

Human morale declines when developers feel their contributions are reduced to a mechanical process devoid of craftsmanship and creativity.

Where the friction concentrates

Let’s take a step back. Much of the frustration in modern development workflows comes from branch isolation. Branches help, but they also create separate timelines in which assumptions change, context is lost, and the real impact only becomes apparent when we merge everything back together.

When you look at what slows teams down, the pattern is clear. Duplicate work occurs when two people fix the same problem without knowing about each other’s progress. Isolated changes can seem fine and pass tests, but fail when combined. New features that work independently might break after merging because parts don’t fit. The more complex the codebase, the more complex the PR reviews. The longer a branch exists, the more likely it is to cause merge conflicts and the less likely it is to be thoroughly reviewed.

Even our tools are a confession that we accept this as normal. We invent rituals, write more tickets to keep changes small and the scope narrow, push for immediate PR reviews, and have CI pipelines to prove that merges were safe and that the code still works. We introduce naming conventions, stricter PR templates, more checks and branch rules, stronger definitions of done, appoint sheriffs, add rules against opportunistic refactoring, and hold more meetings to align on changes. While many of these practices are useful, they still rest on the assumption that parallel work requires isolation, because human attention is the bottleneck and integration is a separate phase.

This attachment to our rituals reflects our identity within a human-centric development culture, pointing to the broader challenge of embracing the necessary cultural shift toward a mindset in which process and mindset are inseparable.

Agents change the physics of development

Human developers compromised on branches because they need a stable context bubble. They can’t keep the entire system in mind. They can’t constantly adapt to new contexts. They require uninterrupted time to think, concentrate, to reach “the flow”. Branching is a cognitive prosthetic to solve one problem at a time.

Agents do not have those limitations; they can adapt to changes instantly and are not interrupted. Not long, and they can work with nearly unlimited context, watch files, rerun suites, and update approaches immediately as context changes. Agents retrieve details on demand and coordinate at a pace humans can’t match. One agent may own tests, another may focus on implementation, a third may handle documentation, and another may manage performance.

And yet we treat agents like humans who type a bit faster and don’t rest. We use the same process: hand them tickets, send them to work in isolation, and wait until they return with pull requests ready for human review. We funnel everything through the same integration bottleneck. We scale output without scaling the coordination model.

This is where a branch-centric workflow falls short. If your team has many contributors who can act continuously, isolation is not the only way to work in parallel. Isolation keeps changes hidden until the pull request is merged, so other agents can't adapt to or use new code until it’s merged. Humans solve this through communication, daily standups, and async updates.

But how does this work when much of the team is software? What does alignment look like for agentic AI?

Do agents dream of electric sheep?

One obvious approach is to assign a 'coordinator' or 'orchestrator' agent that mimics the role of a human lead developer or project manager. We are seeing workflows built on existing version control systems increasingly emphasize change sets over branches.

Both models (and there are a few more) are still centered on human cadence. Humans supervise, Humans review, humans approve, humans merge - because the human mind is limited in its capabilities and human developers have different skill levels.

The harder question isn’t about new tools. It’s whether we’re ready to let go of the workflows and habits that have shaped software development for decades. This questions the deep-rooted mindset associated with human cadence, underscored by an ingrained belief that human supervision is essential at every step.

How can we achieve unparalleled parallelism?

This mindset shift is simple to say and hard to implement. We should move away from treating branches as the default unit of parallel work. Instead, parallel work should be seen as collaboration, with changes, contracts, and live verification as the unit of collaboration.

Future workflows should focus on evolving change sets within a single review thread, enabling a truly continuous process. We should also consider APIs for change sets to facilitate agent communication within the same codebase.

In this agent-oriented workflow, the codebase remains shared. Each contributor’s changes are tracked as first-class objects with clear ownership, traceability, and interfaces to ensure visibility and responsiveness. Instead of separate branches, imagine a continuous stream of proposed changes that are combined, tested, and accepted in real time.

Now imagine a 'change ledger' that lets each agent track its own change sets. This ledger would expose an API that other agents can use to verify changes and receive real-time updates. Agents could subscribe to changes they need and use them as soon as they are stable. Humans could also see what’s happening and what’s stable in real time. At any given time, the workflow and codebase are transparent, the system is easy to observe, and progress is visible in real time.

What becomes possible when work is visible

A traditional branch-centric workflow is like a series of cascading waterfalls, each branch representing an isolated stream. Work progresses independently through various channels, only to merge at the end, often resulting in sudden turbulence and inefficiencies. In contrast, imagine a live mesh, a flexible, interconnected network where changes flow freely and dynamically adapt to one another in real time. A mesh-like coordination that allows for seamless integration and continuous collaboration.

Agents can act as watchers, not just workers. If one agent owns the API contract and another handles implementation, the implementation agent can adjust as soon as the change is stable. A third agent building a consumer can do the same. Coordination is no longer the bottleneck; now it happens in real time through clear interfaces.
The mental model of code quality and code testing could shift from a binary gate to a live dashboard that monitors the entire application.

In an agent-first model, stakeholders could see which system components are functioning, which tests are failing, who is responsible, and what actions are underway in real time. Not only after they ran all test suites in a separate step once a feature's development is done.

Humans no longer need to review every change to assess product health; they can monitor signals, review contracts, and focus on critical behaviors. When issues arise, agents can be deployed immediately to address problems and facilitate real-time recovery.
As a result, the perception of collaboration changes. Instead of treating isolation as the default, we can design for structured concurrency, real super-charged parallel engineering. One agent produces a change set. Another checks it for consistency. A third expands test coverage. A fourth looks for performance regressions. If all happens at the same time, integration is no longer a conflict between timelines. Then, it is a shared view of the same change and the evidence that it works in a running application.

The Future of Dev Workflows Is Not a Better Branch Strategy

Our workflows always mirror the capabilities of our contributors. As software development teams evolve, our workflows and models must adapt as well.

We stand at a critical juncture in the evolution of software development. We can keep evolving branch management and spend the next decade fighting the same problems at a higher velocity. Or we can step back and ask what it would mean to design development around shared reality, explicit contracts, live verification, and traceable change ownership.
With agents as part of the team, we redefine what it means to collaborate. The team is no longer constrained by the same parameters that shaped our previous processes.

I don't have a ready-made solution, a tool to sell, or a workflow to promote, but it’s time to talk about what a true agentic workflow could be. I’d love to hear your ideas and thoughts: let’s figure this out together.

Next.js: Internationalisation (i18n) for the `app directory`

Martin Krause — Mon, 15 Jan 2024 15:44:57 +0000

A while ago, we released version 3.0.0 of next-export-i18n, the most popular i18n module for Next.js, which is fully compatible with next export.

Version 3.0.0 fully supports the app directory and comes with the highly sought-after feature of storing the selected language in localStorage instead of the search parameter on the URL.

The case for next-export-i18n

Since v10.0.0 Next.js has an out-of-the-box support for internationalised (i18n) routing and it streamlines the touring and locale parsing for nearly all existing l18n library solutions available for Next.js, for example, react-intl, react-i18next, lingua, rosetta, next-intl.

Those are amazing libraries, but unfortunately, next.js' i18n-routing does not support statically exported pages that you create with next export or the config: export property.

With next-export-i18n, you can easily add internationalisation (i18n) to your h actual static exported pages by operating exclusively on the client side.

For the `page router`

In case you're using the page router please use version 2.x of next-export-i18n with npm install --save-dev next-export-i18n@^2

Migrating your code

In case you're migrating from the page router to the app directory, please look at the 2.x to 3.x Migration guide.

next-export-i18n v2.3.5: localStorage and an internal link component

Martin Krause — Tue, 12 Dec 2023 16:29:08 +0000

Announcement: next-export-i18n v2.3.5 3.x.x with support for Next.js' app directory is available at npm!

Version 3.x.x exclusively supports Next.js' app directory architecture. The 2.x.x branch continues to support the page directory, please.

next-export-i18n v2.3.5: localStorage and an internal link component

Today, we released version 2.3.5 of next-export-i18n, the most popular i18n module for Next.js, which is fully compatible with next export.

The new version has two main additions: local storage support and a new internal link component.

The default method to store the selected language is the search parameter, next-export-i18n, which adds the language to the URL as ?lang=. With Version 2.3.5, you can set the configuration option languageDataStore to either query or localStorage. The latter changes the behaviour, instead using the browser's local storage to keep your URLs cleaner.

When using next-export-i18n with the default query store, it is vital to remember that all internal links require the language parameter. Otherwise, the exported application falls back to the default language. We've added a custom component to simplify that.

Using the new <LinkWithLocale> component, you no longer need to add the query manually. Previously, your code would have looked similar to this listing:

import {useLanguageQuery} from 'next-export-i18n';

export default function Page({ }) {
  const [query] = useLanguageQuery();
  return (
    <Link href={{ pathname: "path", query: query }}>
      Link to path
    </Link>
  );
}

You can use the failsafe, streamlined new component:

import {LinkWithLocale} from 'next-export-i18n';

export default function Page({ }) {
  return (
    < LinkWithLocale href="path">
      Link to path
    </Link>
  );
}

Install next-export-i18n with $ npm i next-export-i18n or get next-export-i18n v2.3.5 from npm.js.

About `next-export-i18n`

This npm module provides a simple solution for the Internationalization (i18n) of projects using next export.

Next.js already has support for internationalized (i18n) routing out-of-the-box. You can provide a list of default and domain-specific locales, and Next.js automatically handles the routing. It streamlines the touring and locale parsing for nearly all existing l18n library solutions available for Next.js, such as react-intl, react-i18next, lingui, rosetta, next-intl.

Unfortunately, Next.js i18n-routing does not support next export.
This means that none of the i18n-libraries (utilising the built-in i18n-routing) can support fully static sites generated with next export.

next-export-i18n provides a simple solution for Internationalization (i18n) when you want to generate a genuinely static website with next export.

Read the Introduction to next-export-i18n - next.js: i18n with static sites for more details.

Sample implementation

You can also take a look at the example implementation next-export-i18n-example.vercel.app and its source code at github: https://github.com/martinkr/next-export-i18n-example.

DEV Community: Martin Krause

Chapter 7: Skill, Workflow or Agent?

Chapter 6: From Skills to Workflows

Chapter 5: Skill Boundaries

Chapter 4: Your First Skill

ClaudeCode #AgentSkills #AIEngineering

Chapter 3: What a Skill actually is

Chapter 2: What Agentic Engineering Actually Means

Why Anthropic’s Scion Forces Us to Think "Agent-Native"

Anthropic vs Git's assumptions

Engineering leadership matters more than ever

ai #softwareengineering #engineeringmanagement #agents

Chapter 1: From Prompts to Skills

If you have a collection of prompts you keep rewriting, this chapter is probably for you.

Claude Code Beyond the Prompt (Announcement)

Toward Agent Native Development

The workflow we inherited

The new contributor we pretend is a faster human.

Where the friction concentrates

Agents change the physics of development

Do agents dream of electric sheep?

How can we achieve unparalleled parallelism?

What becomes possible when work is visible

The Future of Dev Workflows Is Not a Better Branch Strategy

Next.js: Internationalisation (i18n) for the `app directory`

The case for next-export-i18n

For the page router

Migrating your code

next-export-i18n v2.3.5: localStorage and an internal link component

About next-export-i18n

Sample implementation

Links

For the `page router`

About `next-export-i18n`