@event4u/agent-config 1.16.0 → 1.18.0

package/.agent-src/skills/readme-writing/SKILL.md

@@ -15,29 +15,34 @@ execution:
 - Creating a new README for an **application, CLI tool, internal tool, template, or framework**
 - Rewriting an outdated or weak README
 - Improving after major repo changes (new tooling, restructure)
+- Adapting README for a different audience
 
-Do NOT use for:
+Do NOT use when:
 
-- **Packages/libraries** → use `readme-writing-package` instead
-- Minor typos, single-section updates, reference docs in separate files
+- Writing a README for a **reusable package or library** → use `readme-writing-package` instead
+- Fixing minor typos or updating a single section
+- Writing reference docs that belong in separate files
+- Only adding a badge or version bump
 
 ## Goal
 
-Accurate, evidence-based, scannable README for the intended audience.
-Reflects the real repository — not assumptions.
+Write a README that is accurate, evidence-based, scannable, and useful for
+the intended audience. Reflects the real repository — not assumptions.
 
 ## Core principles
 
-- Analyze first, write second — inspect repo before writing
-- Evidence-based — every command, step, feature must exist in repo
-- Strong quickstart over exhaustive noise — get started in 30 seconds
-- Right scope — overview in README, deep content in dedicated docs
-- Match repo type — package README ≠ app ≠ CLI tool ≠ framework
+- **Analyze first, write second** — inspect the repo before writing a single line
+- **Evidence-based only** — every command, setup step, and feature must exist in the repo
+- **Strong quickstart over exhaustive noise** — a reader should get started in 30 seconds
+- **Right scope** — high-level overview in README, deep content in dedicated docs
+- **Match the repo type** — a package README differs from an app, CLI tool, or framework
 
 ## Procedure
 
 ### 1. Identify README type and audience
 
+Determine repository type:
+
 | Type | Audience | Priority |
 |---|---|---|
 | **Library/Package** | Developers consuming it | Install → Usage → API |
@@ -49,94 +54,114 @@ Reflects the real repository — not assumptions.
 
 ### 2. Inspect the repository
 
-Read truth-defining files:
+Read these files to extract truth:
 
-- `README.md` (existing), `package.json`, `composer.json`
-- `Dockerfile`, `docker-compose.yml`
-- `Taskfile.yml`, `Makefile`
-- CI workflows, config files, `docs/`, `agents/`
+- `README.md` (existing, if any)
+- `package.json`, `composer.json` — name, description, scripts, dependencies
+- `Dockerfile`, `docker-compose.yml` — runtime setup
+- `Taskfile.yml`, `Makefile` — available commands
+- CI workflows — what gets tested, how
+- `docs/`, `agents/` — existing documentation
+- Config files — what tools are used
 
-Extract: purpose, install path, commands, requirements, workflows, testing, contribution flow.
+Extract: project purpose, install path, main commands, requirements,
+key workflows, testing/linting commands, contribution flow.
 
 ### 3. Choose sections
 
-Only include sections that provide value:
+Only include sections that provide value. Candidates:
 
 1. **Title + one-line summary** — always
-2. **Why / what problem** — if not obvious from name
-3. **Key features** — if more than trivial
+2. **Why / what problem it solves** — if not obvious from name
+3. **Key features or capabilities** — if more than a trivial tool
 4. **Requirements** — only if non-obvious
 5. **Installation / setup** — always
-6. **Usage / quickstart** — always (most important)
-7. **Configuration** — if applicable
-8. **Development workflow** — if accepts contributions
+6. **Usage / quickstart** — always (most important section)
+7. **Configuration / customization** — if applicable
+8. **Development workflow** — if repo accepts contributions
 9. **Testing / quality** — if tooling exists
 10. **Project structure** — if non-trivial
-11. **Contributing** — if open/team project
+11. **Contributing** — if open or team project
 12. **License** — if applicable
 
+Do NOT include sections "because READMEs usually have them."
 Skip empty or near-empty sections entirely.
 
 ### 4. Write evidence-based content
 
-- Only document commands that exist in the repo
+Rules:
+
+- Only document commands that actually exist in the repo
 - Only describe setup steps supported by scripts/configs
 - Only claim features confirmed by code or docs
-- Unclear? Inspect more or ask — never invent
+- If something is unclear: inspect more or ask — never invent
+
+Formatting:
 
-Formatting: tables for comparisons, code blocks for commands (copy-pasteable),
-short paragraphs (max 3 sentences), directory trees for structure.
+- Tables for structured comparisons (tools, options, features)
+- Code blocks for every command (copy-pasteable)
+- Short paragraphs — max 3 sentences before a break
+- Directory trees for project structure (use `tree` format)
+- Badges only if they link to live CI/release status
 
-### 5. Optimize for first screen
+### 5. Optimize for the first screen
 
-Reader must answer within 10 seconds: What is this? Why? How to start?
+A reader scanning the README should answer within 10 seconds:
 
-First screen (before scroll): title, summary, install or quickstart.
+1. What is this?
+2. Why does it exist?
+3. How do I install/start it?
+
+The first screen (before scrolling) must contain the title, summary,
+and either install command or quickstart. Everything else comes after.
 
 ### 6. Size and structure
 
-Keep README scannable. Past ~150 lines: add Table of Contents. Past ~300
-lines: split deep content to `/docs/` or `references/`. Use `<details>`
-only for secondary, bulky content — never for install, first example, or
-requirements.
+Keep the README scannable. If it grows past ~150 lines, add a Table of
+Contents; past ~300 lines, split deep content out to `/docs/` or
+`references/`. Use `<details>` only for secondary, bulky content (never
+for install, first example, or requirements).
 
 → See `docs/guidelines/docs/readme-size-and-splitting.md` for thresholds,
 splitting strategies (reference-split, deep-link tables, collapsibles),
-multi-audience handling, anti-patterns.
+multi-audience handling, and anti-patterns.
 
 ### 7. Validate
 
-- [ ] Every command exists in repo (`Taskfile.yml`, `Makefile`, `package.json`, etc.)
-- [ ] Setup steps are reproducible
-- [ ] No invented features or capabilities
+After writing, verify:
+
+- [ ] Every documented command exists in the repo (`Taskfile.yml`, `Makefile`, `package.json scripts`, etc.)
+- [ ] Setup steps are reproducible (no missing prerequisites)
+- [ ] No features or capabilities are invented
 - [ ] First screen answers: what, why, how-to-start
 - [ ] No dead sections (heading with 1-2 trivial sentences)
-- [ ] Deep content in dedicated docs, not crammed in README
-- [ ] Size below "overloaded" threshold, or splitting in place (see size guideline)
-- [ ] ToC present if > 150 lines or > 6 top-level sections
+- [ ] Scope is right — deep content moved to dedicated docs, not crammed in
+- [ ] Size below the "overloaded" threshold, or splitting is in place (see size guideline)
+- [ ] ToC present if README > 150 lines or > 6 top-level sections
+- [ ] Matches existing tonality if repo has established voice
 - [ ] All file paths and references are valid
 
 ## Output format
 
 1. Full README draft
 2. Short note: detected repo type + audience
-3. Uncertainties or assumptions needing confirmation
+3. Any uncertainties or assumptions that need confirmation
 
 ## Gotcha
 
-- Model writes generic boilerplate instead of repo-specific docs
-- Model includes commands/steps that don't exist in the repo
-- Model over-documents, burying the quickstart under walls of text
-- Existing README structure can mislead — don't preserve weak structure blindly
-- Package READMEs need install/usage focus, not internal dev workflow
-- Model forgets to validate commands against `Taskfile.yml` / `Makefile` / `package.json`
+- The model tends to write generic boilerplate instead of repo-specific documentation
+- The model tends to include commands or setup steps that don't actually exist in the repo
+- The model tends to over-document and bury the quickstart under walls of text
+- Existing README structure can be misleading — don't preserve weak structure blindly
+- READMEs for packages consumed by others need install/usage focus, not internal dev workflow
+- The model forgets to validate commands against `Taskfile.yml` / `Makefile` / `package.json scripts`
 
 ## Do NOT
 
-- Do NOT invent features, setup steps, or commands not in the repo
-- Do NOT copy generic templates without adapting to the project
-- Do NOT overload with deep reference material — link to docs
+- Do NOT invent features, setup steps, or commands not found in the repo
+- Do NOT copy generic README templates without adapting to the actual project
+- Do NOT overload with deep reference material — link to docs instead
 - Do NOT write for "everyone" — choose a real audience
 - Do NOT skip repository inspection before writing
-- Do NOT preserve weak structure just because it exists
-- Do NOT add marketing language ("blazing fast", "revolutionary")
+- Do NOT preserve weak structure from an existing README just because it exists
+- Do NOT add marketing language ("blazing fast", "revolutionary", "next-gen")

package/.agent-src/skills/readme-writing-package/SKILL.md

@@ -13,27 +13,28 @@ execution:
 ## When to use
 
 - Creating a README for a package, library, SDK, or framework extension
-- Rewriting after major changes (new API, version bump, new registry)
-- Improving a weak package README (missing install, no example, no compatibility)
-- Documenting for Packagist, npm, or internal registries
+- Rewriting a package README after major changes (new API, version bump, new registry)
+- Improving a weak package README (missing install, no example, no compatibility info)
+- Documenting a package for Packagist, npm, or internal registries
 
-Do NOT use for:
+Do NOT use when:
 
-- Full applications, CLI tools, internal team repos → use `readme-writing`
-- Minor typos, single-section updates, deep reference docs in `/docs`
+- Documenting a full application, CLI tool, or internal team repo → use `readme-writing` instead
+- Only fixing minor typos or updating a single section
+- Writing deep reference docs that belong in `/docs`
 
 ## Goal
 
-Package README that makes adoption easy. Developer knows within 30 seconds:
-what it does, whether it fits their stack, how to install, how to use.
+Package README that makes adoption easy. A developer should know within 30 seconds:
+what it does, whether it fits their stack, how to install it, and how to use it.
 
 ## Core principles
 
-- User adoption over internal architecture — consumer first, maintainer second
-- Install + first example = most important sections
-- Compatibility must be explicit — don't imply broad support without evidence
-- First example: real, minimal, verified — no pseudo-code
-- README = onboarding, /docs = reference
+- **User adoption over internal architecture** — consumer first, maintainer second
+- **Install + first example = most important sections** — everything else is secondary
+- **Compatibility must be explicit** — don't imply broad support without evidence
+- **First code example must be real, minimal, and verified** — no pseudo-code
+- **README = onboarding, /docs = reference** — keep README focused
 
 ## Procedure
 
@@ -49,16 +50,18 @@ what it does, whether it fits their stack, how to install, how to use.
 
 ### 2. Inspect package truth sources
 
+Read files that define actual package behavior:
+
 - `composer.json` / `package.json` — name, description, requirements, scripts
-- Source entrypoints — public API, main classes/functions
+- Source entrypoints — public API surface, main classes/functions
 - Config files — publishable configs, defaults
-- CI workflows — supported versions matrix
-- Tests — actual API usage patterns
+- CI workflows — what gets tested, supported versions matrix
+- Tests — reveal actual API usage patterns
 - `CHANGELOG.md` / releases — current state, breaking changes
-- Examples directory if present
+- Examples directory — if present
 
-Extract: name, purpose, install command, runtime requirements, supported
-versions, public API, setup steps, test/lint commands.
+Extract: package name, purpose, install command, runtime requirements,
+supported versions, public API, setup steps, test/lint commands.
 
 ### 3. Choose sections
 
@@ -68,14 +71,14 @@ Priority order for packages:
 2. **Why / what problem** — if not obvious from name
 3. **Requirements / compatibility** — always (versions, extensions, frameworks)
 4. **Installation** — always (exact command, post-install steps)
-5. **Minimal usage example** — always (most important)
-6. **Configuration** — if config publish, env vars, or registration needed
-7. **More examples** — if API has multiple entry points
+5. **Minimal usage example** — always (most important section)
+6. **Configuration / setup** — if config publish, env vars, or registration needed
+7. **More examples / common use cases** — if API has multiple entry points
 8. **Development / testing** — for maintainers/contributors
-9. **Contributing** — if open/team project
+9. **Contributing** — if open or team project
 10. **License** — if applicable
 
-Skip sections with no real content. Never pad.
+Skip sections that have no real content. Never pad.
 
 ### 4. Write requirements and compatibility
 
@@ -89,12 +92,12 @@ State only what is tested and supported:
 - ext-json
 ```
 
-Don't imply broad compatibility if only tested in narrow range. Include
-framework version, language version, required extensions, services.
+Do NOT imply broad compatibility if only tested in narrow range.
+Include framework version, language version, required extensions, services.
 
 ### 5. Write installation that actually works
 
-Exact install command and required follow-up:
+Document the exact install command and any required follow-up:
 
 ```bash
 composer require vendor/package
@@ -103,25 +106,25 @@ composer require vendor/package
 php artisan vendor:publish --tag=package-config
 ```
 
-Validate each step against the codebase. Include post-install steps
-(publish, register, env setup) if required.
+Validate each step against the actual codebase.
+Include post-install steps (publish, register, env setup) if required.
 
-### 6. Write minimal working example
+### 6. Write the minimal working example
 
-**Most critical section.** Rules:
+**This is the most critical section.** Rules:
 
 - Smallest possible working example — one use case, one result
 - Real API calls, not pseudo-code
 - Copy-pasteable without hidden setup
 - Show expected result or effect if helpful
-- Must match actual package API (verify against source)
+- Must match the actual package API (verify against source)
 
 Bad: abstract, large, requires unexplained setup.
 Good: 5-15 lines, directly relevant, immediately runnable.
 
 ### 7. Keep architecture out of README — use reference-split
 
-Move deep content to dedicated docs. Recommended layout:
+Move deep content to dedicated docs. Recommended layout for packages:
 
 ```
 README.md              ← entry: what, why, install, minimal usage
@@ -133,13 +136,13 @@ docs/
   migration.md         ← version upgrade guides
 ```
 
-Multi-platform install (> 5 variants): prefer single table with deep
-links over stacked inline blocks. Occasionally-needed detail (long
-platform quirks, troubleshooting): use `<details>` — never for install,
-first example, or requirements.
+For multi-platform install (> 5 variants), prefer a single table with
+deep links over stacked inline blocks. For occasionally-needed detail
+(long platform quirks, troubleshooting), use `<details>` — never for
+install, first example, or requirements.
 
 → See `docs/guidelines/docs/readme-size-and-splitting.md` for thresholds,
-deep-link-table pattern, collapsibles, anti-patterns (premature
+deep-link-table pattern, collapsibles, and anti-patterns (premature
 splitting, duplication between README and `/docs/`).
 
 README = enough to adopt. Docs = enough to master.
@@ -148,11 +151,11 @@ README = enough to adopt. Docs = enough to master.
 
 - [ ] Install command is correct and complete
 - [ ] Compatibility/requirements match `composer.json` / `package.json` / CI matrix
-- [ ] First example matches real API (verified against source)
+- [ ] First example matches real API (verified against source code)
 - [ ] All documented commands exist in repo
 - [ ] No invented features or capabilities
 - [ ] Consumer can get started without reading source code
-- [ ] Deep content in docs, not README (see size guideline)
+- [ ] Deep content is in docs, not README (see size guideline)
 - [ ] Multi-platform install uses a table, not stacked blocks
 - [ ] No duplication between README and `/docs/`
 - [ ] First screen shows: what, install, requirements
@@ -167,11 +170,11 @@ README = enough to adopt. Docs = enough to master.
 
 ## Gotcha
 
-- Model writes package READMEs like app READMEs (too much architecture)
-- Model invents compatibility claims or setup steps
-- First example often too large, too abstract, or uses pseudo-code
+- Model writes package READMEs like app READMEs (too much architecture, not enough install/usage)
+- Model tends to invent compatibility claims or setup steps
+- First example is often too large, too abstract, or uses pseudo-code
 - Model over-explains internals before showing how to use the package
-- Existing README may be outdated — verify against `composer.json` / source
+- Existing README may be outdated — verify against actual `composer.json` / source, not old text
 - Model forgets post-install steps (config publish, service provider, env vars)
 
 ## Do NOT
@@ -179,7 +182,7 @@ README = enough to adopt. Docs = enough to master.
 - Do NOT invent package capabilities or compatibility
 - Do NOT skip the minimal working example
 - Do NOT prioritize internal architecture over user onboarding
-- Do NOT document commands not in the repo
+- Do NOT document commands not present in the repo
 - Do NOT hide requirements or version constraints
-- Do NOT write a giant example when 10 lines would do
-- Do NOT overload README with reference material — link to /docs
+- Do NOT write a giant example when a 10-line one would do
+- Do NOT overload README with reference material — link to /docs

package/.agent-src/skills/receiving-code-review/SKILL.md

@@ -10,9 +10,10 @@ source: package
 
 ## When to use
 
-* PR has review comments (bots like Copilot, Greptile, Augment, or human
-  reviewers) and the next step is addressing them
-* Someone pasted review feedback and asks you to "fix it" or "handle it"
+* A PR has review comments (from bots like Copilot, Greptile, Augment,
+  or from human reviewers) and the next step is to address them
+* Someone pasted review feedback into the conversation and asks you
+  to "fix it" or "handle it"
 * A pair-programming partner gave verbal suggestions about code you
   just wrote
 * You are tempted to reply "you are absolutely right" before reading
@@ -21,10 +22,10 @@ source: package
 Do NOT use when:
 
 * You are writing a review yourself (different discipline)
-* User explicitly asks for blind implementation of a specific change
-  not framed as review feedback
-* Pure style/formatting the linter should decide automatically — run
-  the linter
+* The user explicitly asks for blind implementation of a specific change
+  that is not framed as review feedback
+* The feedback is pure style/formatting that a linter should decide
+  automatically — just run the linter
 
 ## Goal
 
@@ -40,40 +41,42 @@ NO IMPLEMENTATION UNTIL THE FEEDBACK IS UNDERSTOOD AND VERIFIED.
 ```
 
 A "fix" implemented against a misread comment is worse than no fix —
-ships the wrong behavior under the label of "addressed feedback".
+it ships the wrong behavior under the label of "addressed feedback".
 
 ## Procedure
 
 ### 1. Read the full comment set before touching code
 
 Read **every** open comment on the PR first. Comments often relate to
-each other — fixing comment #3 in isolation can conflict with #5. Group:
+each other — fixing comment #3 in isolation can conflict with comment
+#5. Group them:
 
 * **Blocking** — breaks behavior, introduces a bug, security issue
-* **Important** — logic correct but design / readability issue
+* **Important** — logic is correct but design / readability issue
 * **Minor** — naming, comment style, formatting the linter missed
-* **Wrong** — reviewer misunderstood the code, or suggestion regresses
-  another behavior
+* **Wrong** — reviewer misunderstood the code, or suggestion would
+  regress another behavior
 
 ### 2. Restate each comment in your own words
 
 For every comment, write (internally or to the user): *"The reviewer
 is asking me to X because Y."*
 
-Cannot complete that sentence confidently → the comment is unclear. Ask
-for clarification **before** implementing anything. Do not implement
-the clear ones first and ask later — they may be linked.
+If you cannot complete that sentence confidently → the comment is
+unclear. Ask for clarification **before** implementing anything. Do
+not implement the clear ones first and ask later — they may be linked.
 
 ### 3. Verify each claim against the code
 
-For each blocking/important comment:
+For each comment classified as blocking/important:
 
 * Reproduce the alleged issue locally (run the test, hit the endpoint,
   read the actual runtime value — see [`systematic-debugging`](../systematic-debugging/SKILL.md))
 * Check what the code actually does, not what the reviewer **thinks**
   it does
 * Check whether the suggested fix would break another test or caller
-* Check `git blame` / history — current code may be that way for a reason
+* Check `git blame` / history — the current code may be the way it is
+  for a reason
 * **Consult memory for prior context.** Via
   [`memory-access`](../../../docs/guidelines/agent-infra/memory-access.md),
   call `retrieve(types=["historical-patterns", "architecture-decisions"],
@@ -86,21 +89,21 @@ For each blocking/important comment:
 
 | Situation | Response |
 |---|---|
-| Reviewer right, fix local, no caller impact | Implement, reference the comment in the commit message |
-| Reviewer right but fix affects other callers | Note downstream effects in the reply, then implement |
-| Reviewer wrong — misreading the code | Reply with evidence (specific line / test / value), do not change code |
+| Reviewer is right, fix is local, no caller impact | Implement, reference the comment in the commit message |
+| Reviewer is right but fix affects other callers | Note the downstream effects in the reply, then implement |
+| Reviewer is wrong — based on misreading the code | Reply with evidence (specific line / test / value), do not change code |
 | Reviewer suggests a feature the codebase does not use (YAGNI) | Reply asking whether the feature is actually needed, do not build speculatively |
 | Reviewer and user / architecture disagree | Escalate to the user before implementing either path |
 
 ### 5. Reply in the right place, with the right tone
 
-* Inline PR comments → reply **in the thread** of that comment, not as
-  a top-level PR comment
+* For inline PR comments → reply **in the thread** of that comment,
+  not as a top-level PR comment
 * Quote **evidence**, not opinion — "line 47 already handles this via
   `$x->isNull()`" beats "I think that's fine"
 * No flattery. No "great catch", "absolutely right", "thanks for
-  noticing". The `language-and-tone` rule already bans this — actions
-  are the acknowledgement
+  noticing". The existing `language-and-tone` rule already bans this —
+  actions are the acknowledgement
 * If you were wrong in your earlier pushback, state it factually and
   move on. No long apology
 
@@ -108,11 +111,11 @@ For each blocking/important comment:
 
 1. Blocking issues first
 2. Important issues next
-3. Minor issues last (or bundle into a single commit)
+3. Minor issues last (or bundle them into a single commit)
 4. Wrong / YAGNI: no code change, only a reply with reasoning
 
-Run relevant tests and linters **between** each group — do not batch
-four changes and then run tests once. See
+Run the relevant tests and linters **between** each group — do not
+batch four changes and then run tests once. See
 [`verify-before-complete`](../verify-before-complete/SKILL.md).
 
 ## Output format
@@ -122,34 +125,36 @@ When reporting back to the user after handling review:
 1. **Triage table** — comment → classification → decision
 2. **Implemented changes** — bullet per change with file + commit ref
 3. **Pushed back** — bullet per rejected comment with the evidence
-4. **Outstanding** — anything awaiting clarification, with the specific
-   question
+4. **Outstanding** — anything awaiting clarification, with the
+   specific question
 
 ## Gotchas
 
 * Bot comments (Copilot, Greptile) are **not** automatically right.
-  Frequently flag false positives on patterns the codebase uses
-  deliberately. Verify like a human comment.
-* A comment reading like a question ("should this be X?") is often a
-  polite way of saying "change it to X". Ask if unclear.
+  They frequently flag false positives on patterns the codebase uses
+  deliberately. Verify like you would a human comment.
+* A comment that reads like a question ("should this be X?") is often
+  a polite way of saying "change it to X". Ask if unclear instead of
+  guessing the register.
 * Resolving a comment in the GitHub UI without an accompanying fix or
-  reply silently marks it handled — reviewers may miss the lack of
-  substance.
+  reply silently marks it handled — reviewers may not notice the lack
+  of substance.
 * Stacked PRs — a comment on the base PR may already be fixed in the
   child PR. Check both before touching code.
 * A suggestion that passes review aesthetics but fails the test suite
   is still a regression. Run tests even when "the change is trivial".
-* Flattery leaks in as "good point" or "thanks". Delete before sending.
+* Flattery leaks in as "good point" or "thanks". Delete before
+  sending. The code change itself is the acknowledgement.
 
 ## Do NOT
 
 * Do NOT reply "you are absolutely right", "great catch", or any
   flattery variant — actions acknowledge, words do not
 * Do NOT implement a suggestion before verifying it against the code
-* Do NOT fix the clear items first and ask about the unclear ones later
-  when the items are linked
-* Do NOT accept a reviewer's suggestion that conflicts with an explicit
-  architectural decision without raising it
+* Do NOT fix the clear items first and ask about the unclear ones
+  later when the items are linked
+* Do NOT accept a reviewer's suggestion that conflicts with an
+  explicit architectural decision without raising it
 * Do NOT batch multiple unrelated fixes into one commit — reviewers
   cannot re-review selectively
 * Do NOT mark a comment resolved without either a code change or a
@@ -159,15 +164,15 @@ When reporting back to the user after handling review:
 
 * Replying "Fixed!" after a commit that does not actually address the
   comment (wrong file, missed case)
-* Rewriting the comment author's suggestion into your own words without
-  checking whether the reinterpretation still matches intent
+* Rewriting the comment author's suggestion into your own words
+  without checking whether the reinterpretation still matches intent
 * Implementing the YAGNI-suggested feature "just in case" the reviewer
   comes back
 * Silent disagreement — ignoring a comment without a reply
 
 ## When to hand over to another skill / command
 
-* Executing fixes across many comments → [`fix-pr-comments`](../../commands/fix-pr-comments.md)
+* Executing the fixes across many comments → [`fix-pr-comments`](../../commands/fix-pr-comments.md)
   (handles both bot + developer), [`fix-pr-bot-comments`](../../commands/fix-pr-bot-comments.md),
   [`fix-pr-developer-comments`](../../commands/fix-pr-developer-comments.md)
 * Running the full verification gate before pushing replies →
@@ -181,10 +186,10 @@ When reporting back to the user after handling review:
 
 Before considering review handling done:
 
-* [ ] Every open comment read, classified, decision made
-* [ ] No comment implemented without a one-sentence restatement
-* [ ] Every implemented fix verified by a test or runtime check
+* [ ] Every open comment has been read, classified, and has a decision
+* [ ] No comment was implemented without a one-sentence restatement
+* [ ] Every implemented fix has been verified by a test or runtime check
 * [ ] Every rejected comment has a reply quoting evidence
-* [ ] No comment marked resolved without code change or reply
+* [ ] No comment was marked resolved without code change or reply
 * [ ] No reply contains flattery
 * [ ] Linters and relevant tests pass after the changes

package/.agent-src/skills/refine-prompt/SKILL.md

@@ -217,4 +217,3 @@ For `low`, the question replaces the AC list:
 - [`work_engine.scoring.confidence`](../../templates/scripts/work_engine/scoring/confidence.py) — rubric + band thresholds
 - [`ask-when-uncertain`](../../rules/ask-when-uncertain.md) — one-question-per-turn Iron Law
 - [`artifact-drafting-protocol`](../../rules/artifact-drafting-protocol.md) — this skill was drafted under it
-- `agents/roadmaps/archive/road-to-prompt-driven-execution.md` — Phase 3 owns this skill (archived on completion)