v1.9.0 ·
Skills the app owns: operational work as a lifecycle deliverable
An app built with AIDLC needs repeatable operations that are not features. A blog app needs "create a new post about topic X" with the right frontmatter, slug and date conventions, image paths and index updates. Those belong in the app's repo as agent skills. AIDLC had no opinion about them.
So nobody could tell whether writing such a skill, or running one, should go through the lifecycle. The result was one of two things. Either a lifecycle instance for every blog post, which is ceremony. Or nobody writing the skill at all, because its status was unclear.
What changed
Two things shipped. The first is a rule, written into the aidlc-overview skill under "Lifecycle or Skill?": lifecycle for changes to the system, skills for repeatable operations of the system. It comes with a worked example, adding a series feature versus publishing a post, and an escape hatch for when an operation turns up a missing capability. It also says where verification belongs: inside the skill, not in phases wrapped around each run. The aidlc-getting-started skill points at it, so people meet the rule during onboarding.
The second is a paved road. The aidlc-add-skill skill handles the judgment: asking what you want, and turning away requests that are really features. A new command, aidlc add skill, does the mechanics: validation, redaction, an atomic write, a smoke check and registration in the knowledge graph. One canonical body goes in the operational skills directory, OPERATIONAL_DIR in packages/cli/src/operational/packagers.ts, created on the first run. Native pointers go out for all five platforms. The verification steps are written into the skill as literal text from the content package, so every generated skill carries its own check.
Why both
I weighed four shapes. Guidance alone is the smallest change, but every user still invents the skill structure by hand and nothing makes the verification appear. Tooling alone teaches the build half and not the use half, so someone could still conclude that running a skill needs an instance. Letting a feature's implementation work include its operational skills fits the concepts well, but it touches the template model and has the largest blast radius, so I left it as a practice to document later.
Each half covers the other's weakness, and both reuse things already in the codebase: the adapter seam, the guidance placeholders and the knowledge graph.
I also rejected a dedicated template for authoring a skill. Writing one app skill is an implementation plus a smoke test, which the smallest existing template already handles.
What it costs
One more guidance layer and one more skill to maintain, both in slots that already exist.