Implement planner tickets inside a workspace (a git worktree). Progress is reported by this session itself: ticket movement is derived from live session state, not from a stored workspace status.

Workflow

Identify the ticket. You are given the ticket's shorthand (e.g. PS-12). Pass it to --id — commands resolve it. If the ticket is missing or ambiguous, ask the user to confirm it.
- For "implement the next ticket", pick the first ready ticket: pst tickets list --status <ready-status> (see pst statuses list for the project's status names).
- Read the full ticket body first: pst tickets view --id <shorthand>.
Implement the change, scoped to the ticket, following the host repo's own contributor conventions (its build, test, and style rules).
Produce a validation report (see below) that proves the work is correct.
Report through the session, not by editing the ticket status:
- Done and ready for review: finish the session with the validation report saved — a completed session hands the ticket onward.
- Blocked: ask the user for the input you need; a session awaiting input flags the ticket as blocked.
- Do not run pst tickets update --status during or after implementation — ticket transitions are derived from session state.
Attach the review link when you open one. If you create a pull request or merge request for the ticket, run pst tickets link-review --id <shorthand> --url <review-url>.

Validation Report

To be review-ready a ticket must produce verifiable outputs generated while doing the work. Capture them in a workspace report so reviewers can inspect the proof alongside the implementation:

Run pst reports write --kind validation --name implementation.
Add command outputs, screenshots, logs, or traces under .pstdio/reports/implementation/files/.
Summarize the evidence in .pstdio/reports/implementation/report.md.
Run pst reports save --name implementation.

Report evidence includes:

Test, build, and run outputs
Walkthroughs of the change
Screenshots or screen recordings (UI / E2E)
curl responses
Any file needed to prove the ticket is implemented correctly

Artifacts must be concrete, inspectable, and reproducible.

Más de este repositorio

mismo repositorio

pstdio

pufflyai/prompt-studio

Guidance for Prompt Studio and the pstdio CLI for managing project workflows. Covers setup, configuration (.pstdio/config.json), agent configuration, CLI reference, and troubleshooting. Use for "setting up Prompt Studio", "configuring agents", "how does pst work", "what commands are available", or general Prompt Studio questions.

2026-07-157

create-pstdio-extension

pufflyai/prompt-studio

Create or edit a Prompt Studio extension. Use when asked to add or change extension behavior, user actions, automation, project or workspace workflows, templates, skills, custom pages, native resource editors, resource file trees, settings UI, themes, artifact storage, workspace providers, agent providers, or extension validation.

2026-07-067

create-proposal

pufflyai/prompt-studio

Create a proposal ticket. Use this when asked to write a proposal, introduce changes that add features, large refactors, introduce breaking API or schema changes, modify architecture or design patterns, update security patterns, or to save a plan as proposal. Do not create proposals for bug fixes that restore intended behavior, typos or formatting/comment-only changes, non-breaking dependency updates, configuration-only changes, or tests that validate existing behavior.

2026-07-027

use-reports

pufflyai/prompt-studio

Hand off task results between agents. Use when asked to produce a validation, review, test, or implementation report.

2026-07-027

refine-ticket

pufflyai/prompt-studio

Provide additional information to a ticket by researching the codebase and documentation, and/or format a ticket given a template. Use when asked to refine, improve, expand, or format an existing ticket.

2026-06-287

lab-resource

pufflyai/prompt-studio

Shape controlled Glass Lab artifacts.

2026-06-157

name	implement-ticket
description	Implement a ticket end-to-end. Use when asked to implement or complete a ticket.
metadata	{"version":"0.0.6"}

Implement planner tickets inside a workspace (a git worktree). Progress is reported by this session itself: ticket movement is derived from live session state, not from a stored workspace status.

Workflow

Identify the ticket. You are given the ticket's shorthand (e.g. PS-12). Pass it to --id — commands resolve it. If the ticket is missing or ambiguous, ask the user to confirm it.
- For "implement the next ticket", pick the first ready ticket: pst tickets list --status <ready-status> (see pst statuses list for the project's status names).
- Read the full ticket body first: pst tickets view --id <shorthand>.
Implement the change, scoped to the ticket, following the host repo's own contributor conventions (its build, test, and style rules).
Produce a validation report (see below) that proves the work is correct.
Report through the session, not by editing the ticket status:
- Done and ready for review: finish the session with the validation report saved — a completed session hands the ticket onward.
- Blocked: ask the user for the input you need; a session awaiting input flags the ticket as blocked.
- Do not run pst tickets update --status during or after implementation — ticket transitions are derived from session state.
Attach the review link when you open one. If you create a pull request or merge request for the ticket, run pst tickets link-review --id <shorthand> --url <review-url>.

Validation Report

To be review-ready a ticket must produce verifiable outputs generated while doing the work. Capture them in a workspace report so reviewers can inspect the proof alongside the implementation:

Run pst reports write --kind validation --name implementation.
Add command outputs, screenshots, logs, or traces under .pstdio/reports/implementation/files/.
Summarize the evidence in .pstdio/reports/implementation/report.md.
Run pst reports save --name implementation.

Report evidence includes:

Test, build, and run outputs
Walkthroughs of the change
Screenshots or screen recordings (UI / E2E)
curl responses
Any file needed to prove the ticket is implemented correctly

Artifacts must be concrete, inspectable, and reproducible.