Claude Skill

implement

TRIGGER when: user asks to implement, fix, build, or work on something — whether from a docs/feat/wip plan OR a standalone task (bug fix, GitHub issue, one-off change). Examples: "work on task 1", "fix this bug", "implement feature X from the issue". Provides structured execution

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download serpro69-claude-toolbox-klaude-plugin_skills_implement-4b66a41.zip · 13 KB

serpro69/claude-toolbox 149 31 forks Updated 7d ago

Part of serpro69/claude-toolbox — 15 skills

Install

skills CLI npx skills add https://github.com/serpro69/claude-toolbox/tree/master/klaude-plugin/skills/implement

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install serpro69-claude-toolbox@llmmart

Git git clone https://github.com/serpro69/claude-toolbox.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole serpro69/claude-toolbox collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Files (claude-toolbox)

evals

no-profile-detection-still-runs

test-files

docs

feat

wip

team-handbook

design.md 728 B

# Design: team-handbook

## Problem

New joiners get account access on day one but have no guidance for the rest of the first week. Each team lead improvises, and steps get missed.

## Solution

Extend `docs/handbook/onboarding.md` with a first-week checklist that every team lead follows.

## First-week checklist

- [ ] Pair with a buddy for at least two working sessions
- [ ] Read the architecture overview and ask one question about it in the team channel
- [ ] Ship one small change end to end (branch, review, merge)
- [ ] Attend one incident review or read the most recent post-mortem
- [ ] Schedule the end-of-week check-in with the team lead

## Non-goals

- Role-specific onboarding tracks
- Automating the checklist

implementation.md 321 B

# Implementation: team-handbook

## Files

- `docs/handbook/onboarding.md` — the only file touched.

## Approach

Documentation-only change: insert a `## First week` section between the Accounts and Contacts sections, containing the five checklist items verbatim from `design.md`. No code, no dependencies, no tooling.

tasks.md 319 B

# Tasks: team-handbook

**Status:** in-progress

## Task 1: Add the first-week checklist to onboarding

**Status:** pending
**Dependencies:** none

- [ ] 1.1 Add a `## First week` section to `docs/handbook/onboarding.md` after the Accounts section, with the five checklist items from `design.md` §First-week checklist

handbook

onboarding.md 374 B

# Onboarding

Welcome. This page covers your first days on the team.

## Accounts

Your team lead requests accounts before your start date. On day one, confirm you can sign in to:

- Source control
- The issue tracker
- The team chat workspace
- The CI dashboard

## Contacts

- Team lead: see the team page
- Buddy: assigned on day one
- IT support: the `#it-help` channel

eval.json 2.3 KB

{
  "id": 2,
  "name": "no-profile-detection-still-runs",
  "description": "A markdown edit to a generic document that matches no profile must still run profile detection; only the implement content load is skipped, and the agent says so. Staging requirement: stage test-files/ as the workspace root, outside any SKILL.md-rooted directory. Evaluated in place under skills/implement/evals/, the skill-md nearest-ancestor walk would reach the implement skill's own SKILL.md and activate skill-md, inverting this eval.",
  "skills": ["implement"],
  "prompt": "Work on task 1 of the team-handbook feature.",
  "trap": "The target is a plain markdown page outside any skill, chart, or code tree. The model either skips profile detection entirely because 'no profile could match a handbook page', or over-activates a profile (e.g. skill-md) because the file is markdown. The correct behaviour is to run detection, report an empty result, skip only the implement content load, and proceed with the remaining pre-write steps.",
  "files": [
    "test-files/docs/feat/wip/team-handbook/tasks.md",
    "test-files/docs/feat/wip/team-handbook/design.md",
    "test-files/docs/feat/wip/team-handbook/implementation.md",
    "test-files/docs/handbook/onboarding.md"
  ],
  "assertions": [
    { "id": "2.1", "text": "Agent runs profile detection against docs/handbook/onboarding.md by reading the known profiles' DETECTION.md files, rather than declaring detection inapplicable to a markdown page." },
    { "id": "2.2", "text": "Agent reports no active profile: in the staged workspace, onboarding.md matches no filename or content signal and has no SKILL.md ancestor; skill-md is not activated." },
    { "id": "2.3", "text": "Agent does not read any profiles/<name>/implement/ file, and states that the content load is skipped because no profile is active." },
    { "id": "2.4", "text": "Agent performs the plan-mode capy search before any edit, or explicitly notes that capy tools are unavailable or the knowledge base is empty." },
    { "id": "2.5", "text": "Agent sets task 1's status to in-progress in tasks.md before editing docs/handbook/onboarding.md." },
    { "id": "2.6", "text": "The first Edit or Write to onboarding.md happens only after detection has completed; the agent does not justify skipping detection by file type or task size." }
  ]
}

standalone-trivial-fix-runs-pre-write-steps

test-files

deploy

web-deployment.yaml 520 B

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: frontend
  labels:
    app: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27.l
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 64Mi
            limits:
              cpu: 250m
              memory: 128Mi

eval.json 2.9 KB

{
  "id": 3,
  "name": "standalone-trivial-fix-runs-pre-write-steps",
  "description": "A one-character image-tag typo fix in standalone mode (no feature or task reference) must still run every pre-write step: standalone capy search, profile detection (k8s via content signal), k8s implement gotchas loaded, and dependency handling for the changed image tag, all before the first edit. Staging requirement: stage test-files/ as the workspace root, outside any SKILL.md-rooted directory, so that skill-md does not activate via the implement skill's own SKILL.md ancestor.",
  "skills": ["implement"],
  "prompt": "The nginx image tag in deploy/web-deployment.yaml has a typo: it says 1.27.l (letter l) but should be 1.27.1. Fix it.",
  "trap": "The user supplies the exact correct value and the change is one character in one YAML file. The model treats standalone-mode step 7's 'trivial fix' clause as permission to skip SKILL.md Step 2, edits the file directly, and neither runs profile detection nor looks up the tag. Both skips are wrong: the file is a Kubernetes manifest (top-level apiVersion and kind), so the k8s profile activates and its implement gotchas cover image-tag pitfalls; and an image tag change is an explicit Step 2.3 dependency trigger regardless of who supplied the value.",
  "files": [
    "test-files/deploy/web-deployment.yaml"
  ],
  "assertions": [
    { "id": "3.1", "text": "Agent operates in standalone mode and performs the standalone capy search over kk:arch-decisions, kk:project-conventions, kk:lang-idioms, kk:review-findings, and kk:debug-context before any edit, or explicitly notes that capy tools are unavailable or the knowledge base is empty." },
    { "id": "3.2", "text": "Agent identifies deploy/web-deployment.yaml as the only target file and proceeds to SKILL.md Step 2; 'trivial' affects only whether an approach statement is written, not whether Step 2 runs." },
    { "id": "3.3", "text": "Agent runs profile detection by reading the known profiles' DETECTION.md files and reports k8s as active via the content signal (top-level apiVersion and kind in the document), not merely via the deploy/ path signal; in the staged workspace no other profile is reported active." },
    { "id": "3.4", "text": "Agent reads the k8s profile's implement/index.md and every file it lists under Always load into context before the first edit." },
    { "id": "3.5", "text": "Agent treats the image tag change as a dependency change under Step 2.3 and applies /kk:dependency-handling to verify the nginx 1.27.1 tag before writing it, rather than writing the user-supplied value unverified." },
    { "id": "3.6", "text": "The first Edit or Write to deploy/web-deployment.yaml happens only after assertions 3.1 through 3.5 are satisfied." },
    { "id": "3.7", "text": "Agent does not justify skipping or abbreviating any pre-write step by the fix's size, its one-character nature, or the user having supplied the correct value." }
  ]
}

trivial-task-runs-pre-write-steps

test-files

docs

feat

wip

greeting-skill

design.md 753 B

# Design: greeting-skill

## Problem

Users ask the assistant for short, personalised greetings in several languages. Without a dedicated skill the output format drifts between sessions.

## Solution

A `greet` skill under `skills/greet/` that asks for name and language when missing and emits a one-line greeting.

## Scope boundaries

The skill is over-triggering on any message that contains "hello". Add a "When not to use" paragraph to the skill body with this wording:

> Do not use this skill for conversational openers the user writes themselves, for translating existing text, or for anything longer than one sentence. Those are ordinary requests and need no skill.

## Non-goals

- Multi-sentence introductions
- Translation of arbitrary text

implementation.md 433 B

# Implementation: greeting-skill

## Files

- `skills/greet/SKILL.md` — the only file touched by tasks 1 and 2.

## Approach

Task 1 creates the skeleton. Task 2 is a documentation-only change: insert one paragraph under a `## When not to use` heading, placed between the Overview and Workflow sections. No code, no dependencies, no tests beyond confirming the file still parses as a skill (frontmatter intact, headings in order).

tasks.md 543 B

# Tasks: greeting-skill

**Status:** in-progress

## Task 1: Create the greet skill skeleton

**Status:** done
**Dependencies:** none

- [x] 1.1 Create `skills/greet/SKILL.md` with frontmatter and an Overview section
- [x] 1.2 Add the Workflow section with the two-step greeting flow

## Task 2: Document when not to use the skill

**Status:** pending
**Dependencies:** Task 1

- [ ] 2.1 Insert a "When not to use" paragraph into `skills/greet/SKILL.md` directly after the Overview section, using the wording in `design.md` §Scope boundaries

skills

greet

SKILL.md 469 B

---
name: greet
description: Greet the user by name in their preferred language. Use when the user asks for a greeting or a one-line introduction message.
---

# Greet

## Overview

Produces a single-line greeting addressed to the user by name, in the language they prefer. Defaults to English when no language is given.

## Workflow

1. If the name or language is missing, ask for it in one message.
2. Emit exactly one line: the greeting, the name, and nothing else.

eval.json 2.3 KB

{
  "id": 1,
  "name": "trivial-task-runs-pre-write-steps",
  "description": "A one-paragraph markdown edit to a SKILL.md in plan mode must still run every pre-write step; profile detection activates skill-md and its implement gotchas load before the first edit.",
  "skills": ["implement"],
  "prompt": "Work on task 2 of the greeting-skill feature.",
  "trap": "The task is a single paragraph inserted into a markdown file. The model judges the pre-write steps (plan-mode capy search, SKILL.md Step 2 profile detection and gotcha loading) as ceremony that cannot surface anything for a task this small, and edits SKILL.md directly. The judgment is wrong: the target is a SKILL.md, an authoritative filename signal for the skill-md profile, whose always-load implement checklist is exactly the guidance for this edit.",
  "files": [
    "test-files/docs/feat/wip/greeting-skill/tasks.md",
    "test-files/docs/feat/wip/greeting-skill/design.md",
    "test-files/docs/feat/wip/greeting-skill/implementation.md",
    "test-files/skills/greet/SKILL.md"
  ],
  "assertions": [
    { "id": "1.1", "text": "Agent reads tasks.md, design.md, and implementation.md in full and identifies task 2 as the next pending task before any edit." },
    { "id": "1.2", "text": "Agent performs the plan-mode capy search over kk:arch-decisions, kk:project-conventions, kk:lang-idioms, and kk:review-findings before any edit, or explicitly notes that capy tools are unavailable or the knowledge base is empty." },
    { "id": "1.3", "text": "Agent sets task 2's status to in-progress in tasks.md before editing skills/greet/SKILL.md." },
    { "id": "1.4", "text": "Agent runs profile detection against skills/greet/SKILL.md by reading the known profiles' DETECTION.md files, and reports the skill-md profile as active via the SKILL.md filename signal." },
    { "id": "1.5", "text": "Agent reads the skill-md profile's implement/index.md and every file it lists under Always load into context before the first edit to skills/greet/SKILL.md." },
    { "id": "1.6", "text": "The first Edit or Write to skills/greet/SKILL.md happens only after assertions 1.1 through 1.5 are satisfied." },
    { "id": "1.7", "text": "Agent does not justify skipping or abbreviating any pre-write step by the task's size, simplicity, or markdown-only nature." }
  ]
}

plan-mode.md 1.8 KB

# Plan Mode

Applies when the user references a docs/feat/wip feature or task number.

## Entry Procedure

1. Read the feature's `tasks.md` file to get the task list and current progress
2. Read the entire `design.md` and `implementation.md` files to **understand the full feature context**
3. Identify the next pending task (one whose dependencies are all done)
4. **Capy search:** Search `kk:arch-decisions`, `kk:project-conventions`, `kk:lang-idioms`, and `kk:review-findings` for context relevant to the identified task. Run it for every task, however small — whether the knowledge base holds something relevant is unknowable until searched, and an empty result costs nothing
5. Review critically — identify any questions or concerns about the plan
6. If concerns: Raise them with your human partner before starting

After completing the entry procedure, return to SKILL.md Step 2 (Execute).

## Iteration

After each execution + review cycle (SKILL.md Steps 2–3):

- Verify the completed task's **Required Outputs** are all checked
- Move to the next pending task in `tasks.md`
- Return to the Entry Procedure above to load context for the new task
- Repeat until all tasks are completed

## Completion

After all tasks are complete and verified:

- Use `/kk:test` skill to verify and validate functionality
- Use `/kk:document` skill to create or update any relevant docs
- **Reflect:** briefly note where the implementation diverged from the plan, what turned out harder or simpler than expected, and any surprises that future work in this area should know about. Keep it short — a paragraph, not an essay. Index non-obvious learnings as `kk:project-conventions` or `kk:arch-decisions` if they weren't already captured during per-task cycles.
- Update the feature status in `tasks.md` header to `done`

SKILL.md 7.8 KB

---
name: implement
description: |
  TRIGGER when: user asks to implement, fix, build, or work on something — whether from a
  docs/feat/wip plan OR a standalone task (bug fix, GitHub issue, one-off change).
  Examples: "work on task 1", "fix this bug", "implement feature X from the issue".
  Provides structured execution with profile detection, dependency handling, review checkpoints.
---

# Implementing Work

## Conventions

- **Read capy knowledge base conventions** at [shared-capy-knowledge-protocol.md](shared-capy-knowledge-protocol.md).
- **Read profile detection** at [shared-profile-detection.md](shared-profile-detection.md). When the sub-task's target files activate a profile that contributes an `implement/` subdirectory (e.g., `${TOOLBOX_PLUGIN_ROOT}/profiles/k8s/implement/`), its `index.md` lists per-task gotchas the skill must consult BEFORE writing. See Step 2.

## Modes

Two modes, determined automatically: **plan mode** when the user references a docs/feat/wip feature or task number; **standalone mode** otherwise (bug fix, GitHub issue, one-off change). When ambiguous, ask.

- **Plan mode:** Read [plan-mode.md](plan-mode.md) for entry, iteration, and completion procedures.
- **Standalone mode:** Read [standalone-mode.md](standalone-mode.md) for entry procedure.

Both modes share the same execution core (Step 2 onward) — profile detection, dependency handling, verification, review.

## Required Outputs

After each execution + review cycle, verify all outputs:

- [ ] Implementation addresses the requirement (plan mode: matches plan)
- [ ] Verification/tests pass
- [ ] Code review completed (via `/kk:review-code` — which owns indexing its own `kk:review-findings`)
- [ ] New project conventions indexed as `kk:project-conventions` (skip if none established)
- [ ] (Plan mode only) `tasks.md` updated to `done`

**Indexing ownership:** Review skills (`/kk:review-code`, `/kk:review-spec`) index their own findings. This skill only indexes `kk:project-conventions` for non-obvious patterns discovered during implementation. Do NOT duplicate review indexing here.

### Review Mode

By default, review checkpoints use **isolated mode** (`kk:review-code:isolated`, `kk:review-spec:isolated`). This is mandatory because the implementing session has authorship bias — the same model that wrote the code produces weaker reviews of it. Isolated mode spawns an independent sub-agent with no prior exposure to the implementation.

The user can override at any checkpoint ("use standard review for this one") to fall back to in-session `/kk:review-code`.

## Workflow

**Mandatory order — understand before executing.** The flow below is strictly sequential. Do not read source files to modify, write code, edit files, run tests, or otherwise act on any task until you have loaded full context (design, implementation plan, task list in **plan mode**, or full problem understanding in **standalone**) and completed profile detection and loaded all resolved profile content. The only early contact with the codebase is the task's target filenames — enough to drive profile detection, not enough to pattern-match implementation.

## The Process

### Step 1: Load Context

Determine mode (see §Modes), then read the appropriate mode file and follow its entry procedure:

- **Plan mode:** Read [plan-mode.md](plan-mode.md) — loads tasks.md, design.md, implementation.md, identifies next task.
- **Standalone mode:** Read [standalone-mode.md](standalone-mode.md) — parses the problem, explores relevant code, forms an approach.

After completing the mode's entry procedure, continue with Step 2.

### Step 2: Execute

**Mandatory order — instructions before action.** Steps 1–3 load instructions; step 4 is the first step that touches subject matter. Do not write code, edit files, or otherwise act until steps 1–3 have been performed in order. If a later step reveals that an instruction was missed, return to step 1.

1. (Plan mode only) Update `tasks.md`: set the task's status to `in-progress`.
2. **Profile-aware per-task gotchas (pre-write).** Run the `shared-profile-detection.md` procedure against the target files (and any diff-so-far). Detection itself always runs, however small or "just markdown" the task looks — that judgment is unreliable (a one-paragraph edit to a `SKILL.md` activates the `skill-md` profile), and whether detection fires is unknowable until it has run. For each active profile, load `${TOOLBOX_PLUGIN_ROOT}/profiles/<name>/implement/index.md`; if the read fails with ENOENT, that profile contributes no implement guidance — move on. Otherwise read the always-load + any matching conditional content. Apply those gotchas to the upcoming edits — they exist to prevent mistakes the post-write reviewer would otherwise catch. When no active profile contributes `implement/`, only the content load is skipped — never the detection.
3. **Dependency-handling (pre-write).** Whenever the task introduces or changes a dependency — new import, version bump, unfamiliar call, **and per the widened trigger also: a Kubernetes API version, a CRD, a Helm chart or chart dependency, or a container image tag/digest** — apply the `/kk:dependency-handling` skill BEFORE writing the call. Do not guess signatures, API versions, or configuration; look them up via capy/context7 per that skill's rules. Per-profile lookup cascades live in each profile's `overview.md` (e.g., `${TOOLBOX_PLUGIN_ROOT}/profiles/k8s/overview.md` §Looking up Kubernetes dependencies).
4. Make the changes. (Plan mode: follow the plan exactly.)
5. (Plan mode only) Check off subtasks (`- [x]`) in `tasks.md` as you complete them.
6. Run verifications; run `/kk:test` skill.

### Step 3: Report and Review

- Show what was implemented
- Show verification output
- Load `kk:review-code:isolated` skill — this handles both sub-agent and pal codereview internally with independent reviewers. Do NOT run a separate `pal` codereview call, as it is already included in the isolated workflow.
- Based on user and code-review feedback: apply changes if needed and finalize
- (Plan mode only) Update `tasks.md`: set the task's status to `done`

**After finalizing**, verify all items in the **Required Outputs** section above:

- [ ] Implementation addresses the requirement (plan mode: implementation matches plan)
- [ ] Verification/tests pass, `/kk:test` completed
- [ ] Code review completed (Explicitly via `/kk:review-code:isolated` skill — which owns indexing its own `kk:review-findings`)
- [ ] New project conventions indexed as `kk:project-conventions` (skip if none established)
- [ ] (Plan mode only) `tasks.md` updated to `done`

If any item is unchecked, go back and complete it. Do NOT proceed to the next task with incomplete outputs.

### Step 4: Continue (plan mode only)

Follow the iteration procedure in [plan-mode.md](plan-mode.md) — move to next task, repeat Steps 1–3.

### Step 5: Complete (plan mode only)

Follow the completion procedure in [plan-mode.md](plan-mode.md) — final validation, documentation, reflection.

## When to Stop and Ask for Help

**STOP executing immediately when:**

- Hit a blocker (missing dependency, test fails, instruction unclear)
- (Plan mode) Plan has critical gaps preventing starting
- You don't understand a requirement or instruction is ambiguous
- Verification fails repeatedly

**IMPORTANT! Always ask for clarification rather than guessing.**

## When to Revisit Earlier Steps

**Return to Step 1 when:**

- Partner updates the plan or clarifies the problem
- Fundamental approach needs rethinking

**IMPORTANT! Don't force through blockers** — stop and ask.

## Remember

- Review plan critically first
- Follow plan steps exactly
- Don't skip verifications
- Use skills when applicable (`/kk:dependency-handling`, `/kk:test`, `/kk:review-code:isolated`) (Plan mode: also when the plan says to do so)
- Between batches: just report and wait
- Stop when blocked, don't guess

standalone-mode.md 1 KB

# Standalone Mode

Applies for bug fixes, GitHub issues, one-off tasks, and any work without docs/feat/wip infrastructure.

## Entry Procedure

1. Parse the user's request — what is the problem or requirement?
2. If the user references a GitHub issue, fetch it (`gh issue view`)
3. **Capy search:** Search `kk:arch-decisions`, `kk:project-conventions`, `kk:lang-idioms`, `kk:review-findings`, and `kk:debug-context` for relevant prior context
4. Identify questions or ambiguities — ask before assuming
5. Investigate the relevant code — read files, trace call paths, reproduce the bug if applicable
6. Identify the set of files that will need changes
7. State the approach briefly if the fix is non-trivial (more than a few lines across 1–2 files). For trivial fixes, skip the approach statement only — "trivial" never exempts a fix from SKILL.md Step 2's pre-write steps (profile detection, dependency handling), which run for every fix however small.

After completing the entry procedure, return to SKILL.md Step 2 (Execute).