issue-flow 0.18.0 → 0.19.1

package/prompts/analyze.md

@@ -1,25 +1,22 @@
+<!-- Generated by skills:sync; edit canonical sources, not this artifact. -->
+
 You are analyzing issue #__ISSUE_NUMBER__ for this repository.
 
-The issue content is already resolved and given below — do NOT fetch it, and do
-not assume it lives on GitHub.
+The issue content is already resolved; do not fetch it or assume it is on GitHub.
 
 - Source: __ISSUE_SOURCE__
 - Reference: __ISSUE_URL__
 - Title: __ISSUE_TITLE__
 - Labels: __ISSUE_LABELS__
 
-Issue body:
-
 <issue-body>
 __ISSUE_BODY__
 </issue-body>
 
-Steps:
-1. Analyze the codebase to understand the affected areas, tech stack, and architecture
-2. Identify the scope, complexity, and key files/modules involved
-3. Produce a structured analysis
+Analyze the codebase, identify affected areas, architecture, scope, complexity,
+risks and key files. Return exactly one final block with this structure:
 
-Save your analysis to __ANALYSIS_PATH__ with this structure:
+<issue-analysis>
 
 # Issue Analysis: #__ISSUE_NUMBER__
 
@@ -37,24 +34,24 @@ Save your analysis to __ANALYSIS_PATH__ with this structure:
 
 ## Implementation Notes
 [Key considerations, risks, dependencies]
+</issue-analysis>
 
-IMPORTANT: You MUST write the analysis to the file path above. Do not just output it.
+Do not write the artifact yourself. The orchestrator validates and persists the block.
 
 <!-- if:__REPO_POLICY__ -->
 ## Repository policy
 
-The repository this runs in declares the conventions below. They were discovered
-from its own files (Issue Templates, labels, `AGENTS.md`, `CONTRIBUTING.md`,
-`CODEOWNERS`) and from its configuration.
-
 __REPO_POLICY__
 
-**This section takes precedence over any convention stated earlier in this
-prompt.** Where the two disagree, follow the repository. Where the repository is
-silent, the defaults above still apply.
+For repository conventions, these resolved values take precedence over prompt
+defaults. Defaults apply only to undeclared choices. Paths are references: read the
+applicable documents when a decision depends on them, following instruction indexes.
+
+Use the repository's applicable issue template instead of layering another body template over it. Fill required fields; ask when two templates fit equally. Keep the PR template's sections, explaining non-applicable ones briefly.
+
+Use existing label casing. Never create a label unless explicitly opted in by issues.allowLabelCreation and the action is authorized. Drop labels known to be absent; report lost classification. When the registry is unavailable, report that validation could not be performed rather than claiming the label does not exist. Local metadata labels are free-form and should reuse the local vocabulary.
 
-Paths listed under "Policy documents" are pointers, not content: read them when
-a decision depends on what they say.
+Prefer native fields over labels and textual prefixes. Do not reintroduce a type prefix when the repository uses native Issue Types unless its declared title convention requires it. Defaults apply only to undeclared choices; obtain the fallback taxonomy from the bundled conventions helper where supplied.
 
 ### Judging completeness against this repository
 

package/prompts/execute.md

@@ -1,163 +1,92 @@
-# Issue Flow Agent Instructions
-
-You are an autonomous coding agent working on a software project.
-
-## Your Task
-
-1. Read the PRD at `__PRD_FILE__`
-2. Read the progress log at `__PROGRESS_FILE__` (check Codebase Patterns section first)
-3. Check you're on the correct branch from PRD `branchName`. If not, check it out or create it from `__BASE_BRANCH__`.
-4. Treat the issue as unresolved if **any** `userStories[].passes` is `false`, **or** if the PRD's top-level `lastReviewFindings` is non-null — that second condition holds even when every story already passes (see "Correction Findings from a Failed Review" below).
-5. If `lastReviewFindings` is non-null, address it first (see below); otherwise pick the **highest priority** user story where `passes: false`
-6. Implement that single user story
-7. Run the quality checks that cover the files you changed (typecheck/lint/test for those paths). The orchestrator runs the full suite at the end of execute and again in review.
-8. Update CLAUDE.md files if you discover reusable patterns (see below)
-9. If checks pass, commit ALL changes with message: `__COMMIT_MESSAGE__`
-10. Update the PRD to set `passes: true` for the completed story
-11. Append your progress to `__PROGRESS_FILE__`
-
-## Correction Findings from a Failed Review
-
-A prior automated review may have already run against this same code and found it wanting — its findings are persisted verbatim in the PRD's top-level `lastReviewFindings` field. When that field is non-null:
-
-- Treat it as **the** priority for this iteration, ahead of any story whose `passes` is still `false`.
-- The findings describe concrete defects in code that was already implemented and marked `passes: true` — they are not a new story. Do **not** re-implement stories from scratch; make the smallest correct change that addresses every finding.
-- Run the project's quality checks (typecheck, lint, test) to confirm the fix, exactly as for a normal story.
-- Commit the fix with message `__FIX_COMMIT_MESSAGE__` (or a more specific message naming what was fixed, keeping the same prefix).
-- Once every finding has been addressed, set `lastReviewFindings` back to `null` in the PRD before finishing this iteration. Leaving it non-null means the orchestrator will treat the issue as still uncorrected and loop again.
-- If a finding turns out to be a false positive or already fixed, still clear `lastReviewFindings` to `null`, but say so explicitly in the progress log entry so a human can double-check.
-- If you cannot fully resolve the findings in this iteration, leave `lastReviewFindings` as-is (do not clear it) and record what you did and what remains in the progress log — the orchestrator will invoke another iteration.
-
-## Progress Report Format
-
-APPEND to `__PROGRESS_FILE__` (never replace, always append):
-```
-## [Date/Time] - [Story ID]
-- What was implemented
-- Files changed
-- **Learnings for future iterations:** (omit this block when the iteration discovered nothing reusable)
-  - Patterns discovered (e.g., "this codebase uses X for Y")
-  - Gotchas encountered (e.g., "don't forget to update Z when changing W")
-  - Useful context (e.g., "the evaluation panel is in component X")
----
-```
-
-The learnings section is required only when the iteration discovered something reusable. Do not invent patterns.
-
-## Consolidate Patterns
-
-If you discover a **reusable pattern** that future iterations should know, add it to the `## Codebase Patterns` section at the TOP of `__PROGRESS_FILE__` (create it if it doesn't exist). This section should consolidate the most important learnings:
-
-```
-## Codebase Patterns
-- Example: Use `sql<number>` template for aggregations
-- Example: Always use `IF NOT EXISTS` for migrations
-- Example: Export types from actions.ts for UI components
-```
-
-Only add patterns that are **general and reusable**, not story-specific details.
-
-## Update CLAUDE.md Files
-
-Before committing, check if any edited files have learnings worth preserving in nearby CLAUDE.md files:
-
-1. **Identify directories with edited files** - Look at which directories you modified
-2. **Check for existing CLAUDE.md** - Look for CLAUDE.md in those directories or parent directories
-3. **Add valuable learnings** - If you discovered something future developers/agents should know:
-   - API patterns or conventions specific to that module
-   - Gotchas or non-obvious requirements
-   - Dependencies between files
-   - Testing approaches for that area
-   - Configuration or environment requirements
-
-**Examples of good CLAUDE.md additions:**
-- "When modifying X, also update Y to keep them in sync"
-- "This module uses pattern Z for all API calls"
-- "Tests require the dev server running on PORT 3000"
-- "Field names must match the template exactly"
-
-**Do NOT add:**
-- Story-specific implementation details
-- Temporary debugging notes
-- Information already in progress.txt
-
-Only update CLAUDE.md if you have **genuinely reusable knowledge** that would help future work in that directory.
-
-## Quality Requirements
-
-- ALL commits must pass your project's quality checks (typecheck, lint, test)
-- Do NOT commit broken code
-- Keep changes focused and minimal
-- Follow existing code patterns
-
-## Browser Testing (If Available)
-
-For any story that changes UI, verify it works in the browser if you have browser testing tools configured (e.g., via MCP):
-
-1. Navigate to the relevant page
-2. Verify the UI changes work as expected
-3. Take a screenshot if helpful for the progress log
-
-If no browser tools are available, note in your progress report that manual browser verification is needed.
-
-## Pipeline State Tracking
+<!-- Generated by skills:sync; edit canonical sources, not this artifact. -->
+
+# Execute the current task
+
+Implement the selected story or resolve pending review findings in this repository.
+
+## Workflow and constraints
+
+1. Verify the attached checkout matches `branchName`. If `noBranch=true`, never
+   switch/create a branch: report a mismatch. Otherwise use the planned branch,
+   creating it from `__BASE_BRANCH__` only when safe. Preserve unrelated user work.
+2. Pending `lastReviewFindings` take priority even if every story passes.
+   Otherwise implement the active story in the context below.
+   Work on one story; when __STORIES_PER_ITERATION__ is greater than 1, you may
+   complete that many related stories after verifying their dependencies in the plan.
+3. Follow existing code and applicable repository rules. Verify the change with
+   relevant checks after the final edit. The orchestrator runs acceptance at the end
+   of execute and again before review; that does not replace this story's evidence.
+4. Stage only this logical change and commit after its required checks pass, using
+   `__COMMIT_MESSAGE__`. Update only verified stories to `passes: true` and record
+   concise evidence in their notes. Preserve other plan fields and unrelated stories.
+5. Append progress with timestamp, story ID, changes, affected files, commands/results
+   and unresolved limitations. Add reusable discoveries to Codebase Patterns; preserve
+   previous entries. Put durable repository knowledge in its existing documentation,
+   linking it from AGENTS.md when appropriate, without duplicating instruction files.
+
+<!-- if:__CORRECTION_MODE__ -->
+## Correction findings
+
+Validate each finding against code and requirements. Make focused corrections rather
+than reimplementing completed stories. Commit fixes using `__FIX_COMMIT_MESSAGE__`
+(or a more specific subject with the same resolved prefix).
+
+Clear `lastReviewFindings` only after every finding is addressed or rejected with
+recorded evidence. If work remains, keep the findings and record what remains in
+progress. A fresh review still decides whether the corrected work passes.
+<!-- /if -->
 
-The task plan may contain a `pipeline` object that tracks orchestrator phase completion. Update these fields as appropriate:
+## Completion and blockers
 
-- After completing a story: set `pipeline.executionCompleted` to `false` (still in progress)
-- After ALL stories complete: set `pipeline.executionCompleted` to `true`
+Emit `<promise>COMPLETE</promise>` only after all stories pass, pending findings have
+been addressed, and required verification is complete. Otherwise end normally for
+another iteration, or record a non-transient blocker in top-level `lastError` as
+`{message, category, at}` with an ISO timestamp. Clear lastError only when its blocker is resolved.
 
-The task plan may also contain `correctionCycle` and `maxCorrectionCycles` fields. These track how many review-fix cycles have occurred. The execution loop does not manage the correction loop — that is handled by the orchestrator or manually.
+__EXECUTION_SCOPE__ The CLI owns pipeline flags, timestamps and final phase status;
+changing these fields in the projection cannot complete review or publication.
 
-If these fields don't exist in the task plan (older format), ignore them — they are optional.
+<!-- if:__REPO_POLICY__ -->
+## Repository policy
 
-## Stop Condition
+__REPO_POLICY__
 
-After completing a user story or addressing `lastReviewFindings`, check if ALL stories have `passes: true` **and** `lastReviewFindings` is `null`.
+For repository conventions, these resolved values take precedence over prompt
+defaults. Defaults apply only to undeclared choices. Paths are references: read the
+applicable documents when a decision depends on them, following instruction indexes.
 
-If ALL stories are complete and passing and there are no pending review findings, first update the task plan metadata:
-- Set `issueStatus` to `completed`
-- Set `completedAt` to the current ISO timestamp
-- Set `lastAttemptAt` to the current ISO timestamp
-- Clear `lastError`
-- If `pipeline` object exists, set `pipeline.executionCompleted` to `true`
+Use the repository's applicable issue template instead of layering another body template over it. Fill required fields; ask when two templates fit equally. Keep the PR template's sections, explaining non-applicable ones briefly.
 
-Then reply with:
-<promise>COMPLETE</promise>
+Use existing label casing. Never create a label unless explicitly opted in by issues.allowLabelCreation and the action is authorized. Drop labels known to be absent; report lost classification. When the registry is unavailable, report that validation could not be performed rather than claiming the label does not exist. Local metadata labels are free-form and should reuse the local vocabulary.
 
-If there are still stories with `passes: false`, or `lastReviewFindings` is still non-null, end your response normally (another iteration will pick up the next story, or continue addressing the findings).
-If you need to stop for user guidance or another non-transient blocker, record it in top-level `lastError` and do not clear it.
+Prefer native fields over labels and textual prefixes. Do not reintroduce a type prefix when the repository uses native Issue Types unless its declared title convention requires it. Defaults apply only to undeclared choices; obtain the fallback taxonomy from the bundled conventions helper where supplied.
+<!-- /if -->
 
-## Important
+<!-- if:__COMMIT_CONVENTION__ -->
+## Commit convention
 
-- Work on ONE story per iteration unless `__STORIES_PER_ITERATION__` is greater than 1, in which case you may close that many related stories that touch the same files, in one session. The default is 1.
-- Commit frequently
-- Keep CI green
-- Read the Codebase Patterns section in `__PROGRESS_FILE__` before starting
+This repository declares: __COMMIT_CONVENTION__
+The messages above use the resolved format. Choose any `<type>` from the repository
+vocabulary to match the actual change.
+<!-- /if -->
 
-<!-- if:__REPO_POLICY__ -->
-## Repository policy
+## Evidence before completion
 
-The repository this runs in declares the conventions below. They were discovered
-from its own files (Issue Templates, labels, `AGENTS.md`, `CONTRIBUTING.md`,
-`CODEOWNERS`) and from its configuration.
+Use fresh evidence from the revision being delivered. Read the repository's test/build instructions and execute the relevant checks after the final meaningful change. Record commands, results and material coverage limits. An earlier green run, a checked checkbox or another agent's claim is not current verification.
 
-__REPO_POLICY__
+If a required check fails or cannot run, report the failure or unverified criterion. Do not mark that criterion passed or emit a completion/approval signal. Discover checks appropriate to the stack; do not require TypeScript checks in a project without TypeScript. For UI acceptance, use an available browser capability and record what was exercised; missing browser verification remains pending when required.
 
-**This section takes precedence over any convention stated earlier in this
-prompt.** Where the two disagree, follow the repository. Where the repository is
-silent, the defaults above still apply.
+For bug fixes, reproduce the defect with a focused check before correcting it when the repository and environment permit. Follow existing testing conventions; do not impose universal TDD or tests that merely restate the implementation.
 
-Paths listed under "Policy documents" are pointers, not content: read them when
-a decision depends on what they say.
-<!-- /if -->
+Evaluate review feedback against the code and requirements before applying it. Reproduce valid defects where feasible. Record why an incorrect or inapplicable finding was rejected, with evidence, rather than changing code just to satisfy its wording. Re-review after valid fixes.
 
-<!-- if:__COMMIT_CONVENTION__ -->
-## Commit convention
+## Required context
 
-This repository declares: __COMMIT_CONVENTION__
+__EXECUTION_CONTEXT__
 
-The commit message above is already in the resolved format. If you must pick a
-`<type>` inside that format, choose from the repository's vocabulary and match
-the **nature of this commit** — never invent a type outside it.
-<!-- /if -->
+This is a read-only projection of `__PRD_FILE__` (the task plan, not the prose PRD).
+Use the selected story and its complete criteria. Read other plan entries or
+requirements only when a dependency, finding or implementation decision needs them.
+Read Codebase Patterns and the latest relevant entries of `__PROGRESS_FILE__`;
+search older entries when an unresolved decision or finding requires their evidence.
+Do not load the entire history merely because another iteration started.

package/prompts/generate.md

@@ -1,4 +1,8 @@
-You are drafting an issue for this repository.
+<!-- Generated by skills:sync; edit canonical sources, not this artifact. -->
+
+You are drafting an issue for this repository. Destination: __DESTINATION__.
+For local delivery, never run GitHub commands or remote probes. Inspect local
+conventions and duplicates only; unavailable remote information is not required.
 
 The user provided this description:
 __USER_PROMPT__
@@ -17,11 +21,13 @@ Steps:
 3. Check for duplicates before drafting. This is a **multi-strategy search** —
    one query finds only issues worded the way you happened to word yours:
    - Local issues: read `__LOCAL_ISSUES_DIR__/*/metadata.json` (the directory may not exist)
+<!-- if:__REMOTE_DISCOVERY__ -->
    - Remote issues, only if `gh` is installed and authenticated:
      - 2-3 different keyword combinations drawn from the title and the core problem:
        `gh issue list --search "<keyword1> <keyword2>" --state all --limit 30 --json number,title,state,url`
      - the affected area, when the request names one (auth, database, API…)
      - a label the request maps to, when the repository has a matching one
+<!-- /if -->
    Judge a candidate on whether it describes the **same problem**, not on textual
    overlap. If an existing issue already covers the request, still emit the draft,
    but say so in the body under a "Possible duplicates" section, citing the issue.
@@ -62,18 +68,17 @@ Rules for the block:
 <!-- if:__REPO_POLICY__ -->
 ## Repository policy
 
-The repository this runs in declares the conventions below. They were discovered
-from its own files (Issue Templates, labels, `AGENTS.md`, `CONTRIBUTING.md`,
-`CODEOWNERS`) and from its configuration.
-
 __REPO_POLICY__
 
-**This section takes precedence over any convention stated earlier in this
-prompt.** Where the two disagree, follow the repository. Where the repository is
-silent, the defaults above still apply.
+For repository conventions, these resolved values take precedence over prompt
+defaults. Defaults apply only to undeclared choices. Paths are references: read the
+applicable documents when a decision depends on them, following instruction indexes.
+
+Use the repository's applicable issue template instead of layering another body template over it. Fill required fields; ask when two templates fit equally. Keep the PR template's sections, explaining non-applicable ones briefly.
+
+Use existing label casing. Never create a label unless explicitly opted in by issues.allowLabelCreation and the action is authorized. Drop labels known to be absent; report lost classification. When the registry is unavailable, report that validation could not be performed rather than claiming the label does not exist. Local metadata labels are free-form and should reuse the local vocabulary.
 
-Paths listed under "Policy documents" are pointers, not content: read them when
-a decision depends on what they say.
+Prefer native fields over labels and textual prefixes. Do not reintroduce a type prefix when the repository uses native Issue Types unless its declared title convention requires it. Defaults apply only to undeclared choices; obtain the fallback taxonomy from the bundled conventions helper where supplied.
 
 ### Drafting against this repository's conventions
 
@@ -92,3 +97,11 @@ a decision depends on what they say.
 - **Labels.** Use only the ones listed. Anything else is dropped.
 - **Title.** Follow the convention shown above when there is one.
 <!-- /if -->
+
+## Authorized publication
+
+A request to analyze, plan or review does not itself request a remote comment, closure, push or PR. Publish only when the user's request or existing session authorization includes that action. Preparing a concrete draft, diff and verification result comes before asking for any missing authorization. Do not ask again for authorization already granted.
+
+Before creating an issue or PR, check for an existing equivalent item. Reuse a matching open PR instead of creating another. Updating, closing or reopening an existing item requires authorization for that action. On an uncertain publication result, query the remote before retrying to avoid duplicates.
+
+Pass user text as structured tool arguments or a UTF-8 body file, never shell interpolation. Use argument arrays for commands. Verify success before deleting a draft. If publishing fails, preserve the draft and report the failed operation and actionable reason. Never force-push.

package/prompts/plan.md

@@ -1,14 +1,14 @@
+<!-- Generated by skills:sync; edit canonical sources, not this artifact. -->
+
 You are converting a PRD into a structured JSON task plan for issue #__ISSUE_NUMBER__.
 
-The issue is already resolved — do NOT fetch it:
+The issue content is already resolved; do not fetch it or assume it is on GitHub.
 
 - Source: __ISSUE_SOURCE__
 - Reference: __ISSUE_URL__
 - Title: __ISSUE_TITLE__
 - Labels: __ISSUE_LABELS__
 
-Issue body (the original demand, for the description field):
-
 <issue-body>
 __ISSUE_BODY__
 </issue-body>
@@ -17,82 +17,54 @@ Here is the PRD:
 
 __PRD_CONTENT__
 
-The next available User Story number for this project is __NEXT_US_NUMBER__. This
-was already resolved by the CLI (from the project's numbering history, or from an
-explicit --continue / --start-us override) — do NOT restart numbering at US-001
-unless __NEXT_US_NUMBER__ is itself US-001. Number the first story in this plan
-__NEXT_US_NUMBER__ and every subsequent story sequentially from there (e.g. if
-__NEXT_US_NUMBER__ is US-016, use US-016, US-017, US-018, ...).
-
-Create a tasks.json file at __TASKS_PATH__ with this exact structure:
+Return the semantic plan as exactly one final block:
 
+<task-plan>
 {
-  "project": "<repo-name>",
-  "issueNumber": __ISSUE_NUMBER__,
-  "issueUrl": "__ISSUE_URL__",
-  "branchName": "__BRANCH_NAME__",
   "description": "<brief description>",
-  "issueStatus": "pending",
-  "completedAt": null,
-  "lastAttemptAt": null,
-  "lastError": null,
-  "correctionCycle": 0,
-  "maxCorrectionCycles": 3,
-  "lastReviewFindings": null,
-  "pipeline": {
-    "analyzeCompleted": true,
-    "prdCompleted": true,
-    "jsonCompleted": true,
-    "executionCompleted": false,
-    "reviewCompleted": false,
-    "prCreated": false
-  },
-  "userStories": [
+  "stories": [
     {
-      "id": "__NEXT_US_NUMBER__",
+      "key": "short-unique-key",
       "title": "...",
       "description": "As a ..., I want ... so that ...",
       "acceptanceCriteria": ["..."],
-      "priority": 1,
-      "passes": false,
-      "notes": ""
+      "dependsOn": []
     }
   ]
 }
+</task-plan>
 
 Rules:
-- Each user story from the PRD becomes one entry in userStories
-- Priority should order stories by dependency (build foundations first)
-- Story ids MUST start at __NEXT_US_NUMBER__ and increase sequentially — never
-  restart at US-001 when __NEXT_US_NUMBER__ says otherwise
-- acceptanceCriteria must include "Typecheck passes" for code changes
-- issueUrl is already resolved above: a GitHub URL when the source is `github`,
-  the path of the local issue file when the source is `local`. Use it verbatim
-  and never derive it yourself
-- Get the repo name from the repository itself (package name, directory name)
-- If __ISSUE_NUMBER__ is not a number, keep it as a JSON string in issueNumber
-- branchName is already resolved: use __BRANCH_NAME__ verbatim. Do not invent a branch.
-
-IMPORTANT: You MUST write the tasks.json to the file path above. Do not just output it.
+- Order stories by dependency and implementation priority; foundations come first
+- key is unique inside this plan and dependencies refer to earlier story keys
+- acceptanceCriteria must name relevant checks from the repository toolchain; include
+  typechecking only when the project has a typechecker
+- Do not include lifecycle state, story IDs, priorities, branch or issue metadata;
+  the orchestrator derives and validates those fields deterministically
+- Do not write tasks.json yourself
 
 <!-- if:__REPO_POLICY__ -->
 ## Repository policy
 
-The repository this runs in declares the conventions below. They were discovered
-from its own files (Issue Templates, labels, `AGENTS.md`, `CONTRIBUTING.md`,
-`CODEOWNERS`) and from its configuration.
-
 __REPO_POLICY__
 
-**This section takes precedence over any convention stated earlier in this
-prompt.** Where the two disagree, follow the repository. Where the repository is
-silent, the defaults above still apply.
+For repository conventions, these resolved values take precedence over prompt
+defaults. Defaults apply only to undeclared choices. Paths are references: read the
+applicable documents when a decision depends on them, following instruction indexes.
+
+Use the repository's applicable issue template instead of layering another body template over it. Fill required fields; ask when two templates fit equally. Keep the PR template's sections, explaining non-applicable ones briefly.
 
-Paths listed under "Policy documents" are pointers, not content: read them when
-a decision depends on what they say.
+Use existing label casing. Never create a label unless explicitly opted in by issues.allowLabelCreation and the action is authorized. Drop labels known to be absent; report lost classification. When the registry is unavailable, report that validation could not be performed rather than claiming the label does not exist. Local metadata labels are free-form and should reuse the local vocabulary.
+
+Prefer native fields over labels and textual prefixes. Do not reintroduce a type prefix when the repository uses native Issue Types unless its declared title convention requires it. Defaults apply only to undeclared choices; obtain the fallback taxonomy from the bundled conventions helper where supplied.
 <!-- /if -->
 
-## Branch naming
+## Evidence before completion
+
+Use fresh evidence from the revision being delivered. Read the repository's test/build instructions and execute the relevant checks after the final meaningful change. Record commands, results and material coverage limits. An earlier green run, a checked checkbox or another agent's claim is not current verification.
+
+If a required check fails or cannot run, report the failure or unverified criterion. Do not mark that criterion passed or emit a completion/approval signal. Discover checks appropriate to the stack; do not require TypeScript checks in a project without TypeScript. For UI acceptance, use an available browser capability and record what was exercised; missing browser verification remains pending when required.
+
+For bug fixes, reproduce the defect with a focused check before correcting it when the repository and environment permit. Follow existing testing conventions; do not impose universal TDD or tests that merely restate the implementation.
 
-`branchName` is `__BRANCH_NAME__`. Copy it exactly. The CLI computed it from the
-repository convention; do not slugify the title yourself.
+Evaluate review feedback against the code and requirements before applying it. Reproduce valid defects where feasible. Record why an incorrect or inapplicable finding was rejected, with evidence, rather than changing code just to satisfy its wording. Re-review after valid fixes.