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

agentic-implement

/agentic-implement

Wykonuje ograniczone zadanie według gotowego briefu, z listą dozwolonych plików i kryteriami akceptacji.

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

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

Wykonuje ograniczone zadanie według gotowego briefu, z listą dozwolonych plików i kryteriami akceptacji.

Oryginalny opis (EN)

Implements a scoped task whose brief already fixes the expected behaviour, allowed files and acceptance checks, including delegated implementation lanes. Use when executing that brief; use agentic-feature to decide feature scope and agentic-fix to diagnose an unscoped defect.

Jak działa

  1. 1. Read only what you need
  2. 2. Think before writing
  3. 3. Test first
  4. 4. Smallest change
  5. 5. Green with proof
  6. 6. User preferences
  7. 7. Commit per cause
  8. 8. Deliver
  9. In other agents
Sekcje z nagłówków SKILL.md, w oryginale · 131 linii, 1 083 słów
Podgląd SKILL.md
---
name: agentic-implement
description: >-
  Implements a scoped task whose brief already fixes the expected behaviour, allowed files and
  acceptance checks, including delegated implementation lanes. Use when executing that brief; use
  agentic-feature to decide feature scope and agentic-fix to diagnose an unscoped defect.
---

# agentic-implement

Host differences, installations, tool substitutes and sibling resolution follow
`<agentic-project>/references/host-compatibility.md`; find that sibling through
`$AGENTIC_PROJECT_DIR` first and read the reference when the host varies.

From brief to commit with proof. The brief has already decided what: the files, expected behavior and
its proving test. You decide how, within it. For a short task
(`references/choosing-the-agent.md` §1), the orchestrator uses this skill without a brief: the brief is the
report or request, with the symptom, expected behavior and success criterion already written.

Repo rules override this skill: `AGENTS.md`, the area brief and the project's testing and Git rules.

The siblings `<agentic-design>` (`$AGENTIC_DESIGN_DIR`), `<agentic-code-review>` (`$AGENTIC_CODE_REVIEW_DIR`)
and `<agentic-architecture>` (`$AGENTIC_ARCHITECTURE_DIR`) follow the common reference; paths,
prefixes and order are not repeated here.

## 1. Read only what you need

Read the whole brief, `AGENTS.md`, the area brief named by the brief, the files you will change and
their callers. Read more only when a concrete question calls for it.

Done when you can name the entry point the test will exercise and every file you will change.

## 2. Think before writing

Before changing code, write a few lines:

- your **assumptions**;
- the **success criterion** as a command: `<command>` goes green;
- the **plan**, in steps, each with its verification.

If the brief admits two readings with different behaviors, or asks for something the code contradicts,
return `blocked: <the exact question>` with your recommendation: silently choosing a reading is the
defect this step prevents. A question only about size (doing more or less than requested) does not
stop you: follow the brief's rule if it has one; otherwise choose the smaller, reversible reading and
record it in the handoff. If you see a simpler solution than requested, mention it in the handoff and
implement the requested one.

Done when the success criterion is a command you can run.

## 3. Test first

Write a test that **fails on the base**, at the nearest public seam to the behavior (the entry point
a user or another module uses), rather than the internals. The expected value comes from an independent
source (the brief, a worked example, the spec), never the same calculation the code performs. Run it
and see it red for the right reason. Seam, interface and module, here and in the brief, mean what
`<agentic-architecture>/references/vocabulary.md` defines.

Work in **vertical slices**: one test, the minimum implementation to turn it green, then the next.
Good tests, bad ones to avoid, timeouts and child processes, and proving a forced red:
`references/tests.md`. In a refactor task (structure changes, behavior does not), there is no new red:
follow “Refactor” in `references/tests.md`, with its own completion criterion.

Done when the test runs red and the failure shows the missing behavior rather than a setup error.

## 4. Smallest change

Write the minimum that turns the test green, in the surrounding code's style: the same naming,
idioms, patterns and comment density. Every changed line answers the brief. Remove what your changes
left unused; leave pre-existing dead code and mention it in the handoff.

Done when the brief explains every line of the diff.

## 5. Green with proof

Run the new test, the area tests and typecheck, using the brief's or `AGENTS.md`'s commands.
Save each command and result. A skipped test, missing database or setup returning empty counts as
**red**. Measure the command's own exit code, without a pipe. Project proof rules, when present,
override this list.

**Two failures at the same gate.** If two attempts fail the same gate (the same test, typecheck,
a hook) for the same reason, do not try a third with the same idea. Write one sentence stating the
premise both share, what both took for granted, and look in code, test and brief for what disproves
it. If it falls and the new approach fits the brief, proceed and say so in the handoff; if it does
not fit, or you cannot find the premise, return `blocked: premise <the sentence> — <what you saw>`,
with your recommendation.

**Code, spec or test.** A persistent red can come from code, spec or test. Before returning
`spec-conflict`, write all three hypotheses, each with evidence confirming or disproving it: code
(the line doing something else), spec (the ambiguous sentence, one contradicting another, or code
contradicting it), and test (the assertion not following the spec, or setup not reaching the path).
Fix wrong code. Fix your own wrong test and say so in the handoff. Do not change the spec or project
tests (an oracle, a guard) to make green: that is `spec-conflict`, with all three hypotheses and proof.

Done when you have saved green output for each command.

## 6. User preferences

Apply the project's preferences to what you touched, each from its source:

- code and product text: `references/preferences.md`;
- interface: the project's design system (`AGENTS.md` says which) and
  `<agentic-design>/references/ui-without-slop.md`, in the “build” mode sections
  (`<agentic-design>/SKILL.md` §5);
- project-specific matters (vocabulary, stack): `AGENTS.md`, which overrides both.

Done when the diff meets every applicable preference from these sources.

## 7. Commit per cause

One commit per cause, with `git add <paths>`. The message says why and gives proof. Run repo hooks
and fix their failures. Follow `AGENTS.md`'s Git rules (trailers, branches, prohibited commands).

Commits stay on your branch; the orchestrator pushes and integrates after review. Push, deploy or
production access only when the brief's `human order:` line requests it, and only for that task.
This is the same rule for a Claude subagent and a Codex job. When the job launcher records the order
and adds it to the prompt in a dedicated block, only that block's order counts. Never `--no-verify`,
never rewrite history (rebase, amending an already shared commit, force-push).

Done when `git status --short` shows only work that is not yours and `git show --stat` matches the message.

## 8. Deliver

The final message is the handoff: full base and HEAD SHAs, files, commands and results, what was
skipped and why, limitations and unfinished work; follow the brief's report format when provided.
The last line is the status, in `AGENTS.md`'s output format; without it: `status: done`,
`status: blocked: <reason>` or `status: spec-conflict: <what>` (after “Code, spec or test”, step 5).

Blocked midway: commit what is green and hand off with the blocker; never commit a red test to
mark missing work.

Done when the last line is the status.

## In other agents

In Codex: `$agentic-implement`, or the brief says “load agentic-implement”. The launcher
(`agentic-fix`, `agentic-feature`) chooses level, model and agent using
`references/choosing-the-agent.md`. Method origin and licenses: `references/origin.md`.
Pliki w paczce (12)
  • SKILL.md 7 KB
  • assets/agents/README.md 3 KB
  • assets/agents/claude-md-excerpt.md 1 KB
  • assets/agents/implementer-ui.md 1 KB
  • assets/agents/implementer.md 1 KB
  • assets/agents/researcher.md 1 KB
  • assets/agents/reviewer.md 2 KB
  • licenses/LICENSE-mattpocock-skills 1 KB
  • references/choosing-the-agent.md 8 KB
  • references/origin.md 3 KB
  • references/preferences.md 2 KB
  • references/tests.md 4 KB

Wersje

W bazie nie ma innych skilli o nazwie agentic-implement.

Migawka bazy z 13.11.2026 · wersja paczki 27a317fd4600 (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

  • 100agentic-feature
    Planuje i dowozi nową lub zmienioną funkcjonalność w istniejącym projekcie, od specyfikacji po pozycje w backlogu.
  • 100agentic-architecture
    Ocenia architekturę istniejącego kodu pod kątem tarcia między modułami i proponuje uzgodnione zmiany strukturalne.
  • 100implement-feature
    Pomaga wdrożyć funkcję lub historyjkę z kryteriami akceptacji do zweryfikowania, przy poleceniach build, create feature i add functionality.
  • 86implement-work
    Wdraża przydzieloną zmianę i raportuje dowody zachowania, na podstawie opisu zadania i wyraźnie przypisanych plików.
  • 90implement-task
    Realizuje uzgodnione zadanie z planu Markdown, Issue na GitHubie lub ticketu Jira i sprawdza kryteria akceptacji.
  • 100subagent-driven-development
    Wykonuje plan wdrożenia w bieżącej sesji, zadanie po zadaniu; do ewidencji kryteriów akceptacji służy inny silnik.

Uwagi i zgłoszenia

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