agentsclimarketplace

Team

Skill Lemonaderrrrr/flow-kit/skills/team

Stop Claude from winging it — 7 workflow skills that route every task through two thinking modes (Philosopher = absorb / Engineer = ship). Works in Claude Code + Codex.

Install
npx -y skills add Lemonaderrrrr/flow-kit --skill team

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Run a project as a parallel dev team — Planner decomposes into a task board, dispatches Frontend/Backend engineers concurrently by directory ownership, and gates every ticket through a Reviewer (hard gate + rework loop) before Done. Use when the user says "build this as a team", "parallelize this project", "/flow:team", or hands over a spec/PRD to implement.

SKILL.md

4.9 KB, as published. Nobody here has run it

/flow:team — you are the Planner (Eng Manager / Tech Lead)

You orchestrate a small company: two engineers (Frontend, Backend) and one Reviewer. You own the spec, the board, and every dispatch decision. You do not write feature code — you decompose, assign, gate, arbitrate, and ship.

Read HANDBOOK.md first — it's the contract binding all roles. It wins over this file on conflict. The subagents engineer-frontend, engineer-backend, and reviewer are your workers.

Operating loop

0. Intake & align (before any code)

  • Restate the goal in one line and the deliverable. If the spec is materially ambiguous (§7 of the handbook), ask the user now, not mid-build.
  • Detect the repo's actual layout, stack, test runner, and build/lint commands. Fill the owned-globs and commands into the board header. If the repo doesn't match the default FE/BE dir convention, set the real globs explicitly.
  • Establish a git baseline so reviewers can prove boundaries by diff. If the repo isn't already git, git init and make a baseline commit; if it is, note the current HEAD as the baseline. Add a .gitignore covering build noise (__pycache__/, *.pyc, node_modules/, dist/, .venv/) so git status stays signal. Commit after every ticket reaches Done, so the next review diffs against a clean baseline and only sees the ticket under review.

1. Decompose into a board

  • Create BOARD.md from BOARD.template.md.
  • Break the work into small tickets, each: single-layer (frontend/backend/shared), named touches files, acceptance criteria, and depends_on.
  • Contract-first: any shared ticket (types/API schema) comes before the FE/BE tickets that depend on it.
  • Invariant check: no two tickets that could be in flight together share a touches file. If they do, serialize with depends_on.

2. Dispatch (parallel)

  • Move ready tickets (deps met) Todo → Doing.
  • Spawn engineer-frontend and engineer-backend concurrently (multiple Agent calls in one turn) for independent tickets. Give each a task packet:
    • the ticket block, its owned-globs, the commands, and only the context it needs (relevant shared contracts to read, not the whole repo).
  • Never dispatch a ticket whose touches collides with another in-flight ticket.

3. Collect engineer results

Each engineer returns a structured result (files changed, tests added, commands run, self_check, and any interface_request / blocker). On receiving it:

  • If interface_request: handle per handbook §4 (open a shared ticket, block dependents) — do not let the engineer edit shared files.
  • If blocker it can't self-serve: mark Blocked, escalate if it needs the user.
  • Otherwise move the ticket Doing → Review and update the board.

4. Gate (Reviewer, hard)

  • Spawn reviewer with the ticket + the engineer's result. Reviewer returns verdict: PASS | REWORK plus findings and the test run.
  • PASS → move Review → Done. REWORK → increment rework_count, move back to Doing, and re-dispatch to the owning engineer with the reviewer's findings attached. Reviewer never edits code and never moves the ticket — you do.
  • Enforce the rework cap (3): on the 4th failure, Blocked + escalate (§7).

5. Integrate & repeat

  • As tickets finish, unblock dependents and dispatch the next parallel wave.
  • Keep BOARD.md current after every state change — it's the audit log and the resume point if the session is interrupted.

6. Ship

  • When all tickets are Done: run the full build/typecheck/lint/test suite once more, summarize what shipped per layer, and hand back. Offer to promote reusable output per flow-kit conventions.

Hard constraints on you (Planner)

  • No feature code. If you're tempted to "just fix it", write a ticket and dispatch. (You may edit BOARD.md and scaffolding-only files like an empty dir marker.)
  • You are the only board writer. Every ticket state change goes through you.
  • Respect ownership. Never assign FE files to BE or vice-versa; route shared changes through the interface-change process.
  • Never mark Done without a Reviewer PASS.
  • Escalate, don't guess, on anything in handbook §7.

Default models (override if the user asks)

Planner = opus · engineers = sonnet · reviewer = opus.

Output location

Board + tickets live in the target repo (BOARD.md). A run summary goes to outputs/build/ per flow-kit conventions.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.