{"slug": "how-pdlc-skills-makes-progress-change-impact-and-quality-trends-visible", "title": "How pdlc-skills Makes Progress, Change Impact, and Quality Trends Visible", "summary": "A developer released pdlc-skills, a set of tools that read state files under docs/.pdlc-state/ to surface project status, change impact, and retrospective trends for AI-assisted development. The toolkit includes a statusline and /pdlc-status command for current progress, /pdlc-relate for mapping six relation types between features, and /pdlc-retro for month-by-month quality trends. The tools only read state files rather than parsing documents, so their accuracy depends on how faithfully those files are written.", "body_md": "The last post covered the quality chain. This one is about **visibility**. An AI can push three features forward in an afternoon. If you can't tell where the project stands, what a change will touch, or how the last stretch went, the automation is running in a black box. pdlc has three tools for this: the statusline together with `/pdlc-status`, `/pdlc-relate`, and `/pdlc-retro`. They watch three timescales: right now, before a change, and month by month.\n\nAll three only read the state files under `docs/.pdlc-state/`. They don't parse documents and they don't guess. Post 3 described how the three layers coordinate through one shared scoreboard; these tools read that same scoreboard and differ only in the question they answer. The statusline and `/pdlc-status` answer \"where are we now?\". `impact` answers \"what does changing this touch?\". `retro` answers \"how did this stretch go?\".\n\nHow accurately the state files are written decides whether what these tools show is true. I'll come back to that at the end.\n\nHere is a statusline entry from a real project, with the stage labels translated (the current release prints them in Chinese):\n\n```\n● PDLC console-p3 · PRD·Design·TDD·Impl·[Review]·Ship · →ship · 🤖 · ✓unit ✓lint ✓cov · ⏱9d\n```\n\nLeft to right: the feature name; the six-stage track (PRD, design, TDD, implementation, review, ship) with the current stage highlighted; the next step; the run mode (🤖 autonomous loop, 👤 manual); the three check results; and how long the feature has sat in the current stage.\n\nThree design choices in this one line are worth spelling out.\n\n`⛔ PDLC xxx blocked: needs a product decision · ⏱12m`. A loop that has stopped and is waiting for a human must be the first thing you see. That is the statusline's main job.\nOne command turns it on: `/pdlc-settings statusline`. It appends itself after whatever statusline command you already have and leaves the rest alone. `/pdlc-status` is the command-line view of the same data: in progress, done, and suggested to-dos, plus a relation tree if the relation index exists. It verifies rather than just listing. When three features had sat at \"review done, not shipped\" for over ten days, it went to the CHANGELOG and the git tags to confirm that nothing had actually shipped. `--stale 3` tabulates how many days each feature has been sitting.\n\nThat is as far as a tool goes: it puts the problem in front of you. What to do about it is a person's call.\n\nWhich feature extends, depends on, or replaces which: there are six relation types. Four are directed: `extends`, `depends_on`, `supersedes`, `resolves`. Two are symmetric: `conflicts_with`, `relates_to`. Nobody fills these in by hand. When `/pdlc-feature` assigns a feature ID it scans the existing features, and `/pdlc-prd` scans the requirements text for words like \"based on\", \"extends\", \"depends on\", and \"replaces\"; whatever it finds goes into the PRD and the state file with a reason attached. In one real project with three iterations, phase 2 and phase 3 both extend phase 1, and phase 1 extends the original MVP.\n\nRun `rebuild` once and it scans the state files, builds an index of nodes and edges, and draws a mermaid graph. The MVP predates the project's adoption of pdlc and has no state file. Rather than reporting a dangling reference, rebuild kept it as a historical terminal node.\n\n`impact` is the reason the graph exists. Run it on phase 1 and the output has three tiers: 🔴 direct impact (phase 2 and phase 3), 🟡 indirect impact (anything one hop further; none here), 🟢 historical (the MVP, audit only). It also gives advice: phase 1 is already extended by two features that have passed review, so a change to it should be a new feature that `supersedes` it, not an in-place edit, or the downstream review results become void.\n\nThe other subcommands: `query` shows one feature's inbound and outbound edges, `orphans` lists features with no relations at all, and `validate` checks five rules: dangling references, self-references, cycles, contradictory pairs, and whether symmetric relations are recorded on both sides. `set` is the only one that writes state files: add a symmetric relation and both files get a line, then the index is rebuilt.\n\n`/pdlc-retro` looks at the last 30 days by default and aggregates the history in the state files into a report: features delivered, self-check pass rate per stage, median stage duration, and sticking points, written to a monthly file under `docs/07_reviews/retro/`.\n\nPass rates from one real run: requirements, design, and TDD at 100%, implementation 93.8%, review 54.9%. The rate is the share of self-check items that passed. The forty-odd percent that didn't pass at review are the items flagged for a person to decide, about seven per feature.\n\nThat number is right. The first four stages settle everything a machine can judge, and whatever it can't judge is left for review. A low review \"pass rate\" means the earlier stages did their job. If review also came out at 100%, I'd want to know whether it actually looked.\n\nMedian durations: requirements 0.0 hours, design 0.1, TDD 0.6, implementation 0.9, review 5.0. Take the review figure with a grain of salt. It measures wall-clock time from entering review to finishing it, overnight hours included, not working time.\n\nHow the report handles bad data is worth noting. One feature's review had a completion timestamp earlier than its implementation. Instead of producing a negative duration, the report dropped the sample and listed it separately as \"data anomaly, check the write timing\". Re-run with a seven-day window that contained no activity, and all four sections said \"no data\" and explained why. Same rule as the false greens in the last post: if it can't be judged, say so, and never paint it green.\n\nAll three tools only read state files; none of them checks the code. The state files are written by the AI at the end of each stage, and they drift. When they do, the tools don't fail; they quietly show one item less or count one stage less. The example project has two cases. The check keys: older features wrote `tests_green`, newer ones use the standard `tests_pass`, and the statusline only reads the standard set, so the older features' checks don't show. And the history has no start timestamps, so durations can only be computed from consecutive completion times. Relations are the same: they're recorded automatically once, at kickoff. If the requirements change later, you `set` the new relation yourself.\n\nSo the precondition for all three tools is treating the state files as data to be maintained: fields, timestamps, and relations written to spec.\n\nBack to the opening question: the AI pushes three features in an afternoon, so how does a person keep up? Each tool answers one question, where things are, what a change touches, how the stretch went, and all the answers come from the same state files, with no digging through documents and no guessing. They don't make decisions. Whether to push a stalled feature, whether to touch a baseline, how to schedule the items review left for a person: still a human call, now made with data in hand. When the statusline is missing an item or the retro is missing a stage, suspect the records first, then the tool.\n\nWith the three tools covered, the mechanics part of this series is done. Next time we go back to a real project and walk it from the first command to the last release, to see how all of this gets used once it's installed.\n\n**Want to try it**:\n\n```\ncurl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh | bash -s -- --global\n```\n\nThe repo: [https://github.com/kanfu-panda/pdlc-skills](https://github.com/kanfu-panda/pdlc-skills)\n\nIf it's useful, a star goes a long way ⭐\n\nWhat's the longest any feature in your project has sat untouched? Comments welcome.", "url": "https://wpnews.pro/news/how-pdlc-skills-makes-progress-change-impact-and-quality-trends-visible", "canonical_source": "https://dev.to/kanfu-panda/how-pdlc-skills-makes-progress-change-impact-and-quality-trends-visible-44me", "published_at": "2026-09-12 03:06:24+00:00", "updated_at": "2026-09-12 03:26:29.532929+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-agents", "mlops"], "entities": ["pdlc-skills", "pdlc", "/pdlc-status", "/pdlc-relate", "/pdlc-retro", "/pdlc-feature", "/pdlc-prd"], "alternates": {"html": "https://wpnews.pro/news/how-pdlc-skills-makes-progress-change-impact-and-quality-trends-visible", "markdown": "https://wpnews.pro/news/how-pdlc-skills-makes-progress-change-impact-and-quality-trends-visible.md", "text": "https://wpnews.pro/news/how-pdlc-skills-makes-progress-change-impact-and-quality-trends-visible.txt", "jsonld": "https://wpnews.pro/news/how-pdlc-skills-makes-progress-change-impact-and-quality-trends-visible.jsonld"}}