Add /awos:prototype-prompt command for AI prototyping tools #64
Conversation
Generates AI-optimized prompts for Figma Make, v0, Lovable, Bolt.new. Supports 3 modes: Basic (roadmap), Hybrid (mixed), Detailed (full specs). Interactive structure & design system approval flow. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
There was a problem hiding this comment.
Pull Request Overview
This PR adds a new /awos:prototype-prompt command that generates AI-optimized prompts for visual prototyping tools. The command analyzes architecture and feature specifications to create comprehensive prompts suitable for AI prototyping platforms like Figma Make, v0, Lovable, and Bolt.new.
Key Changes:
- Introduces a new optional workflow step for generating visual prototypes before implementation
- Supports three detail modes (Basic, Hybrid, Detailed) based on available specifications
- Integrates with existing architecture and spec documents while remaining optional in the workflow
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
commands/prototype-prompt.md |
Main command logic with 9-step process for generating prototype prompts from architecture and specs |
templates/prototype-prompt-template.md |
Simple template structure for storing generated prototype prompts |
claude/commands/prototype-prompt.md |
Stub file that redirects to the main command implementation |
README.md |
Documentation update positioning the new command as an optional workflow step |
| # INPUTS & OUTPUTS | ||
|
|
||
| - **Template File:** `.awos/templates/prototype-prompt-template.md` (The required structure). | ||
| - **Required Input:** `context/product/architecture.md` (Tech stack, design constraints). |
There was a problem hiding this comment.
The path context/product/architecture.md is incorrect. Based on other AWOS commands (architecture.md, product.md), architecture files are stored at context/product/architecture.md, but the prerequisite check at line 33 and other references suggest this should be the correct path. However, this inconsistency needs verification - all other commands consistently use context/product/ for product-level documents like architecture, roadmap, and product-definition.
| 3. Paste the prompt and let it generate your prototype | ||
| 4. Iterate on the generated prototype as needed | ||
|
|
||
| Once you have a prototype, you can start implementation with `/awos:tasks` for each feature. |
There was a problem hiding this comment.
The suggested next step should reference /awos:spec before /awos:tasks. According to the workflow in README.md, the sequence is /awos:spec → /awos:tech → /awos:tasks → /awos:implement. A prototype would typically be created before detailed specifications, so the next step after prototyping should be /awos:spec to define functional requirements for features.
| Once you have a prototype, you can start implementation with `/awos:tasks` for each feature. | |
| Once you have a prototype, the next step is to define functional requirements for each feature using `/awos:spec`. | |
| Proceed through the workflow: `/awos:spec` → `/awos:tech` → `/awos:tasks` → `/awos:implement`. |
| # Prototype Prompt: [Application Name] | ||
|
|
||
| - **Generated:** [Date] | ||
| - **Detail Level:** Basic | Hybrid | Detailed |
There was a problem hiding this comment.
[nitpick] The template should include placeholder text or brief descriptions for 'Basic', 'Hybrid', and 'Detailed' modes to guide users. Other templates like architecture-template.md provide examples within brackets (e.g., [Technology Choice]), but this template doesn't explain what these detail levels mean. Consider adding a comment like <!-- Basic: Architecture + roadmap | Hybrid: Mix of specs and roadmap | Detailed: Full spec-based -->.
| - **Detail Level:** Basic | Hybrid | Detailed | |
| - **Detail Level:** Basic | Hybrid | Detailed | |
| <!-- Basic: Architecture + roadmap | Hybrid: Mix of specs and roadmap | Detailed: Full spec-based --> |
| - Feature name and description | ||
| - User goals or problems being solved | ||
| - Any mentioned capabilities or requirements | ||
| - Infer likely screens and UI elements based on feature type |
There was a problem hiding this comment.
[nitpick] The instruction to 'Infer likely screens and UI elements based on feature type' at line 89 is vague and could lead to inconsistent results. Consider providing examples of common feature types and their typical UI patterns (e.g., 'Authentication features typically include: Login screen, Registration screen, Password reset screen') to ensure more predictable AI behavior.
| - Infer likely screens and UI elements based on feature type | |
| - Infer likely screens and UI elements based on feature type. Use the following examples to guide your inference: | |
| - **Authentication features:** Login screen, Registration screen, Password reset screen, Email verification prompt. | |
| - **User Profile features:** Profile view, Edit profile form, Avatar upload, Account settings. | |
| - **Dashboard features:** Overview screen with key metrics, Recent activity feed, Quick actions panel. | |
| - **CRUD (Create/Read/Update/Delete) features:** List view (table or cards), Detail view, Create/Edit form, Delete confirmation modal. | |
| - **Search features:** Search bar, Results list/grid, Filters/sorting controls, No results state. | |
| - **Notifications:** Notification center, Toasts/snackbars, Notification settings. | |
| - **Settings:** Settings overview, Individual settings forms, Save/cancel actions. | |
| - **Onboarding/Tutorial:** Welcome screen, Step-by-step wizard, Progress indicator. | |
| - **E-commerce/Product features:** Product list/grid, Product detail, Cart, Checkout flow, Order confirmation. | |
| - For any other feature types, use your best judgment and reference common UI/UX patterns. |
|
Is there a way to send the result right in a service? Maybe some MCP or whatever? Like instead of showing a prompt to the user, give them a ready link to the generated app, let's say in figma make. |
|
@mkf-simpson I believe we need a public API to be able to do that. Figma Make doesn't have it yet (neither Bolt.new). Lovable has a build-with-url functionality, where we need to open a url with predefined prompt, then it starts building. v0 has a public API which seems like a perfect way to send a prompt. |
Generates AI-optimized prototype building prompt for Figma Make, v0, Lovable, Bolt.new.
Supports 3 modes: Basic (roadmap), Detailed (full specs), Hybrid (mixed).
Includes interactive structure & design system approval flow.