temple8
Health Gecti
- License — License: MIT
- Description — Repository has a description
- Active repo — Last push 0 days ago
- Community trust — 12 GitHub stars
Code Gecti
- Code scan — Scanned 12 files during light audit, no dangerous patterns found
Permissions Gecti
- Permissions — No dangerous permissions requested
This tool is a spec-driven agent orchestration template that uses YAML-defined state machines to route multi-agent workflows. It is designed to provide structured development processes, allowing developers to use any LLM locally without vendor lock-in.
Security Assessment
The overall security risk is Low. Based on a light audit of 12 files, no dangerous code patterns were found. The tool does not request any dangerous system permissions. Because it is a local project template designed to run on your own infrastructure, it appears to process data locally without exposing it to external vendors by default. No hardcoded secrets were detected, and the lightweight codebase leaves a minimal attack surface.
Quality Assessment
The project exhibits strong quality and maintenance signals. It is actively maintained, with its most recent push occurring today. It uses the highly permissive MIT license, meaning it is safe for both personal and commercial use. While the community is currently small with 12 GitHub stars, the repository features excellent documentation, clear badges indicating 100% code coverage, and active continuous integration (CI) pipelines. These are highly positive indicators of a well-structured and professionally maintained project.
Verdict
Safe to use.
Spec-driven agent orchestration template. YAML state machines route multi-agent workflows. Any LLM, any process, zero lock-in.
You have tried to ship features with AI assistants. The agent writes code, you review it, and somehow the spec still drifts from the implementation. Tests pass but the feature doesn't match what stakeholders asked for. Architecture decisions vanish into commit messages nobody reads. The review cycle is a black box: either everything passes or nothing does, with no structured progression.
temple8 replaces ad-hoc agent orchestration with state machines that route every step through the right agent with the right skills at the right time.
Flow definitions in YAML declare what happens at each state: who owns it, what they may read, what they must produce, and which conditions gate the next transition. No agent guesses what to do next. No step is skipped. Artifacts are scoped to each state's input/output contract.
Who is this for?
Developers moving from vibe coding to agentic engineering
You have shipped code with AI assistants and hit the wall: the agent writes code, you review it, the spec drifts. Vibe coding works for prototypes. It breaks at scale. temple8 replaces "prompt and pray" with spec-driven development: BDD scenarios from interviews, @id traceability from scenario to test function, red-green-refactor cycles enforced by default, three-tier review that catches what linters miss.
Teams wanting structured agent orchestration without lock-in
Your team follows a real methodology: Scrum, Kanban, SAFe, or something custom. Multi-agent orchestration should adapt to it, not the other way around. temple8 flows are YAML state machines you define, extend, or replace. Named specialists per state. No subscription, no vendor account, no code leaving your infrastructure. MIT licensed.
Anyone evaluating spec-driven development
Spec-driven development is gaining traction across AI coding tools. You want to try it without committing to a cloud IDE or a monthly subscription. temple8 is a project template: clone it, run it locally with any LLM, see if the process discipline works for your team. Already have a Python project? Use agents-smith to add temple8's agentic capabilities with one command.
What it does
flowr check → inspect a state's owner, skills, and transitions
flowr next → see which transitions pass given your evidence
flowr transition → advance to the next state with evidence
State machines route the work. YAML flows define the delivery pipeline: discovery, architecture, planning, TDD cycles, review gates, delivery. Each state declares an owner, skills, input/output artifacts, and guard conditions. The engine validates transitions. The agent executes.
Workflows are configurable. The default flows cover spec-driven software development. Replace or extend them for your team's process: Kanban, SAFe, ITIL, or any custom pipeline. If it is a state machine, flowr can express it.
Agents execute it. Each state's owner dispatches to the right agent (PO, SE, SA, DE, R). Skills are loaded per state. Input/output contracts constrain scope. Evidence gates prevent premature transitions.
Branch discipline is explicit. Every state declares git: main or git: feature. Project-phase work commits to main. Feature work commits to a feature branch. No ambiguity about where changes belong.
Quick start
New project
git clone https://github.com/nullhack/temple8
cd temple8
curl -LsSf https://astral.sh/uv/install.sh | sh # skip if uv is already installed
uv sync --all-extras
opencode && @setup-project # personalise for your project
uv run task test && uv run task lint && uv run task static-check
Existing project
pip install agents-smith
smith clone # adds temple8's agents, flows, skills, and knowledge
Commands
uv run task test # full suite + coverage
uv run task test-fast # fast, no coverage (use during TDD loop)
uv run task lint # ruff format + check
uv run task static-check # pyright type checking
uv run task run # run the app
uv run task doc-build # build API docs + coverage report
FAQ
How is this different from Kiro?
temple8 evolved over years of accumulated practice, not as a response to Kiro. Both identified the same pain points in AI-assisted development. The standards differ: Kiro uses EARS notation and property-based testing; temple8 uses BDD, TDD, and DDD with three-tier progressive review. Kiro is a cloud IDE on Bedrock. temple8 is a local project template with any LLM. MIT licensed, zero cost.
How is this different from Cursor or Copilot?
Cursor and Copilot help write code. temple8 provides the process that decides what to write, in what order, and what review it passes before shipping. Think of them as the engine and temple8 as the map. Use both together.
How does this relate to Claude Code or opencode?
Claude Code and opencode are general-purpose agent runners. temple8 gives them a process: YAML state machines, scoped agent roles, and evidence-based transitions. Without temple8, they follow prompts. With it, they follow a workflow.
Do I need to replace my existing tools?
No. temple8 is a project template: flows, agent definitions, skills, and knowledge files you drop into any Python project. Keep your editor. Bring your own LLM via opencode or a compatible agent runner. Already have a Python project? Use agents-smith to add temple8's agents, skills, and flows with one command: smith clone.
Is this only for software development?
The default flows cover software development (discovery, architecture, TDD cycles, review). Any repeatable process with steps and conditions can be expressed as a flowr state machine: ops runbooks, compliance audits, content pipelines, incident response.
Documentation
- Product Definition: product boundaries, users, and scope
- System Overview: architecture, domain model, module structure, and constraints
- Glossary: living domain glossary
License
MIT. See LICENSE.
Author: @nullhack · Documentation
Yorumlar (0)
Yorum birakmak icin giris yap.
Yorum birakSonuc bulunamadi