Przejdź do treści
Biblioteka skilli
Zarządzanie i produkt · Integracja z narzędziem

flow-next-tracker-sync

/flow-next-tracker-sync

Rzutuje specyfikację flow-next na zgłoszenie w trackerze (Linear, GitHub, GitLab, Jira) i uzgadnia zmiany w obu kierunkach.

Repozytorium
flow-next ↗
Licencja
MIT
Ostatnia zmiana repozytorium
25.10.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
17
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 25.10.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

Rzutuje specyfikację flow-next na zgłoszenie w trackerze (Linear, GitHub, GitLab, Jira) i uzgadnia zmiany w obu kierunkach.

Oryginalny opis (EN)

Project a flow-next spec to a tracker issue (Linear, GitHub, GitLab, Jira) and reconcile two-way. Use when asked to sync to a tracker. NOT plan-sync.

Jak działa

  1. Load the reached path
  2. Deterministic boundary
  3. Exactly five judgment surfaces
  4. Discovery ceremony
  5. Operating rules
  6. Boundaries
Sekcje z nagłówków SKILL.md, w oryginale · 126 linii, 869 słów
Podgląd SKILL.md
---
name: flow-next-tracker-sync
description: Project a flow-next spec to a tracker issue (Linear, GitHub, GitLab, Jira) and reconcile two-way. Use when asked to sync to a tracker. NOT plan-sync.
user-invocable: false
allowed-tools: Read, Bash, Grep, Glob, Write, Edit
---

# flow-next-tracker-sync

The flow spec is the source of truth and quality layer. The tracker is a
co-editable projection. Tracker activity never starts agents or changes Flow
task state.

Read [working-rules.md](../../references/working-rules.md) first unless you already have this run; it holds for every step of this skill.

## Load the reached path

Read [steps.md](steps.md) for the operation sequence and
[references/adapter-interface.md](references/adapter-interface.md) for the
normalized contract. Load only references needed by the reached path:

- Body comparison or conflict:
  [references/body-merge.md](references/body-merge.md).
- Status projection: [references/status-sync.md](references/status-sync.md).
- Comment or question-valve content:
  [references/comments-sync.md](references/comments-sync.md).
- Hybrid identifiers: [references/identity.md](references/identity.md).
- Linear transport shape: [references/linear-ladder.md](references/linear-ladder.md),
  then only the reached MCP or GraphQL reference.
- GitHub, GitLab, or Jira transport shape: the matching provider reference only.

Never load an unselected provider merely because another reference links it.

## Deterministic boundary

`flowctl tracker` owns tracker transport, normalization, credentials, retries,
capability degradation, lifecycle ordering, receipts, and atomic local state.
The skill supplies only approved semantic inputs and reacts to the structured
result. Do not reconstruct provider requests in skill prose or shell.

Use the lifecycle facade for event-driven projection:

```bash
FLOWCTL="${CODEX_HOME:-$HOME/.codex}/scripts/flowctl"
[ -x "$FLOWCTL" ] || FLOWCTL="<plugin-root>/scripts/flowctl"   # <plugin-root> = the directory two levels above this skill's SKILL.md file (the harness gave you that file's absolute path when the skill loaded); substitute it literally
[ -x "$FLOWCTL" ] || FLOWCTL=".flow/bin/flowctl"
$FLOWCTL tracker sync "$SPEC_ID" --op "$OP" --event "$EVENT" \
  --flow-file "$FLOW_FILE" --body-file "$BODY_FILE" \
  --comments-file "$COMMENTS_FILE" --source-body-file "$SOURCE_BODY_FILE"
```

Pass only flags legal for the selected operation. [steps.md](steps.md) lists
the file contract. For discovery, create-first, link, unlink, status, relation,
attachment, and direct wire maintenance, use the matching `flowctl tracker`
verb. `flowctl tracker --help` is the executable source of truth.

Every command returns one JSON object on stdout. Success has `success: true`,
`data`, `degraded`, and `probe`. Failure has `success: false`, `class`, `error`,
`retryable`, and typed `details`. Branch on `class`, never provider text.

## Exactly five judgment surfaces

These are the only five surfaces intentionally retained in the host agent:

1. **MCP rung.** MCP tools exist only in the host tool environment, so flowctl
   cannot invoke them. The agent may perform the explicitly requested Linear
   MCP action, then hands the returned identity to `tracker persist-external`.
2. **Discovery ceremony.** Choosing a tracker, project or team, and enabling
   lifecycle events is an ambiguous one-time product decision. The agent
   surfaces detected choices and asks before persisting configuration.
3. **Body-merge conflict adjudication.** A three-way body conflict is semantic
   because equivalent prose, intent, and requirement meaning cannot be resolved
   from hashes or syntax alone. The agent adjudicates only conflicting sections,
   while flowctl owns snapshots and atomic persistence.
4. **Comment content synthesis.** Lifecycle comments communicate human context.
   The caller decides what the comment should say and supplies a stable
   occurrence identity as the first file line, `evidence=<token>`. Flowctl
   rejects missing/placeholder evidence, strips that line from visible content,
   and owns marker dedup, transport, and the receipt.
5. **Recovery routing from a structured error.** A typed conflict,
   `external_action_required`, or non-retryable capability result can require a
   user choice, an MCP continuation, a local correction, or a defer. The agent
   selects that next action from the structured envelope instead of parsing
   error prose.

No other tracker operation is agentic. In particular, request construction,
pagination, provider field mapping, status policy, relation projection,
comment dedup, credential selection, retry timing, and receipt writes remain
deterministic.

## Discovery ceremony

The bridge is off until the user confirms it; [steps.md](steps.md) §1 is the procedure. Every
discovery surfaces the provider signals, the proposed project or team, and the lifecycle defaults.
Credentials remain in the environment. Never copy credentials into config, a prompt, argv,
receipt, or error note.

Linear MCP is discovery/create only. All later shell-reachable operations use
the deterministic GraphQL route. If an MCP create returns only a display key,
`tracker persist-external` resolves and stores its durable identity.

## Operating rules

- One Flow spec maps to one tracker issue. Tasks remain Flow-local.
- Tracker-first creation uses the hybrid identifier rules in `identity.md`.
  Never rename an existing Flow-first spec.
- Callers retain their bridge-active and `perEvent` gates. An inactive bridge
  remains silent because the lifecycle facade is not invoked.
- Event-driven callers use `tracker sync`, not granular tracker verbs.
- Comment text and merged body text travel through mode `0600` temporary files,
  never argv. Delete temporary files after the call.
- The facade writes one aggregate receipt. Do not add a second receipt.
- A pull or reconcile may update Flow prose, but never Flow task status.
- Dependency projection is additive and provenance-led. Never delete or
  recreate a user-controlled relation without evidence that Flow owns it.
- `inactive` is a silent no-op for lifecycle callers.
- `rate_limited` is retried only when the envelope says `retryable: true`.
- `auth`, `unresolved`, `stale_id`, `conflict`, `capability`, and
  `external_action_required` follow the recovery table in `steps.md`.
- In any unattended run (a stage `flow --auto` dispatched, any
  `mode:autonomous` caller) or a forked lifecycle call, queue a decision that
  needs a person with `flowctl sync defer`. Never attempt an interactive prompt
  there.

## Boundaries

This skill is projection, not coordination. `/flow-next:tracker-sync` is
distinct from `/flow-next:sync`. Flow state remains authoritative. Provider
wire details live in deterministic Python; the Markdown references document
their shapes so reviewers can inspect the contract without copying executable
transport recipes into prompts.
Pliki w paczce (17)
  • SKILL.md 7 KB
  • steps.md 11 KB
  • agents/openai.yaml 1 KB
  • references/adapter-interface.md 5 KB
  • references/backlog-ops.md 3 KB
  • references/body-merge.md 19 KB
  • references/chart-subjects.md 4 KB
  • references/comments-sync.md 20 KB
  • references/create-first.md 2 KB
  • references/github.md 2 KB
  • references/gitlab.md 2 KB
  • references/identity.md 7 KB
  • references/jira.md 4 KB
  • references/linear-graphql.md 2 KB
  • references/linear-ladder.md 2 KB
  • references/linear-mcp.md 1 KB
  • references/status-sync.md 28 KB

Wersje

RepozytoriumWynikLicencja
Ta strona · gmickel/flow-next100MIT
gmickel/flow-next100MIT

Identyczna treść występuje jeszcze w 1 innych folderach na GitHubie. Tu pokazujemy jedną, najlepiej ocenioną kopię.

Migawka bazy z 28.10.2026 · wersja paczki 21ee068ecf99 (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

  • 90marker-sync
    Synchronizuje Marker.io z trackerem zgłoszeń (GitHub, Linear, Jira): przenosi nowe zgłoszenia, wzbogaca tickety o kontekst i uzgadnia statusy w obu miejscach.
  • 95sync-work-items
    Uzgadnia lokalne zadania z trackerem Jira lub Linear, pokazuje, co zmieni synchronizacja, i rozwiązuje rozbieżności.
  • 90ticket-sync
    Wysyła zadania do systemu zgłoszeń zespołu, np. GitHub Issues, Jira lub Azure DevOps, i może je także pobrać z powrotem.
  • 100beads
    Obsługuje tracker zadań Beads (bd) oparty na Dolt: polecenia CLI, molekuły, synchronizację Dolt i integracje z Linear, Jira oraz GitLab.
  • 86enhance-story
    Ocenia historyjkę użytkownika w trackerze, np. GitLab lub Jira, i przepisuje ją na podstawie oceny.
  • 90dev10x:linear
    Obsługuje zgłoszenia w Linear przez narzędzia MCP: pobiera, tworzy i aktualizuje zgłoszenia, komentarze i statusy.

Uwagi i zgłoszenia

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