stp-editor

name	stp-editor
description	Normalize and tighten an STP task card without changing issue intent or taking over lifecycle orchestration. Use when an STP needs bounded structural cleanup, clearer acceptance criteria, or repo-consistent prompt sections before readiness review or execution.

STP Editor

This skill owns bounded editing of stp.md task cards.

Its job is to:

• normalize STP structure and field shape
• tighten clarity around goal, required outcome, acceptance criteria, and scope
• remove placeholders, ambiguity, and repo-incompatible wording
• preserve issue intent and lifecycle boundaries
• stop before branch/worktree actions, implementation, or output-card authoring

This is a helper skill, not a lifecycle orchestrator.

Prompt-Template Tooling Boundary

When creating a new STP or fully re-rendering one, prefer the active prompt-template values renderer and structure/schema validators before using Markdown as lifecycle state:

adl-csdlc tooling prompt-template validate-values --kind stp --values <path>
adl-csdlc tooling prompt-template edit-values --kind stp --values <path> --set <field=value> --out <path>
adl-csdlc tooling prompt-template render --kind stp --values <path> --out <path>
adl-csdlc tooling prompt-template validate-structure --kind stp --input <path>

If adl-csdlc is not already on PATH, run the same commands from a fresh checkout through cargo run --manifest-path adl/Cargo.toml --bin adl-csdlc -- ....

Use this skill for STP truth repairs: task intent, required outcome, acceptance criteria, bounded scope, validation plan, and placeholder cleanup. Do not use it to bypass locked template prose or schema validation. When a supported declared values field is the only change needed, prefer edit-values before rendering instead of patching rendered Markdown.

Required Inputs

At minimum, gather:

• repository root
• stp_path
• one explicit editing mode

Useful additional inputs:

• source prompt path
• issue number
• target lifecycle phase
• review findings or concrete defects to fix

Quick Start

1. Read the STP and the linked source prompt if available.
2. Preserve issue scope, intent, and milestone context.
3. Normalize only the STP surface.
4. Make the task wording precise, bounded, and repo-consistent.
5. Remove placeholders or contradictory instructions.
6. Emit a structured edit result and stop.

Allowed Edits

This skill may:

• improve goal wording without changing intent
• set card_status to draft, ready, blocked, or superseded according to observed STP truth; pre-run execution readiness requires ready or approved
• tighten required outcome and acceptance criteria
• make the selected task explicit enough for design-time readiness, including deliverables, touched surfaces, proof shape, invariants, and non-goals
• normalize inputs, targets, validation plan, and constraints sections
• remove template placeholders and contradictory notes
• align STP wording with the tracked issue prompt and current lifecycle phase

This skill must not:

• create or bind branches/worktrees
• invent implementation results
• set card_status: "completed" without explicit lifecycle closeout evidence
• rewrite SIP/SOR content except by explicit handoff to those skills
• widen issue scope
• silently change source-prompt meaning

Handoff

Typical callers are:

• pr-init after mechanical bootstrap, for qualitative STP cleanup
• pr-ready when readiness is blocked by STP drift
• pr-run when execution is blocked by a stale or contradictory STP

Output

Return a concise structured result including:

• target STP path
• issues corrected
• sections normalized
• unresolved risks
• recommended next handoff