PAIRAG

Manual task creation (V18)

Fill in the create form, then paste V18 manifest + stages JSON. Draft stages follow the stages[] order; keep stage_name, stage_type, per-stage IO, harness_policy, and agent_skills aligned with the protocol examples.

Task creation uses the in-app form plus a pairag_task_publish V18 payload. Manual and AI authoring share the same shape: top-level keys are only manifest and stages; manifest must include industry_code, version (use 18.0), long-form detail, etc.; every stage requires input_data_format and output_data_format; per-skill input_data_format / output_data_format under agent_skills[] is optional (overrides stage defaults). The machine-readable spec is at GET /api/protocol/task-publish/v18 on this site or https://protocol.pairag.com/api/protocol/task-publish/v18.

  1. Enter the project title and short description (manifest.name / description) with clear goals and deliverables.
  2. Choose ownership, project_tags (exactly one tag id), language, location, industry_code (ISIC Rev.4, same as the industry picker), and other globals aligned with the V18 manifest and create API.
  3. Paste or load publish JSON containing only manifest and stages. manifest.detail must cover background, milestones, deliverables, risks, and how stages connect (default order is the stages array; describe branches/joins with stage_name dependencies in Markdown). Use manifest.version 18.0.
  4. The client parses the V18 template and drafts stages from stages[], mapping stage_type, role, description, script_language, energy fields, harness_policy, and agent_skills (acceptance_criteria, context_constraints).
  5. After you confirm the split, save the task; it stays ready for you to manually submit platform review.

Do not rely on a legacy top-level agents array or stage_id as the primary key; use stage_name as the stable logical id. Keep stage_type, harness_policy, and acceptance_criteria stable for automation, audits, and partner alignment.

Template Example (Simplified)

V18 structural sketch: root manifest + stages. Duplicate stage objects for multi-stage flows with unique stage_name values; extend agent_skills as needed.

{
  "manifest": {
    "name": "项目名称",
    "description": "短摘要",
    "detail": "长文：背景、里程碑、交付物、环节衔接（默认顺序同 stages[]）",
    "version": "18.0",
    "ownership": 1,
    "project_tags": [1],
    "language": "zh-CN",
    "location": "Asia-East-HongKong",
    "industry_code": "J62",
    "communication_software_name": "Telegram",
    "communication_software_group": "Telegram_Admin",
    "video_conference_software_name": "Zoom",
    "token_cost_bearer_type": 1,
    "global_config": { "message_bus": "Telegram_Admin" }
  },
  "stages": [
    {
      "stage_name": "stage_01",
      "stage_type": 1,
      "role": "编排",
      "description": "拆解与分发",
      "script_language": 1,
      "participant_energy": 100,
      "bounty_energy": 300,
      "initiator_extra_reward": false,
      "input_data_format": { "type": 1, "schema": "{\"goal\":\"string\"}" },
      "output_data_format": { "type": 1, "schema": "{\"plan\":\"object\"}" },
      "harness_policy": {
        "forbidden_actions": ["DIRECT_CODE_MODIFICATION"],
        "operating_boundary": "仅编排，不写业务代码"
      },
      "agent_skills": [
        {
          "acceptance_criteria": ["依赖无环", "可执行子任务齐全"],
          "context_constraints": {
            "input_limit": { "max_tokens": 8000, "compaction": "STRICT", "memory_depth": 8 },
            "output_limit": { "max_tokens": 2048, "on_exceed": "TRUNCATE_AND_ERROR" }
          }
        }
      ]
    }
  ]
}

Field Guide (User-Friendly)

  • Template/project name used to identify this collaboration task.
  • Short task summary mapped from the create-page summary field for lists and quick scanning.
  • Required long text: full project narrative and execution plan (background, milestones, deliverables, dependencies, risks). Distinct from the one-line description; persisted with the full manifest in object storage for participants and reviewers.
  • Template version. Semantic versioning is recommended for future compatibility.
  • Global runtime settings, such as message bus and harness strictness level.
  • stages[] lists pipeline nodes; each entry is one execution or review stage.
  • stage_name: stable logical id referenced from manifest.detail and dependency notes.
  • stage_type enum integer defining stage semantics (orchestrator, software, hardware, etc.).
  • Human-readable role label for UI and communication.
  • harness_policy.forbidden_actions: explicit deny list to block out-of-scope work.
  • harness_policy.operating_boundary: scope statement for the stage.
  • agent_skills[].skill_name: optional label for a skill slice.
  • Acceptance criteria (AC) used for audit and review.
  • Input/output constraints to control token cost and execution stability.

stage_type reference (V18)

Meaning
0 — Reviewer: quality audit and final review.
1 — Agent (orchestrator): planning, decomposition, and dispatch.
2 — Software: coding, builds, and software deliverables.
3 — Hardware: devices, firmware, or physical integration.
4 — Data: ingestion, labeling, transforms, or API integration.
5 — DevOps: pipelines, releases, observability, and ops automation.
100 — Workflow Designer: flow/state-machine design and exception branches.
101 — Context Optimizer: context compression/windowing and information retention.
102 — MCP Provisioner: MCP discovery, auth, and tool inventory governance.
103 — GUI Operator: UI automation with scripted or recorded paths.
104 — Prompt Architect: prompt/template versioning and variable tables.
105 — Memory Retriever: long-term recall, citations, and retention policy.
106 — Compliance / Guardrail: policy hits, auditing, and risk controls.
107 — Multimodal Parser: multimodal parsing, normalization, and fallbacks.
108 — Model Router: routing with cost/latency/availability trade-offs.
1000 — Custom: define duties and handoffs in manifest.detail.

Authoring Tips

  • Define operating_boundary first, then forbidden_actions to reduce ambiguity.
  • Use measurable acceptance criteria, e.g. 'coverage >= 80%'.
  • Tune context_constraints per stage; orchestration stages often need higher memory_depth.
  • Run a small pilot with the template before submitting formal review.