skeleton

Generates reviewable code skeletons with real signatures and intentionally unimplemented bodies from implementation plans.

Updated May 11, 2026
One-click install
npx skills add https://github.com/mmnavarr/harness --skill skeleton-mmnavarr
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: skeleton
Source: https://github.com/mmnavarr/harness/tree/main/skills/skeleton
Command: npx skills add https://github.com/mmnavarr/harness --skill skeleton-mmnavarr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often jump straight from a plan to full implementation, making it hard to review architecture, file layout, and dependency wiring before real logic is written. This Skill produces a code skeleton with real files, names, and call flow but deliberately empty bodies, so reviewers can validate the shape of a feature before any business logic exists. ## Core Features & Use Cases - Shape-first scaffolding: Creates real files, public types, function signatures, routes, and dependency injection wiring that mirror the final implementation. - Loud stubbing: Bodies fail fast with explicit not-implemented signals (e.g., throw new Error("Not implemented"), NotImplementedError, todo!()) instead of fake data or silent placeholders. - Verification of wiring, not behavior: Runs the narrowest formatter, typecheck, or build check to prove files parse and dependencies resolve. - Use Case: Given a plan for a new billing webhook feature, generate the route registration, handler signature, service interface, and DI wiring across the repo so reviewers can approve the architecture before logic is written. ## Quick Start Use the skeleton skill to scaffold the file and function layout for my planned notification retry feature without writing the actual logic.

Frequently Asked Questions about skeleton

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I scaffold code from an implementation plan before writing logic?▼

Provide the plan and request a skeleton: the workflow creates real files, public types, function signatures, and call chains matching your repo conventions, with bodies that throw explicit not-implemented errors. Reviewers can then approve the shape before logic is written.

What should a code skeleton include for architecture review?▼

A skeleton should include module and class definitions, public interfaces and types, route or handler registration, dependency injection wiring, and exports. It should exclude real algorithms, persistence logic, mock data, and behavior tests.

Should stub functions return placeholder data or throw errors?▼

Stubs should fail fast with explicit not-implemented signals like NotImplementedError or todo!(), never return plausible fake data. Silent placeholder success misleads reviewers into thinking behavior is complete.

When should I not use skeleton scaffolding?▼

Do not use it for normal implementation work or when you need working behavior; skeletons only satisfy shape review, not acceptance criteria. It is intended only for explicit scaffold or stub requests before real logic is written.

How do I verify a code skeleton is correctly wired?▼

Run the narrowest formatter, typecheck, build, or import check that proves files parse and dependencies resolve. If runtime execution hits an intentional not-implemented stub, report that boundary as expected evidence rather than a failure.