# Dev Skeleton

Source-first project skeletons for LLM-assisted development: short skill prompts and templates that record purpose, non-goals, truth sources, durable constraints, and review preferences instead of maintaining a stale implementation knowledge base.

## Metadata

- HTML: https://glenzli.com/en/projects/dev-skeleton/
- Markdown: https://glenzli.com/en/projects/dev-skeleton.md
- Collection: Projects
- Language: en
- Published: 2026-07-02
- Status: active
- Tags: skill, source-first, prompt, review, llm

## Content

Dev Skeleton, published as `dev-skeleton`, is a set of source-first skill prompts and copyable templates for LLM-assisted development. It does not try to compress a project into an implementation knowledge base. It gives the model durable orientation before source reading: purpose, non-goals, truth sources, stable constraints, entry hints, and review preferences.

It is not tied to a specific agent runtime and does not ship a CLI, source index, KB builder, or project-management workflow. Facts still come from code, config, tests, release artifacts, and maintained docs. The skeleton only tells the model what to inspect, what not to trust, and which boundaries matter.

## Project Entry

  ![dev-skeleton compresses messy project context into a source-first skeleton](/images/projects/dev-skeleton-banner.webp)

## Why Not A Knowledge Base

    **Source is authority**
    Code, config, tests, release artifacts, and maintained docs are factual sources. Skeletons must not replace current source.

    **Skeletons orient**
    They record purpose, non-goals, stable constraints, truth sources, domain assumptions, entry hints, and review priorities.

    **No implementation mirror**
    Do not summarize modules, classes, functions, call graphs, APIs, or current behavior. Let the model read source for the task at hand.

    **Refresh sparingly**
    Update only when durable intent, constraints, truth sources, or review preferences change. Routine implementation edits should not update skeletons.

The problem is practical: project context often turns into stale summaries. The more detailed the summary becomes, the more it competes with source. Dev Skeleton constrains itself in the other direction. It keeps only stable orientation and hands implementation judgment back to source.

## Four Skills

      **skeleton-init**
      Create initial `DEV_SKELETON.md`, `REVIEW_SKELETON.md`, and `AGENTS.md` files in a target repository.

```markdown
Create three short orientation files, not a knowledge base.

Read authoritative files:
- README
- manifests and config
- release notes
- tests and schemas
- obvious entrypoints

Capture only durable orientation:
- purpose and non-goals
- truth sources
- constraints
- entry hints
- review priorities
```

Initialization is where context most easily turns into a project encyclopedia. This skill pushes the result back into a skeleton: behavior that can be read from source should not be copied into skeleton files.

      **skeleton-refresh**
      Refresh skeletons only after durable direction changes, not after ordinary refactors, helper renames, or test churn.

```markdown
Refresh for:
- project purpose or non-goals
- runtime, platform, or release boundaries
- source-of-truth files
- stable domain assumptions
- review priorities or red lines

Skip routine implementation movement.
```

The point is to avoid documentation work that tracks every implementation move. If only current behavior changed, the model should read source next time.

      **skeleton-audit**
      Audit skeletons for bloat, stale claims, and source-first violations.

```markdown
Check:
- Does DEV_SKELETON state purpose, non-goals, truth sources, constraints, and refresh triggers?
- Does REVIEW_SKELETON state review priorities and red lines?
- Does any file summarize modules, classes, functions, or behavior that should be read from source?
- Does any file imply skeleton content is authoritative?
```

The output should lead with findings and say whether to delete, shorten, or reframe each issue. It is the brake that keeps skeletons from becoming stale KBs.

      **review-skeleton**
      Use project review preferences to shape review while grounding facts in diffs, source, config, tests, and release artifacts.

```markdown
Use skeletons to bias review, not to prove facts.

Read:
- REVIEW_SKELETON.md
- DEV_SKELETON.md when project purpose matters
- actual diff, source, config, tests, and release artifacts

Lead with findings ordered by severity.
```

It fits code review, design review, and change assessment. If skeletons conflict with source, source wins for facts and skeleton drift becomes a review finding.

## File Roles

| File or directory | Role |
| --- | --- |
| `skills/skeleton-init/SKILL.md` | Create the three source-first skeleton files. |
| `skills/skeleton-refresh/SKILL.md` | Refresh skeletons after durable direction changes. |
| `skills/skeleton-audit/SKILL.md` | Find bloat, stale claims, and source-first violations. |
| `skills/review-skeleton/SKILL.md` | Run source-first review with project review preferences. |
| `templates/DEV_SKELETON.md` | Project orientation template for a target repo. |
| `templates/REVIEW_SKELETON.md` | Review preference template for a target repo. |
| `templates/AGENTS.md` | Agent entry template for a target repo. |

## Boundaries

Dev Skeleton fits repositories that already use AI agents in development but do not want to maintain a project encyclopedia. It provides short, stable orientation. It is not onboarding documentation, a test manual, a release workflow, a source index, or a multi-agent orchestration system.

When a skeleton starts explaining how the current code works, delete that detail and send the model back to source.