agentleFS
websublimewebsublime/mister-anderson/skills/workflow/SKILL.md

workflow

Skill3 starsChanged 7 months agoMITView on GitHub

Meta-orchestrator — shows project state across all 3 stages, suggests next step, and routes to stage orchestrators or individual skills.

71 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use build-keil, can-debug and 10 more.

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.
  • ZhongYechengSkill

    build-keil

    当需要通过 Keil MDK 命令行编译嵌入式工程,调用自带脚本解析工程文件、执行构建并定位固件产物时使用。

    Also in 3 projects that use this

  • ZhongYechengSkill

    can-debug

    当需要调试 CAN 总线通信时使用,支持通过 USB-CAN 适配器监听、发送 CAN 帧和扫描节点。

    Also in 3 projects that use this

  • iPlug2Skill

    build-cmake

    Build an iPlug2 plugin project using CMake with Ninja, Xcode, or Visual Studio generators

    Also in 3 projects that use this

  • +9 more from ZhongYecheng

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 7 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 55 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the user provides $ARGUMENTS, parse them for:

    line 14
  2. Very specific:

    If no PRD → suggest /product or /requirements

    line 71
  3. Very specific:

    If PRD but no Architecture → suggest /product or /architecture

    line 72
  4. Very specific:

    If Architecture APPROVED but no Plan for current phase → suggest /specification {NN} or /plan

    line 73
  5. Very specific:

    If Plan but no Research → suggest /specification {NN} or /research

    line 74
  6. Very specific:

    If Research but no Spec → suggest /specification {NN} or /spec

    line 75
  7. Very specific:

    If Spec but no Beads → suggest /specification {NN} or /tasks

    line 76
  8. Very specific:

    If Beads exist → suggest /implementation {NN} or /investigate with ready tasks

    line 77
  9. Distinctive:

    When suggesting, present both the orchestrator (guided flow) and the direct skill (quick jump):

    line 79
  10. Distinctive:

    When the user provides a stage name, delegate to the corresponding orchestrator:

    line 88
  11. Distinctive:

    When the user provides a specific skill name, check prerequisites before dispatching.

    line 96
  12. Distinctive:

    If prerequisites are unmet, warn but do not block:

    line 113
  13. Very specific:

    If user confirms → dispatch: Skill(skill="{skill-name}") </on-step>

    line 128
  14. Distinctive:

    Always end by showing what comes next — either the next step or phase completion status.

    line 136
  15. Distinctive:

    Do NOT dispatch agents directly — always go through the corresponding skill or orchestrator so prerequisites are checked.

    line 138

“Common” is measured: kept by at least 6 in 10 of the 55 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

Interactive pipeline guide. Shows current project state, suggests the next step, and routes to the correct stage orchestrator or skill.


<on-init> If the user provides $ARGUMENTS, parse them for: - A stage name (`product`, `specification`, `implementation`) → delegate to the stage orchestrator - `next` → advance to the next pending step - A skill name (e.g., `spec`, `research`) → jump directly to that step with prerequisite warnings - `status` → show full state only, no action </on-init><on-state> Scan the filesystem to determine project state across all stages.

Artifact Detection

ArtifactDetection Pattern
Manifestodocs/MANIFESTO.md
PRDdocs/PRD.md or docs/prd/*.md — check for Status: APPROVED
Architecturedocs/*architecture*.md or docs/ARCHITECTURE.md — check for Status: APPROVED
Plandocs/plans/NN-plan-*.md — check for Status: APPROVED
Researchdocs/research/NN-research-*.md — match NN to phase number
Specdocs/specs/NN-spec-*.md — check for Status: APPROVED
Beadsbd list --status=open --json 2>/dev/null — check for epic matching the phase

Phase grouping: Files sharing the same NN prefix belong to the same phase.

Display Format

Stage 1 — Product Discovery              → /product
  {check} Manifesto     {path or "not found"}
  {check} PRD           {path} ({status})
  {check} Architecture  {path} ({status})

Stage 2 — Specification                   → /specification {NN}
  Phase {NN} ({name from plan title}):
    {check} Plan        {path} ({status})
    {check} Research    {count} doc(s) in docs/research/{NN}-*
    {check} Spec        {path} ({status})
    {check} Beads       {epic_id} ({completed}/{total} complete)

Stage 3 — Implementation                  → /implementation {NN}
  Phase {NN}:
    {progress} {completed}/{total} tasks complete
    Ready:       {list of ready task IDs}
    In progress: {list of in-progress task IDs}
    Blocked:     {count}

Where {check} is:

  • [done] — artifact exists and is APPROVED/complete
  • [exists] — artifact exists but not yet APPROVED
  • [missing] — not found
  • [warning] — missing but a later step was already done (skipped step)</on-state>
<on-step name="next"> Determine the next pending step by finding the first incomplete step in order:
  1. If no PRD → suggest /product or /requirements
  2. If PRD but no Architecture → suggest /product or /architecture
  3. If Architecture APPROVED but no Plan for current phase → suggest /specification {NN} or /plan
  4. If Plan but no Research → suggest /specification {NN} or /research
  5. If Research but no Spec → suggest /specification {NN} or /spec
  6. If Spec but no Beads → suggest /specification {NN} or /tasks
  7. If Beads exist → suggest /implementation {NN} or /investigate with ready tasks

When suggesting, present both the orchestrator (guided flow) and the direct skill (quick jump):

Next step: Research (Phase 01)
  Guided:  /specification 01  — walks through remaining steps
  Direct:  /research          — jump straight to research
</on-step><on-step name="stage_jump"> When the user provides a stage name, delegate to the corresponding orchestrator:
  • product → Skill(skill="product")
  • specification → Skill(skill="specification") — ask for phase number if not provided
  • implementation → Skill(skill="implementation") — ask for phase number if not provided</on-step>
<on-step name="skill_jump"> When the user provides a specific skill name, check prerequisites before dispatching.

Prerequisite map:

SkillRequires
requirements—
architecturePRD APPROVED
planPRD APPROVED + Architecture APPROVED
researchPlan APPROVED
specPlan APPROVED + Research (warn if missing)
tasksSpec APPROVED
investigateBeads exist
doBeads exist
reviewBead with needs-review label
qualityBead with approved label

If prerequisites are unmet, warn but do not block:

Warning: You are about to run /spec but the following prerequisites are missing:
  - Research: no docs found in docs/research/{NN}-*

Without validated research, the spec will be based on unvalidated assumptions
from the plan. This historically causes task drift during implementation.

Do you want to:
  1. Run /research first (recommended)
  2. Proceed to /spec anyway
  3. Cancel

If user confirms → dispatch: Skill(skill="{skill-name}") </on-step>

<on-complete> Show full project state and identify the next action. </on-complete><on-next> Always end by showing what comes next — either the next step or phase completion status.

Do NOT dispatch agents directly — always go through the corresponding skill or orchestrator so prerequisites are checked. </on-next>

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.