Workflow 作者 brianlovin 1a9819ebf3fe 无许可证 376 个星标 收录于 2026年10月8日 更新于 2026年10月8日 仓库6个月前更新
Workflow orchestration for complex coding tasks. Use for ANY non-trivial task (3+ steps or architectural decisions) to enforce planning, subagent strategy, self-improvement, verification, elegance, and autonomous bug fixing. Triggers: multi-step implementation, bug fixes, refactoring, architectural changes, or any task requiring structured execution.
版本 1a9819ebf3fe
许可证 无许可证
GitHub 星标 376
文件 1 添加到 SourceWeft 在你自己的智能体中使用
阅读 https://sourceweft.com/skills/gh-brianlovin-agent-config-workflow/install.md 中的说明,按说明安装这个技能。安装前先告诉我它的来源、许可证以及是否附带脚本,等我确认。修改我电脑上的其他任何内容之前也要先问我。
显示完整提示词 你是作者吗?认领此仓库
技能详情
Slug gh-brianlovin-agent-config-workflow
名称 workflow
作者 brianlovin
类型 仅含说明
信任级别 社区
收录时间 2026年10月8日
更新时间 2026年10月8日 通过规划、子代理、验证和经验记录来编排复杂编码任务。
功能 该技能为非平凡的软件任务定义了一套结构化工作流,涵盖计划模式、子代理委派、自我改进循环、完成前验证、平衡的优雅性检查以及自主修复缺陷。它还规定了任务管理步骤,将计划和进度写入 tasks/todo.md,将经验写入 tasks/lessons.md。它产出的是计划、进度记录、评审部分和经验条目,而不是代码产物。
适用场景 适用于多步骤实现、缺陷修复、重构、架构变更或任何需要结构化执行的任务。当任务包含三个或更多步骤或涉及架构决策时,均可使用。
运行要求 不需要脚本或工具,仅为指令。它要求代理能够创建和更新 tasks/todo.md 与 tasks/lessons.md 等文件。 Workflow Orchestration
1. Plan Mode Default
Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
If something goes sideways, STOP and re-plan immediately — don't keep pushing
Use plan mode for verification steps, not just building
Write detailed specs upfront to reduce ambiguity
2. Subagent Strategy
Use subagents liberally to keep main context window clean
Offload research, exploration, and parallel analysis to subagents
For complex problems, throw more compute at it via subagents
One task per subagent for focused execution
3. Self-Improvement Loop
After ANY correction from the user: update tasks/lessons.md with the pattern
Write rules for yourself that prevent the same mistake
Ruthlessly iterate on these lessons until mistake rate drops
Review lessons at session start for relevant project
4. Verification Before Done
Never mark a task complete without proving it works
Diff behavior between main and your changes when relevant
Ask yourself: "Would a staff engineer approve this?"
Run tests, check logs, demonstrate correctness
5. Demand Elegance (Balanced)
For non-trivial changes: pause and ask "is there a more elegant way?"
If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
Skip this for simple, obvious fixes — don't over-engineer
Challenge your own work before presenting it
6. Autonomous Bug Fixing
When given a bug report: just fix it. Don't ask for hand-holding
Point at logs, errors, failing tests — then resolve them
Zero context switching required from the user
Go fix failing CI tests without being told how
Task Management
Plan First : Write plan to tasks/todo.md with checkable items
Verify Plan : Check in before starting implementation
Track Progress : Mark items complete as you go
Explain Changes : High-level summary at each step
Document Results : Add review section to tasks/todo.md
Capture Lessons : Update tasks/lessons.md after corrections
Core Principles
Simplicity First : Make every change as simple as possible. Impact minimal code.
No Laziness : Find root causes. No temporary fixes. Senior developer standards.
Minimal Impact : Changes should only touch what's necessary. Avoid introducing bugs.