Token导航 LogoToken导航TokenDH.com
效率操作浏览器clawhub未标认证来源可访问clear审计提醒

eb-dev-workflowEB 开发工作流程

Agent Skill

eb-dev-workflow 用于补充效率相关能力,适合在 OpenClaw 中需要让 Agent 承接效率相关任务时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

2,228

周安装

91

GitHub Stars

公开资料未说明

下载量

721
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:eb-dev-workflow(EB 开发工作流程)
来源仓库:https://github.com/emersonbraun/eb-dev-workflow
安装命令:
openclaw skills install eb-dev-workflow
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install eb-dev-workflow

简介

eb-dev-workflow 用于完整自主开发生命周期的流程协调管理。

  • 适合在 OpenClaw 中启动新功能或实现想法时的全流程引导。
  • 整合从需求到交付各阶段的任务分解与进度跟踪。
  • 安装命令为 openclaw skills install eb-dev-workflow,需确认任务执行权限。
  • 操作前应明确影响范围,避免误触生产环境变更。

SKILL.md

name
dev-workflow
description
>
metadata
author
EmersonBraun
version
1.1.0

Dev Workflow Orchestrator

Autonomous end-to-end lifecycle manager for Claude Code. Coordinates all phases from idea to merged PR. Delegates to your existing skills where they exist; owns the phases in between.

Skill Map

PhaseOwner
1 — PRDInvoke skill: write-a-prd
2 — Issues from PRDInvoke skill: prd-to-issues
3 — ArchitectureInvoke skill: software-architect
4 — QA PlanningThis skill
5 — DevelopmentInvoke skills: senior-frontend, senior-backend
6 — Automated TestingThis skill (npm test + Playwright)
7 — Code ReviewInvoke skill: code-review:code-review
8 — PR + Close + AdvanceThis skill

Workflow

IDEA
  |-- [Phase 1] invoke skill: write-a-prd
       |-- [Phase 2] invoke skill: prd-to-issues -> ordered issues
            |-- For each issue:
                 |-- [Phase 3] invoke skill: software-architect
                 |-- [Phase 4] QA Planning (before any code)
                 |-- [Phase 5] invoke skills: senior-frontend + senior-backend
                 |-- [Phase 6] npm test + Playwright + coverage check
                 |-- [Phase 7] invoke skill: code-review:code-review
                 |-- [Phase 8] PR created -> issue closed -> next issue

Session Start Protocol

At the start of every session, output this state block and ask the user to confirm:

DEV WORKFLOW STATE
 Feature PRD   : #[number] - [title]
 Current issue : #[number] - [title]
 Current phase : [1-8] - [phase name]
 Remaining     : #X, #Y, #Z

If starting fresh, ask: "Nova feature ou continuando uma issue existente?"


Phase 1 — PRD

Owner: your existing skill.

Invoke skill write-a-prd to create the PRD through user interview and codebase exploration. Wait for the PRD to be submitted as a GitHub issue before advancing.

Exit condition: PRD issue created on GitHub.


Phase 1.5 — Clarify

Trigger: PRD exists but contains ambiguities before issue breakdown begins.

If the PRD contains ambiguities, run a structured clarification pass: identify up to 5 critical unknowns, resolve each through targeted Q&A before proceeding to Phase 2.

  1. Scan the PRD for gaps: missing edge-case behaviour, undefined user roles, vague

success criteria, unstated constraints, or conflicting requirements.

  1. List each unknown as a numbered question (max 5). Prioritise questions that

affect scope, security, or core UX — skip cosmetic or low-stakes ambiguities.

  1. Ask all questions in a single message. Wait for answers before continuing.
  2. Update the PRD issue with the resolved answers and mark the clarification pass

complete as a comment.

Skip this phase when the PRD is unambiguous or the user explicitly says to proceed.

Exit condition: All critical unknowns resolved and documented on the PRD issue.


Phase 2 — Issues from PRD

Owner: your existing skill.

Invoke skill prd-to-issues to break the PRD into independently-grabbable GitHub issues using tracer-bullet vertical slices. The skill handles ordering, dependencies, and scoping.

Wait for all issues to be created and confirmed by the user before advancing.

Exit condition: All issues created on GitHub, order confirmed by user.


Phase 3 — Architecture

Owner: software-architect skill.

Invoke skill software-architect to design the system structure for this issue/feature. For the first issue in a new feature, this produces the full architecture. For subsequent issues, review and update the existing architecture if the new issue changes boundaries.

Skip this phase for small issues that don't affect system structure (bug fixes, copy changes, minor UI tweaks).

Exit condition: Architecture document exists and is appropriate for the issue scope.


Phase 4 — QA Planning

Trigger: Architecture exists (or skipped) for this issue. Rule: This runs BEFORE any code is written.

Generate and post as a GitHub comment on the issue:

## Test Plan - #[issue-number]

### Unit Tests
- [ ] [unit] should [behavior] when [condition]

### Integration Tests
- [ ] [flow] should [result] given [state]

### Edge Cases
- [ ] Null / empty inputs
- [ ] Boundary values
- [ ] Concurrent operations (if applicable)
- [ ] Network / auth failures (if applicable)

### E2E Scenarios (Playwright)
- [ ] Happy path: [user does X -> sees Y]
- [ ] Error path: [user does X -> sees error Z]

### Regression Scope
- Features this change touches: [list files/components]

Exit condition: Test plan posted as issue comment. Do not write code before this exists.


Phase 5 — Development

Trigger: QA plan exists on the issue.

Invoke skills senior-frontend and/or senior-backend as appropriate for the implementation. Use senior-frontend for UI components, pages, and client-side logic. Use senior-backend for API routes, database schemas, and server-side logic.

Claude Code implements autonomously following these rules:

  • Never commit directly to main
  • Branch name: feat/#[issue-number]-short-description
  • Commit format: feat: [description] (#[issue-number])
  • No TODOs left in code
  • Implement against ACs — keep the test plan visible while coding

Exit condition: Implementation complete, all files saved, ready for testing.


Phase 6 — Automated Testing

Trigger: Implementation complete.

5a — Unit & Integration

Always use npm to run tests, regardless of what package manager the project uses:

npm test -- --coverage

Gate: coverage >= 80%. If below, return to Phase 5 with coverage report.

5b — E2E via Playwright Agents (three-agent flow)

  1. Planner — converts QA plan E2E scenarios into navigation flows
  2. Generator — writes Playwright tests, validates selectors against running app
  3. Healer — if a test fails, replays, diagnoses, and patches automatically

5c — Regression

Run smoke tests on every feature listed in "Regression Scope" from the QA plan.

Test Report (post as issue comment)

## Test Results - #[issue-number]
- Unit/Integration : X passing | X failing
- Coverage         : X% (gate: 80%)
- E2E              : X passing | X failing
- Regressions      : None | [list]

Exit condition: All green, coverage >= 80%, zero regressions. On failure, return to Phase 5 with the report attached.


Phase 7 — Code Review

Owner: your existing Code Review skill.

Invoke skill code-review:code-review directly. Pass it the branch/diff context. Wait for verdict before advancing.

  • Approved -> advance to Phase 8
  • Changes requested -> return to Phase 5 with review comments

Exit condition: Code Review skill returns Approved.


Phase 8 — PR + Close + Advance

Trigger: Code review approved.

7a — Create PR

## What
[One paragraph describing the change]

## Why
Closes #[issue-number]
Part of #[parent-PRD-number]

## Checklist
- [x] Unit/Integration tests passing
- [x] E2E tests passing
- [x] Coverage >= 80%
- [x] No regressions detected
- [x] Code review approved

7b — After merge

  • Close issue with comment: Resolved via #[PR-number]
  • Check off the corresponding item on the parent PRD issue

7c — Advance

  • Issues remaining -> update state block -> return to Phase 3 (or Phase 4 if architecture unchanged) for next issue
  • All issues done -> close parent PRD issue with summary -> workflow complete

Exit condition: PR merged, issue closed, next phase identified.


Reference Templates

This skill has detailed reference templates. Consult references/spec-templates.md for structured templates for specs, plans, tasks, and checklists.

TemplatePurposeWhen to use
Feature SpecificationFull spec with scenarios, FRs, entities, success criteriaPhase 1 PRD creation
Implementation PlanPhased plan with research, gates, MVP cut linePhase 2 issue breakdown
Task BreakdownT-NNN task list with parallel markers and user story linksPhase 2 / Phase 4 prep
Requirements ChecklistCHK-NNN quality gates for spec approvalBefore Phase 2 begins
Constitution (optional)Project-level architectural principlesPhase 0 for greenfield projects

Quality Gates

GateRequirementOn failure
QA Plan existsBefore Phase 5 startsBlock — do not proceed
Unit coverage>= 80%Return to Phase 5
E2E testsAll passingReturn to Phase 5
RegressionsZero detectedReturn to Phase 5
Code ReviewApprovedReturn to Phase 5

Never skip a gate. If the user requests skipping, state the risk clearly and require explicit confirmation before proceeding.

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

70.61%
按下载量换算509

安全审计

VirusTotal

可疑

ClawScan

可疑

Static analysis

通过

权限和风险

操作浏览器

该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills