# Pc Feature Development

> Use when a reviewed task slice has tests or acceptance targets and the team must turn it into a small, mergeable implementation increment without expanding scope, breaking contracts, or hiding release-boundary risk.

- Skill: `yknothing/pc-feature-development` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add yknothing/pc-feature-development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yknothing/pc-feature-development/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: yknothing (https://skillmd.com/u/yknothing)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yknothing/pc-feature-development

---


# Feature Development

> Implement the next reviewed slice as a small, test-backed increment that can be reviewed and delivered safely.

## Context

Feature development is where plans become working behavior.

See [context](references/context.md) and [anti-pattern](references/anti-patterns.md) notes.

## Inputs

[I/O contract notes](references/io-contract.md) define required inputs and authority.

## Process

### Step 1: Pick the Smallest Reviewable Slice

Choose one reviewed task or thin vertical slice. Rewrite it in concrete implementation terms: what behavior lands now, what stays out of scope, and what boundary must remain stable.

If the slice is still too large to review comfortably, split it before coding.

### Step 2: Implement Behind the Test Boundary

Use the failing or targeted tests as the implementation guardrail. Add only the code needed to satisfy the current slice. Keep new abstractions local until a second use proves they belong.

Prefer vertical progress over partial framework setup. A small end-to-end slice is more valuable than three half-finished layers.

### Step 3: Preserve Scope and Contract Boundaries

Before each commit or reviewable checkpoint, verify:

- unsupported or deferred behavior is still explicit
- public contract changes are intentional and reflected in tests
- brownfield coexistence or compatibility seams still hold
- configuration, observability, and rollout hooks required by downstream phases are not skipped

### Step 4: Prepare the Increment for Review

Clean up obvious naming, dead code, and accidental noise that would distract review, but do not turn implementation into a refactoring detour. The output should be a small, understandable diff with passing tests and explicit notes on any trade-offs.

## Outputs

Produce only declared outputs at their documented quality boundary.

## Quality Gate

- [ ] One reviewed task slice is fully implemented
- [ ] Relevant tests pass locally or in CI
- [ ] Scope, unsupported behavior, and release boundaries remain explicit
- [ ] Public contract changes are intentional and documented
- [ ] The diff is small enough for effective review

## Distribution

- Public install surface: `skills/.curated`
- Canonical authoring source: `skills/04-implementation/pc-feature-development/SKILL.md`
- This package is exported for `npx skills add/update` compatibility.
- Packaging stability: `beta`
- Capability readiness: `beta`
- Portability: `portable_with_caveat`
- Public caveat: Portable as skill guidance; full governance guarantees require the Prodcraft repository contracts and validation checks.