Discourage implementation details in design-and-plan ticket output

[williamthorsen]

Problem

Tickets produced or refined via the design-and-plan skill consistently leak implementation details — exact code snippets, syntax, file-level technique — into the ticket body. The ticket is supposed to be the contract (problem, context, outcome, acceptance criteria); the approach belongs in the plan. Mixing them has two recurring costs:

1. When implementation discovers the approach was wrong (as on Modify test:sh script to accept file paths #606), the ticket appears to contradict the as-built code. Maintainers reading the ticket later don't know whether the prose or the code is canonical.
2. The "Solution" heading itself reads as binding. Agents and human readers both default to treating it as a directive rather than a snapshot of the best plan at drafting time.

Context

The relevant template lives at packages/agents/content/skills/design-and-plan/SKILL.md, Phase 4. Two specific weak points:

• Heading: ## Solution — reads as prescriptive.
• Body guidance: {The agreed approach — what will be built and how it fits into the existing system} — phrasing ("agreed approach", "what will be built") invites the author to describe the implementation, not the outcome. Surrounding prose reinforces this by saying the section should "capture the agreed design".

Compare to the plan template in the same file (Phase 5), which bounds detail explicitly ({High-level strategy, 2-3 sentences}) and reserves code-level decisions for the per-task structure.

Concrete failure mode from #606: the ticket's "Solution" included a verbatim package.json one-liner that turned out to be wrong; the actual implementation used a different approach (wrapper script). The acceptance criteria still held, but the prose section now misrepresents the as-built code.

Proposed solution

Update Phase 4 of packages/agents/content/skills/design-and-plan/SKILL.md to:

1. Rename the section heading from ## Solution to ## Proposed solution.
2. Replace the body guidance with phrasing that constrains the section to outcome and architectural fit, not code or syntax: "The shape of the proposed approach: components or boundaries involved, how it fits into the existing system, what tradeoffs were chosen. Keep this section outcome-shaped: Specific code, syntax, and file-level technique belong in the plan, not here."
3. Update the surrounding Phase 4 prose to match: the "capture the agreed design" intro paragraph, the bare "solution" reference in the adopt-as-is conditional, and any other references to "agreed design" / "agreed approach" in Phase 4.
4. Add a one-line anti-example showing what doesn't belong (e.g., a struck-through or ❌-marked code fence with a specific snippet) inside or immediately after the template.

The plan template (Phase 5) and its "Approach" section are not affected — they already model the right level for the plan.

Acceptance criteria

• The ## Solution heading in packages/agents/content/skills/design-and-plan/SKILL.md is renamed to ## Proposed solution.
• The section's body guidance constrains detail to outcome/architecture and explicitly excludes code-level technique.
• References to "agreed design" / "agreed approach" / bare "solution" in Phase 4 prose are reworded to reflect the section's tentative nature.
• A concrete anti-example is included in or adjacent to the Phase 4 template, marking code-level detail as out of scope.
• No changes to Phase 5 (plan template) or Phase 4 acceptance-criteria conventions.
• After install/sync, the regenerated copy under ~/.claude/skills/design-and-plan/SKILL.md reflects the new heading and guidance.