com um clique
wiki-research-engineering
Daily research agent for
Menu
Daily research agent for
Weekly research agent for
Daily research agent for
Build, run, and secure Docker containers with current best practices. Use for Dockerfile review, multi-stage builds, Compose orchestration, image hardening, and CI/CD integration.
Operate GitHub repositories, workflows, and PRs efficiently. Use for Actions optimization, PR hygiene, repo maintenance, and team collaboration patterns.
Deploy, manage, and troubleshoot Kubernetes workloads. Use for manifest review, Helm chart validation, resource tuning, RBAC, and cluster operations.
Design and operate application observability with metrics, logs, traces, and alerts. Use for SLO definition, dashboard design, on-call runbooks, and incident response.
| name | wiki-research-engineering |
| description | Daily research agent for |
Process #engineering items from the research queue using the 5-step research loop. Every claim gets a knowledge tier. Every page ends with Limitations.
/app/data/vault/
If the topic is a quick factual lookup (a release note, a docs link, a single fact), use web_search (engine brave) directly, write a one-paragraph wiki page with a source link, and stop. The full loop is for topics that reward depth.
Each step has a gate. Do not advance until the gate is met.
Before searching, write three sentences:
Gate: a reader who hasn't seen the queue item could tell whether your output answered it.
Identify the 1–3 source types most likely to answer the question. For engineering topics, priority order:
web_search with engine brave, then intelli_extract on the URL)wiki/index.md)Run 2–3 Brave queries with focused prompts. For each promising URL, use intelli_extract with a focusPrompt that names the specific question from Step 1.
Gate: you can name 2+ source URLs you will cite before writing the page.
Pull the answer from the triaged sources.
intelli_extract to lift relevant sections from each source.Gate: every claim you plan to write has at least one source URL attached.
For every claim, assign one tier:
For any FACT or LIKELY claim that drives a decision the user might act on (architecture choice, security posture, purchase, migration), run a second web_search to corroborate.
Gate: every claim has a tier. The reader knows which claims to trust and which to test further.
Write the wiki page using the format below. Append a Limitations section.
---
tags: [#engineering]
last_researched: YYYY-MM-DD
---
# <Title>
> One-sentence summary.
## Define
- **Assumption:** ...
- **Unknown:** ...
- **Answer shape:** ...
## Findings
### <Section heading>
- **FACT:** <claim> [^1]
- **FACT:** <claim> [^2]
- **LIKELY:** <claim> [^1, 2]
- **SPECULATIVE:** <claim>
### <Section heading>
...
## Limitations
- What the sources did not cover
- Which claims were not independently verified and why
- What would change the answer
## Sources
[^1]: <url> — accessed YYYY-MM-DD
[^2]: <url> — accessed YYYY-MM-DD
RESEARCH_QUEUE.md in the vault root.- [ ]) under ## #engineering. If none (or only placeholder), stop — log nothing, do nothing.wiki/index.md.
wiki/engineering/<slug>.md.wiki/index.md — add or update the entry.RESEARCH_QUEUE.md: - [x] + — researched YYYY-MM-DD.[x] items into the ## Archive section.wiki/log.md:
## [YYYY-MM-DD] ingest | research-queue #engineering | <topics> → <pages>
raw/, Openclaw articles/, or personal stuff/ — read-only.wiki/ and RESEARCH_QUEUE.md.[x] with — skipped: too vague, clarify topic.