# Create Pillars Document

> Creates or updates PILLARS.md from repository evidence and identity context. Use when a project needs to define, repair, or review the foundational pillars that support its purpose and values.

- Skill: `egohygiene/create-pillars-document` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add egohygiene/create-pillars-document`
- Raw SKILL.md: https://api.skillmd.com/api/skills/egohygiene/create-pillars-document/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: egohygiene (https://skillmd.com/u/egohygiene)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/egohygiene/create-pillars-document

---


# Create Pillars Document

<!-- aether-continuity-disposition: reader-writer -->

## Repository continuity composition

For repository-scoped work, compose `maintain-repository-continuity` in
**Resume** mode before selecting work. After an authorized repository change
passes domain validation, compose **Refresh** and **Verify** immediately before
presenting the pull request, and include the reconciled root `CONTINUITY.md` in
the same change. A policy-permitted no-change or exemption result must be
documented instead of fabricating an edit.

- **Contribute:** Pillars, supporting evidence, tensions, validation, and unresolved stakeholder review
- **Never claim:** That drafted pillars have stakeholder adoption without evidence

## Purpose

Create or update `PILLARS.md` in conformance with `architecture-pillars`.

Primary question:

> What enduring capabilities must remain strong for this work to succeed?

## Use This Skill When

- the canonical document does not exist
- an existing document is incomplete or inconsistent
- upstream identity has changed
- repository architecture is being established or repaired

## Required Inputs

- PURPOSE.md
- VISION.md
- PRINCIPLES.md
- historical and current strategic work
- recurring capabilities
- organizational strengths and gaps
- long-term responsibilities

Missing evidence must be recorded rather than invented.

## Workflow

1. Read upstream identity documents.
2. Identify recurring capabilities needed across multiple initiatives.
3. Remove temporary projects and technologies.
4. Group overlapping capabilities.
5. Define clear boundaries.
6. Validate contribution to purpose and vision.
7. Test whether future initiatives can align to the set.
8. Keep the set intentionally small.

## Output Contract

Produce:

- `PILLARS.md`
- governing specification identifier and version
- assumptions and unresolved questions
- validation results
- downstream review recommendations

## Constraints

- Preserve canonical terminology.
- Separate evidence from inference.
- Do not fabricate intent.
- Do not introduce implementation details outside the specification.
- Do not silently resolve contradictions.
- Do not claim completion when upstream artifacts are missing.

## Validation

Use `references/validation-checklist.md` and the acceptance criteria in
`architecture-pillars`.

## Completion Criteria

- [ ] The governing specification is identified.
- [ ] Required upstream evidence has been read.
- [ ] The document answers its primary identity question.
- [ ] Non-responsibilities are respected.
- [ ] Assumptions and open questions are visible.
- [ ] Structural, semantic, relationship, and evidence checks pass.
- [ ] Downstream review needs are reported.