Introduction to working from a specification

Working from a specification is the practice in which the first artifact in solving a task is a short document: the goal, the context, what we do, what we do not do, the criteria of acceptance, the open questions. The agent works from it, while messages in the chat play a supporting part.

Why the practice is needed

The agent answers not your question but everything that happened to be in its context window by the moment it generated the answer. A forty-turn correspondence is a poor carrier of a task: the intent is smeared across it, the constraints are lost somewhere in the middle of the window, and the criterion of acceptance is never named at all. Hence the familiar result: the code builds, but it does something other than what was needed, and there is nothing to argue about — the agreement exists in no single place.

A specification moves the intent out of the correspondence and into a document. It is short — a page, not a requirements dossier — and its value lies in three things a dialogue never has. First, an explicit negative list. “What we do not do” constrains an agent more firmly than ten clarifications after the fact. Second, a criterion of acceptance named before the work. Until it exists, “done” means “the agent stopped typing”. Third, a shared subject of the task when things diverge. When the result does not match the expectation, you correct the specification and run again instead of explaining anew every time.

What this gives the Academy

The practice sits at the centre of the first two courses, and they divide the work between them. The first sets up the loop: intent → specification → agent → result → human acceptance, with a return to the specification when things diverge. The second answers the question the first only raises: what fills the agent’s context window at the moment the answer is generated and who is answerable for that filling — because the specification enters the window not alone but together with four other layers of context, and competes with them for room in a limited capacity.

Neither step is tied to a platform or to a domain: the practices carry over to any project where you work with agents.

Course 1 · AI-driven PDLC

3 chapters · 19 lessons · available in full

Why you need this course. You already write code with an agent, but the result depends on luck: sometimes it works the first time, sometimes much of it — or all of it — has to be rewritten. The course turns that work into a result you can repeat.

What you will learn. Framing a task and assembling its context, the specification as the first artifact, basic checking of the result, the analysis of risks and guard rails. Then the concept of the lifecycle: from Waterfall to working from intent, the roles of an AI team, agentic patterns. The third chapter is a workshop on two instruments, Claude Code and Cursor: subagents, skills, MCP, the links and the boundaries of the agent’s loop.

What you gain. You stop treating the agent as a clever autocomplete and start seeing exactly where the work needs your gate.

How it is built. Three chapters, 19 lessons, every lesson ends with three tests and explanations. Prerequisites — development experience, Git and the command line.

Open in the cabinet

Course diagram: from intent to deliveryIntent sets the specification the agent works from; task context and guard rails feed the same agent. The result — code and tests — goes to human acceptance: a divergence returns to the specification, an acceptance goes to delivery.Intentwhat and why?SpecificationAgentexecutionTask contextGuard railswhat we do not do?Resultcode and testsHuman acceptanceacceptedDeliverydivergence

Course 2 · Context management for AI agents in team development

3 chapters · 24 lessons · prerequisite — the first course

Why you need this course. The agent answers not your question but everything the context window holds. The course is about what fills that window and who is answerable for filling it.

What you will learn. The five layers of context — permanent, project, task, session and tool: each with its own lifetime, its own owner and its own way of reaching the window. Why the permanent layer is not remembered for good but weakens as the session goes on, and why the window is a capacity the layers compete for. Then the development team’s context system: rules, README files and the decision log, the artifact standard and its owner, the normative layer, implicit sources, quality metrics and the symptoms of degradation. The third chapter is work on a task: planning mode, working from a specification and folding the context, review of the context package, test design, research.

What you gain. You stop fixing the agent’s answers and start fixing its input.

How it is built. Three chapters, 24 lessons, every lesson ends with three tests and explanations. Prerequisite — the first course.

Open in the cabinet

Course diagram: the context layers and the context windowFive layers — permanent, project, task, session and tool — converge on the context window and compete for its capacity. The window yields the agent's answer, then metrics and symptoms of context degradation, then folding and refreshing the context, which returns the window to working order.Permanent layerrules, README, decisionsProject layersubsystems and diagramsTask layerspecification and criteriaSession layerthe exchange so farTool layertools, MCP, subagentsThe context windowa capacity the layers compete forThe agent's answerMetrics and symptomsof context degradationFolding and refreshingthe context

The next step is the introduction to Agentic Ops: the same discipline inside a regulated ecosystem and inside a closed perimeter.

HealthOS Academy materials are instructional. Course progress is stored only in your browser and never leaves your device.