Mark393295827/third-brain-v7-skills

# Agent Teams Command — 安德智能体集群指挥系统 (V8.1)

<skill_contract>
  <input>A mission with independently ownable workstreams, time SLA requirements, pre-flight task list, token budget, interfaces, permissions, and an integration owner.</input>
  <output>An isolated worker fleet (5 to 100+ agents), typed IPC ledger, pre-allocated token ledger, serial integration, cleanup, and evidence receipts.</output>
  <done>Pre-flight task list is 100% reconciled, integrated artifacts pass mission checks, token consumption is within TCLR boundaries, and cleanup gates pass.</done>
  <non_goals>Parallelism without a task list, unbounded token burn, overlapping writers, or worker self-certification.</non_goals>

Strategic intent and final integration remain serial; owned execution runs in dynamically scaled parallel squadrons (5, 10, 50, 100+ agents). Use the Ender lens for commander intent and squad autonomy, Palantir for operational objects/actions, and von Neumann for executable process architecture. Detailed patterns: `references/ender-palantir-command-patterns.md`; examples: `references/classic-campaigns.md`.

## Usage Template

Provide: mission, time SLA, task list candidate, workstreams, scaling tier (5/10/50/100+), dependencies, acceptance criteria, token budget (ETC limit), permissions, runtime capabilities, and integration owner.

# Agentic Engineering

<skill_contract>
  <input>An engineering objective, inspectable repository or workflow, acceptance criteria, permissions, risk, and state location.</input>
  <output>The smallest sufficient model-native process with bounded autonomy, evals, recovery, and verified write-back.</output>
  <done>Fresh task and adoption evidence support the observable end state without crossing authority boundaries.</done>
  <non_goals>Agent complexity for its own sake, premature multi-agent topology, or unverified knowledge promotion.</non_goals>

An agent is a stateful engineering process, not a prompt. Its quality ceiling is the combination of objective, context, tools, taste/evaluation, permissions, recovery, and feedback latency.

## Usage Template

Provide: engineering objective, repository/workflow, users, acceptance criteria, constraints, permissions, risk, current evidence, and durable state location.

# AI Six Sigma Property OS

<skill_contract>
  <input>Named property-service workflow, actors, evidence, CTQs, approval boundaries, and MVP constraints.</input>
  <output>A bounded ontology, DMAIC control plan, agent roles, gates, metrics, and rollback-ready MVP design.</output>
  <done>Every proposed state transition and CTQ has an owner, evidence source, verifier, approval gate, and control receipt.</done>
  <non_goals>Full ERP replacement, autonomous safety or pricing decisions, and automation of undefined processes.</non_goals>

Ontology defines the operating world; bounded agents execute and audit; DMAIC improves rules from work-order evidence. Design the management system before software scope. Load `references/property-control-model.md` for the baseline ontology, CTQs, and state machine.

## Usage Template

Provide: business type, stage, first workflow, current process/data, service standards, approval boundaries, failure history, and MVP budget. Optional: table schemas and sample work orders.

# Anthropic OS

<skill_contract>
  <input>One owned work system with its workflow, users, traces, permissions, metrics, constraints, and review horizon.</input>
  <output>A supervised operating-system redesign with one bounded experiment, control gates, cadence, and rollback.</output>
  <done>The selected practice has a baseline, hypothesis, owner, metric, guardrail, budget, stop rule, and review receipt.</done>
  <non_goals>Extreme productivity claims, surveillance, automatic policy evolution, or cadence without supporting context and capability.</non_goals>

Redesign one work system as a supervised learning loop. Plasticity means practices may change from evidence; competition means alternatives contend; constraint means attention, time, permissions, and review bandwidth shape the design. Load `references/operating-system-playbook.md` for diagnostics and artifacts.

## Usage Template

Provide: system boundary, owner, desired outcome, users, current workflow, local metrics, traces/data, permissions, failure history, review capacity, and horizon.

# Behavior Design

<skill_contract>
  <input>Actor, desired outcome, current behavior, context, constraints, baseline evidence, and review horizon.</input>
  <output>An agency-preserving HAS behavior system with cues, effort levels, SOP, measures, recovery, and review cadence.</output>
  <done>The target behavior is observable, runnable on a low-motivation day, evidenced, and assigned one review owner.</done>
  <non_goals>Coercion, unsupported identity claims, vague motivation advice, or optimizing lagging outcomes without behaviors.</non_goals>

Convert an outcome into the smallest observable behavior system that can survive low-motivation days. Preserve agency; optimize the environment before blaming the actor.

## Usage Template

Provide: desired outcome, actor, context, current behavior, constraints, review horizon, and available evidence. Optional: failed attempts and environmental cues.

# Cognitive Compile

<skill_contract>
  <input>Source-grounded material, original question, learning or decision goal, audience, and destination.</input>
  <output>An eight-part evidence-aware mental model separating facts, mechanisms, conflicts, hypotheses, decisions, and action.</output>
  <done>Each material claim retains provenance and uncertainty, and one bounded next action answers the original question.</done>
  <non_goals>Inventing missing claims, erasing contradictions or provenance, or treating interpretation as source fact.</non_goals>

Compile information into a decision-ready mental model. Compression must preserve provenance, uncertainty, contradiction, and the original question.

## Usage Template

Provide: source material, original question, intended decision or learning goal, and preferred destination. Optional: existing wiki concepts to compare.

# Context Manager

<skill_contract>
  <input>An active objective, runtime context limits, decision-critical state, evidence, budgets, and durable storage.</input>
  <output>A bounded context manifest, checkpoint, compaction decision, and capability-routing receipt.</output>
  <done>The next decision can be resumed without losing constraints, permissions, provenance, or failure history.</done>
  <non_goals>Task orchestration, vendor-specific routing, hidden truncation, or retaining history that cannot change a decision.</non_goals>

Treat context as RAM, durable storage as disk, and tools as retrieval. Pay only for information that changes the next decision or prevents an execution error.

## Usage Template

Provide: objective, phase, runtime context limit, token/cost budget, active constraints, current evidence, durable state location, and expected next decisions.

# Creativity Engine

<skill_contract>
  <input>Defined problem, target user, desired change, constraints, prior attempts, and experiment budget.</input>
  <output>Three non-equivalent options with scored mechanisms and falsifiable minimum experiments.</output>
  <done>Each selected option has a hypothesis, smallest artifact, participant, threshold, budget, stop rule, and failure learning.</done>
  <non_goals>Unbounded brainstorming, novelty without utility, polished prose before diversity, or presenting ideas as validated demand.</non_goals>

Create option value by combining mechanisms, constraints, and analogies, then convert the strongest options into minimum experiments.

## Usage Template

Provide: problem, target user, desired change, constraints, existing attempts, and experiment budget. Optional: domains or concepts to combine.

# Daily OKR

<skill_contract>
  <input>Date, one priority objective, available time, active project, current inputs, and prior-day evidence.</input>
  <output>A seven-KR daily cycle linking input, cognition, wiki, behavior, creativity, output, and feedback.</output>
  <done>Each claimed KR has a durable receipt, and today's feedback changes one explicit next-day action or knowledge state.</done>
  <non_goals>Seven unrelated priorities, invented completion, activity counting without evidence, or treating scheduled notes as execution.</non_goals>

Run one daily objective through seven linked Key Results. The cycle compounds only when evidence from today changes tomorrow's behavior or knowledge state.

## Usage Template

Provide: date, one objective, available time, active project, knowledge inputs, and yesterday's evidence. Optional: a scheduled knowledge-loop note; treat it as input, not proof of execution.

# Deep Research

<skill_contract>
  <input>Decision-relevant question, audience, scope, recency, source and privacy boundaries, budget, and required deliverable.</input>
  <output>An answer-first synthesis with source and claim ledgers, citations, contradictions, uncertainty, and durable handoff.</output>
  <done>Decision-critical claims are traceable and adversarially checked, unresolved gaps are explicit, and the stop rule is met.</done>
  <non_goals>Link collection, uncited material claims, privacy leakage, exhaustive search, or autonomous high-impact experiments.</non_goals>

Research is an evidence loop, not a volume contest. Define the decision, gather the minimum diverse evidence, maintain source and claim ledgers, attack the synthesis, then stop when additional search no longer changes the answer.

## Usage Template

Provide: research question, audience/decision, scope, recency, allowed/excluded sources, privacy boundary, budget, output format, and wiki destination if durable. Load `references/research-ledgers.md` for ledger schemas.

# Graph Engineering

<skill_contract>
  <input>A dependency-heavy objective with candidate nodes, data schemas, owners, effects, verifiers, joins, budgets, and durable state paths.</input>
  <output>A validated static DAG contract with typed edges, explicit joins, node-local recovery, and graph-level receipts.</output>
  <done>Static invariants and terminal acceptance checks pass with fresh node, join, budget, permission, and state evidence.</done>
  <non_goals>Temporal loop design, worker-team command, runtime-kernel implementation, dynamic graphs, or universal parallelism.</non_goals>

Use Graph Engineering for dependency width. Use `loop-engineering` for repeated
execution through time, `agent-teams-command` for process ownership and IPC,
and `harness-engineering` for scheduler, permission, lease, and observability
infrastructure. A graph node may contain a bounded Loop or Agent Team.

## Usage Template

# Harness Engineering

<skill_contract>
  <input>An agent workflow, runtime environment, tools, data sensitivity, effects, cadence, risk, and operator constraints.</input>
  <output>An auditable runtime kernel with scoped permissions, scheduling, observability, recovery, and eval controls.</output>
  <done>An end-to-end trace and failure-path tests prove bounded, replayable, recoverable delegated action.</done>
  <non_goals>Business-task decomposition, prompt-only safety, broad credentials, or unbounded scheduled autonomy.</non_goals>

Treat the harness as the kernel around an LLM OS: context is RAM, durable state is disk, tools are system calls, skills are programs, the scheduler is control, and evals are verifiers. Load `references/runtime-control-patterns.md` for matrices and schemas. Start guarded automation from `references/runtime-envelope-example.json` and validate it with `scripts/validate_runtime_envelope.py --strict`.

## Usage Template

Provide: workflow, users, agent roles, environment, tools/connections, data sensitivity, delegated actions, cadence, throughput/SLA, failure history, and risk tolerance.

# Knowledge Operations

<skill_contract>
  <input>Vault root, operation, scope, canonical-store rules, permissions, destination, and execution budget.</input>
  <output>Verified classification, retrieval, deduplication, synchronization, audit, or governed promotion changes with receipts.</output>
  <done>Canonical Markdown remains authoritative, provenance and immutability are preserved, and representative checks pass.</done>
  <non_goals>Using vectors as canonical storage, silent provenance merges, automatic semantic rewrites, or one-signal rule promotion.</non_goals>

Operate the wiki as durable disk and governance layer. Markdown pages hold understanding and provenance; indexes, memory, vectors, and dashboards are replaceable access paths.

## Usage Template

Provide: vault root, operation (`organize`, `deduplicate`, `retrieve`, `sync`, `audit`, `promote`), scope, destination, permissions, and budget. Load `references/storage-governance.md` only when designing layers or promotion queues.

# Loop Engineering

<skill_contract>
  <input>A repeatable task with inspectable state, finite budgets, permissions, and an independent verifier.</input>
  <output>A validated Trigger -> Execute -> Verify -> State contract plus resumable run receipts.</output>
  <done>The declared metric or stop condition is supported by fresh validator and verifier evidence.</done>
  <non_goals>Dependency-graph orchestration, unbounded autonomy, or self-certified completion.</non_goals>

Build loops only when repeated execution creates evidence. Every loop needs admission, a validated contract, durable state, independent evaluation, bounded retries, stop/recovery rules, and a final receipt.

## Usage Template

Provide: objective, trigger, scope/non-goals, inputs, state/artifact paths, metric, verifier, permissions, budgets, stop condition, recovery, and write-back. See `references/ci-repair-loop-example.md` for a worked contract.

# Project Flow Ops

<skill_contract>
  <input>Project objective, tasks, owners, dependencies, budgets, artifacts, current states, and definitions of done.</input>
  <output>A WIP-limited project state with ranked work, explicit blockers, bounded actions, and verified closure receipts.</output>
  <done>Every active item has one owner and observable artifact, and completion is backed by its named fresh verification.</done>
  <non_goals>Hidden WIP, duplicate ownership, status by intuition, backlog accumulation, or completion without evidence.</non_goals>

Maintain a small, inspectable project state machine: `BACKLOG -> ACTIVE -> BLOCKED | COMPLETED`. Optimize flow and verified outcomes, not task volume.

## Usage Template

Provide: project objective, current tasks, owners, dependencies, time budget, artifacts, and definition of done. Optional: prior review receipts.

# Session Learn

<skill_contract>
  <input>Completed session objective, actions, artifacts, verification receipts, errors, decisions, and destination paths.</input>
  <output>Deduplicated durable deltas for concepts, entities, corrections, patterns, ideas, decisions, and gaps.</output>
  <done>Each retained delta is formatted, linked, logged, provenance-preserving, and paired with a traceable next action when unresolved.</done>
  <non_goals>Automatic-capture claims without a hook, raw transcript storage, conversational filler, or immutable-source edits.</non_goals>

Close a session by extracting only reusable deltas. Invocation must be explicit or performed by a verified external hook; this skill never claims it ran automatically.

## Usage Template

Provide: session objective, actions, outputs, verification receipts, errors, decisions, and destination paths. Optional: existing notes for deduplication.

# Startup Evaluation

<skill_contract>
  <input>Company, stage, evaluation decision, customer evidence, traction, economics, team, runway, terms, and risks.</input>
  <output>An evidence-weighted health, venture-suitability, and financing assessment with one top constraint and cheapest test.</output>
  <done>Every score and verdict traces to evidence, fatal risks remain visible, and the next test has owner, threshold, budget, and stop.</done>
  <non_goals>Investment advice by narrative, averaging away fatal risk, or treating market size, conviction, or pitch quality as demand.</non_goals>

Evaluate the company the evidence supports, not the story it tells. Distinguish business health, venture suitability, and financing readiness; they are different decisions.

## Usage Template

Provide: company, stage, startup type, evaluation decision, customer, problem, product, traction, team, economics, runway, round terms, and known risks. Use the rubric in `references/evaluation-rubric.md` when scoring is requested.

# Verify Before Claim

<skill_contract>
  <input>One falsifiable claim, its artifact or system, risk, expected result, permissions, and available checks.</input>
  <output>A scoped claim decision with fresh evidence, residual risk, approval, and rollback status.</output>
  <done>The cheapest direct check after the final material change supports the exact allowed wording.</done>
  <non_goals>Producing the artifact, inferring success from effort, or widening a claim beyond checked evidence.</non_goals>

No evidence, no claim. Match the check to the exact claim, use fresh evidence, and keep execution authority separate from approval authority for consequential actions.

## Usage Template

Provide: proposed claim, artifact or system, risk level, available checks, expected result, permissions, and rollback path.

# Wiki Ingest

<skill_contract>
  <input>Accessible PDF, URL, transcript, clipping, or note plus vault root, topic, provenance, permissions, and lifecycle context.</input>
  <output>Immutable source evidence, linked concept and entity updates, navigation and lifecycle changes, and a verified ingest receipt.</output>
  <done>Touched files pass source, link, block-ref, frontmatter, lifecycle, understanding, and read-after-write checks.</done>
  <non_goals>Fabricated provenance, source mutation, raw-summary dumping, unsupported rule promotion, or unverified completion.</non_goals>

Use STOW: **Source -> Transform -> Organize -> Write-back**. The source is evidence, the concept page is current understanding, and the log is the receipt. Load `references/stow-contract.md` for schemas and lifecycle details.

## Usage Template

Provide: source path/URL/note, vault root, intended topic, permissions, and whether the item came from a clipping queue. Optional: path config, prior canonical source, and desired behavior/skill candidate.

# Wiki Lint

<skill_contract>
  <input>Vault root, path configuration, audit scope, exclusions, prior baseline, and explicit repair authorization if any.</input>
  <output>A reproducible, severity-ranked wiki health report with file-level evidence, debt queues, and bounded repair proposals.</output>
  <done>All twelve checks record scope and receipts, findings are reproducible, and report-only mode leaves content unchanged.</done>
  <non_goals>Silent deletion, immutable-source mutation, unapproved repair, semantic rewrite, or health claims without scan evidence.</non_goals>

Audit the wiki as a governed knowledge graph. Report prioritized, reproducible findings; make no content mutation unless separately authorized.

## Usage Template

Provide: vault root, optional path config, audit scope, prior report, and whether repairs are authorized. Default to report-only.

# Workflow Audit

<skill_contract>
  <input>Bounded manual notes, prior-session evidence, or interview answers describing work, repetition, decisions, and constraints.</input>
  <output>A deterministic audit with mode, evidence-bounded candidates, skill/automation/loop decisions, permissions, and a typed handoff.</output>
  <done>Every recommendation points to supplied evidence, remains within the input bound, and has an explicit supervised promotion decision.</done>
  <non_goals>Editing skills, changing schedules, mutating Vault state, inventing metrics, or executing an unapproved external action.</non_goals>

## Usage Template

Provide: objective, evidence source, mode (`manual`, `session`, or `interview`), size bound, candidate limit, operator/approval owner, and desired handoff.

## Workflow