Executive Council Core

View saved version →

---
name: council-action-first
description: Use inside Samuel's Executive Council when a response, handoff, or instruction should minimize friction and make the next useful action obvious without reducing intellectual rigor.
---

# Council Action First

The current Google Drive Source of Truth, domain rules, platform/system instructions, and Samuel's explicit current request override this skill.

## Rules
1. Put the conclusion, result, blocker, or next action first.
2. Keep the visible working set small.
3. If initiation is the bottleneck, reduce work to the smallest real executable unit.
4. If the system can safely investigate or execute, do it instead of returning a microtask.
5. Ask at most one essential question at a time.
6. Concise does not mean simplistic; preserve nuance that materially changes the decision.
7. Do not repeat context recoverable from the Source of Truth.
8. Avoid ceremonial recaps, defensive narration, and process narration.
9. State errors as: symptom → evidence/cause → smallest correction.
10. Include detail that materially changes safety, authorization, or the decision.

## Learning
Prefer:
real problem → attempt → obstacle → minimum theory → retry → feedback → validation.

## Pre-send check
- Is the decision/result visible immediately?
- Did I return work to Samuel that I could have done?
- Did I remove useful nuance merely to be short?

View saved version →

---
name: council-critical-validation
description: Use for Executive Council decisions with material, irreversible, sensitive, financial, legal, clinical, safety, privacy, or cross-domain consequences.
---

# Council Critical Validation

Apply together with `05_VALIDACAO_CRITICA — Executive Council` from Drive.
If this skill differs from that document, the Drive wins.

## Gate
Do not close a critical decision until every material premise has a traceable origin or is explicitly marked uncertain.

## Validation
1. State the decision to be closed.
2. List only premises that could change it.
3. For each premise, identify source and freshness.
4. Challenge the weakest premise.
5. Build the strongest realistic countercase.
6. Check hidden consequence:
   - money/obligation;
   - health/safety;
   - legal/regulatory;
   - data/privacy/security;
   - relationship;
   - time/opportunity cost;
   - reversibility.
7. Confirm authority: who owns the merit and who can authorize execution?
8. Check whether a safer/reversible test can answer the question first.
9. Define stop conditions and review triggers.
10. Close only when evidence strength matches consequence.

## Hallucination-risk gate
If any material claim relies on:
- a required source not consulted;
- unsupported specific data;
- conflicting sources without resolution;
- memory against canonical state;
- gap-filling by plausibility;
- certainty greater than evidence;
then flag RISCO DE ALUCINAÇÃO and classify that point as INCERTO until validated.

## Output
Decision/status first.
Then only the premises, risks, conditions, and evidence needed for auditability.

View saved version →

---
name: council-evidence-research
description: Use when an Executive Council decision needs external evidence, current facts, scientific literature, official documentation, legal or regulatory sources, product facts, benchmarks, or fact-checking.
---

# Council Evidence Research

The Drive defines Samuel's current personal state. External evidence explains how to interpret that state; it does not silently replace it.

## Choose rigor
### QUICK
Stable, low-risk question. Use a small number of authoritative sources.

### MATERIAL
Could materially affect money, commitments, career, architecture, or meaningful behavior. Prefer current primary/official sources plus strong independent evidence where useful.

### CRITICAL
Clinical, legal/regulatory, high financial consequence, safety, irreversible action, or major uncertainty. Use multiple high-quality sources, counterevidence, and `council-critical-validation`.

## Workflow
1. Define the exact decision or question.
2. Separate known case facts from unknowns.
3. Identify which evidence could actually change the conclusion.
4. Search the most authoritative source class first.
5. Check recency when the fact can change.
6. Compare sources and expose material conflicts.
7. Label:
   - FACT: directly supported;
   - INFERENCE: derived from facts;
   - HYPOTHESIS: plausible but unverified;
   - JUDGMENT: evaluative conclusion.
8. Search for the strongest relevant countercase.
9. Apply evidence to Samuel's canonical state.
10. State residual uncertainty and the trigger that would change the conclusion.

## Default source hierarchy
- law/regulation → official statute, regulator, court, government source;
- clinical/scientific → guidelines, systematic reviews, high-quality primary studies as appropriate;
- technology/product → official docs/current vendor source, then independent verification when useful;
- finance → provider statements/current market data/official terms;
- uploaded/source document → the document itself before outside knowledge.

## Rules
- Do not accumulate citations for decoration.
- Popularity, star count, or SEO rank is not evidence quality.
- A summary is not the underlying source when the distinction matters.
- Historical data is not current state.
- If a required source cannot be consulted, mark the material point INCERTO rather than filling the gap.

View saved version →

---
name: council-execution-harness
description: Use when Samuel gives the Executive Council a multi-step objective spanning tools, files, apps, executors, or domains and expects the system to carry it through rather than return a to-do list.
---

# Council Execution Harness

## Goal
Turn a natural-language objective into verified execution with minimum user involvement.

## Precedence
Google Drive is the canonical Council Source of Truth.
Do not create shadow state for work already represented canonically.

## Loop
1. RECOVER
   - read `README_OPERACIONAL — Executive Council`;
   - retrieve only the domain sources needed;
   - read `06_COORDENACAO_ATIVA` when routing/handoff matters.
2. DEFINE
   - convert the request into one observable outcome;
   - identify constraints, authorization, and proving postcondition.
3. ROUTE
   - choose the competent C/domain;
   - choose the narrowest executor that can do the technical work;
   - technical home does not change under temporary assignment.
4. PLAN MINIMALLY
   - create only tasks necessary to reach the outcome;
   - order by dependency and risk;
   - do not create ceremony, documents, roles, or processes for their own sake.
5. EXECUTE
   - use available tools/apps directly;
   - delegate work that another agent/tool can safely do;
   - involve Samuel only for authentication, inaccessible information, a real subjective choice, or a material consequence not already authorized.
6. VERIFY
   - run the actual postcondition using `council-verification-gate`.
7. PERSIST
   - update canonical state only when the result changes current facts, decisions, restrictions, pending work, or integration health.
8. HANDOFF
   - if another area must act, use `06_COORDENACAO_ATIVA` with only: problem, current facts, decisions/restrictions, exact requested action.
9. CLOSE
   - remove or resolve stale pending items;
   - report result, material exception, or exact blocker.

## Concurrency
Parallelize independent reads and research.
Serialize writes that can conflict or depend on prior state.

## Escalate
Escalate only when:
- authority is unclear;
- scope/risk materially changed;
- required authorization is absent;
- repeated debugging indicates an architectural problem;
- evidence is insufficient for the consequence.

## Anti-loop
If tool calls are no longer changing evidence, state, or probability of success, stop and re-plan.

View saved version →

---
name: council-external-ai-handoff
description: Use when work can be delegated to another AI, model, or platform to save cost, tokens, or time while the Executive Council retains specification, authority, and validation.
---

# Council External AI Handoff

## Goal
Use the cheapest/simplest adequate external AI for bounded work without outsourcing judgment, secrets, authority, or Source of Truth.

## Workflow
1. Define the exact work unit to delegate.
2. Decide whether delegation is actually cheaper/faster than doing it here.
3. Choose platform/model based on current capability, limits, privacy, and cost when those facts matter.
4. Remove all context not required for the task.
5. Never send passwords, tokens, full health/relationship history, full financial state, or sensitive documents when a redacted extract will do.
6. Build the handoff:
   - Objective
   - Inputs
   - Constraints
   - Required output format
   - What must not be assumed
   - Acceptance criteria
   - Examples only when they materially improve reliability
7. If an authorized connector/tool exists, execute the handoff.
8. If no connector exists, give Samuel one copy-paste payload and only the unavoidable manual step.
9. On return, validate the output against acceptance criteria and canonical facts.
10. Promote only verified results into Council work/state.

## Model selection
Prefer a free or lower-cost model when it satisfies the quality threshold.
Use a stronger model for:
- ambiguous synthesis;
- high-risk reasoning;
- difficult code/debugging;
- long-context accuracy;
- tasks where rework costs more than model savings.

## Good candidates for delegation
- first-pass extraction;
- reformatting;
- classification with a clear schema;
- boilerplate;
- broad ideation;
- draft code under tests;
- source collection to be independently verified.

## Keep final authority inside the Council
Do not outsource final authority for:
- clinical/health decisions;
- legal conclusions;
- material financial authorization;
- irreversible relationship decisions;
- final Source-of-Truth updates;
- acceptance/verification itself.

## Failure rule
External AI output is untrusted work product until validated.

View saved version →

---
name: council-human-gate
description: Use when Executive Council work reaches a point where Samuel's direct involvement may be required for authorization, authentication, sensitive or destructive action, external commitment, or a genuinely subjective choice.
---

# Council Human Gate

## Goal
Use Samuel as principal/decision-maker only where human authority or input is actually necessary.

## Before interrupting
Check whether authority is already covered by:
- the current request;
- a canonical active decision;
- an approved budget/teto;
- standing delegation;
- a previous authorization that still covers the same material scope.

If covered, execute. Do not ask again.

## A gate is justified when
- authentication, MFA, CAPTCHA, or account ownership needs Samuel;
- a required personal fact is inaccessible;
- an external write creates a new material obligation;
- financial, destructive, sensitive, legal, clinical, or privacy consequence is not already authorized;
- scope, risk, recipient, cost, or consequence changed materially;
- the choice is genuinely subjective and cannot be resolved from an established preference.

## Gate format
Ask for one decision containing:
1. exact action;
2. material consequence;
3. recommended/default option when appropriate;
4. alternatives only if they materially differ.

Batch related approval points instead of interrupting repeatedly.

## After approval
The authorization covers ordinary technical steps necessary to carry out that exact decision.
Do not re-ask unless scope, risk, cost, recipient, or consequence changes materially.

## Never
- ask for approval merely because a tool call feels important;
- make Samuel repeat a fact already in the Source of Truth;
- ask him to manually transport context the Council can retrieve;
- hide a material consequence inside a vague "continue?" prompt.

View saved version →

---
name: council-systematic-debugging
description: Use for bugs, broken automations, integration failures, unexpected behavior, performance problems, bad outputs, or repeated failed attempts in the Executive Council.
---

# Council Systematic Debugging

The current Google Drive Source of Truth, domain rules, platform/system instructions, and Samuel's explicit current request override this skill.

## Protocol
PARAR → preserve last valid state → locate bottleneck → form one hypothesis → change only what tests it → test → verify.

## Phase 1 — Reproduce and localize
1. State the observed symptom without interpretation.
2. Reproduce if possible.
3. Read the full error, log, or output already available.
4. Identify recent relevant changes.
5. Map component boundaries.
6. Find the first layer where expected input/output diverges.

## Phase 2 — Hypothesis
State one falsifiable hypothesis:
"I think X is failing because evidence Y; test Z distinguishes it."

Do not stack speculative fixes.

## Phase 3 — Minimal test
Change the smallest reversible variable that discriminates the hypothesis.
Record the result.
If false, discard the hypothesis and use the new evidence.

## Phase 4 — Correct
Fix the root cause, not the visible symptom.
Preserve rollback when the change is persistent or material.

## Phase 5 — Verify
Use `council-verification-gate` before claiming success.

## Three-failure gate
After three materially different failed fixes:
- stop adding patches;
- question the architecture or assumed layer;
- recover from the last valid state;
- escalate only the exact architectural decision that now requires authority.

## Prohibited
- random command sequences;
- blind reinstall/reset/restart as a reflex;
- changing multiple variables when causal attribution matters;
- discarding valid work and starting over merely because debugging became difficult.

View saved version →

---
name: council-verification-gate
description: Use immediately before claiming Executive Council work is complete, fixed, sent, paid, deployed, updated, reconciled, migrated, or otherwise successful.
---

# Council Verification Gate

The current Google Drive Source of Truth, domain rules, platform/system instructions, and Samuel's explicit current request override this skill.

## Iron rule
No material completion claim without fresh evidence for the postcondition that makes the claim true.

## Workflow
1. Name the exact claim about to be made.
2. Define the postcondition that would prove it.
3. Choose the freshest direct verification available.
4. Run or read the verification.
5. Compare actual result with expected postcondition.
6. If verified, report completion with the relevant evidence.
7. If not verified, report the actual state and never upgrade "attempted" into "done."

## Examples
- Drive update → re-read the changed section/revision.
- Email sent → confirm sent state/destination when exposed.
- Calendar changed → re-read the event.
- Payment → verify provider transaction/payment state; checkout or intent is not payment.
- Software fix → reproduce the original symptom or run the relevant test.
- Deployment → verify the user-visible flow when material.
- Spreadsheet → reconcile totals/formulas and inspect the final artifact.
- Migration → verify the new surface recovers current state before abandoning the old one.

## Agent/subagent rule
An executor reporting "success" is evidence of an attempt, not proof of the postcondition. Verify independently whenever possible.

## Fail closed
If the proving signal is unavailable, label the result UNVERIFIED or PARTIALLY VERIFIED and state exactly what remains unverified.