|
| 1 | +--- |
| 2 | +name: design-prototyping |
| 3 | +description: This skill describes how to create prototype pages to explore website designs and copy |
| 4 | +--- |
| 5 | + |
| 6 | +# Design Brief |
| 7 | + |
| 8 | +You are creating design prototypes for a marketing/landing page site. |
| 9 | + |
| 10 | +## Step 1: Understand the Product |
| 11 | + |
| 12 | +If this is a new repo: |
| 13 | + |
| 14 | +- Read `docs/concept.md` in this repository. It describes the product or concept this site will market. Internalize the key value propositions, features, and positioning before proceeding. |
| 15 | + |
| 16 | +If this is an existing website: |
| 17 | + |
| 18 | +- Read the `src/index.astro` in this repository. The copy should be used as a source for the concept of the site. |
| 19 | + |
| 20 | +## Step 2: Clarify the Purpose |
| 21 | + |
| 22 | +Confirm with the user the following before proceeding: |
| 23 | + |
| 24 | +1. **Who is the intended audience?** (e.g., developers, small business owners, general consumers, enterprise buyers) |
| 25 | +2. **What is the primary call-to-action?** The most common case is email collection for gauging interest (lean startup MVP style), but confirm this with the user. Other options could include: Calendly style scheduler (Use ShadCN), Join our Discord, follow us on Bluesky/X |
| 26 | +3. **Are there any brand constraints?** (e.g., specific colors, existing logo, tone of voice) If none, you have full creative freedom. |
| 27 | +4. **What company owns the site?** Ask if the site should state one. By default the company that owns the site is Wyrd, at https://wyrd.company. Other options includes Dark Futures Interactive (https://darkfutures.com) and Scratching Monkey Software (https://scratchingmonkey.com). The user may ask to omit it. |
| 28 | +5. **Whould the site have a login page, about page, privacy policy page, and/or terms of use page?** |
| 29 | + |
| 30 | +## Step 3: Set Up the Project (skip if already setup) |
| 31 | + |
| 32 | +1. Run `pnpm create astro@latest` in the project root. Choose the empty template, strict TypeScript, and accept defaults. Answer yes to installing dependencies. You will have to copy the contents of the subfolder created to the root. Do not overwrite README.md. |
| 33 | +2. Update the astro config to bind the site to the host 0.0.0.0 since you are running in a devcontainer. |
| 34 | +3. Install and configure Tailwind CSS for Astro. |
| 35 | + |
| 36 | +## Step 4: Create Design Prototypes |
| 37 | + |
| 38 | +Create the number of distinct prototypes specified by the user in their prompt (e.g., "create 3 prototypes"). |
| 39 | + |
| 40 | +### Routing |
| 41 | + |
| 42 | +- Each prototype is a single page accessible at `/1`, `/2`, `/3`, etc. |
| 43 | +- Create these as `src/pages/1/index.astro`, `src/pages/2/index.astro`, etc. |
| 44 | + |
| 45 | +### Design Requirements |
| 46 | + |
| 47 | +- **Each prototype must be a completely different design.** Vary layout structure, color palette, typography, visual style, and overall feel. One might be bold and dark, another minimal and airy, another playful and colorful. Exercise full creative freedom. |
| 48 | +- Each prototype is a complete, single-page marketing/landing page. |
| 49 | +- Write original copy for each prototype grounded in `concept.md` and tailored to the intended audience established in Step 2. Don't reuse the same copy across prototypes. |
| 50 | +- Each prototype must include the agreed-upon call-to-action (e.g., an email signup form). |
| 51 | +- Use Tailwind CSS for all styling. No external CSS frameworks. |
| 52 | +- If the page has interactive elements, use React/ShadCN when needed. |
| 53 | +- Pages should be responsive and look good on both mobile and desktop. |
| 54 | + |
| 55 | +### Prototype Navigation |
| 56 | + |
| 57 | +Include a navigation element on every prototype page that allows switching between prototypes (links to `/1`, `/2`, `/3`, etc.). Implement a common layout that adds the navigation to each prototype. |
| 58 | + |
| 59 | +**Important:** This navigation is a utility element for reviewing the prototypes. It is **not** part of the prototype's design. It should be clearly separate and unobtrusive -- you decide the form (a floating bar, a small corner pill, a minimal strip, etc.) as long as it does not interfere with or appear to be part of the prototype design itself. |
| 60 | + |
| 61 | +## Step 5: Verify |
| 62 | + |
| 63 | +1. Run `pnpm dev` and confirm each prototype page loads without errors. |
| 64 | +2. Verify that navigation between prototypes works. |
| 65 | +3. Check that pages render correctly at different viewport widths. |
| 66 | + |
| 67 | +## Step 6: Review |
| 68 | + |
| 69 | +Review the prototypes created, even previous ones. Provide your opinion on which are your favorites and why. Also consider the copy of each one, what is the strongest copy and why? |
| 70 | + |
| 71 | +## Step 7: Iterate and select |
| 72 | + |
| 73 | +The user will likely want to iterate on the designs. This may involve creating new prototypes. Some entirely new, others variations of existing ones. |
| 74 | + |
| 75 | +The user will eventually identify the one prototype that is the winner. |
| 76 | + |
| 77 | +## Step 8: Finalize |
| 78 | + |
| 79 | +Once the winner is selected: |
| 80 | + |
| 81 | +1. Update the root page to the design of the winning prototype. |
| 82 | +2. Remove the existing prototypes. |
| 83 | +3. (If new or updated) Use the favicon skill to create a favicon for the site. Use `rsvg-convert` to convert the svg to png so it is not blurry. |
| 84 | +4. (If new) Have the user set the GitHub repository secret: DREAMHOST_REMOTE `ssh://scratchingmonkey@<site name>/home/scratchingmonkey/<site name>.git` |
| 85 | +5. If there is an email form, set it up to use the `sf_3ha45db65ai25lcglfme20fj` key and show a confirmation page, `signup-confirmed` or `waitlist-confirmed`, that has a button to go back to the home page. |
| 86 | +6. Update the README.md |
| 87 | +7. **Where will the site be hosted?** Ask if the site will be hosted on Dreamhost or Cloudflare. The `.github/workflows/cd.yml` has commented out steps for each. Uncomment the appropriate one and remove the unneeded commented step. |
| 88 | + |
| 89 | +```html |
| 90 | +<form action="https://api.staticforms.dev/submit" method="POST"> |
| 91 | + <!-- Your API Key (replace with your actual key) --> |
| 92 | + <input type="hidden" name="apiKey" value="YOUR_API_KEY"> |
| 93 | +``` |
0 commit comments