Plan

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

- REQ-<SYSTEM>-<CAPABILITY>-001

- REQ-<SYSTEM>-<CAPABILITY>-001

- AC-<SYSTEM>-<CAPABILITY>-001.1

.claude/agents

.claude/skills

.github/CLAUDE.md

CLAUDE.md

apps/backend/CLAUDE.md

import { test, expect } from "../../fixtures/test-base";

apps/web/generated/licenses.json

Audit 0.4.1 · source sha 786d4817799e · 18 Oct 2026Report an issue or request a re-scan

• Publisherkdlbs GitHub organizationOwner of the repository this skill is read from
• Source folderkdlbs/kandev/.agents/skills/planThe exact folder we audited
• LicenceAGPL-3.0As the repository states it
• Commit pinned for this verdict786d4817799eA new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Create an implementation plan and work orders from approved requirements and current system designs. Leave the design package uncommitted for review before implementation.

---
name: plan
description: Create an implementation plan and work orders from approved requirements and current system designs. Leave the design package uncommitted for review before implementation.
---

# Create an Implementation Plan

Translate requirements and system designs into a delivery plan under
`docs/plans/<initiative>/`. The plan and its work-order files are implementation
records. They are not product specifications.

Read `docs/specs/guide/plans-and-work-orders.md` and
`docs/specs/guide/traceability-and-lifecycle.md` before you write the plan.

## Inputs

Read these sources in full:

- The applicable requirement documents and `REQ-*` or `AC-*` IDs.
- The applicable system-design documents.
- Related ADRs.
- The relevant source, tests, and one similar implementation.

Use the legacy feature specification during migration only when no replacement
requirement or design exists.

Read each spec's `Implementation Plans` and related-plan links, then inventory
all existing companion plan directories. Treat linked packages as one
synchronized implementation record: reconcile every affected task scope, E2E
scenario matrix, status, and exact final verification results/counts before
completion.

## Outputs

Create:

```text
docs/plans/<initiative>/plan.md
docs/plans/<initiative>/task-<NN>-<short-slug>.md
```

`plan.md` is the work-package manifest. Each `task-*.md` file is one work order.

## Workflow

### 1. Map the change

Run the `/interview-me` assumption check, reusing settled specification choices.
Resolve material blockers before decomposing the affected work. For large
uncertain initiatives, use that skill's decision-mapping reference first.

Identify:

- The required outcomes and acceptance criteria.
- The design boundaries that implementation must preserve.
- Existing models, repositories, services, handlers, clients, stores, and UI.
- Existing tests and end-to-end patterns.
- The dependency order for implementation.

Use `python3 scripts/list-docs.py decisions --text <capability-term> --format paths`
to locate relevant decisions. Stop when the requirements, system design, ADRs,
and code disagree on a material boundary.

### 2. Write `plan.md`

Use this structure:

```markdown
---
created: YYYY-MM-DD
status: draft
requirements:
  - REQ-<SYSTEM>-<CAPABILITY>-001
system_design:
  - ../../specs/<system>/system-design/<capability>.md
legacy_specs: []
---

# Implementation Plan: <Initiative>

## Overview

State the result, the implementation order, and the reason for that order.

## Scope

### In scope

- List the owned outcomes.

### Out of scope

- List explicit exclusions.

## Technical approach

Name exact files, symbols, schema changes, contracts, and integration points.
Organize this section by implementation boundary or vertical slice.

For a shared provider or adapter path, include a compact compatibility matrix
covering the provider, transport, identity or capability shape, intended
behavior, verification evidence, and unsupported-shape fallback. Shared
implementation does not imply that every provider is supported; state
conditional coverage explicitly.

## ASCII UI preview

Required when rendered UI changes. Follow the preview contract in
`docs/specs/guide/plans-and-work-orders.md`: show labelled views, relevant
states, desktop/phone composition, and structural requirements. Omit for
packages without UI changes.

## Tests

Map every relevant acceptance criterion to its unit or integration evidence.
Name the exact test file and method.

## E2E tests

Include this section when the change has user-visible behavior. Map each flow
to the applicable `AC-*` IDs and name the Playwright file and project.

## Work orders

- [ ] [Task 01: <Title>](task-01-<slug>.md)

## Verification results

Pending.

## Risks

- Name concrete delivery or compatibility risks.

## Open questions

Delete this section when it is empty.
```

Do not place complete work-order bodies in `plan.md`.

### 3. Write work orders

Use this structure:

````markdown
---
id: "01-<slug>"
title: "<Title>"
status: pending
wave: 1
depends_on: []
plan: "plan.md"
requirements:
  - REQ-<SYSTEM>-<CAPABILITY>-001
acceptance_criteria:
  - AC-<SYSTEM>-<CAPABILITY>-001.1
system_design:
  - ../../specs/<system>/system-design/<capability>.md
---

# Task 01: <Title>

## Summary

State the implementation outcome in two or three sentences.

## In scope

- List the responsibilities that this work order owns.

## Out of scope

- List adjacent work that this work order does not own.

## Acceptance

- Give one to three concrete implementation conditions.

## ASCII UI preview

For a UI work order, include its relevant view or excerpt from the plan with
the same view label, a link to the full preview, and applicable AC references.
Omit for work orders without rendered UI changes.

## Verification

```bash
<exact targeted command>
```

## Files likely touched

- `path/to/file`

## Dependencies

Name prior work orders or write `None`.

## Risks

- Name concrete implementation or compatibility risks, or write `None`.

## Parallelism

`sequential`

## Inputs

- Requirement and system-design sections.
- Existing code and test patterns.

## Results

Pending.
````

Each work order must deliver one independently verifiable outcome in one focused
implementation pass. Prefer a narrow end-to-end slice. Split by layer only for
a real dependency or verification boundary, not because files occupy different
directories. Title wording does not determine task boundaries.

For broad migrations that cannot proceed in vertical slices, sequence compatible
expansion, bounded caller migrations, and final removal of the old contract.
If a batch cannot pass independently, keep it with its required integration in
one work order. Add only dependencies that actually block the outcome. Preserve
the exact acceptance IDs, likely files, and verification commands in each work order.

Use `parallel-safe` only when files are disjoint and the tasks share no schema,
migrat

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/kdlbs/kandev
git -C kandev checkout 786d4817799e

Works in

1. 2026-10-18
   ✕BLOCK D 69 / 100

   first audit · source 786d4817799e

Questions about Plan

• github.com/kdlbs/kandev/tree/main/.agents/skills/plan — the audited source at commit 786d4817799e and every finding aboveObserved · 18 Oct 2026

Spotted something wrong? Report a correction · Methodology