YuShenLiu06/yushen-skills

Requirements to Acceptance

1. Restate and Confirm

Restate the user's goals, non-goals, observable acceptance criteria, risks, and budget constraints. Proceed to implementation after confirmation; if already explicitly confirmed, reuse it without repeatedly asking for authorization. Only ask about gaps that truly affect implementation. This workflow does not expand tool, fee, push, merge, or deployment permissions.

2. Coordinator Directly Splits

• The coordinator directly defines functional boundaries, dependencies, interfaces, responsible parties, and acceptance items, without adding an additional splitting layer. Independent tasks are parallel; dependent tasks proceed according to interfaces and order.
• A independently testable, revertible feature corresponds to one independent worktree, branch, and real PR. Pin the target branch and base/head SHA; different implementers do not share a working directory or borrow branches from other tasks.
• The final additions + deletions of a single-feature PR should not exceed 1000 lines, including tests, documentation, and generated files. Split reasonably first if exceeded; if splitting is impossible, explain the reason and scale; do not hide generated files or forcibly split half a feature.
• For multi-feature batches, record sub-PR URLs, dependencies, and independent acceptance items. Organize using the project's supported stacked PRs or integration branches, verifying actual capabilities; task numbers in documentation must not impersonate real PRs.

3. Implementer Runs and Self-Verifies

• The implementer completes implementation, self-checks, and runs key user paths before submitting for independent review; do not offload the primary running verification and screenshot work to the reviewer.
• Record the exact SHA, commands, environment, actual results, untested items, and risks. For bugs, provide reproduction before the fix and the result after the fix on the same path. Separate reports for build, mock, and real service acceptance.
• For UI changes, provide actual runtime screenshots of the key steps and results. Place screenshots in PR comments or attachments, not in the code branch. First verify the parameters supported by the upload tool; if upload fails, report the blockage, do not fabricate attachment URLs.
• For backend permission, data, or financial actions, provide corresponding API/data evidence. Use isolated environments and synthetic data for testing; do not leak credentials or personal data.
• For non-UI rule or documentation changes, do not fabricate screenshots; check scope, links, rule consistency, and diff. Use authorized isolated environments for container verification; do not arbitrarily roll back the user's personal machine.
• PRs use the four-section template, with each piece of evidence linked to an actual commit.

4. Separate Code and Security Reviews

• Prioritize reusing the repository's configured automated code and security reviews, verifying completion status, covered SHA, and unresolved findings respectively. Do not add duplicate reviews or manually trigger them again.
• If not configured, not triggered, or not covering the target SHA, report the gap; handle according to authorized fallback plans; if no fallback authorization exists, obtain a decision. No comments do not equal review completion.
• For code quality, read the installed yushen-code-quality-review as needed; for security, read the installed yushen-security-review. Use the actual installation path; if missing or not read, explain.
• Reviews only raise evidence-backed issues; for external implementations, you may compare and suggest, but do not change the scheme, migrate, or add dependencies without user adoption.

5. Maximum of Three Convergence Rounds

A round consists of review feedback → fix or evidenced disposition → verification. Code and security reviews count together, with a total of up to three rounds; switching agents, models, retrying, restacking, or reopening the same work PR does not reset the count.

The first round reviews the complete diff against requirements; the second and third rounds check new diffs, closure of existing issues, and affected regressions. Merge findings with the same root cause using a stable issue ID, recording location, evidence, first round, status, fix SHA, and verification. Use evidence to dismiss false positives; do not make meaningless changes to eliminate comments. Do not mark resolved without re-review.

If the same issue has no progress after two effective repair rounds, it can be escalated early. If there are still unresolved issues after the third round, stop automatic convergence and hand over to the coordinator to summarize evidence, reconsider the solution, and request a decision; do not lower the bar, auto-approve, or merge.

6. Combined Version Check

The coordinator verifies final necessary CI, conflict resolution, shared state, and combined user paths, recording each sub-PR SHA and the combined candidate SHA. Passing each layer individually does not imply combined passing. After rebase, conflict resolution, or implementation changes, update the SHA mapping and supplement affected regression; old evidence must not impersonate current version results.

7. Human Acceptance

Provide the candidate SHA, runnable artifact, minimal test steps, expected results, and remaining risks. Only after the user personally tests and explicitly confirms the corresponding version should merging proceed according to actual authorization. After code changes, reconfirm the affected parts; automated tests and bot approvals do not replace personal acceptance. Releases and deployments follow their respective authorization.

When delivering an installer, desktop application, or other actual release artifacts, read the installed yushen-release-acceptance as needed, verify the complete path from final download file to usability, and distinguish platform conclusions from preview limitations. Pure copy or internal minor changes do not enforce the full release acceptance process.

Model and Cost Strategy

Select models based on configurable task difficulty, risk, budget, and available capability: scripts for deterministic checks; low-cost tiers for clearly localized implementations; capability-appropriate tiers for complex diagnosis, design, and high-risk judgments; lower cost tiers for evidence compilation. At the start, explain the selected role, cost boundary, and escalation conditions; do not assume a specific model is default available in a public environment.

First exclude environment failures and missing context before deciding to escalate. If exceeding budget, increasing paid calls, or beyond authorized capability, obtain the corresponding decision first; do not retry indefinitely. At batch end, use the rework summary as needed; rule updates go through the normal acceptance workflow.

Project Rule Integration

In the project's AGENTS.md, explicitly require reading the relevant skills and REVIEW.md per task; do not assume links expand automatically. REVIEW.md should only contain long-term, verifiable project rules; per-round findings and evidence remain in the PR. Report missing files or constraint conflicts; do not fabricate mechanisms.

When creating project rules, you may refer to the generic REVIEW example as needed, keeping only the terms that are actually applicable and verifiable.