SuperAPI AI Directory

meta-cognition

Agents & models

View repository

Updated 10-15 11:24

About this skill

Meta-Cognition

Use this skill to turn a vague request, anomaly, or project into a governed execution loop.

This skill is for judgment before action and closure after action. It is especially useful for CEO-style coordination where the main risk is not lack of tools, but wrong framing, wrong ownership, missing verification, or shallow status reporting.

Core protocol

For any non-trivial task, produce these six sections before major execution:

  1. 问题本质 / Problem Essence
  2. 责任归属 / Ownership Routing
  3. 风险等级 / Risk Gate
  4. 最小闭环 / Minimum Closure
  5. 执行动作 / Action Plan
  6. 验证与复盘 / Verification & Retro

If the user asks for a fast answer, compress the six sections into short bullets instead of skipping them.

When to apply strict mode

Use full strict mode when any of the following is true:

  • The request affects money, production systems, accounts, auth, deployments, or public output.
  • The task spans multiple agents or requires dispatch.
  • The user explicitly says "analyze first, then do", "don't rush to develop", "do a retrospective", or asks for strategy.
  • You detect stale sessions, zombie jobs, aborted runs, or cron drift that needs resolution.
  • You are about to claim a task is done and fresh verification matters.

In strict mode, do not jump from detection straight to execution. Frame → route → gate → act → verify.

Step 1 — Problem Essence

Rewrite the request into the real problem.

Answer:

  • What is the surface request?
  • What is the underlying business/operational problem?
  • What would count as success in one sentence?
  • What is still unknown?

Rules:

  • Strip hype and vague labels.
  • Prefer operational language over abstract buzzwords.
  • If the request is probably misframed, say so directly.

Step 2 — Ownership Routing

Decide who should do the work.

Answer:

  • Which agent owns the core capability?
  • Which supporting agents, if any, should assist?
  • Should the CEO/main session coordinate only, or also execute?
  • Can independent sub-tasks run in parallel?

Rules:

  • CEO should prefer routing and quality control over doing specialized execution.
  • Route by core capability, not by convenience.
  • If a task crosses functions, split it into separate deliverables.

For detailed routing heuristics, read references/ownership-routing.md.

Step 3 — Risk Gate

Assign a risk level before acting.

Use three levels:

  • P0 / High risk — money movement, prod changes, auth, data loss, public posting, destructive actions
  • P1 / Medium risk — important but reversible config/code/content changes
  • P2 / Low risk — read-only analysis, drafts, internal notes, low-impact summaries

For every task, state:

  • Risk level
  • Main failure mode
  • Whether user confirmation is required
  • What should be protected from overreach

Rules:

  • For high-risk work, default conservative.
  • “Can do” is not enough; ask whether it should be done now.

Step 4 — Minimum Closure

Define the smallest end-to-end result that counts as actually finished.

Examples:

  • Not “cron checked”, but “cron updated, effective model confirmed, drift explained”.
  • Not “agent notified”, but “agent received, responded, and delivered or was escalated”.
  • Not “API built”, but “fresh tests passed and real request returned required fields”.

State:

  • Deliverable
  • Verification method
  • Evidence expected
  • What remains out of scope

For closure patterns, read references/closure-loop.md.

Step 5 — Action Plan

Only now decide what to do.

Use one of four modes:

  • Act now — enough clarity, low/moderate risk, tools available
  • Dispatch — another agent should own execution
  • Ask first — critical missing context or approval needed
  • Defer — low ROI or blocked

When dispatching:

  • Give a clear objective
  • Specify output location/format
  • Specify how completion should be reported
  • Define timeout/escalation expectations

If useful, use this structure:

  • Objective
  • Owner
  • Inputs
  • Output
  • Deadline / next check
  • Escalation path

Step 6 — Verification & Retro

Before saying “done”, check:

  • What was verified just now?
  • What evidence supports the claim?
  • What is still assumed rather than proven?
  • What lesson should become memory, SOP, skill, or cron?

Never collapse “looks good” into “done”.

If the task produced a reusable lesson, explicitly propose one of:

  • Update memory
  • Update skill
  • Update SOP/checklist
  • Update cron/monitoring
  • No durable lesson

For retro extraction prompts, read references/retro-prompts.md.

Default output template

Use this template unless the user asks for a different format:

## 1. 问题本质
- 表层需求:
- 真问题:
- 成功标准:
- 未知项:

## 2. 责任归属
- 主负责:
- 协同:
- CEO 是否亲自执行:
- 是否并行:

## 3. 风险等级
- Level:P0 / P1 / P2
- 失败模式:
- 是否需确认:

## 4. 最小闭环
- 交付物:
- 验证方式:
- 完成证据:
- 当前不做:

## 5. 执行动作
- 模式:Act / Dispatch / Ask / Defer
- 下一步:

## 6. 验证与复盘
- 已验证:
- 未验证:
- 可沉淀项:

Anti-patterns

Do not do these:

  • Jump straight into execution when the request is still ambiguous.
  • Treat status reporting as problem resolution.
  • Keep work in the CEO session when a specialist agent should own it.
  • Claim completion without fresh evidence.
  • Inflate low-confidence guesses into decisions.
  • Leave anomalies as “known issue” without owner, next step, or closure condition.

Trigger phrases

This skill is a strong match for prompts like:

High-frequency Chinese triggers

  • "Analyze first, then do" / "Don't start yet" / "Don't rush to write code"
  • "Assess first" / "Decide the plan first" / "Think it through before doing it"
  • "Help me break this down" / "How do we close out this matter" / "Give me a minimum closure"
  • "Who should this be assigned to" / "Who's responsible" / "You coordinate this" / "Pull in multiple agents to do it together"
  • "CEO directive" / "CEO dispatch" / "Legion task" / "Help me schedule this" / "Assign it and track it to closure"
  • "How should anomalies be handled" / "Why did it blow up again" / "Why was it detected by monitoring but not resolved" / "Do a retrospective on this incident" / "Give me a retrospective"
  • "Don't just report status" / "I want results, not process" / "Give me a version that can be accepted"
  • "Look at risk first" / "Is it worth doing" / "Should we do it now" / "Assess ROI / risk first"
  • "Help me set owner / deadline / acceptance criteria" / "How do we push this forward" / "Who does the next step"

English triggers

  • “analyze first, then do” / “think first” / “frame this before acting”
  • “who should own this?” / “route this to the right agent” / “orchestrate this”
  • “give me a closure plan” / “what is the minimum end-to-end closure?”
  • “don’t just give status, close the loop” / “turn this into a verified outcome”
  • “postmortem this” / “retro this” / “why did this fail?”
  • “dispatch this across agents” / “multi-agent coordination” / “CEO delegation”

Group chat / command-style phrasing

  • "Don't do it yet, assess first"
  • "Produce an analysis framework before executing"
  • "Go investigate clearly and then report back"
  • "First give conclusions, risks, owner, next steps"
  • "Track it to closure, don't just urge action"
  • "Do a retrospective on this and distill SOP / memory / skill"

Resource map

Read bundled references only when needed:

  • references/ownership-routing.md — choose the right agent and decide parallelism
  • references/closure-loop.md — convert detection into verifiable closure
  • references/retro-prompts.md — extract durable lessons without noise