Living Specs

Status: Draft white paper Last updated: 2026-05-20

Personal Note

In the agentic coding era, code is becoming disposable. More of the real effort moves into prompting: describing the domain, setting constraints, explaining intent, naming edge cases, and steering the agent away from plausible but wrong solutions.

If that is where the effort goes, why throw it away?

The value of a product is not only in its code. It is in the domain knowledge that tells the code what to be: the product model, rules, tradeoffs, user expectations, rejected alternatives, and accumulated learning. That is where the intellectual property lives.

Living Specs also give coding agents the thing they need most: context. In agentic coding, context is king. Without a maintained product model, an agent has to inspect the codebase, infer architecture from implementation, and guess at product intention. With Living Specs, the agent can start by reading the curated truth: what the product does, why it does it, what constraints matter, and what must not be invented.

Put another way: code is no longer the only durable artifact. Context is. Living Specs are the durable context layer for human and agentic software development.

Traditionally, keeping product specs aligned with code has been difficult, if not impossible. Delivery pressure pushes all effort toward working software, and docs become temporary scaffolding: PRDs, tickets, and notes that expire as soon as implementation starts.

Living Specs invert that effort. The spec becomes the durable product memory. The code becomes the current implementation of that memory. In this model, code can be regenerated, rewritten, or replaced; the living spec is the asset that preserves what the product actually knows.

Abstract

Software teams have spent decades treating requirements documents as disposable scaffolding. A product requirements document is written, decomposed into tickets, implemented, and then quietly abandoned. The code becomes the only durable record of what the product does, even though code is often the least accessible place to understand product intent, tradeoffs, release history, and domain reasoning.

AI-assisted development changes the economics of this arrangement. If code can be generated, rewritten, migrated, and refactored faster than before, then the durable asset is no longer only the current implementation. The durable asset is the continuously maintained description of the product: what it does, why it does it, what has shipped, what remains unresolved, and what the business now believes to be true.

This paper proposes Living Specs: a methodology for maintaining specs as a continuous representation of product truth. Living Specs are not throwaway PRDs, Jira epics, or frozen design documents. They are versioned, reviewed, agent-readable documents that evolve as strategy, implementation, release history, and operating reality evolve.

Living Specs also address a failure in many nominally agile processes. Short sprints do not automatically create real iteration. When each sprint starts from a fixed mini-requirements document and ends with closed tickets, the team is often running waterfall in smaller batches. Living Specs keep the product truth open to learning during and after the delivery cycle.

The goal is not more documentation. The goal is to move durable product knowledge out of transient tickets and implicit code paths into a corpus that humans and AI agents can use as the primary design and implementation source.

1. The Problem With Disposable Product Documents

Most product organisations already write something before they build. They write PRDs, design briefs, Jira epics, architecture notes, acceptance criteria, and delivery plans. The problem is not that documents do not exist. The problem is that most of them expire.

A common lifecycle looks like this:

1. A product requirement is written to justify or frame a piece of work.
2. The requirement is decomposed into tickets.
3. Engineers implement the tickets.
4. The tickets are closed.
5. The product changes.
6. The original requirement no longer describes reality.

At that point, the organisation has three weak sources of truth:

• the code, which says what happens but rarely explains why
• the tickets, which say what was once intended but are usually fragmented
• the people, who remember the decisions until they leave, forget, or disagree

This failure mode is familiar because the incentives are familiar. A PRD is usually judged by whether it gets work started, not by whether it remains useful six months later. A Jira epic is optimised for assignment and closure, not for preserving the current shape of product knowledge. Architecture notes often capture an important decision, but not the whole feature or domain that decision belongs to.

The result is knowledge decay. The system keeps moving, but the explicit product truth falls behind. New engineers reverse-engineer intent from implementation. Agents infer product rules from local code. Product owners re-litigate past decisions because the reasoning is buried or absent.

Living Specs are a response to that decay.

They are also a response to pseudo-agile delivery. Many teams call their process agile because work is broken into short sprints, but the underlying pattern is still linear:

write requirements -> estimate -> build -> demo -> close tickets

That is not deep iteration. It is a smaller waterfall. The feedback may arrive faster, but the artifact that should absorb the learning has already been discarded.

True iteration needs a durable object that can be changed by learning. Without that object, teams can build, use, and evaluate, but the adjustment usually lands as another ticket, another patch, or another meeting memory. Living Specs make the adjustment explicit by updating the product truth itself.

2. Why This Matters More Now

For many teams, the implementation has been treated as the scarce artifact. Code takes significant time to write, and documentation above the code can look like duplicate work. When delivery pressure rises, teams protect the code path and let supporting documents rot.

AI-assisted coding weakens that assumption. Generating plausible code from a sufficiently clear description is becoming cheaper. Translating a product model into a new framework, refactoring across modules, or producing a first-pass implementation is no longer the same bottleneck it was.

That does not make engineering trivial. It changes where the bottleneck moves. The hard part becomes:

• knowing what should be built
• preserving domain rules
• maintaining architectural boundaries
• recording rejected alternatives
• distinguishing present product truth from release delivery facts
• keeping agents from inventing plausible but wrong behaviour

In that environment, the durable asset is the specification corpus. Code is still essential, but it is an expression of the product truth at a point in time. The spec is the higher-level artifact that should survive framework churn, implementation rewrites, and individual ticket lifecycles.

The practical thesis is:

In an AI-assisted software company, the implementation can be regenerated more

easily than the product understanding can be rediscovered. Therefore the

durable investment should move upward into continuously maintained specs.

3. What Is A Living Spec?

A Living Spec is a continuously reconciled representation of product truth. It describes a durable product, platform, operational, or domain capability at a level detailed enough that a competent engineer or coding agent can implement from it without inventing major rules.

A Living Spec is not:

• a one-time PRD
• a Jira epic
• a frozen RFC
• a task list
• a test file
• a substitute for code review

A Living Spec is:

constraints

• current prose describing the capability, domain, rules, interfaces, and
• a record of what durable feature work exists or has landed
• a backlog of unresolved decisions, risks, dependencies, and validation gaps
• a release-aware record of what was targeted and what actually shipped
• a reviewed artifact in version control
• an input to human implementation and AI-assisted implementation
• a place where implementation findings are reconciled back into product truth

The essential distinction is continuity. A Living Spec does not expire when implementation starts. It changes because implementation, review, production use, and strategy reveal better information.

4. The Three-Layer Model

Living Specs sit in a simple three-layer model:

Strategy  ->  Specs  ->  Code
Why           What      How, right now

Strategy: Why

Strategy describes why the company exists, who it serves, what it sells, what it will not sell, and what direction the product should move in. Strategy changes, but usually on a slower cadence than implementation.

Specs: What

Specs describe what the system is meant to do. They contain product role, user objectives, domain rules, contracts, constraints, edge cases, important non-goals, and known unresolved pressure.

This is the layer where product knowledge becomes durable. A good spec should outlive the first implementation of the feature it describes.

Code: How, Right Now

Code is the current implementation of the spec. It is the executable reality, but not the whole product truth. Code can answer what happens today. It is usually weaker at answering what was intended, what tradeoffs were rejected, what future constraints matter, and what shipped in which release.

Living Specs do not diminish code. They give code a stable source to serve.

5. Core Principles

5.1 Specs Are Present Truth, Not Archives

The main body of a Living Spec should describe the present or target truth. It should not accumulate superseded versions inline. Version control already preserves prior states.

When a feature is redesigned, the prose should be rewritten to describe the new design. Delivery facts should remain in tracking rows and release tags, not in stale paragraphs that compete with the present truth.

5.2 Delivery Facts Are Not Product Truth

One of the common failures in product tracking is mixing up implementation progress, release history, and product confidence.

"Done" can mean too many things:

• implemented locally
• merged
• released
• validated
• trusted
• no longer relevant

Living Specs should keep these separate. A capability can be implemented but not shipped. Shipped but not validated. Validated but later found wrong. Stable but still have planned future work.

5.3 Specs And Code Must Reconcile Both Ways

Specs should lead implementation, but implementation teaches the spec. When engineering reveals that the spec is incomplete, wrong, overcomplicated, or missing a constraint, the spec should be updated.

This is the critical loop:

Spec -> Implementation -> Findings -> Spec

Without the return path, "spec-first" becomes waterfall in markdown.

5.4 Agents Need Negative Space

AI coding agents are good at producing plausible implementation details. That is useful and dangerous. A spec should explicitly describe not only what to do, but also what not to do:

• rejected alternatives
• anti-patterns
• boundaries between domains
• assumptions that must not be inferred
• behaviours that are intentionally out of scope

For agent-assisted work, negative space is part of the implementation contract.

5.5 Generated Views Must Not Become Sources Of Truth

Rendered sites, dashboards, rollups, and search indexes are valuable, but they must derive from the authored corpus. If generated tracking pages become editable truth, the organisation has created another drift problem.

The source remains versioned markdown or an equivalent structured authored form that round-trips cleanly through review.

6. Living Specs Unlock True Iteration

Agile development is meant to shorten the distance between building, learning, and adapting. In practice, many agile implementations preserve a linear requirements-to-delivery shape. Scrum can become a cadence for repeatedly running mini-waterfalls:

specify -> commit -> implement -> review -> close

The problem is not the sprint. The problem is the absence of a durable, changeable product-truth artifact inside the loop. If the requirement expires when the sprint starts, then learning has nowhere authoritative to go.

Living Specs change the loop:

spec -> build -> use -> evaluate -> adjust spec -> rebuild

This loop can happen inside one delivery cycle. It can happen after production usage reveals a better rule. It can happen months later when strategy changes or an implementation constraint becomes visible. The important point is that learning updates the spec, not just the ticket queue.

That makes iteration cumulative. The team is not merely producing increments of code; it is improving the shared representation of the product. Each cycle can make the implementation better and the spec more truthful.

The practical effects are significant:

• user feedback changes the product model, not only the backlog
• implementation findings become durable product knowledge
• rework becomes a visible part of learning rather than hidden churn
• agents receive the latest reconciled truth before rebuilding
• future teams inherit the reasoning, not just the final code

This is the sense in which Living Specs unlock agile development. They provide the missing artifact that allows iteration to operate on product truth rather than only on tasks.

7. A Practical Shape For A Living Spec

A Living Spec should be structured enough for tooling and light enough for humans to maintain. A useful baseline is:

edge cases

• Purpose: why this spec exists and what truth it owns
• Product Role: who it serves and how central it is
• References: related specs, decisions, schemas, code areas, and research
• Requirements: behaviour, rules, contracts, constraints, examples, and
• Open Questions: unresolved uncertainty before it becomes structured backlog
• Tracking: durable feature rows and unresolved backlog pressure
• Change Log: meaningful spec authoring changes

The key is not the exact headings. The key is that the document remains the place where product truth is actively maintained.

8. The Tracking Model

The tracking model should be small enough to remember and precise enough to prevent important facts from being blurred together. A Living Spec does not need to become a project management system. It needs to answer four questions:

• can we trust this spec?
• what durable work exists?
• what shipped?
• what pressure remains?

Those questions should stay separate. If they are combined, "done" can mean implemented, shipped, validated, trusted, or merely closed in a ticketing system.

8.1 Can We Trust This Spec?

This is the confidence question. It is represented at spec level because it describes the trustworthiness of the document as product truth, not the delivery state of any individual feature.

This vocabulary is intentionally short. It should be understandable by product owners, engineers, designers, operators, and agents without a separate process manual.

8.2 What Work Exists?

Durable work belongs in feature rows. The spec itself may be edited many times, but the work being tracked is the capability-level change that affects product, platform, operational, or domain truth.

This keeps delivery work close to the capability it affects and avoids turning the spec document itself into a second task tracker.

8.3 What Shipped?

Release history should remain explicit and immutable.

This prevents teams from rewriting release facts when a living spec changes. The prose can move forward while delivery facts remain anchored.

8.4 What Pressure Remains?

Backlog rows represent unresolved pressure, not a second feature tracker.

Useful backlog types include:

• decision
• dependency
• risk
• bug
• cleanup
• enhancement
• validation
• question

The backlog is where uncertainty is made explicit before it turns into bad implementation assumptions. Backlog rows can later become feature rows, decision records, tests, or removals from scope.

9. How Living Specs Differ From Similar Processes

Living Specs are part of a lineage. They borrow from existing practices but combine them for a different purpose.

9.1 GitHub Spec Kit

GitHub Spec Kit is an AI-oriented spec-driven development toolkit. Its workflow uses project principles, feature specs, implementation plans, task generation, and agent execution. It is strong at turning a feature idea into structured work for an AI coding agent.

Its strength is implementation acceleration. It gives teams a repeatable path from idea to spec to plan to tasks to implementation.

Its weakness, relative to Living Specs, is that it is primarily organised around feature generation. It is less explicitly a long-term product memory model for a multi-release corpus of durable product truth.

Living Specs can use tools like Spec Kit, but they sit above them. Spec Kit helps execute work from specs. Living Specs define how the product truth survives after that work lands.

Reference: https://github.com/github/spec-kit

9.2 Kiro Specs

Kiro's spec workflow creates requirements, design, and task artifacts, then supports execution through task tracking and parallel task waves.

Its strength is developer ergonomics. It makes structured planning visible and actionable in the IDE.

Its weakness is tool coupling. The workflow is excellent for moving a feature through implementation, but it does not by itself define a company-wide, tool-independent corpus of evolving product truth.

Living Specs should remain portable across tools. IDE workflows can assist them, but should not own the methodology.

Reference: https://kiro.dev/docs/specs/

9.3 OpenSpec

OpenSpec is a lightweight, open-source spec-driven framework for AI coding assistants. It supports common coding tools, keeps specs in the codebase, and uses change proposals, design notes, tasks, and spec deltas to make intent reviewable before and during implementation.

Its strength is that it operationalises a very similar instinct to Living Specs: agents should not work from chat memory alone, and reviewers should be able to review intent rather than only code. OpenSpec's public material explicitly emphasises specs as persistent context, change-level spec deltas, and a workflow that is iterative rather than waterfall.

Its weakness, relative to this paper, is scope. OpenSpec is primarily a framework and workflow for managing specs and changes around AI-assisted coding. Living Specs are the broader methodology claim: the durable asset is the product-truth corpus itself, including confidence, unresolved pressure, release history, agent context, and the iterative learning loop.

The two are highly compatible. OpenSpec can be used as tooling for a Living Specs practice, especially when a team wants structured proposals, spec deltas, and agent integrations. Living Specs supply the higher-level operating model: why the specs matter, how they become product IP, and how learning flows back into the durable context layer.

References:

• https://openspec.dev/
• https://github.com/Fission-AI/OpenSpec/

9.4 Rational Rose And The Rational Unified Process

Rational Rose was a visual modeling tool closely associated with the Rational Unified Process. RUP described software development as iterative and architecture-centric, with work happening across disciplines such as business modeling, requirements, analysis and design, implementation, test, deployment, configuration management, and project management.

Its strength was that it did not treat analysis, design, implementation, and testing as one-time sequential gates. The familiar RUP phase-and-discipline diagram made the important point that these activities continue across the lifecycle, with different intensity at different times. That is close to the Living Specs argument: product truth should evolve through repeated cycles of modeling, building, testing, feedback, and adjustment.

Its weakness was weight. In many organisations, RUP became tool-centric and ceremonial. The useful idea of durable models could be buried under process configuration, role definitions, UML diagrams, and phase governance.

Living Specs keep the strongest part of that lineage: a maintained model of the system that survives individual implementation increments. The difference is that the maintained model is a lightweight, versioned, agent-readable spec corpus rather than a heavyweight UML repository.

Reference: https://www.ibm.com/docs/en/rational-clearquest/10.0.8?topic=settings-project-planning

9.5 Behaviour-Driven Development And Cucumber

BDD and Cucumber make behaviour executable through examples. Gherkin scenarios can document expected system behaviour and verify that the system conforms.

Their strength is testability. They turn selected behaviours into executable checks.

Their weakness is scope. Executable examples are not enough to capture strategy, architecture, domain boundaries, release history, rejected alternatives, and open product questions.

Living Specs should link to executable tests and may include examples, but they should not collapse into test files.

Reference: https://cucumber.io/docs/

9.6 Architecture Decision Records

ADRs capture significant decisions, their rationale, tradeoffs, and consequences. They are one of the closest ancestors of Living Specs because they preserve reasoning in version control.

Their strength is decision memory.

Their weakness is granularity. ADRs usually describe one decision, not an evolving product or platform capability across releases.

Living Specs should use ADRs as linked decision records when a decision is cross-cutting or important enough to stand alone.

Reference: https://adr.github.io/

9.7 RFC Processes

RFC processes, such as Rust's, provide a reviewed path for substantial changes. They are strong at consensus, structured discussion, and making large changes legible before implementation.

Their strength is governance.

Their weakness is that accepted RFCs often become decision snapshots. They may explain why a change was accepted, but not remain the operating description of a product surface.

Living Specs borrow the review discipline but keep the document alive.

Reference: https://github.com/rust-lang/rfcs

9.8 Shape Up

Shape Up focuses on shaping work before betting on it. It emphasises appetite, boundaries, senior shaping, and giving teams enough room to solve the details.

Its strength is product judgement. It prevents teams from throwing vague work into delivery.

Its weakness, for this purpose, is that a pitch is not necessarily maintained as the product representation after multiple rounds of implementation and learning.

Living Specs are compatible with Shape Up. A shaped pitch can become, update, or reference a Living Spec. The Living Spec then persists after the cycle ends.

Reference: https://basecamp.com/shapeup/

9.9 Docs-As-Code And Backstage TechDocs

Docs-as-code practices keep documentation in version control and publish it through engineering workflows. Backstage TechDocs is a mature example of docs rendering and publishing infrastructure.

Their strength is publishing discipline.

Their weakness is that publishing docs does not guarantee that the docs are the product truth. A beautifully rendered stale document is still stale.

Living Specs use docs-as-code as infrastructure, but add a methodology for continuous reconciliation and release-aware truth.

Reference: https://backstage.io/docs/features/techdocs/

10. Operating Model

10.1 Specs Live With The Owning System

The repository that owns behaviour should own the specs for that behaviour. Central methodology, templates, generated views, and cross-repo search can live elsewhere, but the product truth should be close to the implementation and review loop.

This prevents specs from becoming a remote documentation department.

10.2 Spec Changes Are Reviewable Changes

Living Specs should be edited through the same review discipline as code. A change to a durable product rule is a product change, even if no code changes in the same commit.

For substantial work:

1. Read the owning spec.
2. Update or create the spec if the work is not covered.
3. Implement against the spec.
4. Reconcile implementation findings back into the spec.
5. Report any remaining divergence.

10.3 Release Cuts Stamp History

When a release is cut, completed feature rows targeted at that release should be stamped with Delivered. That value should be treated as immutable release history.

This allows the main prose to evolve while retaining the ability to ask:

• what is true now?
• what did we intend for a release?
• what actually shipped?
• what did the spec look like at the release tag?

Those are different questions. The methodology should not collapse them.

10.4 Generated Views Are Derived

Spec browsers, confidence maps, feature tables, release views, and backlog views should be generated from the corpus.

Useful generated views include:

• spec browser by product area
• feature status board
• release target and delivered filters
• backlog pressure view
• search across prose, features, and backlog rows
• stale or inconsistent spec warnings

The authored specs remain the source.

11. Agent Skills Encode The Methodology

Living Specs give agents context. Agent skills make sure agents use that context consistently.

An agent skill is a reusable instruction file that tells the coding agent how to work inside a repository. For Continuous Specification, the skill should make the spec-first loop explicit:

1. Find and read the owning spec.
2. Use the spec as curated product context before inferring from code.
3. Update or create the spec if durable work is not covered.
4. Implement against the spec.
5. Reconcile implementation findings back into the spec.
6. Report the spec path and any unresolved divergence.

This matters because agentic coding can move quickly in the wrong direction when context is weak. A skill gives the agent a durable operating instruction: do not treat code as the only source of truth; start from the living product model.

A generic example skill is included with this paper:

Living Spec Development Skill

Teams should adapt that file to their own repository layout, spec vocabulary, release process, and review gates. The important part is not the exact wording. The important part is that the agent is explicitly instructed to keep specs and implementation in the same feedback loop.

12. Strengths Of The Living Specs Approach

12.1 It Preserves Product Memory

Living Specs give the organisation a durable place for product reasoning. This reduces dependence on individual memory, closed tickets, and reverse-engineering from code.

12.2 It Improves Agent Output

Agents perform better when they have precise context. A Living Spec gives them domain rules, constraints, non-goals, and current product truth. This lowers the chance that they fill gaps with plausible but wrong assumptions.

This matters because code is an incomplete context source. Code shows how the system behaves, but it rarely explains product intention, rejected alternatives, release boundaries, or the reason a rule exists. A Living Spec gives agents a curated starting point before they inspect implementation details.

12.3 It Separates Current Truth From Release History

The combination of current prose plus immutable delivery facts is powerful. It lets the spec evolve without erasing what shipped.

12.4 It Makes Rework Honest

In many tracking systems, rework looks like failure or churn. In Living Specs, rework is a normal part of product learning. A spec can explicitly move to Needs Rework when new evidence invalidates prior truth.

12.5 It Scales Across Rewrites

If the implementation changes framework, language, database, or UI architecture, the Living Spec should remain useful. This matters more as AI makes implementation rewrites cheaper.

13. Weaknesses And Risks

13.1 The Corpus Can Become Heavy

If every minor task requires elaborate spec editing, the methodology will become ceremony. Living Specs should govern durable product truth, not every small implementation detail.

13.2 Tracking Vocabulary Can Become Process Debt

Too many statuses create confusion. If contributors cannot explain the tracking model without looking up a glossary, the model is too complex.

The methodology should prefer a small vocabulary and add detail only where tooling or real operating pain justifies it.

13.3 Specs Can Still Rot

Putting specs in git does not magically keep them current. The loop must be enforced through review, agent instructions, validation, and cultural habit.

13.4 Tooling Can Hide Bad Authorship

A generated site can make the corpus look more mature than it is. Good rendering is not the same as good product truth. Tooling should expose missing fields, stale dates, unresolved backlog pressure, and inconsistent release facts.

13.5 AI Can Amplify Bad Specs

If the spec is wrong, agents can implement the wrong thing faster. This is not a reason to avoid specs. It is a reason to review them seriously.

14. Terminology

The artifact is a Living Spec.

The methodology is Continuous Specification.

A Living Spec is a continuously reconciled representation of product truth. It is living because it changes as implementation, review, release, usage, and strategy reveal better information.

Continuous Specification is the practice of maintaining specs as durable, versioned, reviewed, and agent-readable product truth throughout the lifecycle of a system.

The terminology matters because nearby phrases carry different assumptions:

with implementation-generation workflows.

• Dynamic Spec suggests automation, runtime behaviour, or vague change.
• Iterative Spec describes the process, but underplays the durable artifact.
• Spec-Driven Development is useful lineage, but is increasingly associated
• Executable Spec is useful for BDD, but too narrow for the full corpus model.

The naming should make the distinction clear:

• Jira epics track work.
• PRDs start work.
• Tests verify behaviour.
• ADRs preserve decisions.
• Living Specs preserve product truth.

15. Adoption Path

Stage 1: Start With One Durable Domain

Choose a product or platform area that changes often and suffers from knowledge drift. Write one Living Spec that captures current truth, not an idealised future state.

Stage 2: Add Feature And Backlog Tracking

Add durable feature rows and unresolved backlog pressure. Keep the vocabulary small. Do not attempt a full program management system.

Stage 3: Make Spec Reconciliation Part Of Implementation

Every durable implementation change should answer:

• which spec owns this?
• did the implementation match the spec?
• did the implementation reveal missing truth?
• has the spec been reconciled?

Stage 4: Add Release Stamping

Use Target for intent and Delivered for history. Stamp delivered rows at release cut. Treat delivered values as immutable.

Stage 5: Generate Views

Only after the authored corpus has enough structure should teams invest in generated browsers, filters, dashboards, and validation. Tooling should serve the corpus, not replace the authoring discipline.

16. Conclusion

Living Specs are not a call for more documentation. They are a call to stop throwing product truth away.

As AI reduces the cost of producing and changing code, the scarce asset becomes the maintained understanding of what the system should be. That understanding cannot live only in tickets, memories, or implementation details. It needs a durable home.

A Living Spec is that home. It is current enough to guide implementation, structured enough for tooling, reviewed enough to be trusted, and continuous enough to survive the work it initiates.

The practical shift is simple but significant:

Stop treating specs as scaffolding for code. Treat code as the current

expression of a living spec.

References

https://github.com/github/spec-kit

https://kiro.dev/docs/specs/

https://openspec.dev/

https://github.com/Fission-AI/OpenSpec/

https://www.ibm.com/docs/en/rational-clearquest/10.0.8?topic=settings-project-planning

https://public.dhe.ibm.com/software/rational/docs/v2002/rose/rose_using/intro.html

https://cucumber.io/docs/

https://adr.github.io/

https://github.com/rust-lang/rfcs

https://basecamp.com/shapeup/

https://backstage.io/docs/features/techdocs/

• GitHub Spec Kit:
• Kiro Specs:
• OpenSpec:
• OpenSpec GitHub repository:
• IBM Rational project planning:
• IBM Rational Rose visual modeling:
• Cucumber documentation:
• Architecture Decision Records:
• Rust RFC process:
• Shape Up:
• Backstage TechDocs: