SpecNexus is an agentic development workflow for turning mixed feature input into framework-native specifications, outcome-based slices, validation evidence, and a traceable delivery path.

Introduction

In the first part of this series, I discussed why agentic development needs more than a well-written prompt. A coding agent can produce useful code quickly, but a feature is not ready simply because a plausible implementation exists. The intent still needs to survive architecture decisions, security constraints, validation, review, and release preparation.

This is the problem I wanted SpecNexus to address. It is not designed as another prompt wrapper, and it is also not designed as a replacement for specification frameworks such as OpenSpec or Spec Kit. It is a structured front door before specification generation and delivery work, so that a ticket, meeting note, product document, or mixed set of inputs can become something engineers can inspect, implement, validate, and trace.

For architects, the value is preserving boundaries and decision records while delivery moves faster. For developers, the value is having a clearer contract for the work instead of reconstructing it from a long conversation. Let us look at how that works through a practical feature example.

Diagram note: Mermaid diagrams are included as source-friendly diagrams. PNG fallback images will be available for publishing platforms where Mermaid does not render; relative fallback references are included below each diagram.

The practical problem: mixed input is not yet a delivery contract

Most features do not arrive as a complete specification. A product ticket may describe the desired result. A follow-up message may mention a role restriction. A repository may already contain conventions that change how the feature should be implemented. A separate security note may introduce an audit requirement. Each item is useful, but together they still leave questions.

Consider a request to add configurable expense approval limits. The initial material might say:

Finance needs managers to configure the approval limit for an expense policy. Employees can submit an expense for approval. Decisions must be visible in the audit history.

This looks straightforward. But before implementation, a team still needs to know who can configure a policy, whether a limit is per currency or per policy, what happens to expenses already in progress, whether a limit can be changed retrospectively, and what data must be retained for audit. These are not details that should be silently invented by an agent.

SpecNexus treats this early uncertainty as a workflow concern. It takes source material, checks repository context where available, and asks up to three material blocking questions when missing information could affect correctness, architecture, contracts, data safety, security, test strategy, rollout, or user-visible behavior. The purpose is not to turn every small change into a committee exercise. It is to make important assumptions visible before they become code.

The workflow also asks the team to select the output framework and, where the repository’s governance requires it, confirm a pinned model before generation. These checks may feel restrictive at first. In practice, they make the generated artifacts easier to review because the delivery path and the generation context are explicit.

Where SpecNexus stands in agentic development

Before we go deeper, it is useful to place SpecNexus correctly in the overall agentic development stack.

An agentic workflow usually has several layers. At one end, there is raw source input such as tickets, notes, conversations, and repository context. At the other end, there is implementation, validation, review, and sign-off. Between these two ends, teams need a way to clarify intent, identify missing decisions, preserve constraints, and then hand the result to a specification framework that gives the work a durable structure.

This is where SpecNexus stands.

SpecNexus is an orchestrator. It sits between messy source material and framework-native specification output. In practical terms, it does three important things before deeper delivery work begins:

1. It normalizes and clarifies mixed input.
2. It derives capabilities, slices, constraints, and validation expectations.
3. It generates output in the framework the team has chosen, such as OpenSpec or Spec Kit.

So the relationship is complementary, not competitive.

• OpenSpec and Spec Kit provide the specification structure the team ultimately works with.
• SpecNexus prepares, governs, and routes the work into those frameworks in a consistent way.

This distinction matters because many readers may otherwise assume that SpecNexus is trying to define a new documentation framework. That is not the point. The point is to improve the quality of what goes into OpenSpec or Spec Kit, and to keep the resulting delivery flow traceable after the files are generated.

Understanding the SpecNexus architecture

Now the question arises: why not place all of this in one large agent prompt? The answer is that source intake, implementation planning, test design, and assurance do not need the same context or have the same responsibility.

SpecNexus uses a thin router to select a focused phase agent. The router does not generate specifications, code, or tests itself. It delegates to the agent responsible for the current stage. Shared utility agents handle concerns that must remain consistent across phases, including model governance and DevSecOps/NFR assessment.

This separation is practical. The DEFINE agent can concentrate on intake, readiness, capability derivation, framework selection, specification generation, slicing, and estimation. The implementation agent can work from approved slices and actual repository conventions. The validation agent can focus on acceptance criteria, test scenarios, regression, accessibility, negative cases, and test data. The assurance agent can review changes and evidence against the agreed specification.

The important point is not the number of agents. It is the boundary between responsibilities. Each phase receives a smaller, more relevant context, while shared controls are implemented once rather than repeated in every prompt.

If we look at this from an agentic-development perspective, the orchestrator is acting as a bridge between three things:

• unstructured feature input;
• a chosen specification framework such as OpenSpec or Spec Kit;
• downstream delivery activities such as implementation, validation, and assurance.

That bridge is where SpecNexus adds its value.

The lifecycle: clarify, build, prove, assure

The delivery lifecycle is deliberately compact:

DEFINE -> IMPLEMENT -> VALIDATE -> ASSURE

Each phase answers a different engineering question. DEFINE asks whether the team understands what must be delivered. IMPLEMENT turns the approved slices into change-ready work. VALIDATE asks whether each result actually meets its acceptance and quality expectations. ASSURE determines whether the combined evidence is sufficient for review and sign-off.

The lifecycle is not a claim that every feature travels in a straight line. It is a way to make the current state visible. A hard stop is appropriate when a framework is not confirmed, a required model has not been pinned, a material clarification remains unanswered, or a gate fails. Continuing without addressing those conditions is not autonomy; it is untracked risk.

When work spans multiple turns or a team requests delivery tracking, the workflow stores a compact state record at pipeline-state/<feature-slug>/state.json. That state records the phase, gate status, canonical capabilities, slice status, validation evidence, blockers, and transition history. In practical terms, it becomes a handoff record between people and agents instead of relying on a chat transcript as the source of truth.

A concrete example: changing expense approval limits

Let us return to the expense approval feature. Assume the input comes from a product note, an Azure DevOps item, and the existing expense-service repository. The request has a business outcome, but it is not yet ready to implement.

1. DEFINE: turn the request into stable capabilities

The clarification gate may establish the following decisions:

• Only finance administrators can create or change a policy limit.
• A policy limit is configured in the policy currency and applies only to expenses submitted after the change.
• An approver can approve or reject an eligible expense, and the decision must retain the acting user, time, and applied limit.

From these answers, the workflow derives canonical capabilities rather than treating the entire request as one vague feature. For this example:

• CAP-1: Configure an expense approval limit for a policy.
• CAP-2: Submit and record an authorized approval decision using the applicable limit.

Capabilities are the specification anchors. A capability is a bounded business or technical outcome that deserves its own framework-native specification target. This prevents a large request from becoming a single document where unrelated requirements, contracts, data changes, and tests are difficult to trace.

The next step is outcome-based slicing. Slices are delivery anchors, not technical layers. Instead of planning “frontend first, API second, database third,” the team can create increments that deliver and verify useful behavior:

• SLICE-1: Finance administrator configures a policy limit and sees validation errors for invalid values.
• SLICE-2: Employee submits an expense and an authorized approver records a decision against the applicable limit.
• SLICE-3: Audit history, regression coverage, and assurance evidence demonstrate that policy changes and decisions are traceable.

Each slice can span UI, API, data, QA, and review work if that is what it takes to produce a usable outcome. It maps back to one or more capabilities, acceptance criteria, test scenarios, dependencies, estimates, and evidence.

2. Choose framework-native output, not another generic template

After the capability boundary is clear, the team selects an output framework. This is a choice about how the team wants to review and work with the specification, not a branding exercise.

OpenSpec fits teams that want a change-oriented proposal, design decisions, tasks, and capability-level spec deltas. Spec Kit fits teams that prefer an explicit specify, clarify, plan, research, and tasks flow. SpecNexus uses its coverage model to check for gaps, but it writes the final artifacts in the selected framework rather than producing a second parallel document structure.

This is exactly why I do not see SpecNexus as a replacement for either framework. OpenSpec and Spec Kit already solve an important problem: they provide a disciplined format for specification work. SpecNexus solves a different problem. It helps the team move from ambiguous source material into those formats with more clarity, governance, and delivery awareness.

In simple terms:

• OpenSpec or Spec Kit defines how the specification is expressed.
• SpecNexus helps define what should go into that specification and how it should progress through delivery.

For the expense feature, CAP-1 and CAP-2 each receive a clear specification target. The generated material can include the business rules, authorization rules, validation constraints, acceptance criteria, data or contract impact when relevant, risks, rollout considerations, and traceable tasks. The document structure differs by framework; the discipline does not.

3. IMPLEMENT: work from a slice with a contract

Implementation becomes more focused when the developer can see the outcome, its acceptance criteria, the active delivery lanes, and the repository conventions. SLICE-1 might include policy-limit validation in the service, the administrative screen, authorization enforcement, and tests. It is still one slice because these items together deliver the administrator’s outcome.

This is also where repository awareness matters. A generated plan should use the repository’s existing conventions for modules, contracts, test frameworks, CI commands, and naming. If the context is unavailable, that limitation should remain an explicit assumption, not become an invented implementation detail.

4. VALIDATE: connect acceptance to evidence

Generated code is not the proof that a capability is complete. For each slice, the validation phase maps acceptance criteria (AC-n) to test scenarios (TS-n) and maps measurable non-functional requirements (NFR-n) to tests as well.

For the approval-limit feature, validation might prove that an unauthorized user cannot modify a policy, that a negative or unsupported limit is rejected, that the correct policy value is applied at submission time, and that the approval decision creates the expected audit entry. The exact mix of API, UI, manual, regression, accessibility, and test-data checks depends on the delivery lanes identified in DEFINE.

This traceability is useful during review because it answers a concrete question: which test or evidence item demonstrates that a stated requirement has been met?

5. ASSURE: review the evidence, not only the diff

In the assurance phase, the review is performed against the requirement, slice mapping, implementation, tests, automation, validation evidence, and relevant DevSecOps expectations. A reviewer can identify a missing test, an out-of-spec production change, or a slice with no changed-file evidence as a specific gap rather than a vague concern.

The final result is not a promise that the agent made good choices. It is a package of reviewable evidence: what was intended, what was built, what was validated, what changed, what remains open, and whether the work is ready for sign-off.

Benefits of using SpecNexus with OpenSpec or Spec Kit

Now let us make the benefit more explicit. If a team is already comfortable with OpenSpec or Spec Kit, the immediate question is: why introduce SpecNexus at all?

The answer is that SpecNexus improves the quality and delivery usefulness of the inputs around those frameworks.

1. Better input before specification generation

Many teams do not struggle because they lack a spec template. They struggle because the input reaching the template is incomplete, mixed, or inconsistent. SpecNexus helps by clarifying the request before it becomes a formal specification artifact.

2. Clearer boundaries between capabilities

When a large feature is treated as one document, traceability becomes difficult. SpecNexus helps derive canonical capabilities and keeps each capability tied to a specific framework-native target. This makes large requests easier to reason about and easier to review.

3. Outcome-based slicing instead of layer-based planning

OpenSpec and Spec Kit can hold tasks and planning information, but teams still need to decide how the work should be broken down. SpecNexus adds value by turning the feature into slices that represent verifiable outcomes rather than disconnected technical layers.

4. Stronger validation and assurance flow

A specification file alone does not guarantee validation traceability. SpecNexus pushes the workflow forward into VALIDATE and ASSURE, which means the team can connect acceptance criteria, test scenarios, evidence, and review outcomes in a more visible way.

5. Better governance for agentic delivery

Model pinning, clarification gates, DevSecOps checks, NFR assessment, and state tracking are especially useful in agentic development because agents can move fast. These controls help the team keep speed without losing reviewability.

6. A consistent orchestration layer across different teams

One team may prefer OpenSpec. Another may prefer Spec Kit. SpecNexus can complement both because its role is orchestration, not framework replacement. This makes it easier to standardize the intake, clarification, slicing, and assurance flow even when output preferences differ.

Why the controls matter in real teams

Specification discipline is sometimes mistaken for a slower alternative to agentic development. I see it differently. The workflow removes repeated interpretation work that otherwise appears later as rework, review churn, or production risk.

Clarification gates protect the team from accidental requirements. Capability-first planning keeps the specification structure aligned to business outcomes. Outcome slices make it possible to deliver a vertical increment and verify it. Model pinning provides reproducibility where teams need it. DevSecOps and NFR checks bring quality expectations into the workflow before assurance. State tracking means an architect, developer, tester, or agent can resume from a visible delivery position.

None of these controls replace engineering judgment. A tool cannot decide whether the product should ship, whether an architectural trade-off is appropriate, or whether a business risk is acceptable. Those decisions remain with the team. What SpecNexus provides is a more disciplined place to make them and retain the evidence.

Practical considerations before adopting SpecNexus

SpecNexus works best when teams use it proportionately. A one-line internal copy change does not need the same lifecycle as a policy, payment, identity, or data workflow. The team should decide when the cost of structured definition is justified by the complexity and risk of the change.

It also depends on source quality. The workflow can surface ambiguity, but it cannot provide product decisions that nobody has made. Treat unanswered questions, unavailable repository context, and unconfirmed constraints as visible inputs to resolve, not as gaps to hide with confident prose.

Finally, avoid treating framework output as the end of the work. OpenSpec and Spec Kit artifacts are useful because they support discussion, implementation, validation, and review. SpecNexus is useful because it helps govern how those artifacts are produced and how the work moves after they are produced. If the team does not maintain the capability, slice, and evidence links as the feature changes, the documents become stale. The lifecycle is valuable only when it reflects the delivery that actually occurred.

Closing thoughts

The central idea behind SpecNexus is simple: in agentic development, specifications are not paperwork after the real work. They are the engineering control layer that connects intent to implementation and implementation to evidence.

For the expense approval example, the value was not a longer prompt. It was turning incomplete input into clarified decisions, stable capabilities, vertical delivery slices, framework-native specifications, validation traceability, and an assurance trail that a team can review.

The important point is that SpecNexus does not ask teams to abandon OpenSpec or Spec Kit. It complements them. OpenSpec or Spec Kit remains the framework where the specification is expressed. SpecNexus stands one layer earlier and one layer wider: it helps shape the input before generation and keeps the delivery workflow governed after generation.

The repository contains the operational details that do not belong in a blog article: installation guidance, prompt packs, framework-specific output structures, validators, and a complete Record an Expense example. Explore the SpecNexus GitHub repository when you are ready to apply the workflow in a real project.