traceflow

Govern software documentation lifecycle with mandatory spec-delta traceability and append-only ADRs.

Updated May 5, 2026
One-click install
npx skills add https://github.com/trypanic/skills --skill traceflow
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: traceflow
Source: https://github.com/trypanic/skills/tree/main/traceflow
Command: npx skills add https://github.com/trypanic/skills --skill traceflow

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) and assets (resource) components.

What problem does it solve?

Software projects accumulate documentation drift as ideas evolve into domain knowledge, architectural decisions get made, and implementation specs ship. Without enforced traceability, it becomes impossible to answer which spec owns a file, why a business rule exists, or which ADR ratified a structural choice. traceflow solves this by treating documentation as a first-class, lifecycle-governed artifact with mandatory delta tracking and reverse-index navigation.

Core Features & Use Cases

  • Four artifact axes: Explicitly governs ideas (brainstorms), domain (durable knowledge), decisions (append-only ADRs), and specs (implementation slices) through defined state machines and promotion criteria.
  • Spec-delta traceability: Every spec declares exactly which domain files and ADRs it adds, modifies, or removes, with typed NONE justifications for non-domain work like refactors or hotfixes.
  • Behavior-scoped diagrams: First-class diagram convention under the domain axis, featuring reusable fragments with canonical ownership, anchor-based cross-references, and composite rollups for scenario navigation.
  • Use Case: A Go monorepo with multiple bounded contexts uses traceflow to keep business rules, architectural decisions, and implementation slices synchronized, run structural invariants via bash smoke tests, and rebuild file-path maps automatically.

Quick Start

Use the traceflow skill to govern your project documentation lifecycle by promoting ideas to domain knowledge, ratifying ADRs, and scaffolding implementation specs with mandatory delta tracking.

Frequently Asked Questions about traceflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I maintain documentation traceability across specs, ADRs, and domain files in a monorepo?

Documentation traceability is maintained by enforcing spec-delta tracking, where every spec declares exact additions, modifications, or removals to domain files and ADRs. This structure ensures synchronized business rules and implementation slices across multi-area monorepos.

What is the best way to manage architectural decision records alongside evolving implementation specs?

Managing ADRs alongside specs requires an append-only decision log mapped to implementation artifacts. Governing the lifecycle across four axes—ideas, domain, decisions, and specs—ensures every structural choice is ratified and linked to its corresponding spec.

How do you track which spec owns a specific file path in a complex software project?

Tracking file ownership relies on structural invariants and a file-path reverse-index map. This automatically rebuilds the link between any file and its owning spec, preventing documentation drift and clarifying ownership across teams.

Can I use lifecycle-driven documentation for non-domain work like refactors and hotfixes?

Lifecycle-driven documentation applies to refactors and hotfixes through typed NONE justifications. When a spec does not modify domain files, it explicitly declares a NONE delta type, maintaining strict traceability without forcing irrelevant domain updates.

When do I need behavior-scoped diagrams for software documentation?

Behavior-scoped diagrams are needed when documenting durable domain knowledge across bounded contexts. They feature reusable fragments with canonical ownership and anchor-based cross-references, enabling composite rollups for complex scenario navigation.

Does this documentation lifecycle approach work for long-lived services with multiple bounded contexts?

This approach suits long-lived services and multi-area monorepos by keeping business rules, architectural decisions, and implementation slices synchronized. It applies structural invariants verified via bash smoke tests to prevent documentation drift over time.