Summary
Build one real app start to finish on Astro + Datastar + Directus, a hypermedia-first stack with a CMS backend, SSR endpoints that stream, and no SPA framework in sight.
Build one real app start to finish on Astro + Datastar + Directus, a hypermedia-first stack with a CMS backend, SSR endpoints that stream, and no SPA framework in sight.
Something strange happened to my job this year. The typing got cheap. An agent can turn a paragraph of intent into a working pull request while I refill my coffee, and yet the projects did not get faster. Not really. More code shipped, more PRs merged, and somehow the same features took roughly the same number of weeks to actually land. That gap is what this guide is about. When machines write the code, the scarce thing is no longer the writing. It's the specifying, the slicing-up, and the reviewing. Project management stopped being about handing out work and started being about feeding agents instructions clear enough that their output is worth keeping, then catching the parts that aren't. I've been running this way for a while now: specs before code, work cut into agent-sized pieces, a small fleet on separate worktrees, and a review loop that assumes the machine got something subtly wrong. This is the playbook I wish someone had handed me. It covers spec-driven development, decomposition, acceptance criteria an agent can test against, parallelism without chaos, the review loop, governance for code you didn't write, and the handful of metrics that tell you whether any of it is actually working. It's written for engineers and tech leads who already use agents to write code and want to run real projects with them, not demos. _This is a living document and will be updated as the tools and the workflows keep evolving._
Read guideYour agent can write code. But does it know how your team cuts a release? Can it run your incident playbook the same way twice, or does it improvise something a little different every time? That gap, between raw capability and a repeatable way of doing one specific job, is exactly what skills fill. A skill is procedural memory you write down once: a packaged, reusable how-to that the agent loads when it's relevant and runs the same way every time. This is the third leg of a trilogy with [Agent Memory](/guides/agent-memory-field-guide) and [The Agent's Self](/guides/agent-self-personality-identity), the three pillars from [Building Your Agentic OS](/guides/building-your-agentic-os). Identity is who the agent is, memory is what it knows, skills are how it does things. We start with what a skill really is, and what it isn't, then build one from a plain folder and a single file. We dig into the two halves of the craft that actually matter: writing a description that makes the agent reach for the skill at the right moment, and writing a body that makes it succeed once it does. We cover progressive disclosure (why the whole skill isn't sitting in context all the time), how to tell a skill apart from a memory or a tool, and how to version and share skills across a fleet without letting them rot. By the end you'll be able to take a capable, general-purpose agent and turn it into a specialist that does your specific jobs your specific way, on demand, every time. _This is a living document and will be updated as the tools and patterns evolve._
Read guideGive two people the same agent and the same task and you'll often get two different results. The usual assumption is that the better result came from a better prompt. Just as often, it came from a better-defined _agent_, one with a stable identity underneath the prompt: a voice it keeps, values it decides by, a role it stays inside. The other person is re-establishing who the agent is supposed to be at the start of every session, and it shows. Identity is the pillar people skip. They pour effort into memory and tools and leave the agent's _self_ to whatever the base model defaults to, which is how you end up with the same bland, hedge-everything, sounds-like-every-other-AI assistant no matter what you bolt onto it. This is a field guide to building the self on purpose: the constitution that anchors it, the voice that makes it recognizable, the values that steer it when the task is ambiguous, and the boundaries that give it a shape at all. We keep it in plain files (legible, versioned, portable), scale it across a fleet where every agent is a distinct citizen with shared values, and, the hard part, evolve a self over time without it drifting into someone else. It's the third leg of a trilogy with [Agent Memory](/guides/agent-memory-field-guide) and the skills pillar, all introduced in [Building Your Agentic OS](/guides/building-your-agentic-os): identity is the _who_, memory is the _what-happened_, skills are the _how_. Get identity right and the agent stops feeling like a tool you operate and starts feeling like someone you work with. _This is a living document and will be updated as the tools and patterns evolve._
Read guide