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.