English | Português (Brasil)

POSE — Project Operating Standard for Engineering

Turn AI-assisted engineering into a repository-owned, machine-checkable delivery system.

Spec-Driven Development for governed agentic software delivery.

POSE is an open-source Spec-Driven Development framework for governed agentic software delivery. It turns specifications, policy, execution, evidence, follow-ups and engineering knowledge into a repository-owned, machine-checkable delivery system. One native Go binary, Apache-2.0, local-first.

flowchart LR
  D[discover] --> S[specify] --> R[route] --> E[execute] --> P[prove] --> C[close] --> L[learn]
  L -. repository-owned context .-> D

Coding agents are increasingly capable of implementing work. POSE governs the conditions around that work:

• what is ready to start;
• which requirements and rules are authoritative;
• which workflow and checks apply;
• what evidence proves completion;
• how residual work must be dispositioned;
• what engineering knowledge should survive the session.

The repository stays the source of truth while agents, models, IDEs and CI providers change.

POSE is not another coding agent, IDE or project board. It is the engineering contract that humans, agents and CI execute against.

Why POSE

Spec-Driven Development improved the path from intent to implementation: requirements stopped living only in the prompt.

POSE extends that idea across the rest of delivery. The same contract that defines the work also determines when it is ready to start, which rules apply, which checks must pass, what evidence proves the delivery, how leftover work is dispositioned, and what should be remembered next cycle.

A spec is not successful merely because code was generated. POSE gates readiness before execution and closeout after it, using repository-native checks and versioned evidence.

The agent can say it finished. POSE requires the repository to prove it.

Agent-neutral, lifecycle-authoritative

POSE works with different coding agents through repository instructions, portable skills, the CLI and MCP. It does not pick your agent, model or editor.

POSE is itself an SDD framework. When adopted, it owns the authoritative specification and delivery lifecycle for that repository — requirement IDs, status, dependencies, readiness, definition of done, closeout and knowledge.

Running a second base SDD framework over the same lifecycle creates competing authorities for exactly those artifacts. So the current interoperability model favours migration over concurrent ownership: existing Spec Kit and OpenSpec work can be imported into POSE, reviewed, and then governed under the POSE lifecycle.

Agent-neutral is not the same as SDD-framework-neutral. POSE is neutral about who executes; it is not neutral about who owns the lifecycle.

POSE today

Editorial review: 2026-10-20. The latest published release is v7.4.1, dated 2026-10-10. The recent line adds guided setup, explicit capability adoption, obligations by actor and phase, signed action answers, local review issuers and bundle-derived delegated review briefs.

• Operate an instance: effective policy and next actions.
• Review and trust: evidence, judgment and identity.
• Multiple projects: authority, federation and transfers.
• Releases and development: shipped changes, pending hardening and plans.

unreleased changes are outside v7.4.1; planning fragments do not prove a functional delivery. Updating the binary and adopting optional capabilities are separate decisions.

Quickstart

Fast path for Linux and macOS (run it from the Git repository that should receive the POSE contract):

curl -fsSLO https://github.com/oseiaspereira88/pose/releases/latest/download/install.sh && bash install.sh

This path follows the latest release and installs the native binary into ~/.local/bin. It relies on HTTPS but does not independently verify the archive checksum or Sigstore identity. Use the pinned flow below when reproducibility or supply-chain verification is required.

Download the released archive for your platform, verify its checksum, place pose on PATH, then install POSE into a Git repository. Release assets are named pose_<version>_<os>_<arch> — tar.gz for Linux and macOS, zip for Windows — on linux/darwin/windows × amd64/arm64.

Linux and macOS (bash or zsh; replace linux_amd64 with your platform):

V=7.4.1
curl -fsSLO "https://github.com/oseiaspereira88/pose/releases/download/v${V}/pose_${V}_linux_amd64.tar.gz"
curl -fsSLO "https://github.com/oseiaspereira88/pose/releases/download/v${V}/checksums.txt"
sha256sum --check --ignore-missing checksums.txt   # macOS: shasum -a 256 -c
tar -xzf "pose_${V}_linux_amd64.tar.gz" pose
install -m 0755 pose ~/.local/bin/pose             # any directory on PATH
pose install /path/to/your/repo

Windows (PowerShell):

$V = "7.4.1"
Invoke-WebRequest "https://github.com/oseiaspereira88/pose/releases/download/v$V/pose_${V}_windows_amd64.zip" -OutFile "pose_${V}_windows_amd64.zip"
Invoke-WebRequest "https://github.com/oseiaspereira88/pose/releases/download/v$V/checksums.txt" -OutFile checksums.txt
(Get-FileHash "pose_${V}_windows_amd64.zip" -Algorithm SHA256).Hash -eq ((Get-Content checksums.txt | Select-String "pose_${V}_windows_amd64.zip") -split '\s+')[0]
Expand-Archive "pose_${V}_windows_amd64.zip" -DestinationPath .
# move pose.exe to a directory on PATH, then:
pose install C:\path\to\your\repo

For the verified path, always check the archive before executing the binary. The release-bundle install.sh can also be downloaded next to that verified binary and run locally.

The installer:

• embeds workflows, rules, templates, skills and the selected locale;
• derives project name and ID, with explicit override flags;
• configures the same binary as the MCP server;
• preserves existing specs, ADRs, knowledge, reports and roadmaps;
• finishes with native init, index and check --strict;
• reports success only when the structural gate passes.

Requirements: Git and the native pose binary. Bash is needed only when using the optional release-bundle install.sh; the runtime itself needs no Bash, Python, Node.js or hosted service. Supported release targets are Linux, macOS and Windows on amd64 and arm64.

Every release publishes compatibility.json (supported engine, schema and upgrade pairs) and the generated compatibility-report.md (the release gate evidence) as release assets. Binary SemVer and repository schema compatibility are independent axes: pose update migrates an instance forward through ordered idempotent migrations; downgrade is unsupported by contract.

Run a first governed delivery

pose setup                                   # identity, commit gate, capability decisions — one confirmed step at a time
pose new-spec customer-export
pose suggest feature

# Fill Intent, R1/R2... requirements and Technical Plan.
pose lint-spec customer-export --ready-check
pose start spec:customer-export --apply --digest <start.digest>

# Implement, run the repository's declared checks, commit with POSE-Spec: customer-export.
pose validate --strict

# Trace every requirement to its evidence, then close through review.
pose close spec:customer-export --apply --reviewer agent:<id>

The quickstart walks the same delivery chapter by chapter, including a decision the maintainer answers with a signed key; CI runs it as written.

Bring specs from another SDD tool

Already use another SDD format?

pose import spec-kit .specify/specs --dry-run
pose import openspec openspec/changes/add-2fa --dry-run

The importer validates the complete batch before writing, rejects symlinks, never overwrites an existing spec and reports everything that still needs human curation.

Full guides, including what does not transfer — requirement IDs are renumbered, status and dependencies do not carry over, validation is a placeholder — are in Migrating from Spec Kit and Migrating from OpenSpec.

See examples/brownfield-kits/ for three real, executable adoption journeys — direct adoption, Spec Kit import and OpenSpec import — each with a staged visibility-to-blocking-gate guide and a rollback story, exercised end to end by the test suite.

What makes it different

AI coding tools accelerate implementation, but speed alone does not solve the system-level problems they amplify:

• requirements remain trapped in chat history;
• agents receive inconsistent instructions;
• “done” is declared without reproducible evidence;
• follow-ups disappear into prose;
• the same failures are fixed repeatedly;
• context is lost when an agent or session changes.

POSE makes each of those concerns an explicit, versioned mechanism.

Differentiator	What POSE does	Verifiable mechanism
Governs delivery, not only generation	Connects planning, execution, acceptance and learning	Specs + workflows + rules + evidence + history
Gates both entry and exit	Refuses execution without readiness and refuses done without closeout	pose lint-spec --ready-check / --strict
Uses real engineering checks	Runs repository-native test, lint, typecheck and build commands	validation-matrix.json + pose validate
Turns evidence into memory	Stores versionable reports and append-only history	.pose/reports/ + pose report
Closes residual work	Requires a disposition for every follow-up	pose followups + closeout vocabulary
Escalates systemic failure	Detects recurring task failures and routes structural correction	pose recurrence-check + escalation workflow
Preserves operational context	Gives handoffs and decisions an owner, sensitivity and TTL	.pose/knowledge/ + knowledge-check
Plans from dependencies	Validates spec and milestone DAGs and computes readiness	depends_on, roadmaps, pose_spec_readiness
Reviews an immutable subject	Separates the sealed review input from its append-only attestation	pose review bundle / attest / verify
Works across agents	Exposes short instructions, portable skills and MCP tools	AGENTS.md, Agent Skills, pose serve-mcp
Keeps control local	Runs offline and stores the source of truth in Git	One CGO-free binary; no hosted dependency

What is in the box

Path or component	Purpose
pose binary	Native CLI, installer, gates, reports, metrics, housekeeping and MCP
.pose/specs/	Living feature contracts with lifecycle and dependencies
.pose/workflows/	Procedures for feature, bugfix, review, refactor, docs, recurrence, release and UI surfaces
.pose/rules/	Cumulative security, backend, frontend, Kubernetes, evidence and knowledge rules
.agents/skills/	Eleven portable Agent Skills; Claude-compatible links are installed
.pose/roadmaps/	Governed roadmaps with milestone DAGs and readiness
.pose/knowledge/	TTL-governed handoffs, notes and decision logs
.pose/reports/	Versionable evidence and append-only JSONL history
.pose/indexes/	Repository, module, task, spec-graph and roadmap projections
pose serve-mcp	58 POSE governance tools and 3 optional Conductor run reporters over stdio or Streamable HTTP
mcp-enforce/	Optional project/run-scoped identity, OPA decisions and audit
pose-action/	GitHub Action adapter for deterministic gates

Read the technical architecture for every component and mechanism. Read the capability assessment for current maturity and best-of-breed gaps. The governed product roadmaps convert those findings into roadmaps, implementation specs and dependency-aware release gates. POSE itself is developed under POSE-governed roadmaps and specifications, tracked under .pose/roadmaps/ and .pose/specs/.

Latest release

See the Releases page for current release notes and verified artifacts. Per-cycle notes live in .pose/changelogs/.

Where POSE is strongest

POSE's core advantage is closed-loop governance. Spec authoring is only the first step. The system also checks whether a spec is ready, routes the correct workflow, executes deterministic quality gates, records the acceptance evidence, forces residual work to be triaged and detects when local fixes should become systemic improvements.

That combination is especially valuable for:

• teams using more than one coding agent or model provider;
• brownfield repositories where architecture and checks already exist;
• regulated or high-accountability delivery;
• monorepos with different stacks and module criticalities;
• platform teams standardizing engineering without forcing one IDE;
• organizations preparing for governed agent orchestration.

POSE deliberately carries more lifecycle structure than lightweight SDD approaches. If your only goal is to turn a prompt into a short-lived implementation plan, that governance will not pay for itself. POSE is built for repositories where readiness, deterministic validation, evidence, residual work and reusable engineering context actually matter.

POSE and other SDD frameworks

POSE is itself a complete Spec-Driven Development framework. When adopted, it owns the authoritative lifecycle for specifications, requirements, dependencies, readiness, delivery evidence, follow-ups and learning.

Running two base SDD frameworks over the same lifecycle creates competing authorities for those artifacts — who owns requirement IDs, status, dependencies, the definition of done, closeout. For that reason POSE favours migration interoperability rather than concurrent lifecycle ownership:

flowchart LR
  SK[Spec Kit] --> I[import]
  OS[OpenSpec] --> I
  I --> P[POSE lifecycle]

Existing work is imported, reviewed, and then governed under POSE — see Bring specs from another SDD tool.

How POSE compares

The tools below are adjacent rather than interchangeable. The useful question is not “which tool wins?” but “which part of delivery does each tool make authoritative?” The SDD frameworks in the first two rows are the exception noted above: POSE imports from them rather than running alongside them.

Solution	Primary strength	POSE's distinction
GitHub Spec Kit	Rich SDD lifecycle with agent integrations, extensions, presets, workflows and bundles	POSE emphasizes repository-wide governance after planning: entry/exit gates, validation evidence, recurrence and expiring knowledge
OpenSpec	Lightweight, agent-neutral brownfield change proposals, deltas and archive-to-source flow	POSE adds deterministic delivery gates, module-aware validation, governed follow-ups, operational history and portfolio readiness
Kiro	Integrated agentic service with specs, steering and event hooks	POSE is editor/model neutral, offline and owned by the repository
Backstage	Organization-wide software catalog, templates and developer portal	POSE governs execution inside each repository and can feed a portal/control plane
CI orchestrators	Execute pipelines and display job results	POSE decides the applicable trail, normalizes severity and preserves evidence as governed product data
Issue trackers	Coordinate people, status and portfolio work	POSE makes the engineering contract and acceptance criteria executable beside the code

POSE does not replace the specialist strengths above. It provides the governance spine that remains stable while agents, editors, CI providers and portals change.

POSE and Harne8

POSE is Apache-2.0, local-first and complete within its domain: it needs no Harne8 account and no hosted service to do its job. Harne8 uses POSE as its governance engine and solves a different problem — the one that appears when the unit stops being a repository.

POSE governs a repository	Harne8 governs a portfolio
Repository-local specs and roadmaps	Visual multi-project portfolio
Workflows, rules and portable skills	Durable task orchestration through Conductor
Deterministic validation and evidence	Governed agent execution through Harness
Local insights and recurrence	Central reliability, cost and policy views
Native MCP governance API	Context enrichment through GraphForge
Optional OPA policy enforcement	Central identity, approvals, audit and operations

Identity follows the same rule: a maintainer proves an answer with an SSH key the project registered (pose identity add, verified offline), and Harne8's issuer is one more emitter of that same proof, not a requirement for it.

The boundary is intentional, and it is not a paywall: nothing is withheld from POSE to create demand for Harne8. They govern different scopes. Harne8 becomes relevant when repository-local governance stops being enough — many repositories, many people, shared policy, central approvals.

Adopt progressively

1. Observe: install POSE and run checks in tolerant mode.
2. Align: customize module metadata, rules and the validation matrix.
3. Enforce: make stable required checks blocking in CI.
4. Learn: generate reports, triage follow-ups and enable recurrence checks.
5. Scale: connect MCP clients or Harne8 without moving the source of truth out of the repository.

Teams using pre-commit.com can enable pose-check, pose-lint-spec and pose-history-check. See the CI guide, the CLI reference and the docs site for the rest.

Security and privacy

• Gates are offline by contract.
• Telemetry is disabled by default and has no built-in collection endpoint.
• Import and module paths are confined to the project root.
• Validation uses structured program/argument arrays; legacy shell commands are rejected.
• Restricted knowledge is excluded from MCP reads.
• OPA-backed MCP policy fails closed on evaluation errors.
• Mutating repository work remains an execution-sandbox responsibility rather than a general MCP write surface.

See SECURITY.md for reporting vulnerabilities.

Current product boundary

POSE currently provides a strong local governance engine, not a hosted multi-team service. Its local reports are auditable Git artifacts, not signed supply-chain attestations. Roadmaps express dependency/readiness, not team capacity. Local insights summarize POSE outcomes, not deployment or incident performance.

Those limits are explicit in the capability assessment, alongside the work required to reach the next maturity level.

License

Apache-2.0 — see LICENSE and NOTICE.

Contributions are welcome: see CONTRIBUTING.md.

POSE is open source under Apache-2.0 and is developed in the open as a standalone project. It also powers the governance model used by Harne8.