olliecrow/sentinel-research

sentinel-research

Use this skill whenever working in the Sentinel repo or answering a trading-related question that can benefit from Sentinel.

Multi-agent collaboration

• Default to using subagents when they are likely to improve speed, quality, confidence, or keep the main context clean.
• Use subagents to widen coverage, dig deeper on one thread, get a fresh second opinion, or keep the main thread clean while side work runs.
• Keep the main agent focused on synthesis, unblockers, and the next critical-path step; let subagents handle bounded side work that can run in parallel.
• Good Sentinel subagent uses: independent reference-context search, source cross-checking, or review of an answer for weak evidence.

Proactive autonomy and knowledge compounding

• Default to autonomous execution: do not pause for confirmation between normal in-scope steps.
• Request user input only when absolutely necessary: unclear requirements, missing required access, or a risky decision that cannot be resolved from evidence.
• Treat iterative execution as the default for non-trivial work; run adaptive loop passes: clarify question, gather evidence, cross-check, assess confidence, fetch more if needed, then answer or report the blocker.
• Keep looping until actual completion criteria are met: the answer is high-confidence, or the remaining uncertainty is explicit and cannot be resolved with available sources.
• Run organise-docs frequently during execution when durable Sentinel behavior or source-scope knowledge changes.
• Create small checkpoint commits frequently with git-commit in the Sentinel repo when making code/docs changes and checks pass.
• Never squash commits; always use merge commits when integrating branches.
• Prefer simplification over added complexity: aggressively remove bloat, redundancy, and over-engineering while preserving correctness.
• When you touch code, leave the touched area in a better state than you found it: clearer, simpler, tidier, and at least as performant unless the task requires an explicit trade-off.
• Use simple, plain English in user messages, docs, notes, reports, code comments, and other explanatory writing. Avoid jargon, fancy wording, and complex phrasing. When a technical term is needed for correctness, explain it in simple words the first time.
• Default to short user-facing responses. Think about what the user most wants to know, and lead with that. Do not dump every detail by default. Always include important changes, blockers, verification gaps, and any important assumptions, nuances, principles, or decisions that shaped the work. Add more detail only when the user asks for it or when uncertainty or risk makes it necessary.

Long-task checkpoint cadence

• For non-trivial Sentinel work, checkpoint at each meaningful milestone after checks pass.
• Keep plan/ scratch untracked and promote only durable guidance into docs/.
• Push Sentinel repo checkpoints when repo policy permits and the working tree is safe.

Terminal state contract (must follow)

Before finishing:

• Objective completion: the question is answered, or the exact blocker is stated.
• Step-level terminal completion: each research step and delegated subtask is explicitly resolved as done, blocked, or not-applicable, with brief evidence before advancing.
• Source completion: every active source needed for the answer is used, ruled out, or marked unavailable with evidence.
• Confidence completion: confidence is stated when it is not high.
• Privacy completion: no raw source payloads, query logs, metrics, or caches were intentionally saved.
• Repo completion: any repo changes are tested, documented when needed, committed, and pushed when appropriate.

Terminal state examples (adapt to skill)

• done: the answer is evidence-backed and high-confidence, or repo changes are complete and verified.
• blocked: a required source, credential, or decision is unavailable after bounded retries, with exact evidence stated.
• not-applicable: a source or repo step is not needed for the current question and that reason is stated.

Stop only after this terminal contract is satisfied; otherwise continue iterating.

Core Rules

• Keep all source access read-only.
• Never place orders, change accounts, mutate broker/trading/risk systems, post social content, or make any external write action.
• Do not persist query logs, request metrics, raw source responses, caches, scrape dumps, or evidence trails.
• Do not implement or use unapproved sources.
• Use clear, plain English with little or no jargon.
• Give high-confidence answers only when the evidence supports them. If confidence is not high, say what is missing.

First Steps

1. Confirm you are in or near the Sentinel repo when local work is needed.
2. Read the current Sentinel rules before acting:
   • AGENTS.md
   • docs/source-roadmap.md
   • docs/implementation.md
   • docs/reference-context.md
3. Refresh relevant reference_context/ repos before using them:
   • fetch remote default branch,
   • reset hard to the remote default branch,
   • clean untracked files,
   • never edit, commit, branch, or push inside reference repos.
4. Check source availability with:

uv run sentinel sources
uv run sentinel self-test

If self-test fails for a source needed by the question, retry once for transient network issues. If it still fails, treat that source as unavailable and state the gap.

Source Use

Approved active sources:

• Deeter prod DB
• Deeter S3
• Supadata
• TwitterAPI.io
• Brave Search
• Finnhub
• generic public web/RSS/media helpers

Do not use Discord, Gmail, SocialData.tools, Twitter browser/cookie access, Bing/legacy scripts, or any other unapproved source unless the user explicitly reopens scope.

Research Workflow

For trading questions:

1. Clarify the exact decision or question internally before fetching.
2. Use reference context heavily when relevant.
3. Use external sources iteratively. Start with small probes, then follow up where evidence is missing, stale, conflicting, or too broad.
4. Cross-check important claims across more than one source when practical.
5. Track source freshness and limits in memory while reasoning. Do not save source payloads or query histories.
6. Prefer direct source evidence over guesses, model memory, or user framing.
7. If a source gives overlapping or conflicting facts, keep the distinction clear instead of flattening it into one unsupported value.

Good default source choices:

• Current Deeter/internal context: Deeter prod DB and reference context.
• Deeter files, backfills, bars, exported datasets, and object metadata: Deeter S3.
• Web/news discovery: Brave Search, then public web/RSS.
• Market data, profiles, filings, earnings, insider context: Finnhub.
• Social/X context: TwitterAPI.io.
• Video/media transcripts or metadata: Supadata.

Answering Standard

Lead with the answer only when confidence is high. Otherwise lead with the uncertainty.

In final answers:

• State the conclusion plainly.
• Mention the main evidence used, without dumping raw outputs.
• Flag stale, missing, conflicting, or unavailable data.
• Say when confidence is not high and what would improve it.
• Do not use a fixed template unless it helps the specific answer.

Local Work

When changing Sentinel:

• Keep source clients read-only.
• Add tests for read-only boundaries and credential behavior.
• Run at least:

uv run pytest
uv run sentinel self-test

• Update durable docs when behavior or source scope changes.
• Commit and push small checkpoints in the Sentinel repo when checks pass.