Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/gpt-pf-chat-gpt-project-forge/llms.txt

Use this file to discover all available pages before exploring further.

TARGET_PROJECT_BRIEF_ARTIFACT is the project-opening brief for the target project. It is the first artifact the target project reads after ENTRY_POINT.md, and it answers the most fundamental question in the package: what is this project and what must it do? Every other artifact in the package is subordinate to the brief on questions of project frame and project-specific operational direction. The brief is not a notebook, not a planning log, and not a mini-protocol. It is the minimum project-specific opening shape — no more, no less.
The brief governs what the project is supposed to do. The Initial SSOT governs what the project is allowed to treat as official basis. These are different questions answered by different surfaces. Keep them separate.

​
Artifact Properties

PropertyValue
PurposeTransmit the minimum project-specific operational brief of the target project
AuthorityLocal to the target project; may not redefine the frame of Project Forge
SurfaceProject-opening artifact
Write TriggerWhen documentary readiness requires a target-project brief
Read TriggerAt target-project opening (immediately after ENTRY_POINT.md)
Freshness RuleUpdate only when the target-project brief changes
Promotion ConditionsNEVER promotable to system canonical

​
Schema Fields

The brief uses five required schema fields. Every field must be filled before the artifact is emitted. A field marked TBD or left empty means the brief is not ready.
​
objective
string
required
A singular, clear statement of what the target project is supposed to accomplish. Must be specific enough that the target project can determine whether a proposed output is in or out of scope. Do not write a paragraph here — write a single closing statement.
​
scope_in
list
required
An explicit list of what is in scope for this project. Each item should be concrete enough that the target project can use it as a boundary test. Vague scope produces vague outputs.
​
scope_out
list
required
An explicit list of what is out of scope. This is not optional. Unspecified exclusions become silent inclusions. Closing scope out is as important as closing scope in.
​
required_outputs
list
required
The specific outputs the target project must produce. These define what done looks like. If outputs are not closed before the brief is emitted, the target project cannot determine when it has finished.
​
project_specific_constraints
list
required
Any constraints that apply specifically to this project and are not already governed by the canonical core. Examples: format requirements, audience restrictions, delivery conditions, regulatory constraints. Do not restate canonical rules here.

​
What the Brief Tells the Target Project

The brief is the target project’s first answer to four questions:
  • What am I? — defined by objective
  • What must I do? — defined by required_outputs
  • What are my boundaries? — defined by scope_in and scope_out
  • What special constraints apply? — defined by project_specific_constraints
Without a complete brief, the target project has no closed starting point. It will reconstruct. It will infer. It will fill gaps from tone and momentum instead of from explicit structure. The brief prevents that.

​
What the Brief Must NOT Do

The brief has hard limits on its authority:
  • Must not redefine official basis — which sources are approved and which materials count as official is the SSOT’s job, not the brief’s
  • Must not silently promote candidate material — material that travels via SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT stays candidate until explicitly validated; the brief cannot promote it by referencing it as if it were approved
  • Must not override package authority order — the brief is the highest surface on project frame, but ENTRY_POINT.md is the highest surface on package interpretation; the brief cannot redefine how the package is read
  • Must not become a notebook — project decisions, rationale, planning notes, and running context do not belong here

​
Template

Use this template to instantiate TARGET_PROJECT_BRIEF_ARTIFACT. Fill every field before emitting. Do not emit a brief with open TBD fields unless the current readiness state is explicitly NOT_READY and that state is being communicated to the operator. 
# TARGET_PROJECT_BRIEF_ARTIFACT

## objective
TBD

## scope_in
- TBD

## scope_out
- TBD

## required_outputs
- TBD

## project_specific_constraints
- TBD
The brief is local to a specific target project opening. It contains project-specific objective, scope, and outputs that are, by definition, tied to one case. Promotion requires material to be stabilized, normative, and non-case-specific. A project brief fails all three conditions: it is stable only for the project it belongs to, it governs only that project’s outputs, and it is entirely case-specific. Attempting to promote a brief to system canonical would contaminate the core with live project state — exactly the failure mode the canonical/artifact separation is designed to prevent.

Build docs developers (and LLMs) love

Get started for freeTalk to us