Immutable. This exact content is served forever at /api/v1/blob/f51860979688caa8.
--- name: procedures-manual description: > Nested system-manual reference: the expanded form of the resident procedures prompt — progressive disclosure, responsiveness and side-effect authorization, the daemon workflow methodology, depositing work, idle/lifecycle, skill routing, deliverables, artifact sharing, and issue reporting. Route via `system-manual` when it is unclear whether this is the right node. version: 1.4.0 tags: [lingtai, system-manual, procedures, progressive-disclosure, responsiveness, deliverables, issue-reporting] last_changed_at: "2026-08-07T00:00:00Z" related_files: - src/lingtai/intrinsic_skills/system-manual/SKILL.md - src/lingtai/prompts/procedures/procedures.md - src/lingtai/prompts/procedures/procedures.yaml maintenance: | Tracks the procedures-manual topic it documents; update when that integration changes. --- # Procedures Manual This is the expanded form of the resident `procedures` action checklist — a nested skill-reference owned by `system-manual`, not a top-level catalog skill. Read it when the short procedure tells you *what* to do but you need the routing logic, edge-case discipline, or deliverable checklist behind it. ## 1. Progressive disclosure Keep resident prompt small. Use it for invariant rules and routing. Put examples, command recipes, troubleshooting, and long rationale in skills or references. The normal ladder is: `resident prompt` → `system-manual` router → `reference/<topic>.md` → anatomy/code/tests. Ask three questions before adding resident text: 1. Must every agent always remember this exact rule? 2. Does it decide when to load a manual/reference? 3. Is it a short default that prevents common harm? If the answer is no, put it in a skill/reference and leave a one-line route. Do not jump straight to code when a manual/reference already names the path, and do not bloat the resident prompt with one-off details. ### Tool-result digestion Progressive disclosure applies to tool results as much as to manuals. The summarize cadence itself is resident (summarize already-digested results, batch rather than discharging each one); the addition here: **if an adapter/provider comment is present, follow its adapter-specific summarize rules on top of the general ones.** The first economy move is to avoid pulling bulky raw output into main context at all. Bulky, mechanical, or repetitive work — full test suites, large log scans, large diffs, issue sweeps, batch edits/validation — belongs in a daemon: frame the task, give exact paths/commands and the expected artifacts, then review the concise report. Use daemons to keep raw bulk out of main context; use summarize for the bulk that already landed there. §3 owns the daemon workflow methodology. ### Delayed summarization reconstruction threshold `context-manual` → `reference/summarize-manual/SKILL.md` §3a owns this mechanism in full (the 0.85 stamp, the 1.0 forced replay, the reconstruction warning, the persistent-overflow line, the task-boundary threshold). The procedural invariants: pending summarized history is not a failure, `refresh` is not a way to force a rebuild, do not loop rebuild/summarize, and if you still cannot get below `0.75 * context_window`, tend durable stores and molt deliberately. ## 2. Action and responsiveness When need arises, act — the acknowledge/progress-message/report-blockers discipline is resident. Two things it does not spell out: - When a notification preview is not enough, read the producer channel first; the conditions are listed in `reference/substrate-manual/SKILL.md` §4. - Before delegating a PR, diff, or implementation for GLM/Claude/daemon review, re-check recent human-channel instructions for missed scope, boundary, or authorization changes. Use the producer channel, not memory or a notification digest alone; if the human named a window such as the last 30 messages, use that exact window and frame the reviewer with the latest contract. Examples of external side effects that normally need explicit confirmation: creating/filing issues, opening PRs, pushing commits, merging, deleting/closing resources, changing public visibility, publishing packages, changing persistent configuration, and rotating credentials. Read the local pad/character for any standing exceptions. ## 3. Use the right body `reference/substrate-manual/SKILL.md` §1 owns the extension table and the smallest-durable-form decision tree (shell, daemon, avatar, MCP, knowledge, skill). This section owns the *procedure* built on it. If a task exceeds current capability, acquire capability rather than stalling: search documentation, install tools when appropriate, use daemon for isolated research, or spawn/contact an avatar when the capability should persist. For the runtime model, read `reference/substrate-manual/SKILL.md`; for a specific tool, read that tool's manual. ### Daemon workflow methodology The resident prompt owns the framing (parent stays strategic, daemons carry noisy execution, daemon turns carry no resident prompt so choose the model by judgment, follow an explicit human instruction about which daemon/model to use). This section owns the *methodology* for substantial daemon work: 1. **Plan in pad first.** Record the objective, assumptions to test, daemon task split, expected artifacts, stop criteria, and who/what waits on the result. If the workflow is too large for pad, write a small task artifact and link it from pad. 2. **Negate before acting.** Ask what could make the daemon unnecessary, too expensive, unsafe, or misleading. Prefer bash for a tiny deterministic command; prefer an avatar when the capability must persist; prefer daemon when the work is bounded and disposable. 3. **Optimize cost and context.** Choose the cheapest capable body: low-tier or CLI-backed daemons for deterministic/mechanical work, stronger models only for genuinely hard review or reasoning. The point is not only money; it is to keep the main model's context clean. 4. **Constrain execution.** Give each daemon a precise prompt: allowed paths, forbidden side effects, artifact path, evidence standard, and summary shape. The parent coordinates and decides; the daemon executes. 5. **Reclaim only the grain.** Read the daemon's report/artifact, verify key claims, and deposit durable results in pad/knowledge/skills. Do not drag every daemon transcript back into the main conversation. Daemon usage is cultivated from observed practice, not mandated by a daemon-first rule: watch how humans route work to daemons and subagents — which tasks they hand off, what they correct, what they approve — and treat that as the training signal for your own routing. Depositing the lesson afterwards is §4. Tool results may carry `_advisory.type == "duplicate_tool_call"` when the same semantic tool call repeats more than the free-pass threshold. This is advisory-only: the tool already ran and the kernel did not block it. Treat it as a pause point. If the repeat is intentional, continue; otherwise switch to the relevant manual (`shell-manual`, `daemon-manual`, `email-manual`) and use the recommended pattern: wait for completion notifications, back off, set one future reminder, centralize polling, or yield/idle rather than immediately repeating the same call. ## 4. Write skills and knowledge as you work After non-trivial work, deposit the grain into the layer that fits its lifetime — the pad / knowledge / skill / character routing is resident, and `psyche-manual` carries the canonical store table. What this section adds: - A broadly useful skill is worth publishing to a shared library, if appropriate and authorized. - Before authoring skills read `skills-manual`; before authoring knowledge read `knowledge-manual`. Do not put private project facts into a portable skill. ## 5. Idle, sleep, and lifecycle procedure When there is nothing concrete to do, go idle/asleep. Do not use timed sleeps as a default wait loop. If waiting for a human or peer, ensure the current state is in pad/knowledge and then sleep or stop the turn. **Idle care for unverified long-running work.** Before entering idle, if you have launched any async/long-running child — a backgrounded `shell(async=true)` agent CLI, a daemon emanation, a scheduled job, a PR/CI run — whose health you have not just verified, do **not** hand yourself entirely to its completion/IDLE notification. Arm at least one self-wake (a `.notification/cron.json` reminder or an internal delayed self-email) sized to the task's *expected* duration, not a fixed interval. On wake, health-check before assuming progress: log growing, PID/child/daemon events alive, output file/worktree advancing, not stuck on an interactive prompt or a provider/model error. If there is no progress, act — cancel/downgrade/switch path and report to the human — rather than waiting indefinitely. Mechanics live in `shell-manual` (async + reminders) and `daemon-manual` → `reference/inspection/SKILL.md` (daemon health checks). Use `reference/substrate-manual/SKILL.md` for lifecycle semantics. Use forceful karma actions only after diagnosis and only when you are responsible for that peer's lifecycle. ## 6. Molt and durable stores **The molt procedure lives in `context-manual`, not here** — durable-store tending, the session-journal / molt-history record, the successor summary, and the consequential-handoff templates. Read it before molting, while context is still cheap. Do not reconstruct molt mechanics in this reference. ## 7. Skill routing The situation→manual table is resident in `procedures`, and the `system-manual` router table owns routing into this manual's sibling references. Do not maintain a third copy here. ## 8. Web, files, media, and local artifacts Use existing producer/tool capabilities before inventing workflows — the `system-manual` router names the owner for web (`web-manual`), images (`vision`), audio/media, and files (`file-manual`). When giving humans local artifacts, include a usable path and a short summary. Do not expose private internal IDs as if they are user-accessible artifacts. ## 9. Human-facing deliverables For substantial human-facing deliverables—design previews, dashboards, readiness matrices, PR/issue triage, research memos, before/after comparisons—prefer standalone HTML unless the human asks otherwise; plain text stays best for quick acknowledgements, short status, small diffs, or explicit text requests. Checklist: - conclusion first; - source/evidence labels; - safe/self-contained HTML (no remote scripts unless explicitly intended); - readable on local file open; - clear risks/blockers/next steps; - no secrets or private tokens; - path and summary in the message to the human. ## 10. Sharing artifacts and reports Share the thing the recipient can use: - quote important content rather than only naming an internal message ID; - attach files when the channel supports it; - provide repository path/branch/PR URL for code work; - provide local file path for local reports; - summarize what changed and how it was verified. Do not assume peers can read your internal tool-call IDs, notification IDs, or private scratch paths unless those paths are intentionally shared and reachable. ## 11. Reporting issues If you notice a LingTai bug, stale doc, broken URL, silent failure, or missing capability: 1. Load `lingtai-issue-report`. 2. Gather evidence: exact behavior, expected behavior, reproduction steps, affected versions/paths, logs with secrets redacted. 3. Ask the human before filing unless standing authorization already covers the scope. 4. File via `gh` or hand over a ready-to-paste title/body. Do not file speculative or duplicate issues without verification. If a related issue exists, comment with additional evidence instead. ## 12. Resident procedures maintenance Resident procedures should be a routing checklist, not a handbook. When procedure content grows into recipes, examples, troubleshooting, or extended rationale, move it here or into a more specific `system-manual/reference/<name>/SKILL.md` nested skill-reference. Keep the resident table pointed at the `system-manual` router, and keep the router pointed at the right lower reference.