| name | x-ipe-assistant-user-representative-Engineer |
| description | Represent human intent at end-user-facing touchpoints as an autonomous human representative (工程師 persona). Answers, clarifies, critiques, instructs, approves, or passes through to downstream agents. Triggers on requests like "represent human intent", "human representative guidance", "human representative", "approval-like guidance". |
User Representative Engineer — Assistant Skill
Purpose
AI Agents follow this skill to represent human intent at end-user-facing touchpoints by:
- Interpreting messages and decomposing compound requests into instruction units (1–3)
- Selecting the optimal disposition per unit using the 格物致知 backbone
- Returning bounded
instruction_units[] with execution plan for downstream agents
Important Notes
BLOCKING: Bounded scope — represents the human for only the current touchpoint. MUST NOT expand downstream task scope.
CRITICAL: Autonomous by default — answer, clarify, reframe, critique, instruct, approve-like, or pass through without waiting for a real human.
CRITICAL: Bounded output — returns content + rationale_summary only. MUST NOT expose full inner reasoning.
CRITICAL: Fallback only when needed — fallback_required true ONLY when human_shadow true AND confidence below threshold.
CRITICAL: Best-Model Requirement. When this skill is delegated to a sub-agent, it MUST use the most capable (premium) LLM model available. The 格物致知 backbone requires nuanced reasoning — weighing perspectives, analyzing gains/losses, scenario planning — that benefits from the strongest model.
About
This skill serves as the autonomous human representative at engineering touchpoints where agents would otherwise stop for human input. It stands in for a human to provide clarification, critique, instruction, or approval-like guidance, enabling uninterrupted workflow execution.
CORE Backbone — 格物致知 (Investigate to Reach Understanding): The skill's internal reasoning follows a two-phase cognitive framework. 格物 (investigate) gathers context, parses messages, and considers three perspectives (supporting/opposing/neutral); 致知 (reach understanding) weighs gains/losses per disposition, validates with worst-case gate, and commits to a bounded response. The framework is not exposed to callers.
Key Concepts:
- Disposition — One of 7 response postures:
answer, clarification, reframe, critique, instruction, approval, pass_through
- Instruction Units — 1–3 bounded response units per message, each with its own disposition and suggested skills
- Execution Plan — Parallel/sequential/mixed strategy for multi-unit output based on dependency analysis
- Human Shadow — Optional real-human fallback when confidence is below threshold and
human_shadow is enabled
- 工程師 (Engineer) Persona — This representative brings an engineering perspective to guidance decisions
When to Use
triggers:
- "represent human intent"
- "human representative guidance"
- "approval-like guidance"
- "guidance on behalf of the human"
not_for:
- "long-term memory retrieval or persistence"
- "knowledge pipeline orchestration (use x-ipe-assistant-knowledge-librarian-DAO)"
Input Parameters
input:
message_context:
source: "human | ai"
calling_skill: "{skill name}"
task_id: "{TASK-XXX}"
feature_id: "{FEATURE-XXX | N/A}"
workflow_name: "{name | N/A}"
downstream_context: "target agent/task context or N/A"
messages:
- content: "raw user-facing message"
preferred_dispositions: ["answer", "clarification", "reframe", "critique", "instruction", "approval", "pass_through"]
human_shadow: false
Input Initialization
<input_init>
<field name="message_context.source">
<validation>MUST be "human" or "ai". FAIL FAST with DAO_INPUT_INVALID if missing.</validation>
</field>
<field name="message_context.messages">
<validation>Non-empty array, each with non-empty content. FAIL FAST if missing.</validation>
</field>
<field name="message_context.task_id">
<validation>Non-empty TASK-{NNN} format. FAIL FAST if missing.</validation>
</field>
<field name="optional_defaults">
calling_skill: omit if not provided
feature_id: default "N/A"
workflow_name: default "N/A"
downstream_context: default "N/A"
preferred_dispositions: all supported dispositions in default order
human_shadow: default false
</field>
</input_init>
Definition of Ready
<definition_of_ready>
<checkpoint required="true">
<name>Message content provided</name>
<verification>message_context.messages contains at least one entry with non-empty content</verification>
</checkpoint>
<checkpoint required="true">
<name>Source identified</name>
<verification>message_context.source is "human" or "ai"</verification>
</checkpoint>
<checkpoint required="true">
<name>Human-shadow policy resolved</name>
<verification>human_shadow is initialized (defaults to false)</verification>
</checkpoint>
</definition_of_ready>
Execution Flow
| Phase | Step | Name | Action | Gate |
|---|
| 0 | 0.1 | 礼 — Greet | Announce identity as '道' | Greeting delivered |
| 1 | 1.1–1.2 | 格物 — Investigate | Parse + decompose + quick perspectives | Units identified with dependencies |
| 2 | 2.1 | 致知 — Reach Understanding | Per unit: match skill → select disposition → commit; then assemble execution_plan | instruction_units[] + execution_plan ready |
| 3 | 3.1 | 录 — Record | Write semantic log entry (all units) | Log written |
| 4 | 4.1 | 示 — Present | Format CLI output (all units) | Output delivered |
BLOCKING: All phases in order 0→1→2→3→4. No phase skipped. One disposition PER unit. Output always instruction_units[].
See references/dao-phases-and-output-format.md for phase definitions, 心法, and CLI output format.
Execution Procedure
<procedure name="user-representative-engineer">
<execute_dor_checks_before_starting/>
<phase_0 name="礼 — Greet">
<step_0_1>
<name>Announce Identity</name>
<action>Print: "道 · User Representative Engineer (工程師) — ready."</action>
<output>Greeting printed to CLI</output>
</step_0_1>
</phase_0>
<phase_1 name="格物 — Investigate">
<step_1_1>
<name>Parse and Decompose</name>
<action>
1. Read messages, strip noise. Produce: "The user needs: {X}."
2. IF message unclear or context missing → flag for `clarification` in Phase 2.
3. Compound check (see references/dao-phases-and-output-format.md decomposition criteria):
- Multiple unrelated instructions for DIFFERENT skills? → split into N units (max 3).
- Otherwise → 1 unit.
4. IF multiple units → mark `depends_on: []` per unit (output feeds input? same file? → dependent).
</action>
<constraints>BLOCKING: Fail `DAO_INPUT_INVALID` if message/source missing. Default 1 unit.</constraints>
<output>Need sentence + instruction units (1–3) with dependency annotations
Quick Perspectives
1. Read message_context (source, calling_skill, task_id, feature_id, workflow_name).
2. Three-voice check: **Supporting** (benefit of doubt) · **Opposing** (risk?) · **Neutral** (detached).
3. Note preferred_dispositions + constraints. Done — move to Phase 2.
Three-perspective summary (internal, brief)
Match, Decide, and Commit (per unit → then assemble)
FOR EACH unit:
1. **Match skill:** Scan `.github/skills/x-ipe-task-based-*/SKILL.md` descriptions.
Rank: strong | partial | none. Consult [references/engineering-workflow.md](.github/skills/x-ipe-assistant-user-representative-Engineer/references/engineering-workflow.md) for stage position. Keyword + engineering-next agree → high confidence. Produce suggested_skills (max 3).
2. **Select disposition:** Weigh 利/害 for each candidate (answer|clarification|reframe|critique|instruction|approval|pass_through).
Two gains → take greater. Two harms → take lesser. Verify: smallest useful intervention, bounded, reversible.
IF worst case unacceptable → fall to next candidate.
3. **Draft:** content + rationale_summary for this unit. Lock — no second-guessing.
AFTER ALL units:
4. **Assemble:** instruction_units[] in order. Confidence = min across units.
fallback_required = true ONLY if human_shadow AND confidence < threshold.
5. **Execution plan:** Group independent units into parallel batches;
dependent units into later sequential groups. Strategy: parallel | sequential | mixed.
Single unit → strategy: "sequential", groups: [[0]].
- Exactly one disposition per unit. `approval` is guidance, NOT human approval.
- Final — MUST NOT revisit after commit. execution_plan MUST reflect step 1.1 dependencies.
operation_output ready (instruction_units[] + execution_plan)
Write Semantic Log
1. semantic_task_type from calling_skill (e.g., "bug-fix" → "bug_fix").
2. Date subfolder: `x-ipe-docs/dao/{yy-mm-dd}/` (e.g., `26-03-11`). Create if missing.
3. Append ONE entry covering ALL units to `x-ipe-docs/dao/{yy-mm-dd}/decisions_made_{semantic_task_type}.md`
using [references/dao-log-format.md](.github/skills/x-ipe-assistant-user-representative-Engineer/references/dao-log-format.md).
MANDATORY. Append-only. One entry per invocation.
Log written
Format CLI Output
1. Format instruction_units[] as structured CLI output (see [references/dao-phases-and-output-format.md](.github/skills/x-ipe-assistant-user-representative-Engineer/references/dao-phases-and-output-format.md)).
2. Print to CLI. Return operation_output contract (YAML).
Structured output only. Skill reminder MANDATORY when suggested_skills non-empty.
CLI output printed + operation_output returned
Output Result
operation_output:
success: true | false
result:
instruction_units:
- disposition: "answer | clarification | reframe | critique | instruction | approval | pass_through"
content: "bounded response for this instruction unit"
rationale_summary: "brief explanation of why this disposition was chosen"
depends_on: []
suggested_skills:
- skill_name: "x-ipe-task-based-{name}"
match_strength: "strong | partial"
reason: "why this skill matches this unit"
execution_steps:
- phase: "1. Phase Name"
step: "1.1 Step Name"
execution_plan:
strategy: "parallel | sequential | mixed"
groups:
- [0]
- [1, 2]
rationale: "brief explanation of why this execution order was chosen"
confidence: 0.0
fallback_required: false
execution_strategy:
interaction_mode: "dao-represent-human-to-interact | interact-with-human | dao-represent-human-to-interact-for-questions-in-skill"
[]
Definition of Done
<definition_of_done>
<checkpoint required="true">
<name>Instruction units produced</name>
<verification>instruction_units[] has 1–3 entries, each with exactly one supported disposition</verification>
</checkpoint>
<checkpoint required="true">
<name>Bounded responses returned</name>
<verification>Each unit's content and rationale_summary are concise, no inner reasoning exposed</verification>
</checkpoint>
<checkpoint required="true">
<name>Fallback logic correct</name>
<verification>fallback_required true only when human_shadow true AND confidence below threshold</verification>
</checkpoint>
<checkpoint required="true">
<name>Execution plan produced</name>
<verification>execution_plan contains strategy + groups[] reflecting dependency analysis</>
Semantic log written
Log entry appended to x-ipe-docs/dao/{yy-mm-dd}/decisions_made_{semantic_task_type}.md
CLI output presented
Phase 4 (示) executed — structured CLI output printed for all units
Error Handling
| Error | Cause | Resolution |
|---|
DAO_INPUT_INVALID | Missing message content, missing source, or invalid source value | Provide message_context with source and at least one message with content |
DAO_DISPOSITION_UNCLEAR | Competing dispositions remain equally plausible after the backbone | Prefer clarification or pass_through, or enable human-shadow fallback |
DAO_HUMAN_SHADOW_REQUIRED | Internal confidence is below threshold while human-shadow is enabled | Route the touchpoint to a real human before irreversible action |
Future Extensions
Reserved for later versions. Do not implement persistence or recall in v1.
- Reusable Memory: A future version may add cross-task experience recall.
References
Examples
See references/examples.md for usage examples.
