agentleFS
xieqiyongxieqiyong/skills/workflow-collaboration-fullstack-skills/SKILL.md

workflow-collaboration-fullstack-skills

Skill4 starsChanged 5 months agoApache-2.0View on GitHub

统一编排前端与后端项目搭建流程,整合 `frontend-scaffold-setup` 与 `backend-springboot4-standard-framework` 两个 Skill 完成全栈项目初始化、目录规划、接口协同和阶段性交付。用于用户提出“搭建完整项目”“前后端一起搭”“先搭前端再补后端”“输出全栈脚手架”这类需求时。

The file

Files
SKILL.md

SKILL.md

Fullstack Workflow Orchestrator

目标

将前端与后端 Skill 组织成一个可执行的全栈搭建流程,避免重复设计和上下文遗漏。

默认支持两种交付路径:

  • 全栈一起搭建:同时规划前端、后端、接口边界和仓库结构
  • 前端优先搭建:先落地前端项目骨架,再预留后端接口契约与接入方式

依赖 Skill

按需读取以下 Skill,只读取完成当前任务所需的部分:

  • 前端:../frontend-scaffold-setup/SKILL.md
  • 后端:../backend-springboot4-standard-framework/SKILL.md

不要在本 Skill 中重复展开前端或后端的全部实现细节;细节交给对应 Skill 处理,本 Skill 只负责编排、衔接和约束顺序。

收集最小上下文

优先确认以下信息:

  • 项目类型:全栈一起搭建,或前端优先
  • 项目名称
  • 前端技术栈是否沿用默认方案:Nuxt 3 + Vue 3 + TypeScript + Nuxt UI
  • 后端是否沿用默认方案:Spring Boot 4.0.1 + JDK 17 + Maven 多模块
  • 后端基础包名 base package
  • 前后端是否同仓库管理
  • 是否需要先定义接口协议、鉴权方式、菜单/权限模型

遵守以下约束:

  • 如果用户要求搭建后端,则必须先拿到 base package
  • 如果用户只要求先搭前端,则允许先不生成后端代码骨架
  • 即使先做前端,也要补一份最小接口协作约束,避免后续后端接入返工

默认工作模式

模式一:全栈并行

在用户明确要求“完整项目”或“前后端一起搭建”时使用:

  1. 确认前后端最小上下文
  2. 先确定仓库结构与模块边界
  3. 先定义接口分层与命名约定
  4. 调用前端 Skill 输出前端脚手架
  5. 调用后端 Skill 输出后端脚手架
  6. 回到编排层补齐联调说明、环境变量和启动顺序

模式二:前端优先

在用户表示“可以先搭前端”“先出页面骨架”时使用:

  1. 调用前端 Skill 先完成页面、布局、路由、请求封装和登录态预留
  2. 输出接口占位方案,包括接口路径命名、请求响应格式、错误码约定
  3. 标出未来后端接入点,例如:
    • 登录接口
    • 菜单/权限接口
    • 列表分页接口
    • 详情查询接口
    • 创建/更新接口
  4. 若用户随后补充 base package,再调用后端 Skill 落地后端骨架

仓库组织约束

默认优先采用单仓库结构:

.
├─ frontend/
├─ backend/
├─ docs/
│  └─ api-contract.md
└─ README.md

如果用户已有仓库结构,则沿用现状,不强制迁移。

目录职责约束:

  • frontend/:放前端 Skill 生成的 Nuxt 项目
  • backend/:放后端 Skill 生成的 Maven 多模块项目
  • docs/api-contract.md:记录前后端联调约定

前后端协同约束

在全栈或前端优先场景下,都要补齐以下协同信息:

  • API Base Path 约定,例如 /api
  • 认证方式,例如 token / cookie
  • 通用响应结构
  • 分页结构
  • 错误码约定
  • 时间字段格式
  • 本地开发代理或跨域策略

如果用户没有特别指定,默认采用以下协同口径:

  • 前端通过统一请求层访问 /api/**
  • 后端返回统一响应体
  • 后端默认使用 POST
  • 前端列表、详情、创建、更新、删除接口均按业务动作命名

执行规则

执行本 Skill 时遵循以下顺序:

  1. 先判断是“全栈并行”还是“前端优先”
  2. 能复用现有 Skill 时,不重复发明实现
  3. 如果后端 base package 缺失,只暂停后端部分,不阻塞前端部分
  4. 如果用户只要结构方案,则输出目录树、模块职责和接口草案,不强行生成全部代码
  5. 如果用户要求直接落代码,则按前端 Skill 和后端 Skill 的默认约束分别生成

交付内容

根据模式不同,至少交付以下内容:

全栈并行

  • 仓库目录结构
  • 前端脚手架方案
  • 后端脚手架方案
  • 前后端接口协作约定
  • 本地启动顺序
  • 环境变量说明

前端优先

  • 前端脚手架方案
  • API 占位与 mock/预留方式
  • 后端待补清单
  • 后续接入步骤

自检清单

输出前检查:

  • 是否明确当前走的是“全栈并行”还是“前端优先”
  • 是否已复用前端 Skill,而不是在本 Skill 中重写前端细节
  • 是否在需要后端时确认了 base package
  • 是否给出了前后端接口协作约定
  • 是否说明了哪些内容已落地,哪些内容只是预留
  • 是否让“先前端后后端”的路径可以无缝继续

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.