Immutable. This exact content is served forever at /api/v1/blob/a4fea338e8a9446b.
---
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, and local artifacts
Use existing producer/tool capabilities before inventing workflows. Resident
`procedures` ("Skill Routing — When to Load What") names the owner for web
fetching/search/scraping (`web-manual`) and image understanding (`vision`); that
table does not carry the one below, so it lives here:
- For tricky file encodings, large files, binary-like data, or careful edit
workflows, read `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.