frontend-from-backend
Skill0 starsChanged 9 months agoMITView on GitHub
Write production-ready frontend specifications deeply grounded in existing backend architecture to prevent integration issues. Use when building frontend features on a working backend or redesigning UI for an existing API. Trigger phrases: 'spec the frontend', 'write frontend spec from backend', 'ground the UI in this API', 'integrate this frontend', 'frontend implementation guide'.
In this repository47 other files it gives its agents.
- agent-teachingSkill
- cf-pages-trespies-deploySkill
- compression-ritualSkill
- context-ingestionSkill
- decision-propagationSkill
- documentation-auditSkill
- era-architectureSkill
- file-managementSkill
- handoff-protocolSkill
- health-auditSkill
- house-poc-builderSkill
- implementation-promptSkill
- iterative-scoutingSkill
- mcp-cloudflare-builderSkill
- mcp-server-builderSkill
- memory-gardenSkill
- multi-surface-strategySkill
- parallel-tracksSkill
- patient-learning-protocolSkill
- planning-with-filesSkill
- poc-tool-forgeSkill
- pre-implementation-checklistSkill
- process-extractionSkill
- product-positioningSkill
- project-explorationSkill
- release-specificationSkill
- repo-context-syncSkill
- repo-statusSkill
- research-modesSkill
- research-synthesisSkill
- retrospectiveSkill
- seed-extractionSkill
- seed-librarySkill
- seed-to-skill-converterSkill
- semantic-clustersSkill
- skill-audit-upgradeSkill
- skill-creationSkill
- skill-maintenanceSkill
- spec-constellation-to-prompt-suiteSkill
- static-tool-verifySkill
- status-templateSkill
- status-writingSkill
- strategic-scoutSkill
- strategic-to-tactical-workflowSkill
- web-research-externalSkill
- workflow-routerSkill
- workspace-navigationSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 11 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 56
Goal: Write a production-ready specification for the new feature that leverages the existing backend.
- Distinctive: line 58
Write a Full Feature Spec: Create a detailed document covering:
- Distinctive: line 70
Goal: Create a practical guide for developers on how to wire the new frontend to the backend.
- Distinctive: line 72
Create a Track-by-Track Guide: If the feature is being built in parallel tracks, create a guide for each track.
- Distinctive: line 74
Explain Streaming Architecture: If the feature uses streaming, document the SSE or WebSocket connection and event handling.
- Distinctive: line 80
Goal: Update all development prompts (e.g., for implementation agents like Zenflow or Claude Code) with backend grounding.
- Distinctive: line 89
Goal: Ensure all documentation is complete, consistent, and ready for commissioning.
- Distinctive: line 92
Write Missing Documentation: If any gaps are found (e.g., design system, API contracts), write the missing documents.
- Very specific: line 93
Push to Repository: Commit all documentation to a dedicated directory (e.g., docs/vX.X.X/).
- Distinctive: line 101
The Backend is the Source of Truth: If there is a discrepancy between the frontend design and the backend API, the backend API is correct.
- Distinctive: line 109
Before commissioning the work, ensure you can answer "yes" to all of the following questions:
- Distinctive: line 121
When running inside the Dojo Genesis plugin:
≈ “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
OpenClaw Integration: This skill is invoked by the Dojo Genesis plugin via
/dojo run frontend-from-backend. The agent receives project context automatically via thebefore_agent_starthook. Usedojo_get_contextfor full state,dojo_save_artifactto persist outputs, anddojo_update_stateto record phase transitions and decisions.
Write Frontend Spec From Backend Skill
Version: 1.0 Created: 2026-02-07 Author: Manus AI Purpose: To provide a structured, repeatable process for writing high-quality frontend specifications that are deeply integrated with an existing backend, ensuring seamless development and reducing integration friction.
I. The Philosophy: Grounding Before Building
Frontend development in a full-stack application does not happen in a vacuum. The most common source of bugs, delays, and rework is a disconnect between the frontend implementation and the backend reality. This skill is built on a simple but powerful principle: grounding before building.
By deeply understanding the existing backend architecture, APIs, and data models before writing a single line of frontend specification, we can prevent entire classes of integration problems. This process transforms specification writing from a creative exercise into a disciplined engineering practice, ensuring that what we design is not just beautiful, but buildable.
II. When to Use This Skill
- When planning a new frontend feature that will interact with an existing backend.
- When writing specifications for a UI redesign of a feature that has a backend component.
- When commissioning frontend work to an autonomous agent like Claude Code, Zenflow, or other implementation agents.
- When you feel a disconnect between the frontend vision and the backend reality.
- At the beginning of any major frontend development cycle.
III. The Workflow
This workflow is a 5-step process that takes you from a high-level feature idea to a production-ready, backend-grounded specification.
Step 1: Deep Backend Analysis
Goal: Achieve a comprehensive understanding of the existing backend architecture.
- Run
/repo-context-sync: Generate a comprehensive context map of the repository. - Read Key Backend Files:
main.go(or equivalent): Understand route registration and server setup.handlers/: Read the handlers for the relevant feature areas.middleware/: Understand the authentication and request lifecycle.
- Document APIs: Map all relevant API endpoints, including methods, authentication requirements, request bodies, and success/error responses.
- Identify Integration Points: For each part of the new frontend feature, identify the specific backend endpoint it will interact with.
Step 2: Comprehensive Feature Specification
Goal: Write a production-ready specification for the new feature that leverages the existing backend.
- Write a Full Feature Spec: Create a detailed document covering:
- Executive summary and problem statement
- Goals, non-goals, and user stories
- Technical architecture (how frontend and backend will interact)
- UI/UX wireframes and interaction flows
- API contracts with request/response examples
- Implementation plan (if multi-phased)
- Security considerations
- Leverage Existing Backend: Design the feature to use existing backend infrastructure wherever possible. Avoid proposing new backend features unless absolutely necessary.
Step 3: Integration Guide Creation
Goal: Create a practical guide for developers on how to wire the new frontend to the backend.
- Create a Track-by-Track Guide: If the feature is being built in parallel tracks, create a guide for each track.
- Document Authentication Flow: Explain how the frontend should handle authentication (guest mode, API key mode, cloud sync).
- Explain Streaming Architecture: If the feature uses streaming, document the SSE or WebSocket connection and event handling.
- Provide Code Examples: Include frontend code snippets for making API calls.
- Document Error Handling: Specify how the frontend should handle different backend error codes.
Step 4: Track Prompt Enhancement
Goal: Update all development prompts (e.g., for implementation agents like Zenflow or Claude Code) with backend grounding.
- Add a "Backend Grounding" Section: In each prompt, add a dedicated section that explains the backend context.
- Document Specific Endpoints: For each part of the implementation, specify the exact API endpoint to use.
- Reference the Integration Guide: Link to the full integration guide for more details.
- Ensure Prompts Use Existing Patterns: Explicitly instruct the development agent to follow existing backend patterns.
Step 5: Audit and Deliver
Goal: Ensure all documentation is complete, consistent, and ready for commissioning.
- Run a Final Audit: Review all documents for gaps, inconsistencies, or missing information.
- Write Missing Documentation: If any gaps are found (e.g., design system, API contracts), write the missing documents.
- Push to Repository: Commit all documentation to a dedicated directory (e.g.,
docs/vX.X.X/). - Confirm Readiness: Announce that the specifications are complete and ready for commissioning.
IV. Best Practices
- No Backend Changes is the Goal: The primary goal of this process is to build a frontend that works with the existing backend. Only propose backend changes as a last resort.
- The Backend is the Source of Truth: If there is a discrepancy between the frontend design and the backend API, the backend API is correct. The frontend design must adapt.
- Over-Document the Integration: It is better to provide too much detail on how the frontend and backend should connect than too little.
- Use this Skill Before Writing Code: This process should be completed before any significant frontend development begins.
V. Quality Checklist
Before commissioning the work, ensure you can answer "yes" to all of the following questions:
- Have you read the main entrypoint of the backend application?
- Have you read the handlers for all relevant API endpoints?
- Have you written a comprehensive feature specification that includes API contracts?
- Have you created a backend integration guide with code examples?
- Have all development prompts been updated with a "Backend Grounding" section?
- Have you audited all documentation for completeness and pushed it to the repository?
OpenClaw Tool Integration
When running inside the Dojo Genesis plugin:
- Start by calling
dojo_get_contextto retrieve full project state, history, and artifacts - During the skill, follow the workflow steps documented above
- Save outputs using
dojo_save_artifactwith theartifactsoutput directory - Update project state by calling
dojo_update_stateto record skill completion and any phase transitions
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.

