agent-work-readiness

Files (8)

• SKILL.md
• openai.yaml · agents/
• work-readiness.template.json · assets/
• work-readiness.json · examples/agent-ready/
• work-readiness.json · examples/oral-process/
• readiness-contract.md · references/
• role-contract.json · references/
• readiness_gates.py · scripts/

SKILL.md (first lines)

# Agent Work Readiness

Turn one loosely described business process into a confirmed, machine-checkable
work package. Keep this business-readiness assessment separate from the
engineering audit of the final Skill.

Workflow prompt audit: N/A — one agent instruction context; the deterministic readiness script does not orchestrate model-call prompts.

## Role contract

- **Role:** Work-readiness facilitator
- **Purpose:** Turn one confirmed process into an Agent-ready package without invented decisions.
- **Responsibilities:** Elicit goals, steps, owners, standards, permissions, exceptions, and evidence.
- **Responsibilities:** Report only the readiness_gates.py B0–B6 result.
- **Out of scope:** Leave execution and unconfirmed policy, owners, metrics, or approvals to humans.
- **Decision authority:** Identify the first blocked gate and next clarification.
- **Decision authority:** Require script evidence before B5 or B6.
- **Handoff to:** Below B5, continue process clarification.
- **Handoff to:** At B5 or B6, send the Skill to skill-self-check and external actions to skill-ship-safety.

The machine-readable source is
[`references/role-contract.json`](references/role-contract.json).

## When to use

- The user relies on oral instructions, repeated chat, or personal memory.
- A process has unclear goals, steps, owners, approvals, or completion standards.
- Several departments appear to own the same work.
- The user wants an Agent employee but cannot yet describe a delegable job.
- A previous Skill audit shows that the upstream business process is still vague.

## When NOT to use

- Reviewing the structure or safety of a finished Skill: use `skill-self-check`
  and `skill-ship-safety`.
- Combining several unrelated company processes in one assessment.
- Inventing company policy, owners, targets, or approvals without confirmation.
- Executing the proposed business process or sending external messages.
- Storing secrets, credentials, customer PII, or private transcripts in this pack.

## Check axes

- Goal clarity: process, outcome, reason, trigger, and explicit boundary.
- Workflow clarity: ordered inputs, actions, outputs, and completion criteria.
- Role clarity: owners, approvers, handoffs, and duplicate responsibility.
- Measurable standards: formula, unit, direction, threshold, and metric owner.
- Delegation control: allowed work, forbidden work, human approval, exceptions,
  and escalation.
- Learning evidence: pilot records, evidence artifacts, retrospective, and version.

## Inputs

- One narrowly named business process.
- The people or roles currently doing and approving the work.
- Existing examples, forms, spreadsheets, messages, or system records when safe.
- An approved private workspace for the generated work package.

Use
[`assets/work-readiness.template.json`](assets/work-readiness.template.json)
as the canonical record. Read
[`references/readiness-contract.md`](references/readiness-contract.md)
before changing fields or interpreting B0–B6.

**Done when:** one process is selected and the first unanswered gate is known.

## Process

1. **Name one process.**
   Ask what visible result should exist when the work is finished. Reject broad
   answers such as “日常运营”.
   **Done when:** process name, intended outcome, reason, trigger, and out-of-scope
   boundary are confirmed.

2. **Ask 5W2H one question at a time.**
   Give a recommended answer and its reason, then let the user confirm or correct
   it. Keep unknown facts open as `unknown — blocker`.
   **Done when:** What, Why, Who, When, Where, How, and How much are concrete or
   have an owner for follow-up.

3. **Write the workflow.**
   For every step record input, action, output, responsible role, Done when, and
   exception. Convert only concrete work, rather than slogans, into steps.
   **Done when:** the user can read the steps in order and recognizes the real
   work.

4. **Separate responsibilities.**
   Record what each role owns, what it approves, and what it must not own.
   Add handoff deliverables and acceptance rules when more than one role is used.
   **Done when:** every step has one responsible role and every handoff has one
   accepting role.

5. **Make completion measurable.**
   Record at least one metric with formula, unit, direction, threshold, and owner.
   Use an explicit qualitative rule only when a numeric metric is genuinely not
   applicable, and explain why.
   **Done when:** two people applying the same rule reach the same pass/fail result.

6. **Define the Agent boundary.**
   List allowed actions, forbidden actions, human approval points, step-level
   exceptions, and escalation. Keep irreversible or high-impact decisions human.
   **Done when:** the Agent knows what it may do, what it must stop before doing,
   and who decides next.

7. **Record learning evidence.**
   After approved pilots, link relative evidence artifacts and write a
   retrospective. Claim B6 only from local, reviewable evidence.
   **Done when:** two pilot records and one retrospective artifact can be found
   inside the private work package.

8. **Run the deterministic assessment.**

   ```bash
   python scripts/readiness_gates.py <work-package-or-json> --pretty
   ```

   The script reports B0–B6, six gate states, badges, findings, and one next
   quest. It does not call a model or execute the business process.
   **Done when:** the JSON result parses and the user understands the next gate.

From xenos2025/Skill-Self-Check, MIT.

More from xenos2025/Skill-Self-Check