Do I need a complete PRD before using Hal?
No. Hal can help turn product intent into a structured PRD, but the developer should still review scope, constraints, and acceptance criteria before running implementation.
Feature 01
Turn product intent into stories, acceptance criteria, and reviewable state before an AI coding agent touches the repo.
Why it matters
Hal starts with a PRD because vague prompts create vague diffs. Planning gives the agent a bounded target and gives the developer something to review before implementation begins.
PRD-driven planning for AI coding means turning product intent into stories, acceptance criteria, and constraints before an AI coding agent edits files. In Hal, this gives developers a reviewable plan before running implementation through supported engines such as Codex, Claude Code, or Pi.
AI coding agents are strongest when the target is narrow. A broad prompt like “add authentication” can sprawl into UI, database, sessions, middleware, tests, copy, and cleanup in one pass. The result may be useful, but it is harder to inspect.
Hal puts planning before implementation. Product intent becomes stories, acceptance criteria, and runtime state so the agent is working against a defined unit of work instead of a loose request.
Run hal plan with a product change, then review the generated requirements before the loop starts.
hal plan "add account settings with one saved preference"
hal convert
hal validateThe important shift is not the command itself. It is the checkpoint. The developer gets to inspect scope before an agent edits files.
hal run.Look for stories that are too broad, acceptance criteria that are not observable, and missing constraints such as authentication, persistence, migration, or UI behavior. If the plan is hard to review, the resulting code will be harder to trust.
| Hal does | Hal does not do |
|---|---|
| Structures PRD-native coding loops around planning, validation, implementation, reporting, and reviewable state. | Guarantee code quality, passing tests, delivery speed, revenue, rankings, or production readiness. |
| Helps supported engines work against smaller, reviewable units of work. | Replace developer review, QA, security review, or merge judgment. |
Before adopting this workflow, verify the current Hal source repository, install docs, pricing status, and machine-readable pricing. Check release notes and engine support before relying on Hal in production work.
Short answers before you put this into an agent workflow.
No. Hal can help turn product intent into a structured PRD, but the developer should still review scope, constraints, and acceptance criteria before running implementation.
Direct prompts work for tiny changes, but larger features need explicit stories, constraints, and review points. Hal makes that structure part of the workflow.
Check that each story has a clear outcome, acceptance criteria, known constraints, and a small enough scope to review after the agent runs.
Keep exploring the pieces of a reviewable coding loop.
Keep long AI coding work from turning into one drifting chat by giving each story its own bounded context window.
Give each AI coding iteration the repo-specific commands, conventions, and review rules it needs to stay consistent.
Move through planning, conversion, validation, implementation, reporting, and archive behavior as one explicit coding loop.