prysai/prysai-llm-playbook/prysai-task-protocol

Task Protocol

Create the smallest contract that makes one task executable and auditable. This Skill defines the boundary; it does not execute the task.

Trigger boundary and handoff

Take ownership for vague verbs such as "improve", "build", "research", or "connect", and whenever scope, authority, acceptance, or side effects are unclear.

Yield when:

• an explicit $skill is named; preserve that route and add only mandatory

safety questions;

• a complete protocol is already supplied and the user wants execution: hand

off to Workflow Orchestrator or the relevant domain route;

• the user is asking whether an existing result is true: Evidence Review;
• the unresolved work is source discovery: Research Router;
• the unresolved work is product positioning: Product Context;
• the unresolved work is Skill choice or installation: Skill Selector.

Never call itself again. It may list a handoff, but it does not recursively rebuild a protocol after another Skill returns unless the user changes scope.

Required inputs and missing-input behavior

Collect goal, background, inputs, constraints, allowed_actions, acceptance_evidence, failure_handling, and delivery_format. Also classify risk as R0, R1, R2, or R3, and record owner, checkpoint, rollback, and confirmation when the task can change shared or external state. Mark unknowns as missing, not as assumptions. Inspect a local, low-risk input before asking about it; ask only questions that change scope, risk, implementation choice, or acceptance. For an external, secret-bearing, production, irreversible, or ownership-sensitive gap, return blocked on <field> and do not execute.

Apply this minimum risk gate before declaring the protocol ready:

Represent read, edit, run, network, commit, push, publish, deploy, restart, and secret access as separate action records with allowed, not_allowed, or confirmation_required state. A broad permission, token, login, or prior approval does not authorize an unlisted action. If the user asks for multiple actions, split them into stages with separate risk, target, confirmation, checkpoint, rollback, and acceptance evidence.

Build order

1. State the outcome and beneficiary.
2. Bound files, systems, accounts, versions, and time period.
3. Separate allowed reads, writes, commands, network calls, commits, pushes,

and publications; do not put them under one undifferentiated permission.

1. Assign the risk level and define the exact target, owner, confirmation point,

checkpoint, rollback and observable acceptance evidence.

1. Mark assumptions, unknowns, and the next handoff.

For every acceptance claim, name the observable artifact or command output that would prove it and the boundary it cannot prove. A protocol is not execution evidence. Do not mark an action complete because it was requested, planned, started, or returned plausible text.

Risk, side effects, and confirmation

Classify R0 explanation/read-only, R1 reversible local change, R2 external service or shared-repository change, and R3 production, irreversible, secret-bearing, or broad-permission action. A protocol may describe a side effect, but execution requires explicit authorization scoped to the exact target and action. Confirmation for "all permissions" is not a substitute for a narrow target. Never include secrets in the protocol. For R2/R3, confirmation must occur after the target and action are fixed, not before. Do not treat a successful build, login, or dry run as confirmation of a later write, push, publication, deployment, or restart.

Hard stops

Return blocked when the beneficiary or outcome is missing, ownership is unclear, acceptance cannot be observed, a secret would be exposed, a target is ambiguous, an irreversible action lacks confirmation, or a project rule and user request conflict. Preserve the failed condition and stop reason. A retry is permitted only when one stated condition changes and the new check is named; otherwise return blocked or unverified rather than retrying indefinitely. Do not convert a missing field into a guessed default when it changes risk or scope.

Fixed output

Return exactly:

1. protocol_status (ready_to_execute or blocked_on)
2. goal
3. background
4. inputs_and_unknowns
5. constraints
6. allowed_actions_and_permissions — separate action records with action

state, target, risk, data exposure, and confirmation requirement

1. acceptance_evidence
2. failure_handling
3. delivery_format
4. handoff
5. risk
6. owner_and_confirmation — exact decision owner, confirmation point, and

unconfirmed actions

1. checkpoint_and_rollback — observable artifact, restore target, and

recovery decision

1. content_status

Evidence and status mapping

The protocol itself is draft until all fields are present, candidate when the contract passes a local completeness check but has not been exercised, verified only after the stated acceptance evidence is observed, and production-ready only after production, rollback, maintenance, and ownership gates pass. Verify the protocol by checking required fields against the risk gate, comparing each action with the exact target and permission state, and tracing every acceptance claim to an observable check. For R2 and R3, verify the confirmation point, checkpoint, rollback, and data-exposure record separately. Do not mark the task complete from protocol readiness.

Maintenance record

• source: CONTEXT.md; docs/charter.md; docs/quality/skill-quality-standard.md
• license: original rewrite; external material remains reference-only under docs/sources/asset-register.md
• owner: task-systems maintainer
• version: 0.2.0
• review_date: 2026-09-09
• content_status: candidate