Przejdź do treści
Biblioteka skilli
Programowanie · Planowanie

pick-up

/pick-up

Podejmuje zgłoszenie z trackera: czyta je wraz z otoczeniem, porządkuje metadane i prowadzi plan, zapisując decyzje z sesji.

Repozytorium
claude-plugins ↗
Licencja
MIT
Ostatnia zmiana repozytorium
23.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 23.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

Podejmuje zgłoszenie z trackera: czyta je wraz z otoczeniem, porządkuje metadane i prowadzi plan, zapisując decyzje z sesji.

Wyzwalacze z opisu

pick this uppick up #Nstart on #N

Argumenty

/pick-up [issue]
Oryginalny opis (EN)

Pick up an issue's work in this session — read the issue and its neighbourhood, report what the scan found, sort the tracker metadata, and start the plan that journals the session's decisions, questions and constraints as they happen, so its commits and PR are written from them. Use when the user says "pick this up", "pick up #N", "start on #N", "/chalk:pick-up", or a session is starting work on an issue.

Jak działa

  1. Before you start
  2. 1. Read the issue and its neighbourhood
  3. 2. Report what the scan found
  4. 3. Report and resolve gaps in the issue
  5. 4. Sort the metadata
  6. 5. Start the plan
  7. 6. Journal as you go
Sekcje z nagłówków SKILL.md, w oryginale · 76 linii, 686 słów
Podgląd SKILL.md
---
name: pick-up
description: Pick up an issue's work in this session — read the issue and its neighbourhood, report what the scan found, sort the tracker metadata, and start the plan that journals the session's decisions, questions and constraints as they happen, so its commits and PR are written from them. Use when the user says "pick this up", "pick up #N", "start on #N", "/chalk:pick-up", or a session is starting work on an issue.
user-invocable: true
argument-hint: "[issue]"
---

# Pick-up

Interpret MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, etc. per RFC 2119.

**Success: the session works from the issue alone, nothing in its neighbourhood that changes the picture has gone unreported, and every commit and PR the session drafts finds its reasoning already written in the plan.**

## Before you start

- **Load `chalk:issue`**, which loads `chalk:voice`.
- **Ground it in the repo, not the transcript**: the branch, `git log` and linked PRs say what has landed.

## 1. Read the issue and its neighbourhood

**The issue, its parent, its sub-issues, what blocks it and what it blocks, and its linked PRs.**

## 2. Report what the scan found

**Say what the neighbourhood tells you about this issue being worked now**, and carry on.
The *why now*, where there is one, is the issue's own (`chalk:issue`); an issue without one is opportunistic.

- **Where the scan changes the picture, wait for the user's agreement before changing anything, the tracker included.**
  An open blocker, a duplicate, or a card that supersedes this one.

- **Where the user named an umbrella rather than a piece of it, ask which piece.**
  You MUST NOT pick the most plausible-looking sub-task instead.

## 3. Report and resolve gaps in the issue

**Against `chalk:issue`'s palette: a missing goal, unclear scope, open questions nobody has answered.**
Report them and resolve them; the answers reach the issue through `chalk:issue`.

## 4. Sort the metadata

**Assignee, status, board — whatever the project's tracker conventions say for a card being picked up.**
Where they don't say, ask.

## 5. Start the plan

**The session's plan — Claude Code's plan file, or the host's equivalent — unless the project names another place.**
Only the session writes it.

- **It opens with one line: `Journalled per chalk:pick-up — <issue link>`**, so a session after a compaction knows which skill to reload.
- **It links the issue rather than copying it.**
- **It holds what has to land, and below it, apart, the journal.**
- **What has to land, not which files to touch.**
- **What has to land SHOULD be a goal tree** (`chalk:goal-tree`): the issue's goal at the root, what lands at the leaves.
  Test each node for sufficiency, mark `check:` where unsure, and say where sufficiency leans on what the user already knows about the system.
- **A sub-goal names what it depends on.**
  **It's ready once everything it depends on is done and no open question blocks it.**
- **What's in hand sits at the top**: the sub-goal being worked, and anything that interrupted it, innermost first.
- **When a sub-goal's commit is made, mark it done with the commit's subject**, not its SHA, which a rebase rewrites.

## 6. Journal as you go

**Write each entry when it happens, not at the end and not from memory.**

- **`D<n>` decision** — the claim, and its grounds.
  A call you aren't sure of is a question, not a decision.
  An alternative rejected is its child, with why.
  A revised decision stays, marked `superseded by D<m>`.
- **`Q<n>` question** — what it blocks, and what would settle it.
- **`constraint:`, `assumption:`, `risk:`** — what the work leans on that it doesn't control, and what could stop it.
- **`dead-end:`** — a road that closed, and what closed it, where that constrains what comes next.

**Cutting scope and accepting a risk MUST be recorded**; they leave no other trace.

**A decision that changes the problem or the agreed scope goes to the issue now**, through `chalk:issue`; the journal records that it went.
**So does a dependency the session discovers**, onto the card it depends on rather than this one, per `chalk:issue`.
**Everything else goes in the journal**, naming the sub-goal it bears on only where the entry doesn't make that obvious.

**Each entry is one claim in `chalk:voice`'s register, terse.**
An entry that would mean nothing in a commit body, a PR or the issue doesn't belong.

**You MAY give a sub-agent the plan's path to read**, told not to write it — never a `weed-*` agent, which works because it arrives without the reasoning.

Wersje

RepozytoriumWynikLicencja
Ta strona · juxt/claude-plugins90MIT
mshadmanrahman/claude-for-designers100MIT

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

  • 100pick-up-issue
    Pomaga przejąć zgłoszenie GitHub przed rozpoczęciem pracy: wybór zgłoszenia, zajęcie go i start pracy nad nim.
  • 100complete-issue
    Podejmuje i kończy zgłoszenie GitHub od początku do końca z TDD, lintowaniem, utworzeniem pull requesta i cyklem przeglądu CI, na podstawie numeru zgłoszenia.
  • 100complete-issue
    Realizuje zgłoszenie GitHub od początku do końca: TDD, linting, pull request i obsługa przeglądu CI, na podstawie numeru zgłoszenia.
  • 100implement-issue
    Realizuje zgłoszenie od początku do końca: pobiera specyfikację z trackera, tworzy gałąź, pisze kod w TDD, uruchamia kontrole, robi commit, publikuje roboczy PR lub MR i zamyka zgłoszenie po scaleniu.
  • 100implement
    Zamienia istniejące zgłoszenie GitHub w gotowy, zrecenzowany pull request: bierze opis zgłoszenia, wdraża funkcję lub poprawkę i prowadzi do przeglądu.
  • 100git-issue-start
    Prowadzi zgłoszenie GitHub od otwartego do wyewidencjonowanej gałęzi: przypisuje je użytkownikowi, oznacza jako w toku, tworzy nazwę gałęzi z etykiety typu i odgałęzia od wykrytej bazy.

Uwagi i zgłoszenia

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