---
name: coding-skill
description: Explicitly commissioned coding workflow with Planning by default, explicit Direct mode, and task-selected execution techniques. Reading or editing this example and ordinary code changes do not activate the workflow; execution organization and Git remain with their configured owners.
disable-model-invocation: true
---

# Coding Skill

## Activation and method

Use only on an explicit Coding Skill commission or a binding continuation of the same undertaking. Reading, discussing or adapting this example does not activate its workflow. Ordinary small changes require no implicit ceremony; this is not a default wrapper for unrelated work.

A new commission starts in Planning unless the user explicitly requests Direct mode. A continuing assignment retains its established phase and technique; review or correction does not silently select Direct. Activation lasts until completion or explicit deactivation.

Planning records each execution task's technique, and the caller passes it explicitly. Ask when an execution assignment lacks a technique; never infer TestLater. Direct uses a concise immediate assignment under [Execution](references/execution.md), without a persisted planning ceremony.

## Capability and responsibility

Inspect the actual offered tools, configured resources, project rules and assigned access before choosing execution organization. A named tool in this example is not evidence of availability or permission. Use [User-facing](../user-facing-orchestrator/SKILL.md) for behavioral archetype, form choice, native delegation and control ownership, and [KISS](../kiss/SKILL.md) for approach decisions. Ask only material questions; do not impose a generic questionnaire.

Working technique and organization are independent. A local session, native workers or [Herdr workflow](../herdr-workflow/SKILL.md) retain the selected technique's requirements. Parallel work respects agreed limits, native runtime capacity and disjoint ownership, not a staffing target. Clarify a missing limit only when it materially changes the task. If desired delegation is unavailable, explain the gap and offer to research a suitable extension; research requires its applicable access authorization. Never install, activate or simulate a capability because this example names it.

Git branches, worktrees, commits, integration, synchronization and publication belong to the recipient's actual project Git rules and configured owner. Identify that source when the boundary arises. This example supplies no Git workflow, remote permission or package-publication policy.

## Implementation contract

Accepted requirements and specification anchors define scope and behavior. Code, tests and Git are evidence, not replacement authority. Use documented library/runtime contracts directly. For a binding conflict, make a bounded FIX only when it preserves requirements within authorization; otherwise BLOCK the affected work and name the missing decision, permission or safe continuation.

Implement real behavior directly. Remove obsolete implementation within actual authorization and rely on version control for history. Refactor the implementation rather than retaining shims, dead abstractions, commented-out replacements or transitional wrappers merely to preserve old structure. If removal is not authorized, report the concrete block.

Compatibility requires a deliberate requirement recorded at its responsible specification source and the smallest real mechanism it needs. Declare test doubles and simulations with their purpose and scope; never present them as production functionality.

Keep executable commands and payloads inspectable as plaintext. Observe actual process exit or native completion and evaluate the result immediately. Handle failures without marker waits or polling substitutes.

## Dependencies and documentation

For dependency changes, inspect the project's agreed version/update policy, manifests, lockfiles and configuration. Preserve required contracts and lockfiles. Clarify a missing material policy decision before changing it; installation authorization remains separate. This example supplies no universal version pinning or update cadence.

Documentation techniques add no universal file or review round:

- For Documentation for Human, read [Human documentation](references/documentation-human.md).
- For Documentation for LLM, read [Agent documentation](references/documentation-llm.md).

## Current phase and role

Read only the selected technique and current role/phase. Assignments carry relevant requirement excerpts, source anchors, concrete checks and method paths, not the full orchestration history.

| Current work | Read |
| --- | --- |
| Planning or plan review | [Planning](references/planning.md) |
| Selected TestLater | [TestLater](references/testlater.md) |
| Selected TDD | [TDD](references/tdd.md) |
| Dispatch, supervision, integration or resumption | [Execution](references/execution.md) |
| Assigned code-implementation worker | [Worker](references/worker.md) |
| Complete-plan, candidate, block or final review | [Review](references/review.md) |
| Selecting checks or judging evidence | [Validation](references/validation.md) |
| Actual Pi extension/tool/SDK development | [Pi development](references/pi-development.md) |

These are ordinary files, not additional advertised Skills or a dispatcher. Native Pi owns resource discovery and loading; loading grants no rights and guarantees no compliance.

## Completion

Evaluate the commissioned outcome and applicable checks on the actual unchanged delivered state. Close supported findings or report the concrete incomplete result. Report evidence and gaps, with synchronization, publication and remaining authorization separately stated. A source review or green test does not prove an unobserved capability.

For human adaptation of this complete, uninstalled example, see [CUSTOMIZE](CUSTOMIZE.md).