agentleFS
vxcozyvxcozy/workflow-orchestration/SKILL.md

workflow-orchestration

Skill115 starsChanged 7 months agoMITView on GitHub

Disciplined task execution with planning, verification, and self-improvement loops. Use when starting non-trivial tasks (3+ steps), fixing bugs, building features, refactoring code, or when rigorous execution with quality gates is needed. Includes subagent delegation, lessons tracking, and staff-engineer-level verification.

11 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use ui-ux-pro-max.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • StrayDragonSkill

    ui-ux-pro-max

    UI/UX design intelligence. 50 styles, 21 palettes, 50 font pairings, 20 charts, 8 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. 0 are common, 16 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 16

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    If something goes sideways, STOP and re-plan immediately

    line 31
  2. Distinctive:

    Use plan mode for verification steps, not just building

    line 32
  3. Distinctive:

    Write detailed specs upfront to reduce ambiguity

    line 33
  4. Distinctive:

    Keep the main context window clean:

    line 37
  5. Distinctive:

    After ANY correction from the user:

    line 54
  6. Very specific:

    Update tasks/lessons.md with the pattern

    line 56
  7. Distinctive:

    Write rules that prevent the same mistake

    line 57
  8. Distinctive:

    Never mark a task complete without proving it works

    line 72
  9. Distinctive:

    Ask yourself: "Would a staff engineer approve this?"

    line 74
  10. Distinctive:

    Run tests, check logs, demonstrate corrections

    line 75
  11. Distinctive:

    If verification fails → return to the plan step and revise before retrying

    line 76
  12. Distinctive:

    If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"

    line 81
  13. Distinctive:

    When given a bug report: Just fix it.

    line 86
  14. Very specific:

    Plan First: Write plan to tasks/todo.md with checkable items

    line 92
  15. Distinctive:

    Verify Plan: Check in before starting implementation

    line 93
  16. Distinctive:

    Verify Results: Run tests and confirm behavior before marking done

    line 96
  17. Distinctive:

    Handle Failures: If verification fails → re-plan (step 1), don't push through

    line 97
  18. Very specific:

    Document Results: Add review to tasks/todo.md

    line 98
  19. Very specific:

    Capture Lessons: Update tasks/lessons.md after corrections

    line 99
  20. Distinctive:

    Minimal Impact: Only touch what's necessary.

    line 116

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Workflow Orchestration

Apply these practices for disciplined, high-quality task execution.

Quick Reference

PracticeWhen to Apply
Plan ModeAny task with 3+ steps or architectural decisions
SubagentsResearch, exploration, parallel analysis
LessonsAfter ANY user correction
VerificationBefore marking any task complete
Elegance CheckNon-trivial changes only

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
  • Use plan mode for verification steps, not just building
  • Write detailed specs upfront to reduce ambiguity

2. Subagent Strategy

Keep the 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

Template:

Agent({
  description: "Search auth patterns",
  prompt: "Find all authentication middleware in src/ and list file paths with a one-line summary of each."
})

3. Self-Improvement Loop

After ANY correction from the user:

  1. Update tasks/lessons.md with the pattern
  2. Write rules that prevent the same mistake
  3. Review lessons at session start

Inline example (full template in references/lessons-format.md):

## 2024-01-10 - Testing
**Mistake**: Mocks hid real API behavior; production broke
**Pattern**: Over-mocking created false confidence
**Rule**: Include at least one integration test hitting real services
**Applied**: All API endpoints, external service integrations

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 corrections
  • If verification fails → return to the plan step and revise before retrying

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

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

Task Management Protocol

  1. Plan First: Write plan to tasks/todo.md with checkable items
  2. Verify Plan: Check in before starting implementation
  3. Track Progress: Mark items complete as you go
  4. Explain Changes: High-level summary at each step
  5. Verify Results: Run tests and confirm behavior before marking done
  6. Handle Failures: If verification fails → re-plan (step 1), don't push through
  7. Document Results: Add review to tasks/todo.md
  8. Capture Lessons: Update tasks/lessons.md after corrections

Inline example (full templates in references/task-templates.md):

# Task: Fix memory leak in WebSocket handler
## Plan
- [ ] Reproduce the issue locally
- [ ] Identify leak source with profiler
- [ ] Implement fix
- [ ] Verification: Memory stable over 1000 connections

Core Principles

  • Simplicity First: Make every change as simple as possible
  • No Laziness: Find root causes. No temporary fixes. Senior developer standards
  • Minimal Impact: Only touch what's necessary. Avoid introducing bugs

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.