Przejdź do treści
Biblioteka skilli
Programowanie · Budowanie i kod

slice

/slice

Implementuje jeden plasterek tracer-bullet metodą od środka: najpierw funkcjonalny rdzeń, potem imperatywna powłoka, połączenie end-to-end i refaktoryzacja wyrównująca.

Repozytorium
labs ↗
Licencja
MIT
Ostatnia zmiana repozytorium
21.10.2026

Ocena i bezpieczeństwo

90/ 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ść25 / 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 21.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

Implementuje jeden plasterek tracer-bullet metodą od środka: najpierw funkcjonalny rdzeń, potem imperatywna powłoka, połączenie end-to-end i refaktoryzacja wyrównująca.

Argumenty

/slice [paste tracer-bullet card (or provide path to it)]
Oryginalny opis (EN)

Implement one tracer-bullet slice following the inside-out methodology. Use when you have a tracer-bullet card ready to build. Implements functional core first, then imperative shell, then end-to-end wiring, then alignment refactor.

Jak działa

  1. Input
  2. Procedure
  3. Constraints
  4. Output
Sekcje z nagłówków SKILL.md, w oryginale · 120 linii, 748 słów
Podgląd SKILL.md
---
name: slice
description: Implement one tracer-bullet slice following the inside-out methodology. Use when you have a tracer-bullet card ready to build. Implements functional core first, then imperative shell, then end-to-end wiring, then alignment refactor.
argument-hint: "[paste tracer-bullet card (or provide path to it)]"
---

# Tracer-Bullet Slice

Implement **one** thin end-to-end slice of functionality, following the inside-out procedure.

## Input

The slice is defined by a **tracer-bullet card**: $ARGUMENTS

**Preconditions**:
- A concept capsule must exist. If none → `/pragma:capsule` first.
- A card must exist. If none → `/pragma:card` first.

Extract from the card: (1) target behavior, (2) boundary crossings, (3) risks/assumptions, (4) definition of done. If the card is incomplete, stop and recommend rerunning `/pragma:card`.

## Procedure

Follow these steps in order. Do not skip or reorder.

### 0. Preflight gates

Before writing implementation code:

- Confirm card includes explicit **BUY-OR-BUILD** decision. If missing, stop and refine `/pragma:card`.
- If requirement behavior is still unclear in practice, stop and run `/pragma:spike` first to prototype/observe.

### 1. Spec tests first (red)

Before implementing behavior, translate card Definition of Done into tests:

- Add or update tests named in the card DoD
- Run tests and confirm at least one fails for the expected reason
- If tests pass unexpectedly, tighten test assertions or refine the card scope
  before writing implementation code

This is the "create the needle" step: define a narrow path to success first.

### 2. Functional core (pure domain logic)

Implement using the functional core / imperative shell pattern (Bernhardt):

- Define types/structures using capsule glossary terms
- Write core function(s) as pure transformations — no I/O, no side effects
- Write tests covering the target behavior
- Enforce invariants at construction boundaries

No frameworks, no infrastructure, no I/O in this step. No speculative abstractions.

### 3. Imperative shell (thin I/O adapter)

Add the minimal I/O boundary connecting the core to the real world. The shell calls the core, never the reverse. No business logic in the shell.

### 4. Wire end-to-end

Connect the full path: entry point → shell → core → shell → output. Make it actually run. Write or update an integration test proving the target behavior.

### 4.5. Commit the behavior (recommended)

Commit the smallest set of changes that makes the E2E path pass.
Message style: `Behavior: <target behavior>`

### 5. Alignment refactor — NOT optional

Refactor immediately while context is fresh:
- **Naming**: all names match the capsule glossary? Rename if not.
- **Module boundaries**: can you complete "This module hides the decision about ___" (Parnas) for each module?
- **Dead code**: delete anything speculative, unused, or "for later."
- **Slice cohesion**: does this slice form a coherent vertical unit?

### 6. Verify

Run the project's existing verification harness. All checks must pass. If any fails, fix and re-run from step 1 of verification.

### 7. Commit the refactor

Separate from the behavior commit. Message style: `Refactor: align slice to capsule`

### 8. Classify authority deltas (mandatory)

Before closing the slice, classify what changed and route updates to the
correct authority artifact:

- Semantics changed (glossary/invariant/happy-path/non-goal meaning) → `/pragma:capsule update`
- Strategy changed (cross-cutting decision/rationale/reversal trigger) → `/pragma:roadmap update`
- Phase control changed (scope/status/ordering/deferment/exit criteria) → `/pragma:milestone update`
- Confidence changed (assumption validated/invalidated/confidence shift) → `/pragma:assumptions update`
- Enforcement readiness changed (invariant now enforceable in code/tests) → `/pragma:contract`

Use explicit `none` for lanes with no change.

### 9. Update the assumptions ledger (mandatory)

Run `/pragma:assumptions update` with the slice summary, assumptions made, and validation evidence.

## Constraints

- **One slice only.** No adjacent behaviors, future features, or "while we're here" improvements.
- **Needle before thread.** Do not write behavior code until spec tests go red for the right reason.
- **No speculative abstractions.** No generic frameworks, no "future extensibility."
- **No new abstractions unless forced.** Only abstract when two concrete cases demand it.
- **Refactor is part of done.** A slice is not done until step 5 is complete.
- **Explicit assumptions.** State them. If risky, flag for a spike.
- **No silent authority drift.** Any non-`none` authority delta must be surfaced
  and routed before additional delivery work.

## Output

1. **Behavior delivered**: what is now true that wasn't before
2. **Files changed**: list
3. **Authority Delta**:
   - Semantics: `none` | `/pragma:capsule update` — [reason]
   - Strategy: `none` | `/pragma:roadmap update` — [reason]
   - Phase control: `none` | `/pragma:milestone update` — [reason]
   - Assumptions: `none` | `/pragma:assumptions update` — [reason]
   - Enforcement: `none` | `/pragma:contract` — [reason]
4. **Assumptions made**: anything that should be validated
5. **Suggested next step**: what slice or action follows
6. **Ledger**: run `/pragma:assumptions update` (mandatory after every slice)
7. **Lifecycle**: `State: delivery`, `Next: first non-'none' authority delta command (otherwise /pragma:assumptions update)`, `Loop: /pragma:consult` (default unless user explicitly continues directly)

Wersje

RepozytoriumWynikLicencja
Ta strona · hashintel/labs90MIT
marcoskichel/empire100MIT
mtrense/skills100MIT
VoxFlowStudio/skills100MIT
thkt/dotclaude90MIT

Migawka bazy z 28.10.2026 · wersja paczki 424737b08566 (skrót SHA-256 całej paczki)

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

Podobne skille

  • 100card
    Pisze kartę tracer-bullet, czyli precyzyjną specyfikację jednego cienkiego wycinka pracy od początku do końca: zachowanie docelowe, granice, ryzyka i definicja ukończenia.
  • 100tdd
    Implementuje jeden gotowy wycinek historyjki z wiki metodą czerwony, zielony, refaktoryzacja, według scenariuszy Gherkin.
  • 100tdd
    Implementuje jeden gotowy wycinek historyjki z wiki metodą czerwony, zielony, refaktoryzacja, według scenariuszy Gherkin.
  • 100test-driven-execution
    Realizuje funkcje i poprawki regresji pętlą red-green-refactor typu tracer bullet, z testami publicznych interfejsów i pionowych wycinków odpornymi na refaktoryzację.
  • 100slicing-into-tracer-bullets
    Dzieli duży, gotowy do budowy opis na pionowe wycinki typu tracer bullet zamiast warstw poziomych i ustala kolejność budowy oraz zadania.
  • 90to-tickets
    Dzieli plan, specyfikację lub rozmowę na zestaw zgłoszeń tracer-bullet z blokadami, zapisując je w pliku lokalnym albo w trackerze.

Uwagi i zgłoszenia

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