docs: tighten prose style in README

Author: mkrtchian

README.md

@@ -6,7 +6,7 @@ Your plan, fresh agents, zero drift.
 [![Markdown only](https://img.shields.io/badge/zero_code-markdown_prompts_only-brightgreen.svg)](#whats-in-this-repo)
 [![Claude Code](https://img.shields.io/badge/Claude_Code-plugin-blueviolet.svg)](https://docs.anthropic.com/en/docs/claude-code)
 
-A structured workflow for AI-assisted development — from discussion to reviewed, tested, standards-compliant code, through a version-controlled plan. 2 skills, 7 agents, ~800 lines of markdown. No code, no config, no state directories — just prompts.
+A structured workflow for AI-assisted development: from discussion to reviewed, tested, standards-compliant code, through a version-controlled plan. 2 skills, 7 agents, ~800 lines of markdown. No code, no config, no state directories. Just prompts.
 
 ## Prerequisites
 
@@ -41,7 +41,7 @@ AI coding assistants hit two walls on non-trivial changes:
 
 ## The approach
 
-Two skills, each orchestrating fresh agents with isolated context. Each agent starts with a fresh context window, focused on a single concern — no attention pollution between phases.
+Two skills, each orchestrating fresh agents with isolated context. Each agent starts with a fresh context window, focused on a single concern. No attention pollution between phases.
 
 ```mermaid
 flowchart TD
@@ -73,11 +73,11 @@ flowchart TD
 
 ## Design decisions
 
-**Isolated passes.** A single agent asked to "implement this plan, follow TDD, and check coding standards" will do all three poorly. An agent that just spent 20 minutes implementing code is not in the right mindset to review standards — it's biased toward defending what it just wrote. Fresh context per concern — same principle as code review. For the detailed rationale, see [workflow.md](docs/workflow.md#why-isolated-context).
+**Isolated passes.** A single agent asked to "implement this plan, follow TDD, and check coding standards" will do all three poorly. An agent that just spent 20 minutes implementing code is not in the right mindset to review standards: it's biased toward defending what it just wrote. Fresh context per concern, same principle as code review. For the detailed rationale, see [workflow.md](docs/workflow.md#why-isolated-context).
 
-**Plans in git.** Your plan is a plain markdown file — it goes through your normal PR review process. No special directories, no hidden state. Two developers can plan and implement different features on different branches without interfering. A plan typically covers: context and approach, files to modify with code details, what stays unchanged, edge cases, test scenarios, and verification commands.
+**Plans in git.** Your plan is a plain markdown file. It goes through your normal PR review process. No special directories, no hidden state. Two developers can plan and implement different features on different branches without interfering.
 
-**Sequential execution.** Each pass builds on verified state — simpler to reason about, debug, and review. Parallel execution saves time but adds coordination complexity that isn't worth it for single-feature work.
+**Sequential execution.** Each pass builds on verified state. Simpler to reason about, debug, and review. Parallel execution saves time but adds coordination complexity that isn't worth it for single-feature work.
 
 **Dynamic discovery over configuration.** Skills detect your project's test runner, linter, and standards by finding and reading `CLAUDE.md` and other relevant files. Nothing is hardcoded to a stack.
 
@@ -89,7 +89,7 @@ flowchart TD
 
 - Developers working on non-trivial features where AI "just do it" approaches produce drift and rework
 - Teams that do code review and want AI-generated code to go through the same rigor
-- Anyone who wants a predictable, inspectable AI workflow — plan in git, fresh agents, no hidden state
+- Anyone who wants a predictable, inspectable AI workflow: plan in git, fresh agents, no hidden state
 
 ## What's in this repo
 
@@ -99,24 +99,24 @@ agents/          7 custom agent definitions (reviewer, implementer, hardener, et
 docs/            Workflow guide and framework comparison
 ```
 
-Each agent is a custom agent definition distributed via the plugin. The orchestrator skills reference them by `subagent_type` — their prompt content is never loaded into the orchestrator's own context. Manual installation is not supported; the plugin system handles resolution.
+Each agent is a custom agent definition distributed via the plugin. The orchestrator skills reference them by `subagent_type`, so their prompt content is never loaded into the orchestrator's own context. Manual installation is not supported; the plugin system handles resolution.
 
 ## Reliability
 
-In practice, well-structured prompts with Opus are followed 95%+ of the time — tests run, TDD is applied, standards are checked. The step hardener catches most of the remaining 5% by verifying each step with fresh context before committing.
+In practice, well-structured prompts with Opus are followed 95%+ of the time. Tests run, TDD is applied, standards are checked. The step hardener catches most of the remaining 5% by verifying each step with fresh context before committing.
 
-For hard guarantees on test/lint/typecheck, pair with git pre-commit hooks — agents trigger them on every commit.
+For hard guarantees on test/lint/typecheck, pair with git pre-commit hooks. Agents trigger them on every commit.
 
 ## Comparison
 
-Tested on the same feature and repo as [GSD](https://github.com/gsd-build/get-shit-done) and [Superpowers](https://github.com/obra/superpowers). All three produced working implementations. The key difference is in the review layer: spec-driven-dev runs dedicated review passes with fresh agents that never saw the code being written — same principle as human code review, where the reviewer shouldn't be the author. The trade-off is speed (~22 min vs ~15 min for the others).
+Tested on the same feature and repo as [GSD](https://github.com/gsd-build/get-shit-done) and [Superpowers](https://github.com/obra/superpowers). All three produced working implementations. The key difference is in the review layer: spec-driven-dev runs dedicated review passes with fresh agents that never saw the code being written. Same principle as human code review, where the reviewer shouldn't be the author. The trade-off is speed (~22 min vs ~15 min for the others).
 
 For the full benchmark and detailed analysis, see the **[framework comparison](docs/comparison.md)**.
 
 ## Contributing
 
-Contributions welcome — [open an issue](https://github.com/mkrtchian/spec-driven-dev/issues) to discuss before submitting a PR.
+Contributions welcome. [Open an issue](https://github.com/mkrtchian/spec-driven-dev/issues) to discuss before submitting a PR.
 
 ## License
 
-MIT — [Roman Mkrtchian](https://github.com/mkrtchian)
+MIT. [Roman Mkrtchian](https://github.com/mkrtchian)