prysai/prysai-llm-playbook/prysai-product-context

Product Context

Create a compact, canonical context that downstream work can reuse. Separate observed facts, attributed customer language, decisions, and hypotheses.

Trigger boundary and handoff

Take ownership when the missing artifact is shared product, audience, positioning, message, brand, conversion, or measurement context.

Yield when:

• an explicit $skill is named; honor it and provide context only if requested;
• external fact-finding is needed: Research Router;
• an existing context's claims need auditing: Evidence Review;
• the request is to execute content or launch changes: Task Protocol or

Workflow Orchestrator;

• the request is only to learn positioning method: Codex Coach.

Do not become the marketing executor, analytics system, or customer-research substitute. Do not call Product Context again for a downstream deliverable unless a material context gap is discovered.

Required inputs and missing-input behavior

Require product_or_project, current_goal, known_audience, available_sources, decision_to_support, and canonical_location. Also require a decision_owner, context_version, and version_baseline; the Skill's own maintenance version is not a product-context version. Inspect the existing context, its current version or hash, and its changelog before proposing a change. Mark absent customer evidence, metrics, testimonials, competitive facts, and preferences as hypothesis or unknown; ask focused questions for high-impact gaps.

Default to a non-authoritative draft or proposed diff. A request to explain, review, or polish an existing context does not authorize rebuilding or writing the canonical file. Before writing a canonical context, require exact target path, current version/hash, changed-field scope, privacy classification and PII decision, owner, reversible backup or rollback target, and explicit confirmation immediately before the write. The confirmation must name the target and action; a login, token, prior approval, or "all access" statement is not sufficient. If any field is missing, return blocked with blocked_on instead of writing or creating a changelog entry. Never overwrite an existing context when the target, baseline, or write scope cannot be matched.

Capture and version

Capture one-liner, category, type, goal, target users and decision-makers, jobs-to-be-done, anti-personas, problems, alternatives, objections, differentiation, proof points, customer language, words to use/avoid, glossary, tone, constraints, conversion action, and measurement decisions. For each material change increment the version and add a dated changelog entry. Tell downstream work which location and version are authoritative.

The changelog entry must identify the prior version, new version, changed claims, evidence used, decision owner, affected downstream artifacts, target path, and rollback target. A draft context is not authoritative until the owner accepts that entry. Keep a proposal, a confirmed write, and a published change as separate states; completion of one does not imply the next.

Downstream design handoff

Product Context constrains downstream design; it does not choose a visual style by taste, generate a finished interface, or verify visual quality. When the downstream artifact is a web page, application, presentation, report, or other visual deliverable, provide a design_handoff that states:

• the real user task and the decision the artifact must support;
• the required information hierarchy and minimum useful information density;
• familiar industry patterns that users can recognise without explanation;
• required trust signals, sources, disclosures, ownership, and contact details;
• which photography, inventory, data, customer language, testimonials, and

approved brand assets actually exist;

• prohibited visual or copy patterns that would fabricate evidence or imply

unsupported authority; and

• target viewports, accessibility conditions, review owner, and acceptance

checks for the rendered artifact.

If real photography, inventory, customer language, testimonials, or an approved brand system is absent, do not fill the gap with lifestyle copy, synthetic listings, decorative property illustrations, oversized editorial serif type, soft gradient blobs, floating cards, or excessive rounding. Prefer a buyer guide, service explanation, checklist, comparison, or decision tool whose usefulness does not depend on invented evidence. A visually polished artifact remains unverified until it has been rendered and reviewed under the stated conditions.

Risk, side effects, and confirmation

Drafting from supplied sources is R0 or R1. Writing the canonical file is R1 only when the exact local target, baseline, backup, privacy decision, rollback target, owner, and immediate confirmation are recorded. Publishing, changing a live site, collecting personal data, sending messages, or altering analytics is R2 or higher and requires a separate Task Protocol or Workflow Orchestrator handoff with exact target, scope, owner, and confirmation. Keep personally identifying information out unless necessary and authorized; do not copy raw customer records into a context merely because they were supplied.

Hard stops

Stop with blocked if the product identity, decision owner, canonical location, evidence provenance, privacy boundary, version baseline, current target state, backup, rollback target, or write confirmation is unclear. Also stop if a proposed change would overwrite an unreviewed decision, expose PII, or exceed the requested field scope. Never turn an assumption into proof, a draft into a customer claim, or a context update into permission to publish.

Fixed output

Return exactly:

1. context_scope_and_owner
2. authoritative_version_and_location
3. observed_facts
4. hypotheses_and_unknowns
5. audience_and_jobs
6. positioning_and_message_constraints
7. proof_points_and_evidence_gaps
8. changelog_entry
9. downstream_handoff
10. design_handoff
11. risk_and_permissions — include risk, action_state (draft_only,

write_blocked, write_confirmed, or handoff_required), exact target, privacy decision, owner, confirmation, backup/rollback, and stop conditions

1. content_status

Evidence and status mapping

Label each statement observed, attributed, hypothesis, decision, or unknown. Verify a proposed context by checking every material claim against its cited source, comparing the proposed fields with the current baseline, checking the privacy classification and changed-field scope, and confirming that the acceptance owner can inspect the diff. This verifies the proposal, not customer impact or downstream execution. Use draft before source and ownership review, candidate when a versioned context exists but fresh stakeholder or source checks are absent, verified when the declared evidence and owner review pass, and production-ready only when privacy, publication, maintenance, and rollback gates pass. Context verification does not verify downstream claims.

Maintenance record

• source: docs/charter.md; CONTEXT.md; docs/quality/skill-quality-standard.md
• license: original rewrite; supplied customer or external material remains governed by its source permission
• owner: product-context maintainer
• version: 0.3.0
• review_date: 2026-09-09
• content_status: candidate