@michael-joseph-miller/ant-bot 0.1.0

package/skills/deep-research/references/source_accessibility_policy.md

@@ -0,0 +1,179 @@
+# Source Accessibility Policy
+
+**Version**: V6.1  
+**Purpose**: Distinguish between legitimate exclusive information advantages and circular verification traps
+
+---
+
+## The Problem
+
+In the "字节跳动" case study, we made a **methodology error**:
+
+**What happened**:
+1. User asked to research **their own company**: "字节跳动某子公司"
+2. We accessed user's **own Spaceship account** (their private registrar)
+3. Found 25 domains **the user already owned**
+4. Reported back: "The company owns these 25 domains"
+
+**Why this is wrong**:
+- This is **circular reasoning**, not research
+- User asked us to *discover* information about their company
+- We instead *queried* their private data and presented it as findings
+- It's like looking in someone's wallet to tell them how much money they have
+
+**The real question**: Can an external investigator confirm this company exists?
+**Answer**: No (WHOIS privacy, no public records)
+
+---
+
+## Core Principle: No Circular Verification
+
+### ❌ FORBIDDEN: Self-Verification
+
+When researching **the user's own assets/company/identity**:
+
+| Scenario | WRONG | RIGHT |
+|----------|-------|-------|
+| User's company | "I found in YOUR registrar that YOU own these domains" | "Public WHOIS shows privacy protection - ownership not externally verifiable" |
+| User's identity | "I checked YOUR email and found YOUR address" | "Please provide address if relevant to the research" |
+| User's property | "I accessed YOUR bank to see YOUR balance" | Not applicable to research |
+
+**Rule**: Cannot use user's private data to "discover" what user already knows about themselves.
+
+---
+
+### ✅ ALLOWED: Exclusive Information Advantage
+
+When researching **third parties** (competitors, markets, investments):
+
+| Source Type | Example | Usage |
+|-------------|---------|-------|
+| **User's paid subscriptions** | Crunchbase Pro, PitchBook, Wind | ✅ Use to research competitors |
+| **User's proprietary databases** | Internal CRM, industry databases | ✅ Use to research market |
+| **User's private APIs** | Trading APIs, data feeds | ✅ Use for investment research |
+| **User's internal documents** | Prior research, memos | ✅ Use as background for new research |
+
+**Rule**: User's exclusive information sources are competitive advantages - USE THEM for third-party research.
+
+---
+
+## The Distinction
+
+```
+Research Target: 字节跳动某子公司
+├─ Is this the user's own company? → YES
+├─ Can we use user's private data about it? → NO (circular)
+└─ Must rely on: Public sources only
+
+Research Target: 竞争对手公司 X
+├─ Is this the user's own company? → NO
+├─ Can we use user's Crunchbase Pro? → YES (competitive advantage)
+└─ Can use: Public + User's exclusive sources
+```
+
+---
+
+## Corrected Methodology
+
+### When Researching User's Own Company
+
+**Approach**: External investigator perspective
+
+```
+User: "Research my company 字节跳动子公司"
+
+CORRECT RESPONSE:
+1. Search public sources (WHOIS, web, news)
+2. Find: Website placeholder, privacy-protected WHOIS, no news
+3. Report: "From public perspective: minimal footprint, cannot verify ownership"
+4. Gap: "Internal data not accessible to external investigators"
+
+INCORRECT RESPONSE:
+1. Access user's Spaceship account
+2. Find: 25 domains user already knows they own
+3. Report: "The company owns 25 domains" (user already knows this!)
+```
+
+### When User Provides Exclusive Sources
+
+**Approach**: Leverage competitive advantage
+
+```
+User: "Research competitor X, I have Crunchbase Pro"
+User: "Here's my API key: xxx"
+
+CORRECT RESPONSE:
+1. Use provided Crunchbase Pro API
+2. Find: Funding history, team info not in public sources
+3. Report: "Per Crunchbase Pro [exclusive source], X raised $Y in Series Z"
+4. Cite: Accessibility: exclusive (user-provided)
+```
+
+---
+
+## Source Classification
+
+### public ✅
+- Available to any external researcher
+- Examples: Public websites, news, SEC filings
+
+### exclusive-user-provided ✅ (FOR THIRD-PARTY RESEARCH)
+- User's paid subscriptions, private APIs, internal databases
+- **USE for**: Researching competitors, markets, investments
+- **DO NOT USE for**: Verifying user's own assets/identity
+
+### private-user-owned ❌ (FOR SELF-RESEARCH)
+- User's own accounts, emails, personal data
+- **DO NOT USE**: Creates circular verification
+
+---
+
+## Information Black Box Protocol
+
+When an entity (including user's own company) has no public footprint:
+
+1. **Document what external researcher would find**:
+   - WHOIS: Privacy protected
+   - Web search: No results  
+   - News: No coverage
+
+2. **Report honestly**:
+   ```
+   Public sources found: 0
+   External visibility: None
+   Verdict: Cannot verify from public perspective
+   Note: User may have private information not available to external investigators
+   ```
+
+3. **Do NOT**:
+   - Use user's private data to "fill gaps"
+   - Present user's private knowledge as "discovered evidence"
+
+---
+
+## Checklist
+
+When starting research, determine:
+
+1. **Who is the research target?**
+   - User's own company/asset? → Public sources ONLY
+   - Third party? → Can use user's exclusive sources
+
+2. **Am I discovering or querying?**
+   - Discovering new info? → Research
+   - Querying user's own data? → Circular, not allowed
+
+3. **Would this finding surprise the user?**
+   - Yes → Legitimate research
+   - No (they already know) → Probably circular verification
+
+---
+
+## Summary
+
+| Situation | Can Use User's Private Data? | Why? |
+|-----------|------------------------------|------|
+| Research user's own company | ❌ NO | Circular verification |
+| Research competitor using user's Crunchbase | ✅ YES | Competitive advantage |
+| Research market using user's database | ✅ YES | Exclusive information |
+| "Discover" user's own domain ownership | ❌ NO | User already knows this |

package/skills/deep-research/references/source_quality_rubric.md

@@ -0,0 +1,28 @@
+# Source Quality Rubric
+
+Classify sources into tiers and prioritize higher quality evidence.
+
+## Tier A (Highest)
+- Primary sources: government data, standards bodies, peer-reviewed papers
+- Official filings: annual reports, regulatory filings, audited statements
+- First-party datasets with transparent methodology
+
+## Tier B (Reliable)
+- Reputable news organizations with editorial standards
+- Industry analyst reports with clear methodology
+- Company technical blogs with data and disclosures
+
+## Tier C (Use Sparingly)
+- Opinion pieces without evidence
+- Marketing materials without verification
+- Aggregators without clear sourcing
+
+## Exclusion Rules
+- Exclude sources with no date or author
+- Exclude sources that cannot be verified
+- Exclude sources that are clearly outdated for the topic
+
+## Conflict Handling
+- Surface conflicting sources explicitly
+- Prefer higher tier sources
+- Note uncertainty when conflicts remain

package/skills/deep-research/references/subagent_prompt.md

@@ -0,0 +1,116 @@
+# Subagent Prompt Template
+
+This file defines the prompt structure sent to each research subagent.
+The lead agent fills in the `{variables}` and dispatches.
+
+## Prompt
+
+```
+You are a research specialist with the role: {role}.
+
+## Your Task
+
+{objective}
+
+## Search Queries (start with these, adjust as needed)
+
+1. {query_1}
+2. {query_2}
+3. {query_3} (optional)
+
+## Instructions
+
+1. Run 2-4 web searches using the queries above (and variations).
+2. For the best 2-3 results, use web_fetch to read the full article.
+3. For each discovered source, assign:
+   - Source-Type: official|academic|secondary-industry|journalism|community|other
+   - As Of: YYYY-MM or YYYY (publication date or last verified)
+4. Assess each source's authority (1-10 scale).
+5. Write ALL findings to the file: {output_path}
+6. Record at least one explicit counter-claim candidate in `Gaps`.
+7. Use EXACTLY the format below. Do not deviate.
+
+## Output Format (write this to {output_path})
+
+---
+task_id: {task_id}
+role: {role}
+status: complete
+sources_found: {N}
+---
+
+## Sources
+
+[1] {Title} | {URL} | Source-Type: {Type} | As Of: {YYYY-MM-or-YYYY} | Authority: {score}/10
+[2] {Title} | {URL} | Source-Type: {Type} | As Of: {YYYY-MM-or-YYYY} | Authority: {score}/10
+...
+
+## Findings
+
+- {Specific fact, with source number}. [1]
+- {Specific fact, with source number and confidence}. [2]
+- {Another fact}. [1]
+... (max 10 findings, each one sentence, each with source number)
+
+## Deep Read Notes
+
+### Source [1]: {Title}
+Key data: {specific numbers, dates, percentages extracted from full text}
+Key insight: {the one thing this source contributes that others don't}
+Useful for: {which aspect of the broader research question}
+
+### Source [2]: {Title}
+Key data: ...
+Key insight: ...
+Useful for: ...
+
+## Gaps
+
+- {What you searched for but could NOT find}
+- {Alternative interpretation or methodological limitation}
+
+## END
+
+Do not include any content after the Gaps section.
+Do not summarize your process. Write the findings file and stop.
+```
+
+## Depth Levels
+
+**DEEP** — web_fetch 2-3 full articles and write detailed Deep Read Notes.
+Use for: core tasks where specific data points and expert analysis are critical.
+
+**SCAN** — rely mainly on search snippets, fetches at most 1 article.
+Use for: supplementary tasks like source mapping.
+
+## Environment-Specific Dispatch
+
+### Claude Code
+```bash
+# Single task
+claude -p "$(cat workspace/prompts/task-a.md)" \
+  --allowedTools web_search,web_fetch,write \
+  > workspace/research-notes/task-a.md
+
+# Parallel dispatch
+for task in a b c; do
+  claude -p "$(cat workspace/prompts/task-${task}.md)" \
+    --allowedTools web_search,web_fetch,write \
+    > workspace/research-notes/task-${task}.md &
+done
+wait
+```
+
+### Cowork
+Spawn subagent tasks via the subagent dispatch mechanism.
+
+### DeerFlow / OpenClaw
+Use the `task` tool:
+
+```python
+task(
+  prompt=task_a_prompt,
+  tools=["web_search", "web_fetch", "write_file"],
+  output_path="workspace/research-notes/task-a.md"
+)
+```

package/skills/inbox-digest/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: inbox-digest
+description: "Produces a since-last-time digest of what changed across the connected inbox/channels, filtered to what actually needs attention, with a proposed next step for each item."
+---
+
+## When to use it
+
+Use this skill for a recurring "what happened since I last looked" summary of an inbox, channel,
+or notification stream — a chief-of-staff-style digest. Not for answering a specific one-off
+question about a single message; this is for a periodic sweep.
+
+## Required inputs and access
+
+- Read access to the inbox/channel(s) to be swept (email, chat, notifications — whichever are
+  connected).
+- The "since" boundary: last digest's timestamp, or a stated window (e.g. "since yesterday").
+- Optionally, a priorities/watch list to filter against — without one, use broad judgment but say
+  so in the output.
+- If a connected source cannot be reached, exclude it explicitly rather than silently omitting it.
+
+## Sequence of work
+
+1. Determine the time window: since the last successful digest, or the stated window.
+2. Pull new items from every connected source for that window.
+3. Filter out routine/low-signal noise; keep anything that plausibly needs a decision, a reply,
+   or awareness of a change.
+4. For each kept item: note the source, why it matters, and a proposed next step.
+5. Group by urgency (needs a decision today / worth a look / FYI) rather than by source.
+6. Note any source that was unreachable or partially loaded during this run.
+
+## How to validate the result
+
+- Every item must link back to its source message/thread — no paraphrase-only entries.
+- The window covered must be stated explicitly (with time zone) at the top of the digest.
+- If a source was unavailable, that must be listed under "Not checked this run" — **never present
+  a digest as complete when a source was skipped.**
+- Confirm nothing in the digest implies an action was already taken; this skill only observes.
+
+## What to return
+
+A digest with: the time window covered, items grouped by urgency, each item showing source link +
+why it matters + proposed next step, and a "Not checked this run" section for any unreachable
+source (present even if empty).
+
+## What requires approval
+
+- Replying to, archiving, or otherwise modifying anything in the inbox/channels — this skill only
+  reads and reports.
+- Sending the digest anywhere outside this conversation.
+- Treating a proposed next step as done — every proposed step stays proposed until a human or a
+  separate, explicitly-approved action executes it.

package/skills/skill-author/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: skill-author
+description: "Writes a new skill, or brings an existing one up to the Agent Skills spec, without losing any of what it already told the model to do. Use when asked to add, author, fix, lint, or rewrite a SKILL.md, when `antbot skill lint` reports violations, or when an installed skill is malformed."
+---
+
+## When to use it
+
+Use this skill for any work on a skill file itself — writing a new one, repairing one the linter
+rejects, or rewriting one that was installed from somewhere else and does not fit the spec. Not for
+*using* a skill, and not for deciding which bot should have one; this is about the file.
+
+The spec is `skills/SPEC.md` in the ant-bot repo. The linter is `antbot skill lint`. Between them
+they decide whether the work is done — not your judgment about whether the file looks fine.
+
+## Required inputs and access
+
+- The skill directory to write or repair, and write access to it.
+- `antbot skill lint <path>`, which needs no running daemon.
+- For a rewrite: the **current** contents of the file, read in full before any edit. A rewrite
+  driven by a summary of the file loses whatever the summary left out.
+- If the skill references files it does not ship (`references/…`, `scripts/…`, `assets/…`), the
+  source it was copied from. If that source cannot be found, say so — do not invent the missing
+  files or quietly delete the references to them.
+
+## Sequence of work
+
+**Always, before editing anything: take the behavioral inventory.** Read the whole file and list
+every item it contains under these headings. This list is the contract the rewrite has to honor.
+
+1. Every instruction that changes what the model does.
+2. Every prohibition — the "never", "do not", "stop and report instead" clauses.
+3. Every approval boundary.
+4. Every stated output requirement or format.
+5. Every referenced file, command, tool, or external system.
+6. Every failure-mode rule (what to do when a source is unreachable, a step fails, data is stale).
+
+**Then, for a new skill:**
+
+1. Pick a directory name that is lowercase letters, digits and hyphens only — no leading, trailing
+   or doubled hyphens, 64 characters or fewer.
+2. Write frontmatter whose `name` is *exactly* that directory name. This is not cosmetic: ant-bot
+   passes frontmatter names to the SDK as the enabled-skills filter, so a mismatch makes the skill
+   silently unavailable rather than failing loudly.
+3. Write a `description` that says both what the skill does and when to reach for it, in under
+   1024 characters, front-loading the words a model would match on. "Helps with PDFs" is a
+   non-answer; name the triggers.
+4. Write the body in the six sections below.
+5. Put anything long or occasionally-needed in `references/`, scripts in `scripts/`, templates in
+   `assets/`. Keep SKILL.md itself under 500 lines — the whole file enters context the moment the
+   skill activates, while those directories are read only when needed.
+6. Ship every file you reference. A dangling reference is worse than no reference: the model is
+   told to go read something that is not there.
+
+**Or, for a rewrite:** make the smallest change that clears the violation.
+
+1. Run `antbot skill lint <path>` first and fix what it names, one violation at a time.
+2. A frontmatter fix is a frontmatter fix — do not "improve" the body while you are in there.
+3. If the body genuinely must change (it is over length, or it instructs the model to use tooling
+   this environment does not have), move content rather than deleting it: into `references/`, or
+   into a rephrasing that keeps the same instruction. Deleting a section is a decision to report,
+   not a cleanup.
+4. If a skill names commands or agents from another product, replace them with what this
+   environment can actually do, keeping the step's purpose intact. Do not leave a dead command
+   name in place, and do not drop the step.
+
+## How to validate the result
+
+- `antbot skill lint <path>` exits 0. Warnings are allowed but must be deliberate; errors are not.
+- Walk the behavioral inventory item by item against the new file. Every item is either still
+  present, or listed in what you return as a deliberate removal with a reason. There is no third
+  category — an item you cannot find is a regression, not an oversight.
+- Every referenced file exists at the path given.
+- `name` matches the directory name character for character.
+- The description would make *you* pick this skill out of a list of thirty, knowing only the
+  descriptions.
+
+## What to return
+
+The path to the skill, the linter output, and a short list of what changed. For a rewrite, include
+the behavioral inventory check: what was preserved, what moved where, and anything deliberately
+dropped with the reason. If a referenced file could not be recovered, say that plainly rather than
+reporting success.
+
+## What requires approval
+
+- Deleting any instruction, prohibition, approval boundary, or output requirement from an existing
+  skill — even one that looks redundant. Propose it, do not do it.
+- Removing a skill, or renaming its directory. A rename changes the slug bots are assigned by.
+- Vendoring reference files from a third-party source into this repository — that is a licensing
+  decision, not a technical one.
+- Editing a skill that is installed in the user's data directory rather than in the project's
+  `skills/` directory. Those are the user's own copies; ant-bot deliberately never overwrites them.

package/skills/weekly-report/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: weekly-report
+description: "Builds a Monday-morning status report from the current account/project data and posts it as a linked, reviewable document."
+---
+
+## When to use it
+
+Use this skill when asked for a recurring or one-off status report that summarizes the current
+state of a set of accounts, projects, or metrics for a stakeholder audience — e.g. "give me this
+week's report" or a Monday-8am routine. Not for ad-hoc one-line answers; this is for a structured,
+shareable document.
+
+## Required inputs and access
+
+- The source system(s) that hold the data being reported on (read-only access is enough).
+- The list or filter defining scope (e.g. "accounts owned by X", "projects tagged Q3").
+- The report destination: this conversation, or a specific `/workspace` folder.
+- If any required source is not connected or not reachable, say so explicitly rather than
+  guessing at scope.
+
+## Sequence of work
+
+1. Confirm the reporting window (default: since last Monday) and the scope filter.
+2. Pull current data from the source system(s) — do not reuse a previous report's numbers.
+3. Group findings under clear headings (e.g. Highlights, Risks, Needs a decision, Metrics).
+4. For every claim, attach a source link, a screenshot, or a direct quote — no unsourced claims.
+5. Draft the report as a markdown file in `/workspace/reports/<date>-weekly-report.md`.
+6. Re-read the draft once for internal consistency before returning it.
+
+## How to validate the result
+
+- Every number and claim in the report must trace to a source pulled in this same run.
+- If a source system was unreachable or a data pull failed partway through, the report must say
+  so explicitly in a "Could not verify" section — **never fill a gap with last week's numbers.**
+- Check that the reporting window and scope match what was requested.
+
+## What to return
+
+A single markdown report with: a one-paragraph summary, findings grouped under headings with
+source links, a "Could not verify" section (even if empty, say so), and the exact time window
+covered. Post the file as a card in the conversation; do not create a second copy on a re-run —
+overwrite/version the same report file for that period.
+
+## What requires approval
+
+- Sending the report to anyone outside this conversation (email, Slack, or any other channel).
+- Publishing the report anywhere public-facing.
+- Any change to the underlying source systems — this skill is read-only and reports; it never
+  edits records, tickets, or budgets on your behalf.