For a new undertaking, HELPS_HUMANS helps turn intention into a concrete account the human can inspect. Identify the product, intended users, purpose, conditions of use, constraints, required outcomes, interfaces, exclusions, and open choices. Preserve the distinction between the human's commitment and the agent's interpretation. A PRD should be clear enough to support its next use; it need not pretend every technical question has been answered. Label uncertainty and explain what would resolve it. HELPS_HUMANS · Human manual, chapters 1–2

Prepare a source map before substantial drafting. For each significant statement, establish what the source may support: a governing requirement, an accepted decision, observed behavior, a proposed direction, or background explanation. Read the actual source where its meaning matters. A title, search result, extracted snippet, or old summary may identify the material without establishing the claim. Keep unresolved conflicts visible instead of blending incompatible positions into confident prose. DIRECTIVE §§2.4–2.5 · CONTRACT K-PROV-1, K-INVENT-1, K-CONFLICT-1

No software-prd workflow is registered in the Root catalog at this manual's source basis. Conduct PRD formation through the authorized design brief and adopted project method, or prepare a reusable method through create-workflow if asked. The registered dbm-publisher has a different purpose: publication from an accepted DOMAIN root, with its own admission and human decisions. Its source discipline can inform other writing, but its registration supplies no generic PRD method or automatic prerequisite. Establish availability and applicability from the effective catalog and actual package. Workflow index · Design Basis Memorandum publication · Runtime contract

Before decomposition, identify the accepted basis and exact applicable protocol. The repository contains project-decomp for project scope, software-decomp for software, and domain-decomp for knowledge domains. Their current packages express grouped checkpoints, while the current decomposition standard explicitly retains a prospective-status warning and identifies the earlier ratified edition. Use the project's adopted edition and recorded authority. Do not silently substitute the latest package into an in-flight accepted method. Decomposition standard · Project decomposition · Software decomposition · Domain decomposition

The practical decomposition work is to normalize scope, relate it to objectives, propose coherent flat partitions, define bounded production units and anticipated artifacts, and verify coverage. Preserve stable IDs. A Package boundary must express a useful responsibility, not merely a document chapter or temporary agent allocation. A deliverable should be small enough to understand and examine as a contribution while retaining the interfaces and work needed to make it usable. Do not invent scope to make an elegant tree or discard difficult items to make coverage appear complete. Decomposition standard · CONTRACT K-HIER-1, K-ID-1

Prepare the material before each required checkpoint: proposed basis or structure, source mappings, coverage results, ambiguous allocations, exceptions, and a recommendation. The human decides an inspectable package. A deterministic finding normally routes correction within authorized preparation; it does not independently create another human gate. Conversely, a passed ledger validator cannot accept the meaning or boundary of the decomposition. Root entry · Project decomposition

Where the grouped-checkpoint edition is adopted, each accepted group is retained in an immutable checkpoint_snapshots/ package containing DECISION.md, ACCEPTED_MANIFEST.csv, and HANDOFF_STATE.md. The manifest binds artifact paths, package roles, and hashes; the handoff names the upstream basis, derivative and closure position, rerun needs, and blockers. Complete the snapshot before advancing its authorized pointer. Later stages consume it, and _LATEST_ACCEPTED.md leads to the final accepted working package and companion registers. These method-specific transfers do not require a new handoff at every development session. Project decomposition contract · Software decomposition contract · Decomposition standard

After acceptance, project-setup inspects the existing workspace, accepted decomposition, coordination representation, and selected activation scope. It can coordinate scaffolding, production contracts, semantic work, dependency extraction, and other selected setup stages. Existing partially completed setup is recovered from what actually exists. Use accepted choices already in the coordination record rather than asking the human to repeat them. The workflow does not justify running every optional pipeline. Project setup · Setup contract

The preparation skill is structural. It creates accepted folders and source-faithful control files idempotently and reports exact created and skipped paths. Populate only files created in that invocation; existing empty or deficient files require a separately authorized repair. The minimum deliverable fileset includes _CONTEXT.md, _DEPENDENCIES.md, _STATUS.md, _REFERENCES.md, and a placeholder _SEMANTIC.md. Only a newly created status file is initialized to OPEN; optional MEMORY.md requires a selected, authorized path and uses the terse Runs template. Missing accepted metadata is a missing input. Preparation records supplied declarations but does not invent Dependencies.csv. New PROJECT/SOFTWARE production belongs to scope-of-work, MODE=INIT; legacy setup examples do not authorize new four-document production. Preparation skill · Setup contract · Scope-of-work workflow

Coordination mode is consequential. NOT_TRACKED means dependency coordination occurs outside the files: report no computed ready/blocked judgment from an incomplete graph. DECLARED means the recorded critical edges are a partial view. FULL_GRAPH means declarations are intended to cover the selected graph semantics, with closure and cycle treatment needed before computing its blockers. A dependency graph is also not automatically a schedule: scheduling needs its own accepted basis, duration posture, calendar, and hard/soft relationship rules. Setup contract