Przejdź do treści
Biblioteka skilli
AI i agenci · Automatyzacja

spec-workflow

/spec-workflow

Orkiestruje cykl życia OpenSpec w łańcuchu analityk, architekt, programista i recenzent oraz zmienia statusy specyfikacji.

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

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

Orkiestruje cykl życia OpenSpec w łańcuchu analityk, architekt, programista i recenzent oraz zmienia statusy specyfikacji.

Oryginalny opis (EN)

OpenSpec lifecycle orchestration for /workflow chains. TRIGGER when: coordinating the analyst-architect-developer-reviewer chain or managing spec status transitions. SKIP: writing an individual spec artifact (use spec-research, spec-design, or spec-review).

Jak działa

  1. UUID Enforcement
  2. Directory Structure
  3. Status Lifecycle
  4. Agent Routing in /workflow
  5. When Researcher Is Needed
  6. When to Create vs Skip Specs
  7. Orchestration Steps
  8. Context JSON Schema
  9. Schema Reference
Sekcje z nagłówków SKILL.md, w oryginale · 141 linii, 796 słów
Podgląd SKILL.md
---
name: spec-workflow
description: "OpenSpec lifecycle orchestration for /workflow chains. TRIGGER when: coordinating the analyst-architect-developer-reviewer chain or managing spec status transitions. SKIP: writing an individual spec artifact (use spec-research, spec-design, or spec-review)."
---

# OpenSpec Workflow Orchestration

Spec-driven development protocol for coordinating multi-agent workflows.

## UUID Enforcement

**CRITICAL**: The `conversation_id` MUST always be a UUID (format: `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`). NEVER use descriptive names, slugs, or human-readable strings. If no UUID is available, generate one with `uuidgen` or `python3 -c "import uuid; print(uuid.uuid4())"`. Self-check: does the conversation_id match the pattern `[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}`? If not, STOP and use a real UUID.

## Directory Structure

Canonical layout (identical on every machine and in every project):

```
<repo>/.scaffolding/
  conversations -> <share>/projects/<repo-name>/conversations   (symlink to the NFS share)
  worktrees/                      LOCAL real dir, never on NFS
  openspec/  workflows/           git-tracked
  agent-memory/  project-id  ...  local

<share>/projects/<repo-name>/conversations/{conversation_id}/
  context.json                    status + history (merged schema below)
  specs/
    proposal.md   -- WHY + WHAT (analyst)
    design.md     -- WHAT + HOW (architect)
    tasks.md      -- checklist (architect)
  agent-memory/context.md         conversation-tier memory
  attachments/{attId}/{name}      + {attId}.json
  tasks/{taskId}/                 meta.json, output.md, output.jsonl, summary.json, state.json
```

Always read and write through `.scaffolding/conversations/...` (the symlink);
never hardcode the share path. `<share>` differs per machine
(`/mnt/scaffolding-data` or `/mnt/scaffolding`). `nfs-sync.sh` creates the link
at SessionStart or via `nfs-sync.sh link <dir>`; `<share>/platform/conversations`
holds notes only and is never a link target.

## Status Lifecycle

Tracked in `status` of `.scaffolding/conversations/{conversation_id}/context.json`:

| Status | Meaning | Transition |
|--------|---------|------------|
| `exploring` | Research phase | -> `drafting` when proposal done |
| `drafting` | Design + tasks | -> `implementing` when tasks done |
| `implementing` | Code changes | -> `reviewing` when tasks complete |
| `reviewing` | Verification | -> `complete` when verified |
| `complete` | Done | -> `archived` on request |
| `archived` | Historical | Terminal state |

## Agent Routing in /workflow

| Phase | Agent | Reads | Writes | Gate |
|-------|-------|-------|--------|------|
| 1. Analyze | analyst | requirements | `proposal.md` | proposal written |
| 1b. Research (conditional) | researcher | requirements | ResearchPack | score >= 80 |
| 2. Design | architect | `proposal.md` | `design.md`, `tasks.md` | score >= 85 |
| 3. Apply | developer | `tasks.md`, `design.md` | source code | validation passes |
| 4. Verify | reviewer | `design.md`, `tasks.md` | review report | no criticals |

## When Researcher Is Needed

Analyst flags need for research in proposal.md. Researcher is invoked ONLY when the task involves:
- New external API integration (e.g., Stripe, Twilio)
- Unfamiliar library not yet in the project
- Best practices requiring current internet research
- Version-specific documentation for upgrades/migrations

Analyst writes proposal directly (no researcher) for:
- Internal codebase refactoring
- UI/styling changes
- Bug fixes with known root cause
- Configuration changes
- Features using only existing project dependencies

## When to Create vs Skip Specs

| Task Type | Use Specs? | Reason |
|-----------|-----------|--------|
| New feature | Yes | Needs design, multi-file |
| Architecture change | Yes | Needs decisions documented |
| Multi-agent workflow | Yes | Needs coordination |
| Bug fix (simple) | No | Direct to developer |
| Typo / config tweak | No | Direct to developer |
| Single-file refactor | No | Direct to developer |

## Orchestration Steps

1. **Obtain conversation_id UUID**: From prompt context or generate via `uuidgen`. **MUST be a UUID, never a descriptive name** (validate against the regex above before creating any directory).
2. **Create specs directory**: `mkdir -p .scaffolding/conversations/{conversation_id}/specs/`
3. **Set specs_path**: `.scaffolding/conversations/{conversation_id}/specs/`
4. **Analyst writes proposal.md** (requirements, scope, impact, feasibility)
5. **If research needed**: analyst flags in proposal.md, researcher is invoked (score >= 80)
6. **Architect writes design.md + tasks.md** (incorporating proposal.md and ResearchPack if available)
7. **Pass specs_path** in every agent delegation prompt
8. **Update context.json** status after each phase transition (read-merge-write, see schema)
9. **Gate enforcement**: Block next phase if quality gate fails

## Context JSON Schema

One merged schema shared with the platform. **Every field is optional**; readers
treat a missing key as empty.

```jsonc
{
  "conversation_id": "uuid",                  // always a UUID
  // plugin (this workflow)
  "status": "exploring|drafting|implementing|reviewing|complete|archived",
  "description": "string",
  "created_at": "ISO-8601 string",
  "agents_involved": ["architect", "developer"],
  // platform
  "original_intent": "string",
  "task_history": [ { "task_id": "..." } ],
  "cumulative_files_changed": ["path"],
  "cumulative_decisions": ["string"],
  "last_updated": 1760000000,                 // epoch seconds (number)
  "openspec": { "status": "archived" }        // or null
}
```

**Read-merge-write, always.** Read the existing file, change only the keys you
own, write the whole object back. Never recreate the file from scratch and never
drop keys you do not know (e.g. keep `original_intent` and `task_history` when
setting `status`). Keep existing types: `created_at` is an ISO string,
`last_updated` a number. There is no version field. When the file does not
exist yet, create it with `conversation_id` plus the keys you own.

Minimal merge (jq):

```bash
f=".scaffolding/conversations/$CONV_ID/context.json"
[ -f "$f" ] || echo "{\"conversation_id\": \"$CONV_ID\"}" > "$f"
jq '.status = "implementing"' "$f" > "$f.tmp" && mv "$f.tmp" "$f"
```

## Schema Reference

Custom schema: `.scaffolding/openspec/schemas/scaffolding-workflow/schema.yaml`
Config: `.scaffolding/openspec/config.yaml`
Templates: `.scaffolding/openspec/schemas/scaffolding-workflow/templates/`

Wersje

RepozytoriumWynikLicencja
Ta strona · komluk/scaffolding100MIT
sutchan/Agent-Skills-Hub100MIT
tzachbon/smart-ralph100MIT
ramboz/jig91MIT
ramboz/jig91MIT
ramboz/jig91MIT

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

  • 100spec-design
    Pisze artefakty OpenSpec design.md i tasks.md dla funkcji opartej na specyfikacji, czyli projekt techniczny i listę zadań.
  • 100scaffold
    Tworzy w repozytorium workflow OpenSpec: CLAUDE.md dla analityka i architekta oraz subagenty worker, reviewer i supervisor dopasowane do specyfikacji.
  • 84implement-spec
    Koordynuje wdrażanie zadań z dokumentów spec-workflow, uruchamiając agentów realizujących kolejne zadania specyfikacji.
  • 100spec-research
    Pisze artefakt proposal.md w OpenSpec z uzasadnieniem, zakresem i wpływem funkcji, bez projektu technicznego.
  • 100openspec-plus-spec
    Aktywuje się w fazie specyfikacji OpenSpec i pomaga tworzyć, poprawiać oraz recenzować wymagania zapisane w specyfikacjach zmiany.
  • 86lightweight-ai-workflow
    Kieruje zadania kodowania AI w BK-CI: ustala, czy potrzebne są OpenSpec, wielu agentów, lista wpływu lub lista weryfikacji.

Uwagi i zgłoszenia

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