Spec: Design Phase Asset Evidence

User Input

complete all these issues:

into a full ALL STEPS included $delivery-phase in full parallel mode.

make these new skills and edits VERY VERY CONCISE. use $writing-great-skills for all skill editing sessions

Harness needs a route-gated design-phase skill that can turn existing product design evidence into approved artifacts, backlog work, and an activated delivery run. The same flow also needs durable visual evidence: proposal/prototype screenshots should survive into backlog items, and UI implementation should carry before/after evidence into PR review.

Repo provider choices are currently scattered. Agents need .devpunks/settings.json as the repo-level authority for backlog provider, asset provider, repository manager, and required tools. Skills should use one shared repo asset management skill instead of duplicating provider upload commands.

Non-Goals

Do not generate actual product designs, images, or prototypes as part of this spec.
Do not make wiki backlog-provider docs authoritative once repo settings exist.
Do not store durable visual evidence only in temp files, local screenshots, or transient browser URLs.
Do not split web and mobile into separate outer design lifecycles.

Acceptance Criteria

design-phase exists as a concise route-gated skill whose entrypoint loads router.md first, chooses exactly one next phase, records route evidence, and supports intake, grill, prototype, approval, backlog, and delivery-handoff.
The design-phase router preserves the accepted route-gated contract: router output shape, phase handoff shape, route invariants, staleness rules, phase-local delegation rules, route trace, and examples.
Direct entry into any design phase still goes through the router and validates prerequisite evidence before loading the phase file.
Intake records available routes/pages, theme CSS or tokens, global styles, components, screenshots, Figma/design inputs when available, content sources, and brand constraints; missing Figma/screenshots are recorded without blocking by default.
Low-confidence intake asks one concrete clarification or requests one screenshot when evidence is thinner than routes plus one style, component, or content source.
Grill uses requirements-grill only for lean constraints: goals, scope, conflicts, hard requirements, content ownership, surface, and non-negotiables.
Prototype reads artifact intent first, folds design directions directly into artifact production, delegates artifact work to subagents, uses imagegen paths for image requests when available, and falls back to prototype artifacts only when imagegen is unavailable.
Approval is tracked per user-visible scope unit, and backlog conversion is blocked until an approved artifact set exists.
Backlog conversion uses write-backlog and includes explicit approved artifact context, durable visual asset links, acceptance context, and fallback behavior when provider attachments are unavailable.
delivery-handoff activates delivery-phase with backlog ids, approved artifact links, target surfaces, frontend taste skills, browser/screenshot validation expectations, and before/after PR evidence guidance.
.devpunks/settings.json is the canonical repo settings file when present and records backlog provider, asset provider slug, repository manager, and required tools.
Missing repo settings can be backfilled from existing repo/provider hints for backward compatibility, with conflicts surfaced instead of silently guessed.
Scaffold init prompts for repository manager selection alongside backlog provider selection, persists both, and adds the selected repository manager CLI to the required-tools list for scaffold/update validation.
Existing wiki backlog provider files stop acting as configuration authority.
A concise shared repo asset management skill exists with progressive disclosure and provider references for GitHub, GitLab, Azure, and Bitbucket.
Repo asset guidance prefers backlog attachments for approved design/prototype assets and uses repo-provider attachments when backlog attachments are unavailable or unsuitable.
design-phase, write-backlog, implement-spec, and delivery-phase reference the shared repo asset management skill instead of copying provider CLI guidance.
UI implementation closeout and PR-ready handoff carry durable before/after visual evidence links and follow the existing UI screenshot evidence contract.

Constraints

Reusable skill changes are authored first in /Users/stefan/Desktop/repos/wearedevpunks-skills, then synced into Harness.
Skill edits must follow writing-great-skills: concise entrypoints, one behavior per source of truth, progressive disclosure for provider details.
Harness implementation must respect app/package boundaries and update operator docs/runbooks when scaffold or workflow behavior changes.
Subagent execution is required for implementation, with parallelism only across disjoint scopes.

Technical Notes

Source requirements are closed in apps/wiki/content/docs/project/grilling/ui-design-phase-flow-grill-status.md and ui-design-phase-flow-backlog.md.
Provider specifics are summarized in apps/wiki/content/docs/project/grilling/ui-design-phase-flow-backlog.md; implementation may use the original handoff path only as optional working evidence while creating durable skill references.
GitHub durable CLI path is release assets; GitLab prefers package upload for neutral hosting; Azure uses Blob Storage; Bitbucket uses Downloads/API/pipe behavior.

Decision Log

Decision	Rationale
Treat this as one delivery spec across all listed issues.	The issues are one dependency chain for design-phase, repo settings, asset hosting, backlog evidence, and PR evidence.
Use repo settings as authority.	Provider behavior must be machine-readable and committed, not inferred from wiki prose.
Put provider upload commands behind a shared skill.	Phase skills need stable behavior without duplicating stale CLI snippets.

Design Phase Asset Evidence Spec