Website Implementation Plan

Website Implementation Plan

Turns an approved improvement proposal (prd.md) into a phased implementation plan. Landing page first, then deeper pages. Asset collection vs. creation tracked. Writes tasks.md after approval.

When to Use

Trigger when the user asks to:

• Plan the implementation of a website improvement proposal
• Break down a PRD into phased tasks
• Create an implementation plan for a site rebuild

Do not use for building or coding — that is Phase 5 (website-builder).

Workflow

1. Read the approved prd.md
2. Identify phases: landing page first, then deeper content
3. For each task: define scope, outputs, acceptance criteria
4. Track assets: collect from original vs. create new
5. Assemble into tasks.md
6. Present for review
7. Incorporate edits (loop until approved)
8. Persist tasks.md

Output: tasks.md Structure

# Implementation Plan: <site name>
**Source PRD:** prd.md
**Date:** <date>

---

## Overview

Brief summary of the implementation approach and phase ordering rationale.

## Phase 1: Landing Page

The landing/home page is built first so it can be shown to potential users early.

### Task 1.1: Project Setup

**Scope:** Initialize Vite + React + shadcn/ui + Tailwind CSS project. Configure build, routing, and deployment to GitHub Pages.

**Outputs:** Working project scaffold with build pipeline.

**Acceptance Criteria:**
- `npm run dev` starts a local dev server
- `npm run build` produces static assets in dist/
- GitHub Pages deployment configured

**Assets Needed:**
- [Collect] Logo, brand colors, brand name from original site
- [Create] Project repository on GitHub

### Task 1.2: Landing Page Layout

**Scope:** Build the hero section, nav, CTA, and footer based on the improvement proposal. Implement the improved layout, not a clone.

**Outputs:** Landing page component with improved structure.

**Acceptance Criteria:**
- Hero section with clear headline, subtext, primary CTA above the fold
- Responsive layout (mobile + desktop)
- Navigation matches the improved structure

**Assets Needed:**
- [Collect] Hero imagery, copy text, brand colors
- [Create] New CTA copy (if improvement proposes different messaging)

---

## Phase 2: Core Pages

Deeper pages beyond the landing page.

### Task 2.1: <Page Name>

**Scope:** ...
**Outputs:** ...
**Acceptance Criteria:** ...
**Assets Needed:**
- [Collect] ...
- [Create] ...

---

Repeat for each task across phases.

## Phase 3: Optimization and Polish

Performance, SEO, and security improvements from the PRD.

### Task 3.1: Performance Optimization

**Scope:** Image optimization, lazy loading, code splitting, font optimization.

**Acceptance Criteria:**
- LCP ≤ target (from prd.md metrics table)
- CLS ≤ target
- Page weight ≤ target

### Task 3.2: SEO Implementation

**Scope:** Meta tags, structured data, heading structure, alt text, canonical URLs.

**Acceptance Criteria:**
- SEO score ≥ target
- All pages have title, meta description, structured data

### Task 3.3: Security Hardening

**Scope:** HTTPS enforcement, security headers, mixed content fixes.

**Acceptance Criteria:**
- All resources loaded over HTTPS
- Key security headers present

## Asset Summary

| Asset | Source | Action |
|-------|--------|--------|
| Logo | Original site | Collect |
| Brand colors | Original site | Collect |
| Hero image | Original site | Collect |
| CTA copy | Improvement proposal | Create |
| New icons | Generated | Create |

## Deployment

1. Push to GitHub repository
2. Configure GitHub Pages (settings → Pages → source: main /docs or /)
3. Verify deployment at `https://<user>.github.io/<repo>/`

---

*This plan is derived from the approved improvement proposal. Actual task scope may need adjustment during implementation.*

Step 1: Read prd.md

Read file <path-to-prd.md>

If missing, ask for the path. The orchestrator should have produced this in Phase 3.

Step 2: Define Phases

Structure phases so something usable ships early:

Phase 1 must produce an independently usable landing page.

Step 3: Define Tasks

For each task:

• Scope: Clear, bounded description of what to build
• Outputs: Concrete deliverables
• Acceptance Criteria: Measurable pass/fail conditions
• Assets Needed: Distinguish [Collect] from [Create]

Tasks should be small enough for a single implementation cycle.

Step 4: Asset Tracking

For every asset referenced in the plan:

• Mark as [Collect] if it exists on the original site (logos, images, copy, colors)
• Mark as [Create] if it needs to be newly produced (new icons, rewritten copy, generated images)

Step 5: Write Draft tasks.md

Assemble using the structure above.

Step 6: Present for Review

"Here is the implementation plan. Please:

1. Approve — save as tasks.md
2. Edit — specify changes
3. Regenerate — start over"

Step 7: Incorporate Edits (loop)

If edits requested: update, re-present, repeat until approved.

Do not persist until explicit approval.

Step 8: Persist tasks.md

printf '%s\n' "$TASKS_CONTENT" > "$OUTPUT_PATH"

Default: $PROJECT_DIR/tasks.md or ~/workspace/clones/YYYY_MM_DD_slug/tasks.md.

If $ARGUMENTS includes --output <path>, use that.

Confirm:

tasks.md saved to: <absolute-path>
STATUS: approved

Return Contract

When invoked by the website-cloner umbrella (Phase 4 gate), the orchestrator gates Phase 5 on this skill's outcome. The contract:

The orchestrator MUST NOT advance to Phase 5 unless the outcome is approved. A standalone invocation may ignore the status line, but the file-existence rule still holds: no approval, no tasks.md.

Error Handling

Source: luongnv89/skills — distributed by TomeVault.