Przejdź do treści
Biblioteka skilli
Zarządzanie i produkt · Automatyzacja

close

/close

Zamyka gotowe zadania, uruchamia agentów zamykających dla każdego repozytorium i scala dopiero po zgodzie lidera.

Licencja
MIT
Ostatnia zmiana repozytorium
04.11.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 04.11.2026, bez odwołań do wycofanych modeli i API.

Licencja

MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.

Co robi i kiedy

Zamyka gotowe zadania, uruchamia agentów zamykających dla każdego repozytorium i scala dopiero po zgodzie lidera.

Argumenty

/close <task…>
Oryginalny opis (EN)

Closes tasks that are ready_to_close. Dispatches one close-agent per repo in parallel (a hub task is closed by the skill itself), shows the results, merges only on the lead's yes, then records the merge in the wave log and the status block. Use for /lead-flow:close, or when a task session reports ready to close.

Jak działa

  1. 1. Check
  2. 2. Dispatch
  3. 3. Show, then wait
  4. 4. Merge and record
  5. A hub task
Sekcje z nagłówków SKILL.md, w oryginale · 120 linii, 1 171 słów
Podgląd SKILL.md
---
name: close
description: Closes tasks that are ready_to_close. Dispatches one close-agent per repo in parallel (a hub task is closed by the skill itself), shows the results, merges only on the lead's yes, then records the merge in the wave log and the status block. Use for /lead-flow:close, or when a task session reports ready to close.
argument-hint: <task…>
---

# Close

## 1. Check

For each task named (or every task in `ready_to_close`): its status block says `ready_to_close`,
its notes file exists with a `Reviewed sha:` line, and its `task-reviewer` and language reviewer findings are fixed. If not, say what is missing
and skip that task.

Before any command, check the task branch and the wave branch as `close-agent` does: each must
match `^[A-Za-z0-9._/-]+$` and not start with `-` (double quotes do not stop `$(`, `${` or a
backtick). If either fails, report `fail: unsafe branch name` and skip that task.

## 2. Dispatch

A `repo: hub` task gets no `close-agent`: close it as in A hub task below.

One `close-agent` per repo, all in the same message, so they run in parallel. Give each exactly
its inputs: the hub's absolute path, the task id, the wave, the repo id, the task branch, its
reviewed sha (the notes file's `Reviewed sha:`) and the wave branch. The agent reads the rest from
`lead-flow.json` itself. Model: Sonnet, low effort; Opus, high effort for a repo with money or
auth code.

Without subagents (terminal), run the `close-agent` steps yourself, one repo at a time.

## 3. Show, then wait

Show each agent's result: shas, gate on the base and on the merge, new failures (none passes),
merged tree equal to the reviewed tree, the close note. Then ask the lead to approve each merge.
**Never merge without the lead's yes.**

## 4. Merge and record

On the lead's yes, per repo:

1. Merge in a worktree of the wave branch, never in the repo's own checkout (never switch a
   checkout another session uses). If `<repo>/.worktrees/wave-<wave>` already exists, stop and
   report it. Add it with `git -C "<repo>" worktree add "<repo>/.worktrees/wave-<wave>" "<wave branch>"`;
   git refuses when another checkout has the wave branch: stop and report it. Then
   `git -C "<repo>/.worktrees/wave-<wave>" rev-parse HEAD` must equal the close note's
   `Base (wave) sha:`; if not, the wave moved after the trial, so the merged tree was never gated:
   remove the worktree (below) and dispatch `close-agent` for that task again. Write the merge
   message close-agent returned, unchanged, with the Write tool to
   `<hub>/.worktrees/close-<task id>.msg` (close-agent's `<msg file>`). Run the `git.merge`
   style's commands from `close-agent`'s step 2 with `git -C "<repo>/.worktrees/wave-<wave>"` in
   place of `git -C "<close worktree>"`. A command exiting non-zero: for `rebase`, first
   `git -C "<repo>/.worktrees/wave-<wave>" cherry-pick --abort`, which puts the wave branch back;
   report git's message and the paths from
   `git -C "<repo>/.worktrees/wave-<wave>" diff --name-only --diff-filter=U`, then
   `git -C "<repo>" worktree remove --force "<repo>/.worktrees/wave-<wave>"`, and stop. After the
   merge, `git -C "<repo>" worktree remove "<repo>/.worktrees/wave-<wave>"`.
2. Append under the wave log's `## Close`: the merged sha, the gate results, and one deploy note
   per migration, new setting or other deploy step, each on its own line, exactly
   `Deploy: <task id> · migration|setting|note · <text>` (the board's Deploy tab reads these lines).
3. Set the task's `state: merged` with the Edit tool (this fires `/lead-flow:progress`).
4. Commit in the hub: `docs(waves): close <task id>`.

Never push, and never open a merge request, without the lead's separate yes. Then redraw the
board with `/lead-flow:board`.

## A hub task

A task with `repo: hub` changed the hub itself, so this skill closes it in the hub, with no
close-agent:

1. **The hub branch** is the branch the hub's own checkout is on:
   `git -C "<hub>" symbolic-ref --short HEAD`, run in `<hub>`. A detached hub checkout has no hub
   branch: tell the lead and stop. The hub branch passes the same name check as the task branch
   (1. Check); if not, report `fail: unsafe branch name` and stop.
2. **The sha:** `git -C "<hub>" rev-parse "<task branch>"` must equal the notes file's
   `Reviewed sha:`, and `git -C "<hub>/.worktrees/<id>" status --porcelain` must be empty. If
   not, the branch moved after review or the worktree holds unreviewed edits: stop and report it.
   `git -C "<hub>" diff --cached --quiet` must pass too: staged changes in `<hub>` (another
   session mid-commit) refuse the merge. If not, stop and report it.
3. **The gate, on a trial merge,** run by you. The task tip alone proves nothing once the hub
   branch moved, so record its tip as `<base sha>` (`git -C "<hub>" rev-parse "<hub branch>"`) and
   merge in a detached close worktree, which moves no branch. First write the merge message,
   `Merge <task branch>: <one-line summary>` (never with the word "into"), with the Write tool to
   `<hub>/.worktrees/close-<id>.msg` (git-ignored, as close-agent's `<msg file>` is). It is passed
   only as that file, never with `-m`: the branch-name check (1. Check) covers the refs, not the
   summary, so a summary holding `$(`, a backtick or a quote must never reach the shell:

   ```bash
   git -C "<hub>" worktree add --detach "<hub>/.worktrees/close-<id>" "<base sha>"
   git -C "<hub>/.worktrees/close-<id>" merge --no-ff -F "<hub>/.worktrees/close-<id>.msg" "<task branch>"
   python3 "${CLAUDE_PLUGIN_ROOT}/lib/leadflow/cli.py" callmap-check "<hub>" --tree "<hub>/.worktrees/close-<id>"
   python3 "${CLAUDE_PLUGIN_ROOT}/lib/leadflow/cli.py" check-examples "<hub>" "<doc>" --tree "<hub>/.worktrees/close-<id>"
   ```

   A trial conflict: `git -C "<hub>/.worktrees/close-<id>" merge --abort`, stop and report the
   paths. `callmap-check` runs unless
   `python3 "${CLAUDE_PLUGIN_ROOT}/lib/leadflow/cli.py" shape "<hub>"` prints `call-map: off`;
   then record `call map is off (L-063): skipped` in its place. It runs on `call-map: on`, and a
   missing `call-map:` line reads `on` (K7); a non-zero `shape` fails the gate. With it on, check
   the close worktree's `callmap/groups.json` first: a missing file records
   `not run (no groups.json yet)`; any other exit 2 fails the gate. `check-examples` runs
   once per doc the task branch changed, deleted docs left out
   (`git -C "<hub>" diff --name-only --diff-filter=d "<hub branch>...<task branch>" -- docs/`, and
   not `docs/changes/`). It passes when each check that ran passed: `callmap-check` printed a
   line starting `OK:`, and every `check-examples` run exited 0. With neither check run, the
   trial merge still runs (it finds conflicts) and the gate records
   `gate: not run (call map off, no doc changed)`, or
   `gate: not run (no groups.json yet, no doc changed)`. A failing gate: stop and report its
   output; do not ask to merge.
   On every exit, pass or fail, remove the worktree:
   `git -C "<hub>" worktree remove --force "<hub>/.worktrees/close-<id>"`.
4. **Show, then wait:** show `git -C "<hub>" diff --stat "<hub branch>...<task branch>"` and the
   gate's output, then ask the lead to approve the merge. **Never merge without the lead's yes.**
5. **Merge and record,** on the lead's yes, in `<hub>` on the hub branch. First
   `git -C "<hub>" diff --quiet "<base sha>" "<hub branch>" -- callmap/ docs/` and step 2's
   `diff --cached --quiet` must pass; if the first fails, the hub branch's `callmap/` or `docs/`
   moved since the trial: run step 3 again. Then
   `git -C "<hub>" merge --no-ff -F "<hub>/.worktrees/close-<id>.msg" "<task branch>"`
   (step 3's message file: `Merge <task branch>: <summary>`, never with the word "into"). A conflict
   (`git -C "<hub>" rev-parse -q --verify MERGE_HEAD` succeeds): `git -C "<hub>" merge --abort`,
   stop and report the paths. A merge git refused (no `MERGE_HEAD`, such as uncommitted edits on
   a merged path): stop and report git's message. Then 4. Merge and record, steps 2–4: the
   `## Close` entry with the merged sha and the trial gate's results, `state: merged`, and the
   commit `docs(waves): close <task id>`.

Wersje

RepozytoriumWynikLicencja
Ta strona · M-reza-kd/lead-flow-plugin100MIT
digital-stoic-org/agent-skills100MIT
minanyang/10x-agent100MIT
wrg32786/aigent-os100MIT
juanpa1601/stepwise100MIT
apideck-libraries/api-skills100Apache-2.0
snapsynapse/skill-provenance100MIT
dedujeong/gemba90Apache-2.0
foxrun-ai/foxrun90MIT

Migawka bazy z 13.11.2026 · wersja paczki b4c446ddd9fa (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100decision-log
    Zapisuje, zastępuje i kwestionuje decyzje lidera w dzienniku decyzji hubu, gdy wykraczają poza jedno zadanie.
  • 90design-session
    Zamienia wymaganie lidera w zatwierdzone decyzje i notatkę projektową w hubie, zanim zaplanowana zostanie fala prac.
  • 90close-done
    Przygotowuje zbiorcze zamknięcie rozwiązanych lub nieaktualnych pozycji w trackerze, ale sam ich nie zamyka.
  • 100task-close
    Zamyka w całości ukończone zadanie: weryfikuje warunki ukończenia ze specyfikacji, ustawia końcowy stan TASK_STATE.md i przenosi folder z active do archive.
  • 86close-task
    Zamyka ważne zadanie: aktualizuje plik stanu, dopisuje decyzje i zapisuje wnioski w skarbcu.
  • 100flow-next
    Zarządza zadaniami i specyfikacjami w .flow/: pokazuje i listuje zadania, ich status, co jest gotowe oraz szczegóły fn-N.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.