How pdlc-skills Makes Progress, Change Impact, and Quality Trends Visible

The last article focused on the quality chain, while this piece explores visibility. AI can advance three features in an afternoon; however, if one cannot determine the project's current state, the impact of a change, or how the final stage went, the automation operates in a black box. pdlc provides three tools for this purpose: the statusline, /pdlc-status, /pdlc-relate, and /pdlc-retro. These tools monitor three timeframes: right now, prior to a change, and monthly.

All three tools exclusively read state files in docs/.pdlc-state/. They don't parse documents or make assumptions. The statusline and /pdlc-status reveal the current project status, while retro analyzes the past stretch.

The statusline and /pdlc-status display where the project stands. Each feature shows the six stages (PRD, design, TDD, implementation, review, ship) with the current stage highlighted, the next step, run mode (autonomous or manual), check results, and time spent in the current stage. A bug fix may not follow all six stages, so it displays the fixed track and highlights the current position. Checks default to autonomous mode, providing a glance at the health of an unattended loop.

Blocked features alter the line's format: ⛔ PDLC xxx blocked: needs a product decision · ⏱12m. A stopped loop waiting for human intervention appears at the top. The statusline's primary function is to show this.

The /pdlc-status command-line view lists progress, completed tasks, and suggested tasks, along with a relation tree if available. It verifies the data, not merely listing items.

If three features remained at "review done" without shipping for over ten days, the CHANGELOG and git tags were consulted to confirm actual shipping. This tool's purpose is to highlight issues, leaving decision-making to humans.

The relation graph illustrates how a change impacts the project. Six relation types exist: four are directed (extends, depends_on, supersedes, resolves) and two are symmetric (conflicts_with, relates_to). pdlc automatically assigns feature IDs, scans existing features, and records reasons in the PRD and state file. In a three-iteration project, phase 2 and 3 extended phase 1, which in turn extended the original MVP.

Rebuilding the graph updates an index of nodes and edges, drawing a mermaid diagram. Historical nodes, like the MVP, remain in the graph.

Impact is crucial for understanding the graph. It categorizes direct (passed review), indirect (one hop further), and historical (audit only) impacts. When a change targets an already impacted feature, it should be a new feature superseding the old one, not an in-place edit, to maintain downstream review validity.