Expand feature-driven-flow README with clearer workflow and rule guidance

- Add detailed descriptions for skills, prompt, shared rules, and local rule overlays
- Clarify install and usage steps, including scope-to-phase behavior
- Explain rule model fields and precedence conflict handling
- Extend diagnostics with guidance for blocked phases and under-specified outputs
- Add creator LinkedIn profile link

Author: romantal

README.md

@@ -1,20 +1,21 @@
 # Codex Feature-Driven-Flow
 
 Script-free Codex package for one-command feature workflow orchestration with a rules-based extension system.
+It is designed to keep feature delivery predictable by combining a minimal core workflow with declarative rules that can be shared or overridden per repository.
 
 ## Includes
 
 1. Skills:
-   - `skills/feature-driven-flow`
-   - `skills/fdf-code-explorer`
-   - `skills/fdf-implementation-planner`
-   - `skills/fdf-change-auditor`
+   - `skills/feature-driven-flow`: main conductor skill that drives the seven-phase workflow and gate checks.
+   - `skills/fdf-code-explorer`: specialist skill for mapping current behavior and code paths before planning changes.
+   - `skills/fdf-implementation-planner`: specialist skill for turning clarified requirements into a file-by-file implementation plan.
+   - `skills/fdf-change-auditor`: specialist skill for reviewing completed changes, risks, and verification coverage.
 2. Prompt:
-   - `prompts/feature-driven-flow.md`
+   - `prompts/feature-driven-flow.md`: entrypoint that activates the conductor workflow in Codex.
 3. Shared rules:
-   - `skills/feature-driven-flow/extensions/rules/*.md`
+   - `skills/feature-driven-flow/extensions/rules/*.md`: reusable rule set for phase behavior, checks, and expected outputs.
 4. Optional repository-local rules:
-   - `<repo>/.codex/feature-driven-flow/rules/*.md`
+   - `<repo>/.codex/feature-driven-flow/rules/*.md`: local policy overlays that refine shared rules for a specific codebase.
 
 ## Install
 
@@ -28,10 +29,10 @@ codex --help
 3. Create folders:
    - `CODEX_HOME/skills`
    - `CODEX_HOME/prompts`
-4. Copy:
+4. Copy package assets:
    - `codex/feature-driven-flow/skills/*` -> `CODEX_HOME/skills/`
    - `codex/feature-driven-flow/prompts/*.md` -> `CODEX_HOME/prompts/`
-5. Restart Codex session.
+5. Restart Codex session so newly installed prompt and skills are detected.
 
 ## Use
 
@@ -41,7 +42,7 @@ Run the prompt:
 /prompts:feature-driven-flow Implement financial services
 ```
 
-Select shared rules in the request:
+Select shared rules in the request to control phase behavior:
 
 ```text
 /prompts:feature-driven-flow Implement financial services using rules scope-baseline, explore-baseline, clarify-policy, architect-policy, implement-baseline, verify-policy, summarize-policy, security-baseline
@@ -54,6 +55,7 @@ Repository-local baseline rule (auto-applied when present):
 ```
 
 At Scope, Codex infers execution context and proposes a phase-by-phase rule matrix. The user can accept or adjust before Explore.
+The workflow then proceeds through seven phases with explicit gates, checklist-based readiness, and approval points before implementation.
 
 ## Core vs Rules
 
@@ -67,18 +69,19 @@ Core is a light skeleton that enforces:
 6. Checklist-driven gates where phase checklist items are derived from active rule `checks`.
 
 Everything else should live in rules.
+This separation keeps core behavior stable while allowing teams to evolve policy without editing conductor logic.
 
 ## Simple Rule Model
 
 Each rule should define:
 
-1. `id`
-2. `title`
-3. `applies_to_phases`
-4. `intent`
-5. `guidance`
-6. `checks` (also used to derive phase checklist items)
-7. `outputs`
+1. `id`: unique, stable rule identifier used in matrices and traceability.
+2. `title`: short human-readable name.
+3. `applies_to_phases`: one or more phases where the rule is active.
+4. `intent`: what the rule is trying to guarantee.
+5. `guidance`: concrete instructions Codex should follow when the rule is active.
+6. `checks` (also used to derive phase checklist items): verifiable conditions that determine whether a phase can pass.
+7. `outputs`: artifacts or structured results expected from the phase when the rule applies.
 8. `examples` (optional)
 
 ## Rule Precedence
@@ -87,10 +90,17 @@ Each rule should define:
 2. Repository policy constraints in `AGENTS.md`.
 3. User-confirmed phase-by-phase rule matrix.
 4. Within active rules, repository-local rules refine shared rules.
+   When instructions conflict, Codex should prioritize higher-precedence sources and ask for clarification if a conflict cannot be safely resolved.
 
 ## Diagnostics
 
 1. If `codex` is not found, run `codex --help`.
 2. If prompt does not appear, confirm `CODEX_HOME/prompts/feature-driven-flow.md` exists and restart.
 3. If shared rules are not detected, check `CODEX_HOME/skills/feature-driven-flow/extensions/rules/`.
-4. If local baseline rule is not applied, check `<repo>/.codex/feature-driven-flow/rules/project-baseline.md`.
+4. If local baseline rule is not applied, check `<repo>/.codex/feature-driven-flow/rules/project-baseline.md`.
+5. If outputs look under-specified, include explicit rule IDs in your prompt instead of relying on defaults.
+6. If a phase is blocked, inspect active rule `checks` first, then resolve missing inputs or approvals.
+
+## Creator
+
+- LinkedIn: https://www.linkedin.com/in/taluyev/