Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsCommunityBlog
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Authors
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

ProTermsPrivacyRefunds
Back to skills

Wiki Research Engineering

ASecurity

Daily research agent for #engineering queue items. Runs the 5-step research loop (Define → Triage → Query → Verify → Report) and writes a tiered, cited wiki page.

8 stars
0 votes
0 copies
2 views
Added 9/6/2026
researchrustgogitsecurity

Security Analysis

A100/100

Scanned 9/6/2026

Install to Claude Code

$npx -y skills add v1truv1us/ai-eng-system --skill wiki-research-engineering --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Wiki Research Engineering?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Wiki Research Engineering
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/v1truv1us-wiki-research-engineering/badge)](https://www.skillsdirectory.com/skills/v1truv1us-wiki-research-engineering)

More formats (shields.io, HTML) on the badges page.

Download with Pro
Files
SKILL.md
---
name: wiki-research-engineering
description: Daily research agent for #engineering queue items. Runs the 5-step research loop (Define → Triage → Query → Verify → Report) and writes a tiered, cited wiki page.
---

# Wiki Research: Engineering

Process `#engineering` items from the research queue using the 5-step research loop. Every claim gets a knowledge tier. Every page ends with Limitations.

## Vault location
`/app/data/vault/`

## When to skip the loop
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.

## The 5-step loop

Each step has a gate. Do not advance until the gate is met.

### 1 — Define

Before searching, write three sentences:
- **Assumption:** what you currently believe is true about this topic
- **Unknown:** the specific thing you don't know yet, as a question with a verifiable answer
- **Answer shape:** what a good answer looks like (a comparison, a number with conditions, a framework, a yes/no with caveats)

**Gate:** a reader who hasn't seen the queue item could tell whether your output answered it.

### 2 — Triage

Identify the 1–3 source types most likely to answer the question. For engineering topics, priority order:

1. Official docs / changelogs / spec pages (use `web_search` with engine `brave`, then `intelli_extract` on the URL)
2. Recent conference talks, engineering blog posts from named organisations
3. Issue threads, RFCs, design docs (GitHub, W3C, IETF, etc.)
4. Adjacent context: wiki pages already in the vault (`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.

### 3 — Query

Pull the answer from the triaged sources.

- Use `intelli_extract` to lift relevant sections from each source.
- If two sources disagree, capture both positions.
- If a source is older than 12 months and the field moves fast (browsers, security, AI tooling), flag it and search for a newer one.

**Gate:** every claim you plan to write has at least one source URL attached.

### 4 — Verify

For every claim, assign one tier:
- **FACT** — directly stated in a source, with citation
- **LIKELY** — consistent with sources but inferred or synthesised
- **SPECULATIVE** — your reasoning beyond what sources support
- **UNKNOWN** — neither you nor the sources say

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.

### 5 — Report

Write the wiki page using the format below. Append a Limitations section.

## Wiki page format

```markdown
---
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
```

## Per-run workflow

1. Read `RESEARCH_QUEUE.md` in the vault root.
2. Find all unchecked items (`- [ ]`) under `## #engineering`. If none (or only placeholder), stop — log nothing, do nothing.
3. For each real unchecked item, run the 5-step loop above.
4. Determine if a relevant wiki page already exists by reading `wiki/index.md`.
   - If yes: read it, update it with new findings, mark conflicts.
   - If no: create `wiki/engineering/<slug>.md`.
5. Update `wiki/index.md` — add or update the entry.
6. Mark the item done in `RESEARCH_QUEUE.md`: `- [x]` + ` — researched YYYY-MM-DD`.
7. After all items, move `[x]` items into the `## Archive` section.
8. Append one entry to `wiki/log.md`:
   ```
   ## [YYYY-MM-DD] ingest | research-queue #engineering | <topics> → <pages>
   ```

## Rules
- Never edit `raw/`, `Openclaw articles/`, or `personal stuff/` — read-only.
- Only write to `wiki/` and `RESEARCH_QUEUE.md`.
- If a topic is too vague to define an Unknown, mark `[x]` with `— skipped: too vague, clarify topic`.
- Keep one page per concept. If research reveals two distinct concepts, create two pages.
- Today's date comes from system context.

Attribution

v1truv1usv1truv1us
View sourceMore from v1truv1us →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Competitor Analysis

This skill provides comprehensive analysis of competitor SEO and GEO strategies, revealing what's working in your market and identifying opportunities to outperform the competition.

1823 votes

Deep Research

Universal deep research agent team. 13-agent pipeline for rigorous academic research on any topic. 8 modes: full research, quick brief, paper review, lit-review, fact-check, three-way literature scan, Socratic guided research dialogue, and systematic review with optional meta-analysis. Covers research question formulation, Socratic mentoring, methodology design, systematic literature search, source verification, cross-source synthesis, risk of bias assessment, meta-analysis, APA 7.0 report co...

493622 votes

Paperclip Distill

Use when an operation issue is a Paperclip cursor-window, distill, or backfill — `operationType: "distill"` or `"backfill"` and the body references a Paperclip source bundle for a project or root issue. Turn raw Paperclip activity into a wiki-insightful project page, decisions log, and history note. This skill exists specifically to replace the stiff, datestamp-heavy templated output that the deterministic distiller produces.

813271 votes

Academic Pipeline

Orchestrator for the full academic research pipeline: research -> write -> integrity check -> review -> revise -> re-review -> re-revise -> final integrity check -> finalize. Coordinates deep-research, academic-paper, and academic-paper-reviewer into a seamless 10-stage workflow with mandatory, coverage-bounded integrity checks, two-stage peer review, and auditable quality-assurance artifacts. Triggers on: academic pipeline, research to paper, full paper workflow, paper pipeline, end-to-end p...

493621 votes

Exa Search

Semantic search, similar content discovery, and structured research using Exa API

304951 votes
View all in research →