draft-goal-condition: Step 2 enumerates a four-part condition shape the skill claims never to hardcode (reviewer disagreement)

[kyle-sexton]

Context

Deferred from PR #592 (branch feat/481-goal-prompt-crafting-skill), Codex P2 on plugins/planning/skills/draft-goal-condition/SKILL.md line 45 ("Remove the hardcoded condition template").

The tension

The skill states as a core principle that it never bakes the /goal condition shape into its own text:

• Purpose: "reads the current official docs at authoring time and never bakes those values into its own text" (shape + limit).
• Gotcha: "Never hardcode the limit or the shape into a draft, this file, or the script."
• Step 1 requires extracting the live effective-condition shape from the docs.

Yet Step 2 enumerates a concrete four-part shape under a doc-sourced label:

"Structure the draft to the doc-sourced shape. As of the contract this skill targets, that is:

• One measurable end state
• A stated check
• Constraints that must not change
• An optional turn/time bound"

The same parenthetical shape is also embedded in the frontmatter description (measurable end state + stated check + constraints + optional turn/time bound).

Why this is a genuine (but contestable) concern

• Codex (PR feat(planning): draft-goal-condition skill — docs-conformant /goal shape + mechanical length gate #592): if the live /goal docs change their effective-condition shape, a successfully fetched new shape from Step 1 now conflicts with the static four-part enumeration immediately below in Step 2 — steering the draft back toward the old contract, the exact drift this skill exists to prevent.
• claude[bot] (PR feat(planning): draft-goal-condition skill — docs-conformant /goal shape + mechanical length gate #592): the "As of the contract this skill targets, that is:" framing marks it as descriptive reference, not a hardcoded fallback; in the normal path the model uses the live shape, so the enumeration is a reading aid. "No change needed."

Two reviewers reach opposite conclusions on the identical success path, so this is an author design call, not a mechanical defect.

Decision to make

Pick one:

1. Keep as-is — accept the "As of..." descriptive framing as sufficient; the enumeration is a maintainer reading aid.
2. Point-don't-restate — rework Step 2 to reference "the shape you extracted in Step 1" and keep only the shape-agnostic drafting guidance (transcript-demonstrability, which is the skill's core value-add and NOT a doc shape). Then do a consistency pass on the description frontmatter parenthetical, which embeds the same shape.

If (2), preserve the transcript-demonstrability guidance ("every claim in the condition must be something Claude's own output can demonstrate") — it is shape-agnostic and load-bearing.

Not blocking

P2 suggestion; does not block PR #592 CI/readiness. Deferred to keep the merge path clean and let the author choose the tradeoff.

[kyle-sexton]

This was generated by AI during triage.

Triage — ready with noted decision.

Single clear fork between two reviewers' readings of the same success path (keep-as-is vs point-don't-restate), not architectural — confined to one skill file's Step 2 prose + its frontmatter description parenthetical.

Decision defaulted: option 2 (point-don't-restate) — veto before merge. This repo has an explicit standing discipline against exactly this drift pattern (re-anchor:point-dont-copy: never restate a value fetched live elsewhere, since the copy and the source can drift). Codex's read is the one aligned with that convention — the static four-part enumeration will silently contradict a genuinely-changed live shape the moment the docs move. Rework Step 2 to reference "the shape you extracted in Step 1," preserving the shape-agnostic transcript-demonstrability guidance verbatim (it is the skill's core value-add, not a doc shape), then do the matching consistency pass on the frontmatter description parenthetical that embeds the same four-part shape.

Not blocking any open PR — pure follow-up.

[kyle-sexton]

Parking — this is explicitly framed as an author design call between two reviewers reaching opposite conclusions on the same success path, not a mechanical defect. Not blocking PR #592 (already merged).

RECOMMENDED: Option 2 (point-don't-restate) — rework Step 2 to reference "the shape you extracted in Step 1" rather than re-enumerating the four-part shape, keeping only the shape-agnostic transcript-demonstrability guidance. Also do the consistency pass on the frontmatter description parenthetical, which embeds the same shape. This is the more defensible reading given this repo's own stated re-anchor:point-dont-copy convention (never duplicate content that can drift) — the enumeration is exactly the kind of copy that will silently go stale if the live /goal docs change shape, regardless of the "As of..." framing softening it.

Options:

1. Keep as-is — accept the "As of..." descriptive framing as sufficient; simplest, zero-effort, but leaves a literal duplicate of doc-sourced content sitting in the skill file, which is the exact anti-pattern point-dont-copy warns about.
2. Point-don't-restate (recommended) — remove the static enumeration, reference Step 1's live extraction instead, keep the shape-agnostic transcript-demonstrability guidance, fix the frontmatter description too.

label: status: needs-decision