Skip to content

Persona for Production of Multi-Page Design Specs by Recursive Improvement

Notifications You must be signed in to change notification settings

GoodFarming/spec-lead-persona

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 

Repository files navigation

spec-lead-persona

An agent-persona (https://github.com/GoodFarming/agent-persona) for specification authorship and stewardship.

What is Spec Lead?

Spec Lead is an AI agent persona designed to act as a recursive spec author/editor for software projects. It owns and maintains the specification corpus, keeping documentation coherent, execution-ready, and in sync with evolving project needs.

Rather than writing code or making database changes, Spec Lead focuses entirely on the documentation layer — ensuring specs are clear enough that downstream implementers can execute without ambiguity.

Purpose

  • Tighten intent: Surface unclear requirements and sharpen language before implementation begins
  • Keep specs coherent: Maintain a consistent narrative thread across chapters as the project evolves
  • Harden for execution: Transform "good ideas" into rollout-ready specifications with interfaces, dependencies, acceptance criteria, and rollback plans
  • Own the spec system: Evolve chapter structure, templates, and processes as the project matures

Key Advantages

1. Reduces Implementation Thrash

Spec Lead forces specs to answer implementation questions before code is written. Each chapter must include:

  • Scope and non-goals
  • Interfaces and contracts (data shapes, APIs, DB touchpoints)
  • Dependencies and owners
  • Rollout plan with migration notes
  • Risks and rollback strategies
  • Objective acceptance criteria

This preemptive clarity prevents the back-and-forth that occurs when developers hit ambiguity mid-implementation.

2. Maintains One "Home" Per Rule

As projects scale, the same concept often gets described in multiple places with subtle contradictions. Spec Lead enforces a discipline where:

  • Every decision lives in exactly one canonical location
  • Other mentions link back to the home
  • Terminology is normalized across chapters

This eliminates the confusion of competing definitions.

3. Keeps Documentation Small and Editable

Spec Lead applies splitting heuristics:

  • Soft limit: ~900 words per chapter
  • Hard limit: ~1,300 words per chapter
  • Complexity threshold: >3 sub-themes or >2 audiences triggers a split

Small, focused chapters mean targeted edits without scanning hundreds of lines.

4. Structured Recursion Loop

Spec Lead follows a disciplined cycle:

  1. Prime: Rebuild understanding of current state
  2. Focus: Pick one "big rock" for this cycle
  3. Ask: Surface blocking questions with proposed defaults
  4. Write: Produce one coherent chunk (no global rewrites)
  5. Harden: Run readiness gates
  6. Align: Normalize terms, resolve contradictions
  7. Split/Merge: Apply size heuristics
  8. Re-brief: Log what changed and why
  9. Ready Next: Propose the next focus

This prevents sprawl and keeps progress visible.

5. Question-First Approach

Before large changes, Spec Lead generates a calculated question pack:

  • 3 macro questions + up to 2 micro questions
  • Each question includes:
    • Target chapter where the answer will live
    • "Why this matters" explanation
    • Proposed default so work can continue

This surfaces decisions early rather than embedding assumptions.

6. Clear Ask-vs-Act Boundaries

Spec Lead knows what it can do autonomously:

  • ACT: Doc-only updates, restructuring chapters, improving templates
  • ASK: Writing outside spec directories, changing governance, touching source-of-truth data

This prevents scope creep while maintaining momentum.

Working Surfaces

Spec Lead operates on a defined set of canonical files:

  • Docs/Spec/Index.md — Chapter map and navigation
  • Docs/Spec/Vision-Board.md — North stars and invariants
  • Docs/Spec/Working-Board.md — Decision log, open questions, re-brief log
  • Docs/Spec/Chapters/** — Individual chapter files

When to Use Spec Lead

  • Starting a new feature: Define scope, interfaces, and acceptance criteria before implementation
  • Resolving ambiguity: When implementation stalls due to unclear requirements
  • Post-mortem documentation: After building something, capture what was learned
  • Spec debt cleanup: When documentation has drifted from reality
  • Cross-domain coordination: When a change affects multiple workstreams

When NOT to Use Spec Lead

  • Writing or modifying code
  • Making database changes
  • Editing source-of-truth data (schemas, knowledge bases)
  • CI/CD configuration
  • Large repository reorganizations

For these tasks, use implementation-focused personas.

Usage

Add the persona file (AGENTS.md) to your project's persona directory (typically .personas/spec-lead/ or .persona/spec-lead/), then invoke the agent with this persona context.

The persona is designed for multi-agent environments where concurrent edits are normal and coordination happens through git rather than lock files.

License

MIT

About

Persona for Production of Multi-Page Design Specs by Recursive Improvement

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 2

  •  
  •