docs: refactor skill governance and reduce workflow duplication

Restructure problem-validate into a lean skill with a separate reference file, align governance requirements with checklist enforcement, and reduce duplicated workflow details between agent and skill while keeping gate semantics unchanged.

Made-with: Cursor

Author: SummerOneTwo

agents/autocode-workflow.md

@@ -38,26 +38,16 @@ Also report:
 
 ## Canonical Workflow
 
-Use this sequence unless the user request is explicitly outside problem creation.
+Use the canonical sequence defined in `skills/autocode-workflow/SKILL.md`.
+This agent is responsible for orchestration and gate handling, not for duplicating the full workflow reference.
 
-Non-interactive:
+Orchestration requirements:
 
-1. `problem_create`
-2. `solution_build(solution_type="sol")`
-3. `solution_build(solution_type="brute")`
-4. `solution_analyze`, `solution_audit_std`, `solution_audit_brute`
-5. `validator_build(accuracy >= 0.9)`
-6. `generator_build`
-7. `stress_test_run`
-8. `checker_build` when non-exact output is required
-9. `problem_validate`
-10. `problem_generate_tests`
-11. `problem_verify_tests`
-12. `problem_pack_polygon`
-
-Interactive:
-
-- replace `validator_build` and `checker_build` with `interactor_build`.
+1. identify current workflow position;
+2. select the next valid MCP call;
+3. block or reroute when prerequisites are missing;
+4. delegate deep checks to dedicated auditors/skills;
+5. continue only after gate evidence is satisfied.
 
 ## Gate Discipline
 
@@ -69,10 +59,8 @@ Interactive:
 
 ## Test-Quality Requirements
 
-During `problem_generate_tests` and `problem_verify_tests`:
-
-- target at least 50% limit-oriented cases (`type=3` + `type=4`) when candidate availability allows;
-- require semantic difference between `type=3` and `type=4` (`type=4` is targeted worst-case/TLE, not only max-parameter scaling).
+Enforce test-quality gates using `testdata-quality` and `problem-validate` skills.
+Do not restate tool reference details here; use skill contracts as the source of truth.
 
 ## Long-Running Generation
 

skills/agent-skill-governance/SKILL.md

@@ -44,6 +44,7 @@ Must include:
 3. Step-by-step execution guidance.
 4. Required output format.
 5. Decision rules (`go` vs `no_go`).
+6. Forbidden behavior.
 
 ## Workflow Consistency Rules
 
@@ -66,8 +67,11 @@ Before finalizing edits:
 Use this checklist when updating any `agents/` or `skills/` file:
 
 - [ ] Role/scope is explicit.
+- [ ] Trigger conditions are explicit (skills).
 - [ ] Output contract is explicit.
 - [ ] Gate behavior is explicit.
 - [ ] Decision rules are explicit.
 - [ ] Forbidden behavior is explicit.
 - [ ] Terminology is consistent with project standards.
+
+Project-specific constraints such as maximum clarification count are allowed as long as they are explicit and non-contradictory.

skills/problem-validate/SKILL.md

@@ -6,217 +6,40 @@ disable-model-invocation: false
 
 # Problem Validation Skill
 
-This skill guides the validation of problem statement samples and sample files to ensure correctness before generating final test data.
+Use this skill to enforce sample correctness before final test generation.
 
-Hard rule:
-- Validation failure is a release blocker. Do not proceed to final test generation or packaging until all sample validations pass.
+## Trigger Conditions
 
-Output contract:
-- `decision`: `go` / `no_go`
-- `blocking_issues`: validation blockers that must be fixed
-- `next_actions`: exact re-validation steps after fixes
-
-## Overview
-
-The `problem_validate` tool verifies that:
-
-1. **Statement Samples**: The expected outputs in the problem statement (README.md) match what the solution actually produces
-2. **Sample Files**: The sample files in `tests/` directory (e.g., `01.in`, `01.ans`) are consistent with the solution
-
-This catches common errors like:
-- Wrong expected output in problem statement
-- Sample files that don't match the problem description
-- Solution bugs that would fail on the provided examples
-
-## When to Use
-
-Use this skill after:
-- `stress_test_run` has passed (solution is verified correct)
-- Before `problem_generate_tests` (ensures samples are correct)
-
-## Validation Types
-
-### 1. Statement Samples (`statement_samples`)
-
-Validates samples embedded in the problem statement (README.md).
-
-**Supported formats (both localized labels and English labels are accepted):**
-
-```markdown
-**样例输入 1**
-```text
-5
-3 -5 2 -8 4
-```
-
-**样例输出 1**
-```text
-2
-```
-```
-
-Or standard English labels:
-
-```markdown
-**Sample Input 1**
-```text
-5
-3 -5 2 -8 4
-```
-
-**Sample Output 1**
-```text
-2
-```
-```
-
-### 2. Sample Files (`sample_files`)
-
-Validates sample files in the `tests/` directory:
-- `01.in`, `01.ans`
-- `02.in`, `02.ans`
-- etc.
-
-## Usage
-
-### Basic Usage
-
-```json
-{
-  "problem_dir": "problems/emergency-escape"
-}
-```
-
-Auto-extracts samples from README.md and validates all sample files.
+Use when:
 
-### With Explicit Samples
+- `stress_test_run` has passed and the next step is sample verification;
+- the user updates statement samples or sample files;
+- workflow is blocked by `problem_validate` or sample mismatch.
 
-```json
-{
-  "problem_dir": "problems/emergency-escape",
-  "statement_samples": [
-    {
-      "input": "5\n3 -5 2 -8 4",
-      "expected_output": "2"
-    }
-  ]
-}
-```
+## Core Instructions
 
-### Validate Only Statement Samples
+1. Run `problem_validate` against statement samples and sample files.
+2. Treat any mismatch as a release blocker.
+3. Classify failures by source: statement text, sample files, or solution behavior.
+4. Re-run validation after fixes before allowing progression.
 
-```json
-{
-  "problem_dir": "problems/emergency-escape",
-  "validate_types": ["statement_samples"]
-}
-```
+## Output Contract
 
-### Validate Only Sample Files
-
-```json
-{
-  "problem_dir": "problems/emergency-escape",
-  "validate_types": ["sample_files"]
-}
-```
-
-## Output Interpretation
-
-### Success
-
-```json
-{
-  "success": true,
-  "data": {
-    "statement_samples": {
-      "validated": true,
-      "passed": 2,
-      "failed": 0,
-      "total": 2
-    },
-    "sample_files": {
-      "validated": true,
-      "passed": 3,
-      "failed": 0,
-      "total": 3
-    }
-  }
-}
-```
-
-### Failure
-
-```json
-{
-  "success": false,
-  "error": "Validation failed",
-  "data": {
-    "statement_samples": {
-      "validated": true,
-      "passed": 1,
-      "failed": 1,
-      "total": 2,
-      "details": [
-        {
-          "index": 1,
-          "input": "5\n3 -5 2 -8 4",
-          "expected": "5",
-          "actual": "2",
-          "passed": false
-        }
-      ]
-    }
-  }
-}
-```
-
-## Error Recovery
-
-### If Statement Sample Fails
-
-1. Check the `actual` output - this is what the solution produces
-2. Verify manually if `actual` is correct
-3. If correct, update README.md with the correct expected output
-4. If incorrect, the solution has a bug - fix and rebuild
-
-### If Sample File Fails
-
-1. Check if the `.ans` file exists
-2. Compare `actual` vs `expected` output
-3. Update `.ans` file if solution is correct
-4. Or fix solution if it's wrong
-
-## Output Comparison Rules
-
-The tool uses multiple comparison methods:
-
-1. **Exact match**: Direct string comparison
-2. **Whitespace-insensitive**: Compares after stripping trailing whitespace from each line
-3. **Token match**: Compares after splitting on whitespace
-4. **Floating-point tolerance**: Compares numeric values within tolerance (default 1e-9)
-
-This handles common formatting variations while catching actual errors.
-
-## Integration with Workflow
-
-The validation step is enforced by `workflow_guard.py`:
-
-```
-stress_test_run -> problem_validate -> problem_generate_tests
-```
-
-You cannot skip validation - it must pass before generating final tests.
+- `decision`: `go` / `no_go`
+- `blocking_issues`: validation blockers that must be fixed
+- `next_actions`: exact re-validation steps after fixes
 
-## Best Practices
+## Forbidden Behavior
 
-1. **Write samples early**: Include samples in README.md during problem creation
-2. **Validate after stress test**: Solution is verified, so any mismatch is likely in the statement
-3. **Keep samples simple**: Use small, easy-to-verify examples
-4. **Include edge cases**: Add boundary samples that test limits
-5. **Match format**: Ensure sample format matches actual input/output format
+- Do not proceed to `problem_generate_tests` while validation is failing.
+- Do not approve based on file presence without validation evidence.
+- Do not rewrite expected outputs unless the corrected output is justified.
 
 ## Decision Rules
 
 - `go`: all selected validation types pass without unresolved mismatches.
 - `no_go`: any selected validation type fails, or validation evidence is incomplete.
+
+## Additional Resources
+
+For tool examples, detailed output schemas, error recovery playbooks, and comparison rules, see [reference.md](reference.md).