create_prototype
Skill38 starsChanged 2 months agoMITView on GitHub
Create Prototype
In this repository101 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/CLAUDE.mdCLAUDE.md
- .cursor/rules/autonomous_execution.mdcCursor rule
- .cursor/rules/cursor_rules_editing.mdcCursor rule
- .cursor/rules/cursor_rules_sync.mdcCursor rule
- .cursor/rules/cursor_rules_sync_requirement.mdcCursor rule
- site_pages/llms.txtllms.txt
- advisorySkill
- analyzeSkill
- auditSkill
- commitSkill
- create-planSkill
- create_planSkill
- create-prototypeSkill
- create_prSkill
- create-releaseSkill
- create_releaseSkill
- create-ruleSkill
- create_ruleSkill
- debugSkill
- draft-illustrationSkill
- draft_illustrationSkill
- endSkill
- evaluate_positioningSkill
- final-reviewSkill
- final_reviewSkill
- fix-feature-bugSkill
- fix_feature_bugSkill
- learnSkill
- manage-error-debuggingSkill
- manage_error_debuggingSkill
- neversight_learn_skills.dev_obviously_awesomeSkill
- process_issuesSkill
- process_prsSkill
- publish-planSkill
- publish_planSkill
- publishSkill
- pullSkill
- pushSkill
- recover_sqlite_databaseSkill
- releaseSkill
- report-errorSkill
- report_errorSkill
- reportSkill
- reviewSkill
- run-feature-workflowSkill
- run_feature_workflowSkill
- setup-commandsSkill
- setup_commandsSkill
- setup-cursor-copiesSkill
- setup_cursor_copiesSkill
- store-neotomaSkill
- store_neotomaSkill
- sync-env-from-1passwordSkill
- sync_env_from_1passwordSkill
- analyzeSkill
- auditSkill
- commitSkill
- create-planSkill
- create-prototypeSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
17 rules. About 0 are common, 10 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 11
Create fully functional client-side prototype for Feature Unit {{input:feature_id}}.
- Very specific: line 13
Follow foundation/development/feature_unit_workflow.md Step 1 (Prototype Creation).
- Distinctive: line 22
No UI changes required (skip prototype)
- Very specific: line 27
Read foundation-config.yaml to get feature unit settings
- Distinctive: line 36
Verify UX Requirements section exists in spec (from Checkpoint 0)
- Distinctive: line 37
If no UI changes → skip to implementation
- Distinctive: line 38
If UI changes present → proceed
- Very specific: line 41
Use configured prototype directory structure (or default: frontend/src/prototype/)
- Very specific: line 42
Create prototype component(s): {prototype_dir}/components/{{input:feature_id}}_*.tsx
- Very specific: line 43
Create mock API fixtures: {prototype_dir}/fixtures/{{input:feature_id}}_*.ts
- Distinctive: line 48
All API calls mocked (no real backend)
- Distinctive: line 49
All UI states testable (empty, error, loading, success)
- Very specific: line 55
Ensure prototype can be run (e.g., npm run dev:prototype)
- Distinctive: line 56
Document how to run prototype
- Distinctive: line 62
STOP and proceed to Checkpoint 1 (Prototype Review)
- Distinctive: line 78
Update prototype based on feedback
- Very specific: line 84
Document approval in spec: Prototype Approved: YYYY-MM-DD
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- Source: .cursor/skills/create-prototype/SKILL.md -->Create Prototype
Create fully functional client-side prototype for Feature Unit {{input:feature_id}}.
Follow foundation/development/feature_unit_workflow.md Step 1 (Prototype Creation). Configuration is read from foundation-config.yaml.
This happens after Checkpoint 0 (spec creation) and before Checkpoint 1 (prototype review).
Implements prototype creation after Checkpoint 0 (spec) is complete. Creates a fully interactive, client-side prototype with mocked APIs.
Trigger
- Spec created with UI requirements (Checkpoint 0 complete, UI changes present) OR
- No UI changes required (skip prototype)
Tasks
- Load configuration:
- Read
foundation-config.yamlto get feature unit settings - Determine directory structure and prototype paths
- Read
- Load spec and manifest:
{configured_directory}/in_progress/{{input:feature_id}}/{{input:feature_id}}_spec.md(orcompleted/if completed){configured_directory}/in_progress/{{input:feature_id}}/manifest.yaml(orcompleted/if completed)
- Check if UI changes present:
- Review spec and manifest for UI components
- Verify UX Requirements section exists in spec (from Checkpoint 0)
- If no UI changes → skip to implementation
- If UI changes present → proceed
- Create prototype:
- Use configured prototype directory structure (or default:
frontend/src/prototype/) - Create prototype component(s):
{prototype_dir}/components/{{input:feature_id}}_*.tsx - Create mock API fixtures:
{prototype_dir}/fixtures/{{input:feature_id}}_*.ts - Integrate into prototype main file
- Use configured prototype directory structure (or default:
- Prototype requirements:
- Fully interactive (click, type, navigate)
- All API calls mocked (no real backend)
- All UI states testable (empty, error, loading, success)
- Accessible (keyboard nav, ARIA if applicable)
- Uses existing design system components (if available)
- Documented mock API responses
- Make prototype runnable:
- Ensure prototype can be run (e.g.,
npm run dev:prototype) - Document how to run prototype
- Ensure prototype can be run (e.g.,
- Output:
- Prototype location and run command
- Summary of what prototype demonstrates
- List of mocked APIs
- STOP and proceed to Checkpoint 1 (Prototype Review)
User Review Prompt
Present:
- Prototype location
- How to run: [command]
- Summary of prototype features
Ask:
- "Please review the prototype at [location]. Run with [command]."
- "Does the prototype meet your requirements? (yes/no)"
- "Any changes needed? (list changes or 'none')"
If User Requests Changes
- Update prototype based on feedback
- Re-run prototype creation
- Repeat until approved
If Approved
- Document approval in spec:
**Prototype Approved:** YYYY-MM-DD - Proceed to implementation (use
Run Feature Workflow)
Inputs
feature_id(string): The feature identifier
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

