Focus areas & the four-part spec
The core spec primitive — how a goal is broken into reviewable, testable pieces using a four-part structure.
A focus area is one reviewable slice of an initiative, captured as a four-part spec. Together, the focus areas of an initiative describe the full scope of the work — no more, no less.
The four parts
| Part | What it answers |
|---|---|
| Definition | What this slice of work is, in one or two plain sentences |
| Results | The observable outcomes that must be true when it is done |
| Boundaries | What is explicitly not included in this slice |
| Conditions | What should remain true once the work is completed (E.g page load time remains under 10ms) |
Every part matters. Definition sets the scope. Results make "done" testable. Boundaries prevent scope creep. Conditions surface what should be true when the work is complete.
Why four parts
A spec with only a definition is a task description — it tells you what to build but not how to know when you've built it correctly. Results make the definition verifiable. Boundaries make it safe to implement without second-guessing what's in scope. Conditions help cement existing outcomes that should remain untouched by this new work.
Writing good results
Results should be observable and specific. Avoid vague outcomes.
Weak: The notification system works correctly.
Strong: A workspace member receives an email within 60 seconds of a clarification being raised against one of their focus areas. The email contains a link to the clarification. Members who have disabled notifications do not receive emails.
Writing good boundaries
Boundaries are as important as definitions. Saying what you are not building is the fastest way to prevent a focus area from expanding in ways no one agreed to.
Weak: (no boundaries listed)
Strong: This focus area covers email notifications only. In-app notifications, push notifications, and digest emails are out of scope.
Focus areas and the AI
Penling's AI may have suggested an initial set of focus areas from your brief (if you asked it to). These are a starting point — the AI will occasionally combine things that should be separate, split things that should be together, or miss a slice entirely. The review step is where you correct this.
The AI also raises clarifications on focus areas it couldn't resolve from the brief alone. Answering these improves the spec before the plan is generated.
Editing focus areas
Focus areas can be edited at any time, including during the build phase. If a focus area changes materially during implementation, Penling prompts you to decide whether the change is a spec update (planned scope change) or a deviation (unplanned change that should be noted).
Support Files (extra context)
Penling supports the attachment of files to a focus area and these can be as important as the data we define before. Files are uploaded and included as part of the Penling AI analysis. You might want to include a screenshot or a design file that helps define how the focus area should look or behave.
Penling API will examine these attachments one-by-one and identify any additional context, boundaries, constraints or requirements and include them in the generated plan.
Files are also referenced downstream later in the process. The Penling MCP will highight the availability of these context files during the work and encourage your LLM to open and review them as part of its implementation work.