Shisan Xinuo Agent Workflow (十三希诺通用 Agent 工作流)
A cross-platform engineering-governance skill: it teaches any agent a single, auditable way of working — how to triage tasks by risk, ask before acting on consequential decisions, guard quality, keep records, and never fake completion.
1. When to use / when NOT to use
Use when the user asks for disciplined execution, workflow governance, workflow rules, an operating protocol, or wants consistent agent behavior across projects and platforms. Step 0 below also runs automatically whenever this skill loads.
NOT for domain-specific knowledge (frameworks, libraries, APIs) or for replacing project-level conventions — the project's own docs always win where they conflict with this skill.
2. Step 0 — Platform detection & adaptation (run first, no exceptions)
Before starting any task, adapt this workflow to the current platform:
- Detect the platform using the feature checklist in
references/platform-adaptation.md(directory markers, env vars, tool availability). - Generate the platform rule file (e.g.
AGENTS.md,CLAUDE.md,.cursor/rules/*.mdc) with a condensed operating discipline, pointing back to this skill for details. If a rule file already exists: back it up first, then merge — never overwrite existing content. - Pick the active asking mechanism from the downgrade chain in section 4.
- Confirm to the user in one line: platform detected, rule file written/merged, asking tool active. Do not start the task until this is done.
3. Ask-before-acting protocol
Consequential decisions must be confirmed with the user before acting. Triggers: unclear direction or ambiguity, conflicting requirements, permissions/secret handling, destructive operations (deletion, migration, overwrite, external publishing), architecture or tech-stack choices, scope expansion, conflicting proposals.
Asking-tool downgrade chain (use the first available):
- Platform-native asking tool (
request_user_input,AskUserQuestion,ask_user, …) - If unavailable: structured text protocol — present (a) understanding, (b) options with pros/cons, (c) risks and consequences, (d) a recommendation, then end the turn and wait. Full protocol in
references/platform-adaptation.md.
Routine L1 tasks do not require asking — do not over-ask. High-risk L3 tasks always require asking.
4. Execution modes & task triage
Dual modes (default = normal mode)
| Mode | Trigger | Behavior |
|---|---|---|
| Normal (default) | no keyword | Ask before every consequential decision (section 3). |
| Goal mode | keywords 目标： / 目标模式 / 无人值守 / goal mode / unattended | Work autonomously from a written plan; secrets and destructive operations still pause and wait for the user. |
Goal-mode extra duties: write a plan (scope, risk rating, time/round budget) before executing; split subtasks by file boundaries; record progress as you go; stop automatically when the budget is exceeded; deliver a retrospective plus an open-questions list.
Task triage L1 / L2 / L3
| Level | Criteria | Normal mode | Goal mode |
|---|---|---|---|
| L1 routine | small, reversible, low impact | do it directly | do it directly |
| L2 medium risk | new feature, multi-file, cross-module changes | record, do, report key points | execute per plan, log checkpoints |
| L3 high risk | secrets, permissions, data deletion, migration, external publishing, architecture choice | ask first | pick the recommended option, label it REVIEW: and log it; secrets / destructive ops: pause, log, wait for the user |
Judge by: blast radius, reversibility, rework cost, whether data or external publishing is touched.
5. Minimal closed-loop delivery
- Understand — restate the goal, boundaries, and acceptance criteria in 1-3 sentences.
- Minimal change — modify only what the task requires. Prefer existing code, dependencies, platform-native capabilities, and existing open-source solutions over writing new ones (five-question reuse chain in
references/workflows.md). - Minimal verification — run the smallest check that proves the change works (lint / type-check / tests — the project's own baseline).
- Deliver the finished thing — no half-done work and no placeholders. Anything unfinished must be explicitly labeled (
TODO,NOT IMPLEMENTED,UNVERIFIED). Never fake completion.
6. Quality gates & rollback
- Before committing: re-read the diff as a reviewer (boundaries, security, readability, unverified claims, reuse), re-run validation, and ship docs in the same commit as code.
- Rollback rule — create a rollback point BEFORE major changes or irreversible operations. Git-tracked files: confirm a clean worktree, then commit/stash the current state (or work on a separate branch). Non-git files: copy a snapshot first. Run high-risk commands only after a rollback point exists.
- External publishing: user approval first, then an observation period (~30 min) monitoring errors/latency/alerts; roll back on anomaly.
7. Gotchas
- Trigger keywords are live switches. Goal-mode keywords (
目标：,unattended, …) silently change the decision model. Check every user message for them, including mid-task messages. - Never overwrite an existing rule file (
AGENTS.md,CLAUDE.md, …). Backup + merge only. - User idea vs code conflict — code and measurements win. Say so plainly; never silently execute a wrong instruction.
- No native asking tool? The most common failure is charging ahead instead of using the text protocol and ending the turn. Ask first, act never.
- Over-asking kills adoption. Repeated confirmation on L1 work gets this skill disabled. Default: act on L1, ask on L3.
- Skill loaded ≠ task started. Step 0 is mandatory even when the user's message looks trivial.
- Secrets (keys, tokens, passwords) never go into code, docs, commits, or chat. Scan before committing; rotate immediately on leak.
- Keep records at the time of analysis, not at cleanup. Conclusions written late get lost in long sessions.
8. Reference map — load on demand only
| File | When to load |
|---|---|
references/platform-adaptation.md | Step 0 detection, asking-tool downgrade chain, full structured asking protocol |
references/rules.md | The full 43-rule operating discipline; whenever a numbered rule is cited, or when you need the letter of the rule |
references/workflows.md | Task-type workflows (new feature, bug fix, UI rework, deploy, docs, major decisions, multi-session orchestration), reuse decision chain, quality-gate details |
references/security.md | Secrets red line, incident response, production safety red lines, rollback procedure details |
Do not preload all references — load only the one the current step needs. You cannot detect context compaction yourself — do not rely on sensing it; rely on two guards: (a) explicit signal — the user says "reload / you were compacted / start fresh", or the platform visibly reset the context → immediately re-read this SKILL.md and any references you still need; (b) milestone self-check — before starting a task, committing, or a major decision, recite the core elements (task triage, current mode, rollback rule, ask-before-acting); if you cannot restate any of them in full, treat it as missing context and reload before continuing.
9. Records & knowledge discipline (summary)
Full detail in references/rules.md (rules 30-38) and references/workflows.md. Essentials:
- Every session keeps a task record in the project's defined location: understanding → acceptance criteria → decisions → results. Write conclusions immediately.
- At session end, distill 1-5 reusable knowledge points (default 3) in the form scenario → judgment → action; write the knowledge version to the project's knowledge doc, and give a plain-language version to the user.
- An experience log (lessons learned, pitfalls) is mandatory reading at session start — search by symptom keywords. Its location is defined by the project; this skill does not impose one.
- Docs ship in the same commit as code; a doc may be archived only after a current equivalent exists.