agentleFS
Sign inStart free
YIMO691YIMO691/claude-skills-kit/.claude/skills/engineer-coder-orchestrator/SKILL.md

engineer-coder-orchestrator

Skill0 starsChanged 6 months agoMITView on GitHub

编排 engineer 到 coder 的协作流程。Use when a task is complex enough to benefit from separate design and implementation phases, when the user asks for engineer/coder collaboration, or when Codex should first produce an implementation brief and then execute it.

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 12 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run an engineer pass:

    line 15
  2. Distinctive:

    write a coder-ready implementation brief

    line 19
  3. Distinctive:

    Run a coder pass:

    line 20
  4. Distinctive:

    add or update tests when behavior changes

    line 23
  5. Distinctive:

    verify with the narrowest meaningful commands

    line 24
  6. Distinctive:

    update docs only if the workflow or public behavior changed

    line 28
  7. Distinctive:

    If the user asks for a plan only, stop after the engineer brief.

    line 32
  8. Distinctive:

    If the user asks to implement or fix, create the brief internally and continue into coder execution.

    line 33
  9. Distinctive:

    If the environment supports explicit subagents, pass the handoff template to coder.

    line 34
  10. Distinctive:

    Do not split tiny tasks; direct implementation is cheaper.

    line 54
  11. Distinctive:

    Do not let coder invent new architecture when the brief is incomplete.

    line 55
  12. Distinctive:

    If implementation reveals a design flaw, pause and revise the brief before continuing.

    line 56

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Engineer Coder Orchestrator

Purpose

Use engineer for design clarity, then coder for scoped implementation. Keep the handoff explicit so decisions do not disappear between phases. If the user asks you to execute the task, continue from the brief into implementation in the same turn; do not require the user to copy the brief manually.

Workflow

  1. Define the user goal and acceptance checks.
  2. Run an engineer pass:
    • inspect current project context
    • identify constraints and risks
    • choose the smallest viable design
    • write a coder-ready implementation brief
  3. Run a coder pass:
    • follow the brief
    • make scoped changes
    • add or update tests when behavior changes
    • verify with the narrowest meaningful commands
  4. Integrate:
    • compare implementation against acceptance checks
    • note any engineer assumptions that changed
    • update docs only if the workflow or public behavior changed

Execution Mode

  • If the user asks for a plan only, stop after the engineer brief.
  • If the user asks to implement or fix, create the brief internally and continue into coder execution.
  • If the environment supports explicit subagents, pass the handoff template to coder. Otherwise, keep the brief in working context and implement directly.

Handoff Template

## Goal

## Acceptance Checks

## Files / Areas To Inspect

## Implementation Tasks

## Constraints

## Verification

Rules

  • Do not split tiny tasks; direct implementation is cheaper.
  • Do not let coder invent new architecture when the brief is incomplete.
  • If implementation reveals a design flaw, pause and revise the brief before continuing.

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.

Check your setup, free