cogeet-ai-development-specifications — Summary

cogeet-ai-development-specifications is a set of five comprehensive specification documents (.txt files) that define "Infrastructure as Code for AI-assisted development" — applying spec-as-code, testing-as-code, documentation-as-code, context-engineering-as-code, and coding-best-practices-as-code paradigms to AI developer workflows. Each file is a self-contained specification template (~100-200 lines of structured pseudo-code with DEFINE_STAGE, DEFINE_TASK, DEFINE_PRINCIPLE, DEFINE_CONTEXT_PATTERN macros) that teams copy and fill in. There is no CLI, no agent runtime, no hooks — only the specification documents and a PRD template. The target audience is development teams, tech leads, and organizations wanting to systematize AI-assisted development with measurable quality gates.

Differs from seeds: Pure Archetype 4 "Markdown scaffold, zero primitives" but implemented in a structured pseudo-code DSL (.txt files with TOML-like macro syntax) rather than plain markdown. The closest seed is claude-conductor (documentation scaffold) or agent-os (standards files), but cogeet ships a richer specification language with DEFINE_STAGE, DEFINE_TASK, DEFINE_PRINCIPLE macros and explicit quality metric targets (completeness ≥ 0.85, relevance ≥ 0.80, test coverage 90%) rather than markdown prose. Unlike SPEC-KIT (which automates spec creation via hooks), cogeet provides only the specification templates — enforcement is entirely up to the implementing team.

cogeet-ai-development-specifications — Overview

Origin

GitHub: cogeet-io/ai-development-specifications (32 stars, 14 forks, MIT). Author: Cogeet.io. No code, only .txt specification files. Last pushed 2026-02-12.

Philosophy

From README:

"Most AI agent failures aren't model failures - they're context failures." "Stop fighting AI coding assistants. Start engineering them."

The "Six Pillars" (actually five spec files + PRD template):

1. Product Requirements Document Template — The source driving everything
2. Specification as Code — Build pipeline specs
3. Context Engineering as Code — Systematic context assembly
4. Testing as Code — 15+ advanced testing strategies
5. Documentation as Code — Automated documentation practices
6. Coding Best Practices as Code — SOLID/DRY enforcement

The framework positions "Context Engineering" as its key innovation:

"AI failures are usually context failures, not model failures. This specification provides the first systematic approach to engineering context for reliable AI assistance."

Key Claims

• "10x improvement in AI task success rates"
• "50% reduction in debugging and rework time"
• "85% consistency in code quality across teams"

Design Approach

The spec files use a structured pseudo-code DSL:

DEFINE_STAGE(setup_and_config)
DEFINE_TASK "Initialize Project Structure" {
  [manifest] { task_type = "FileSystemSetup", failure_strategy = "Halt" }
  id: setup-project
  depends: [setup-project]
}

This is influenced by Infrastructure-as-Code conventions applied to development process specification.

Inspiration Cited

• Infrastructure as Code principles
• Karpathy's and Lutke's context engineering principles
• Agile/DevOps/CI-CD automation patterns

cogeet-ai-development-specifications — Architecture

Distribution

• Type: Methodology document set (standalone repo)
• Install: Copy files to project, edit, use as AI context
• License: MIT
• Language: None (structured text with pseudo-code DSL)

Directory Tree

ai-development-specifications/
  README.md
  LICENSE
  Product-Requirements-Document-Template.txt
  Specification-as-Code.txt
  Context-Engineering-as-Code.txt
  Testing-as-Code.txt
  Documentation-as-Code.txt
  Coding-Best-Practices-as-Code.txt

Five Specification Files

Required Runtime

None — works with any AI that reads text files.

DSL Syntax

Files use a structured pseudo-code format:

[environment]
target_ai_systems = ["claude_code", "copilot", "cursor", "local_llm"]

DEFINE_STAGE(stage_name)
DEFINE_TASK "Task Name" {
  [manifest] { task_type = "...", failure_strategy = "..." }
  id: task-id
  stage: stage_name
  depends: [other-task]
  description: "..."
}
DEFINE_PRINCIPLE(principle_name) {
  [manifest] { scope = [...], enforcement = "mandatory" }
  rule: "..."
  quality_metrics = { completeness = { min = 0.85, target = 0.95 } }
}

cogeet-ai-development-specifications — Components

Specification Files (6)

Specification-as-Code.txt

Defines build pipeline specification with:

• DEFINE_STAGE macros: setup_and_config, core_implementation, integration, testing_and_validation, packaging_and_deployment
• DEFINE_TASK with task_type, failure_strategy, depends
• Stage transitions and dependency graphs

Context-Engineering-as-Code.txt

Defines context engineering principles with:

• DEFINE_PRINCIPLE(comprehensive_context) — 6 context dimensions
• DEFINE_PRINCIPLE(dynamic_context_assembly) — strategies for task-specific context
• DEFINE_PRINCIPLE(validated_context_quality) — quality metrics (completeness ≥ 0.85, relevance ≥ 0.80, accuracy ≥ 0.95)
• DEFINE_CONTEXT_PATTERN(rust_actor_implementation) — domain-specific context templates
• Context for: code generation, debugging, refactoring, code review, documentation

Testing-as-Code.txt

15+ testing strategies including:

• Property-based testing
• Mutation testing
• Fuzz testing
• E2E tests
• Performance monitoring
• Automated CI/CD pipeline integration

Documentation-as-Code.txt

Automated documentation with:

• Generation validation
• Living documentation (evolves with code)
• Quality measurement and continuous improvement

Coding-Best-Practices-as-Code.txt

SOLID/DRY enforcement with:

• Language-specific patterns (Rust, C#, Python, JavaScript)
• Automated validation rules
• Code quality metrics

Product-Requirements-Document-Template.txt

PRD structure template that feeds all other specifications.

Commands / Skills / Hooks

None. All enforcement is manual — the specifications describe what should happen, not automated tooling.

cogeet-ai-development-specifications — Uniqueness

Differs from Seeds

Closest to claude-conductor (documentation scaffold) and agent-os (standards files), but distinguished by: (1) a structured pseudo-code DSL (DEFINE_STAGE, DEFINE_TASK, DEFINE_PRINCIPLE macros) instead of plain markdown — giving the specs a machine-readable-looking format even though no runtime consumes them; (2) quantified quality targets embedded in the specifications (completeness ≥ 0.85, accuracy ≥ 0.95, task_success_rate = 0.90) — more specific than any seed's quality guidance; (3) Context Engineering as a first-class pillar with 6 context dimensions and dynamic assembly strategies — the most systematic treatment of context as an engineering discipline in the batch; (4) SOLID/DRY-as-code patterns for specific languages (Rust, C#, Python, JS) as a specification file. Unlike agent-os (which ships commands to write the markdown), cogeet ships only the specification documents — no tooling whatsoever.

Positioning

• Target user: Development teams and tech leads who want to systematize AI-assisted development without adopting a specific tooling framework
• Key differentiator: The Context-Engineering-as-Code.txt is the most comprehensive treatment of context assembly as an engineering discipline in the corpus
• Honest gap: All quality metrics are targets described in the spec — there is no enforcement mechanism

Observable Failure Modes

1. No enforcement: Entirely process-dependent; without tooling, teams self-select compliance
2. DSL without runtime: The macro syntax looks like executable code but isn't — potential confusion
3. 32 stars, low adoption signal: Educational content, not yet widely adopted
4. Static documents: Specs don't update as code changes — require manual maintenance
5. Roadmap gaps: VS Code/GitHub Actions integrations promised but not yet delivered