Adopt descriptive task names and update task authoring workflows

.agents/AGENTS.md

@@ -1,24 +1,25 @@
 # Search-SWE Task Workflow
 
-This is the contributor workflow entry point. Detailed task-authoring knowledge
-lives inside the skill, not here. Paths below are relative to the repository
-root unless expressed as Markdown links.
+This is the contributor workflow entry point. Each skill contains its detailed
+guidance. Paths below are relative to the repository root unless expressed as
+Markdown links.
 
 ## Route the request
 
 - **Create or substantially revise a task:** load
   [create-searchswe-task](skills/create-searchswe-task/SKILL.md) and follow its
   workflow, references, and validation gates. If no native skill loader is
   available, open that `SKILL.md` directly. It can also be invoked independently
-  as `$create-searchswe-task`; it does not need this file.
+  as `$create-searchswe-task`.
 - **Review, promote or finalize a task PR as maintainer:** load
   [maintain-searchswe-task](skills/maintain-searchswe-task/SKILL.md), independently
   invocable as `$maintain-searchswe-task`. Default to read-only gh evidence review;
   use its bundled offline promotion/HF staging helpers only at approved stages.
 - **Run an existing task:** use `docs/quickstart.md`; do not scaffold a task.
 - **Restore fixed inputs:** use `docs/assets.md` and the existing download tools.
 - **Edit project documentation:** keep `README.md` and `README_zh.md` aligned.
-  The current public modes are Implementation and Optimization.
+  Describe the current contract and workflow directly; keep migration rationale
+  in the PR description.
 - **Change shared images:** use `docker/README.md`. An ordinary task contribution
   should reuse the CPU/GPU images rather than redesign their shared runtime.
 
@@ -28,32 +29,39 @@ root unless expressed as Markdown links.
    contributors' changes. Ask about uncertainties that affect task design or
    authorization, not information already supplied by the user.
 2. For task contributions, let the skill drive design → structured source →
-   scenario rewrite → grader checks → configured model evaluation. Preserve `raw-instruction.md` and audit all its conditions
-   in the agent-facing `instruction.md`; the skill defines both gates.
+   user-request rewrite → grader checks → configured model evaluation → feedback
+   and task refinement → revalidation of substantive changes. Preserve
+   `raw-instruction.md` and audit all its conditions in the agent-facing
+   `instruction.md`. Describe the task, available inputs, resource constraints,
+   acceptance criteria and optimization objective directly, without invented
+   requester identities or narrative scenes; the skill defines both gates.
    Before scaffolding, inspect one or two closest reviewed packages under
-   `tasks/` as read-only structural precedents, selected by mode, grading shape,
-   resources and hardware. Current repository contracts and validators override
-   older examples; never inherit task-specific data, thresholds, licenses or
-   access merely because another task uses them.
-   A PR may add multiple tasks, all under exactly one first-name namespace, at
-   `task-submissions/<first-name-slug>/<1|2>-x-<positive-ordinal>`; do not use
-   usernames, reuse a promoted temporary ordinal, or guess formal IDs. Follow
+   `tasks/` as read-only structural precedents, selected by engineering objective,
+   grading shape, resources and hardware. Apply current repository contracts
+   and validators, and independently establish the new task's data, thresholds,
+   licenses and access policy.
+   A PR may add multiple tasks at `task-submissions/<task-name>`. Choose a
+   descriptive lowercase name with at most five hyphen-separated words, without
+   a `task-` prefix; `all` is reserved. Keep that name when promoting to
+   `tasks/<task-name>`. Do not reuse a submission path within the same PR. Follow
    `CONTRIBUTING.md` and `docs/contributing.md`: require actual authors and
    explicit `--task-path` for local trials, then promote every task with its own
-   same-PR pure rename and finalization commits before a merge commit (no
-   squash/rebase). Track which stage is complete and which inputs or approvals
+   same-PR pure rename and any necessary finalization commits before a merge
+   commit (no squash/rebase). Track which stage is complete and which inputs or approvals
    are missing.
    Do not duplicate the skill's specifications in this file.
 3. Keep changes within the selected task plus directly necessary integration
    changes. Updating a website, publishing a dataset, pushing images, and opening
    or merging a PR are separate actions, not implied by task creation.
 4. Review the resulting diff and validation evidence. Hand off changed paths,
-   task mode/hardware, commands actually run, observed results, and blockers.
+   task objective/hardware, commands actually run, observed results, and blockers.
    Static checks alone are not evidence of a working end-to-end benchmark.
    Include the exact instruction revision, model/effort, trajectory, score and
-   judge health from the configured-model validation. Reuse session-authorized
-   runs and credentials; do not repeat successful runs just because results
-   were moved or a monitoring pane still looks active.
+   judge health from the configured-model validation, plus any resulting task
+   changes and evidence for the final revision. Reuse session-authorized runs
+   and credentials. If required keys are missing, follow the skill's local
+   configuration handoff to the contributor. Do not repeat successful runs just
+   because results were moved or a monitoring pane still looks active.
 
 Agents are not guaranteed to auto-load an `AGENTS.md` located under `.agents/`
 when editing `tasks/`. Open this entry point explicitly or invoke the skill;

.agents/skills/create-searchswe-task/SKILL.md

@@ -5,14 +5,14 @@ description: Create or substantially revise Search-SWE task packages with CPU/GP
 
 # Create a Search-SWE Task
 
-Deliver a reproducible task whose structured source, scenario instruction,
+Deliver a reproducible task whose structured source, natural-language request,
 environment, submission interface, and grading agree. Validate the setting
-with an actual configured coding-model run as well as grader checks. This skill
-contains its authoring guidance and helpers; no outer AGENTS.md, other skill, or historical Harbor workspace is
-required. It still operates on a **target Search-SWE checkout**: its tasks,
-Docker definitions, and release/download/launch tools are project inputs, not
-bundled copies of this skill. Missing tools or incompatible versions are
-prerequisites to report, not permission to invent a replacement workflow.
+with an actual configured coding-model run as well as grader checks, and use
+the results to refine the setting where needed. This skill contains its authoring
+guidance and helpers. It operates on a **target Search-SWE checkout**, which
+supplies the task packages, Docker definitions, and release/download/launch
+tools. Report missing tools or incompatible versions as prerequisites for the
+affected workflow step.
 
 ## 1. Establish the design
 
@@ -21,9 +21,8 @@ target checkout's status and preserve unrelated changes. Resolve its root
 explicitly; do not infer it from where this skill was installed.
 
 Before scaffolding, inspect one or two closest **formal** packages under the
-target checkout's `tasks/`. Choose them by engineering mode, evaluation/judge
-shape, resources/APIs, hardware and input/artifact layout—not merely by task
-number. Record their exact paths and why they are relevant. Treat them as
+target checkout's `tasks/`. Choose them by engineering objective, evaluation/judge
+shape, resources/APIs, hardware and input/artifact layout. Record their exact paths and why they are relevant. Treat them as
 read-only structural precedents: the current skill, repository validators,
 schema and shared-image documentation take priority. Do not copy task-specific
 IDs, authors, datasets, thresholds, pins, licenses or access policy without
@@ -35,20 +34,18 @@ Record a short design summary before writing the package:
 
 | Decision | What must be known |
 | --- | --- |
-| Identity | Temporary ID (`task-<1|2>-x-<positive-ordinal>`), one PR-wide first-name slug, actual authors, version |
-| Mode | Implementation → `metadata.task_type = "create"`; Optimization → `"optimize"` |
+| Identity | Descriptive task name (at most five lowercase hyphen-separated words), actual authors, version |
 | Goal | What working capability or quality/efficiency improvement is measured |
 | Interface | Container input paths, commands, output paths/formats, artifact transfer |
 | Evaluation | Metric, public gates, baseline if needed, failure/timeout behavior |
 | Inputs | Public/hidden split, actual files, provenance, redistribution rights |
 | Resources | CPU/GPU, memory/storage/time, network, permitted APIs/models |
 | Precedent | Formal task path(s), matching dimensions, structural patterns reused, intentional differences |
 
-Only these two engineering modes exist. CPU is the default; choose GPU for
-actual GPU execution, not merely because model files are involved. Ask for
+CPU is the default; choose GPU when the agent or verifier executes GPU work. Ask for
 missing facts that change the design; do not invent labels, licenses, service
-access, or quality thresholds. An Optimization task needs a meaningful supplied
-starting system/model and comparison criterion, not only a different mode label.
+access, or quality thresholds. When improvement over a starting system/model is measured, supply that baseline
+and a meaningful comparison criterion.
 
 ## 2. Create or edit the package
 
@@ -58,45 +55,28 @@ For a new task, run the bundled helper using its **actual installed path**:
 # Set these to real absolute paths; neither depends on the current directory.
 SKILL_DIR=/path/to/create-searchswe-task
 REPO=/path/to/Search-SWE
-python "$SKILL_DIR/scripts/scaffold_task.py" task-1-x-1 \
-  --repo-root "$REPO" --submission-first-name Alice --author 'Alice Example' \
-  --mode implementation --hardware cpu
+python "$SKILL_DIR/scripts/scaffold_task.py" example-search \
+  --repo-root "$REPO" --author 'Alice Example' --hardware cpu
 ```
 
-Category 1 is Implementation (`create`); category 2 is Optimization (`optimize`).
-The temporary ID and mode must agree. For optimization:
-
-```bash
-python "$SKILL_DIR/scripts/scaffold_task.py" task-2-x-1 \
-  --repo-root "$REPO" --submission-first-name Alice --author 'Alice Example' \
-  --mode optimization --hardware cpu
-```
-
-Hardware is independent of category/mode; use `--hardware gpu` only for GPU work.
-New tasks belong in
-`task-submissions/<first-name-slug>/<1|2>-x-<positive-ordinal>`, not formal `tasks/` directories.
-Use a supplied ASCII first name, not a username; non-Latin names need an explicit
-transliteration. Reuse that contributor directory for every task in the PR.
-Ordinals are temporary, category-local, positive, and unique in the PR/checkout;
-they are not final IDs; never reuse one after promoting its earlier task in the
-same PR. If a different contributor with the same first name needs a namespace,
-explicitly supply `Alice-2` (then `Alice-3`), including after
-checking active PRs; the scaffolder never derives name suffixes from task
-collisions. Repeat `--author` for coauthors.
-The helper refuses overwrites and symlink roots. Regular mode without
-`--submission-first-name` remains compatible for maintainers. Edit an existing
-task in place instead; do not delete it to make the helper succeed.
-
-One PR may add multiple tasks, but every task must use exactly one contributor
-first-name namespace. Read the bundled
-[submission and PR workflow](references/submission-and-pr.md) for branch,
-review gates, maintainer handoff and author identity. A maintainer assigns each final ID close to
-merge and performs a separate pure rename then finalization for each task in
-**the same PR**, using `scripts/promote_task.py`. All tasks must be promoted
-before merge. Preserve every promotion commit and original author commit:
-**merge commit only**, never squash/rebase. No submission task package enters
-final main. Missing workflow tools in an older checkout are a prerequisite to
-report, not a reason to invent a formal ID.
+Use `--hardware gpu` only for GPU execution. New tasks belong at
+`task-submissions/<task-name>`, with `task.name = "search-swe/<task-name>"`.
+Names start with an ASCII lowercase letter, contain lowercase letters/digits
+and single hyphens, and have at most five words. Use a concise description of
+the task; omit the `task-` prefix. `all` is reserved. Check both package roots
+and active PRs for collisions. Repeat `--author` for actual coauthors.
+The helper refuses overwrites and symlink roots. Its explicit `--formal` option
+is for maintainer tooling, not a bypass for new task contributions. Edit an
+existing task in place instead of deleting it to make the helper succeed.
+
+One PR may add multiple uniquely named tasks. Read the bundled
+[submission and PR workflow](references/submission-and-pr.md). Promotion keeps
+the same name: `task-submissions/<task-name>` → `tasks/<task-name>`. Each task
+gets its own pure rename commit in **the same PR**, followed by a separate
+finalization commit when references, assets or integration need changes. Do not
+reuse a submission path in that PR. Preserve original author and promotion
+commits: **merge commit only**, never squash/rebase. All tasks must be promoted
+before merge; no submission package enters final main.
 
 The scaffold is **not a finished task**: its verifier always fails, its asset
 manifest is empty, data/model mounts are absent, and instructions are writing
@@ -112,10 +92,12 @@ Follow the detailed rules in `references/task-authoring.md`:
 1. Define the submission interface and grader behavior in `raw-instruction.md`.
    Preserve an existing structured instruction there before rewriting. Follow
    [references/instruction-rewrite.md](references/instruction-rewrite.md) to write
-   the agent-facing `instruction.md`: a named person in a concrete physical
-   setting asking their coding agent for help in long, natural prose. Preserve
-   every condition and exact interface; do not reveal hidden answers. Audit the
-   two documents for semantic equivalence before running a model.
+   the agent-facing `instruction.md`: a direct user request in connected prose
+   describing the task, current data and starting system, available resources,
+   constraints, acceptance criteria and optimization objective. Omit
+   self-introductions, invented identities and fictional scenes. Preserve every
+   condition and exact interface; do not reveal hidden answers. Audit the two
+   documents for semantic equivalence before running a model.
 2. When adding fixed data/models or external services, read
    [references/assets-and-resources.md](references/assets-and-resources.md).
    Build exact manifests and read-only phase-specific mounts. Keep hidden inputs,
@@ -128,7 +110,7 @@ Follow the detailed rules in `references/task-authoring.md`:
 5. Add author-facing README context and task-local tests, including known-good
    and invalid submissions. Do not change unrelated tasks or scoring policies.
 
-## 4. Validate the task and run a configured model
+## 4. Validate, test with a model, and refine the setting
 
 Read [references/validation.md](references/validation.md) and follow its staged
 checks. Stop advancing to expensive runtime tests when inputs, permissions,
@@ -137,10 +119,19 @@ diagnosis; retry after a relevant fix, not in an unbounded loop.
 
 After local package, asset and grader checks, follow
 [references/model-evaluation.md](references/model-evaluation.md). Run the final
-scenario instruction with the configured coding model and any required judges;
-inspect its trajectory, artifacts, grader result and judge health to validate
-the task setting. An infrastructure failure does not measure difficulty, and
-one low-scoring model run does not establish that a task is impossible.
+rewritten instruction with the configured coding model and any required judges;
+inspect its trajectory, artifacts, grader result and judge health. Use this
+feedback to identify task-setting issues, correct them, and revalidate the
+affected checks. Rerun the model when changes affect its task or scoring, within
+the authorized budget, and record the final evaluated revision. An infrastructure
+failure does not measure difficulty, and one low-scoring model run does not
+establish that a task is impossible or justify weakening it.
+
+If required API keys are missing, tell the contributor which variables are
+needed, what they are for, and where to configure them locally; never ask for
+secret values in chat. Wait for that configuration before the dependent run,
+and continue independent checks. The model-evaluation reference details this
+handoff and the feedback loop.
 
 Local task authoring/validation is the default authorization boundary. It does
 not itself authorize commits, pushes, PR creation/comments, publishing data/images, modifying host
@@ -150,11 +141,12 @@ request or prior session. An explicit request to evaluate with a named model
 authorizes that scoped run; reuse already-authorized local credentials without
 asking again. Ordinary local checks may proceed.
 
-Report the task path, mode/hardware, commands actually executed and their
+Report the task path, objective/hardware, commands actually executed and their
 results, formal reference tasks consulted (or that none was close), intentional
-reuse/deviations, the raw-to-scenario equivalence review, known-good/negative-case
+reuse/deviations, the source-to-request equivalence review, known-good/negative-case
 evidence, the exact evaluated revision/model/effort, observed scores and judge
-health, and every unrun validation layer.
+health, feedback-driven task changes (or why none were needed), and every unrun
+validation layer.
 Never equate a scaffold, a dry-run, or a static release check with a solvable
 end-to-end task.
 

.agents/skills/create-searchswe-task/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Contribute Search-SWE Task"
   short_description: "Author and validate a temporary task submission"
-  default_prompt: "Use $create-searchswe-task to build and locally validate a first-name task submission, then prepare an authorized PR handoff."
+  default_prompt: "Use $create-searchswe-task to build and locally validate a task submission with a descriptive name, then prepare an authorized PR handoff."