Write and validate Grove technical specifications with consistent formatting, ASCII art headers, diagrams, and the Grove voice. Use when creating new specs, reviewing existing specs for completeness, or standardizing spec formatting.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Write and validate Grove technical specifications with consistent formatting, ASCII art headers, diagrams, and the Grove voice. Use when creating new specs, reviewing existing specs for completeness, or standardizing spec formatting.
Grove Spec Writing
A comprehensive guide for writing technical specifications in the Grove ecosystem. Use this skill to create new specs that feel like storybook entries, or to validate and standardize existing specs.
When to Activate
Creating a new technical specification
Reviewing an existing spec for completeness
Adding ASCII art headers to specs missing them
Adding diagrams, mockups, or visual elements to text-heavy specs
Standardizing frontmatter across spec files
Validating a spec against Grove standards before finalizing
The Spec as Storybook Entry
Grove specs aren't just technical documents. They're storybook entries in a larger narrative. Each spec should feel like opening a page in a beautifully illustrated field guide to the forest.
The formula:
Cover page (frontmatter + ASCII art + tagline)
Introduction (what is this, in nature and in Grove)
The journey (architecture, flows, implementation)
The details (API, schema, security)
The path forward (implementation checklist)
Required Structure
1. Frontmatter (REQUIRED)
Every spec MUST have this exact frontmatter format:
---aliases: []
date created: [Day], [Month] [Ordinal] [Year]
date modified: [Day], [Month] [Ordinal] [Year]
tags:-primary-domain-tech-stack-categorytype:tech-spec---
╭──────────╮
╭──│ ╭──────╮ │──╮
╭─│ │ │ ╭──╮ │ │ │─╮
│ │ │ │ │♥ │ │ │ │ │
╰─│ │ │ ╰──╯ │ │ │─╯
╰──│ ╰──────╯ │──╯
╰──────────╯
every ring: a year, a story, a layer of growth
The center that holds it all.
3. Introduction Section
After the ASCII art header:
> *Poetic tagline repeated*
[2-3 sentence description of what this is in the Grove ecosystem]
**Public Name:** [Name]
**Internal Name:** Grove[Name]
**Domain:**`name.grove.place`**Repository:** [Link if applicable]
**Last Updated:** [Month Year]
[1-2 paragraphs explaining the nature metaphor and how it applies]
---
4. Body Sections
Organize content with clear headers. Include:
Overview/Goals — What this system does
Architecture — How it's built (with diagrams!)
Tech Stack — Dependencies, frameworks
API/Schema — Technical details
Security — Important considerations
Implementation Checklist — Clear action items
Required Visual Elements
Flow Diagrams
Every spec describing a process MUST include at least one ASCII flow diagram:
┌─────────────────────────────────────────────────────────────────────┐
│ Client Sites │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Site A │ │ Site B │ │ Site C │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
└─────────┼─────────────────┼─────────────────┼───────────────────────┘
│ │ │
│ 1. Request │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────────┐
│ Central Service │
│ │
│ ┌─────────────────────────┐ ┌─────────────────────────┐ │
│ │ Handler A │ │ Handler B │ │
│ └─────────────────────────┘ └─────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
Box drawing reference:
Corners: ┌ ┐ └ ┘ (square) or ╭ ╮ ╰ ╯ (rounded)
Lines: ─ │ ═ ║
Joins: ├ ┤ ┬ ┴ ┼
Arrows: → ← ↑ ↓ ▶ ◀ ▲ ▼
UI Mockups
Specs describing user interfaces MUST include ASCII mockups:
---
aliases: []
date created: Monday, January 6th 2026
date modified: Monday, January 13th 2026
tags:
- support
- user-communication
- cloudflare-workers
type: tech-spec
---# Porch — Support System
> *Have a seat on the porch. We'll figure it out together.*
Grove's front porch: a warm, accessible space where users sit down and have a conversation. Not a corporate help desk with ticket numbers. A porch where you chat with the grove keeper about what's going on.
**Public Name:** Porch
**Internal Name:** GrovePorch
**Domain:** `porch.grove.place`
**Status:** Planned (Launch Priority)
A porch is where you sit and talk. You come up the steps, have a seat, and the grove keeper comes out to chat. It's not a ticket counter. It's two people on a porch, figuring things out together.
---
Integration with Other Skills
Before Writing a Spec
walking-through-the-grove — If naming a new feature, complete the naming journey first
grove-ui-design — If the spec involves UI, understand design patterns
While Writing
grove-documentation — Apply Grove voice throughout, avoid AI patterns
After Writing
grove-spec-writing (this skill) — Run validation checklist
Review with fresh eyes: Does it feel like a storybook entry?
When to Use museum-documentation Instead
This skill (grove-spec-writing) is for internal technical specifications: architecture decisions, system design, implementation plans. Documentation for developers.
Use museum-documentation when writing for Wanderers who want to understand:
Use grove-spec-writing
Use museum-documentation
Technical specifications
"How it works" for curious visitors
Architecture decisions
Codebase guided tours
Implementation plans
Knowledge base exhibits
Internal system docs
Narrative technical explanations
If the reader is a developer implementing something, use this skill.
If the reader is a Wanderer exploring the forest, use museum-documentation.
Quick Reference
Element
Required
Location
Frontmatter
Yes
Top of file
ASCII art header
Yes
After frontmatter
Poetic tagline
Yes
After ASCII art
Public/Internal names
Yes
Introduction
Architecture diagram
If applicable
Body
UI mockups
If has UI
Body
Implementation checklist
Yes
End of spec
A good spec is one you'd want to read at 2 AM. Make it beautiful.
