voice-before-structure

name	voice-before-structure
model	sonnet
description	Read the project's design language and philosophy before writing structural artifacts. Ground manifests, READMEs, and descriptions in the project's voice, not boilerplate. Use when creating manifests or READMEs for established projects, writing ecosystem-level documentation, building plugin descriptions or marketplace metadata, or authoring metadata that carries a project's identity. Trigger phrases: 'write the manifest', 'create a README', 'describe this plugin', 'ground yourself in the philosophy', 'ecosystem-level work'.
category	wisdom-garden
triggers	["write the manifest","create a README","describe this plugin","ground yourself in the philosophy","ecosystem-level work"]
tier	1
agents	["primary"]
tool_dependencies	["file_system"]
inputs	[{"name":"project_context","type":"string","description":"Description of the project whose design language and philosophy to read before writing","required":true},{"name":"artifact_type","type":"string","description":"Type of artifact to produce — manifest, README, description, or metadata","required":false}]
outputs	[{"name":"voiced_artifact","type":"string","description":"Project-voice-grounded artifact (manifest, README, description, or metadata) written in the established design language"}]

Voice Before Structure

Philosophy

Structure without voice is generic cargo. A manifest read aloud should unmistakably belong to this project, not any project. The voice — the project's design language, founding tensions, philosophy — informs the naming, descriptions, and framing of everything you build.

When you write structural artifacts (manifests, READMEs, descriptions) in a vacuum, you get rewrite cycles. When you ground them in the philosophy first, they land. The difference between "strategic planning tools" and "begin with a tension, not a solution" is the difference between cargo and cargo with identity.

When to Use

• Starting ecosystem-level work: plugin builds, marketplace setup, documentation overhauls
• Creating identity-bearing documents: manifests, READMEs, descriptions, schemas
• Writing for established projects: ones with recognizable design language or founding philosophy
• Metadata authoring: anything that carries the project's identity outward

Avoid using this when working on utility code or implementation details that don't need to express the project's voice.

Workflow

Before Writing Structure

1. Identify philosophy documents in the project (README, design language docs, founding reflections, core principles, vision statements)

2. Read 2-3 documents — enough to hear the voice, not so many that you stall execution

   • What tensions does this project address?
   • What language does it use repeatedly?
   • What does it refuse to do?
   • What's the underlying philosophy?

3. Absorb the voice — not just facts, but how the project thinks

   • Naming conventions and style
   • Metaphors it uses
   • Values it prioritizes
   • Problems it frames differently than standard industry language

4. Draft the structural artifact with voice as a constraint, not an afterthought

   • Use the project's language for concepts
   • Match the tone and cadence
   • Reference the founding tensions or philosophy where relevant

5. Read aloud — the quality check

   • Does it sound like it belongs to this project?
   • Could it belong to any project (generic = failed)?
   • Would someone familiar with the philosophy recognize these descriptions?