first commit

This commit is contained in:
2026-06-10 08:20:27 +02:00
commit f439f0f793
39 changed files with 9716 additions and 0 deletions
+107
View File
@@ -0,0 +1,107 @@
---
name: document-triage
description: Scope a document research task, prioritize sources, and define an evidence-driven reading plan
license: MIT
compatibility: opencode
metadata:
audience: analysts
workflow: research
stage: triage
---
## What I do
- Define the research objective in precise terms
- Break the task into answerable sub-questions
- Identify which documents are likely primary, secondary, or low-value
- Propose a reading order based on expected relevance
- Highlight likely evidence types such as requirements, decisions, risks, assumptions, and timelines
- Create a focused plan before deep reading begins
## When to use me
Use this skill at the start of a document-based research task.
Examples:
- You have a folder of policies, specs, meeting notes, or reports and need a systematic approach
- You need to answer a question using internal documentation
- You need to map a large corpus before extracting evidence
- You want to avoid reading everything in full
## Inputs I expect
Provide as many of these as available:
- Research goal or question
- List of documents, filenames, or brief descriptions
- Any constraints such as deadline, topic boundaries, time period, or required output
- Any known "must-cover" documents
- Preferred output format if already defined
## Workflow
1. Restate the research objective in one sentence
2. Convert the objective into focused sub-questions
3. Classify available documents by likely value:
- Primary source
- Supporting source
- Background source
- Likely irrelevant
4. Identify expected signal in each source:
- Requirements
- Decisions
- Responsibilities
- Risks
- Dates or milestones
- Definitions
- Exceptions
5. Recommend an efficient reading order
6. Define extraction criteria for the next stage
7. Flag ambiguities, missing sources, and review risks
## Output format
Produce these sections:
### Research Objective
A single concise statement of the exact question to answer.
### Sub-questions
A numbered list of focused questions the research should resolve.
### Source Triage
For each document:
- Document name
- Classification
- Why it matters
- What to look for
### Reading Plan
A prioritized reading sequence with rationale.
### Extraction Criteria
A checklist of evidence worth capturing in the next phase.
### Risks and Gaps
Explicitly list missing documents, unclear scope, and likely blind spots.
## Quality bar
- Be specific, not generic
- Prefer primary documents over commentary
- Do not assume a document is authoritative unless the user says so
- Separate fact-finding from interpretation
- Explicitly note what cannot be determined yet
## Do not
- Do not summarize the documents in depth at this stage
- Do not invent document contents
- Do not claim conclusions before evidence extraction
- Do not merge assumptions with facts
## Hand-off to companion skills
After this skill, use:
- `evidence-extraction` to pull structured findings
- `research-synthesis` to produce a final answer, brief, matrix, or report
@@ -0,0 +1,121 @@
---
name: evidence-extraction
description: Extract structured evidence from documents with traceability, quotations, and confidence markers
license: MIT
compatibility: opencode
metadata:
audience: analysts
workflow: research
stage: extraction
---
## What I do
- Read documents and extract evidence relevant to a defined research question
- Separate direct evidence from interpretation
- Capture exact quotations or precise paraphrases
- Record document references for every extracted item
- Structure findings so they can be audited and synthesized later
- Mark uncertain or ambiguous findings for review
## When to use me
Use this after the research task has been scoped and prioritized.
Examples:
- You need requirements, decisions, obligations, controls, or action items extracted from documents
- You need a traceable evidence table
- You need to compare what multiple documents say about the same issue
- You need defensible notes before writing a summary or conclusion
## Inputs I expect
Provide:
- The research objective or sub-question
- One or more documents or excerpts
- Optional triage output from `document-triage`
- Optional extraction schema if the project already has one
## Core extraction rules
For every finding, preserve:
- Finding ID
- Topic or theme
- Evidence type
- Source document
- Section, heading, page, or paragraph reference if available
- Extracted text
- Short analyst note
- Confidence level
- Review flag where needed
Evidence types may include:
- Requirement
- Decision
- Risk
- Assumption
- Responsibility
- Constraint
- Definition
- Date or milestone
- Dependency
- Open issue
## Workflow
1. Read the objective and extraction criteria
2. Scan the document for relevant passages
3. Extract only evidence tied to the research question
4. Distinguish:
- Direct statement
- Implied interpretation
- Missing information
5. Attach traceable references for each item
6. Normalize wording without losing meaning
7. Flag ambiguity, contradiction, or incomplete support
## Output format
Use a structured table like this:
| # | Topic | Evidence Type | Description | Document Reference | Extracted Evidence | Analyst Note | Confidence | Review Needed |
|---|---|----|-----------|-----|--------------------|------|----|---------|------|---------|-------|
Where:
- **Description** is concise and factual
- **Document Reference** is precise enough to locate the source again
- **Extracted Evidence** is a quote or faithful paraphrase
- **Analyst Note** explains relevance without overstating certainty
- **Confidence** is one of: High, Medium, Low
- **Review Needed** is `Yes` when ambiguity remains
## Comparison mode
If multiple documents cover the same topic, add a second table:
| Topic | Source A | Source B | Agreement | Conflict | Notes |
|------|----------|----------|----------|----------|----|
Use this to identify contradictions, differences in wording, or missing alignment.
## Quality bar
- Every claim must be traceable to a source
- Keep extraction atomic: one row per distinct finding
- Preserve important qualifiers such as "must", "should", "may", "unless", and exceptions
- Mark uncertainty explicitly instead of smoothing it over
- Prefer exact citations over memory-based summaries
## Do not
- Do not write the final conclusion here
- Do not collapse multiple findings into one vague row
- Do not omit document references
- Do not present interpretation as if it were a quote
- Do not silently resolve contradictions
## Hand-off to companion skills
After this skill, use:
- `research-synthesis` to turn extracted evidence into a conclusion, report, briefing, matrix, or recommendation
@@ -0,0 +1,131 @@
---
name: research-synthesis
description: Synthesize extracted document evidence into a clear, traceable conclusion, brief, or decision-ready report
license: MIT
compatibility: opencode
metadata:
audience: analysts
workflow: research
stage: synthesis
---
## What I do
- Synthesize extracted evidence into a coherent answer
- Build conclusions that remain traceable to source material
- Identify consensus, conflicts, gaps, and unresolved questions
- Produce outputs such as briefs, summaries, comparison matrices, decision memos, and research reports
- Keep factual findings separate from recommendations or interpretation
## When to use me
Use this after evidence has been extracted and structured.
Examples:
- You need a final answer to a document-based research question
- You need an executive summary grounded in source material
- You need a position paper or internal brief
- You need a gap analysis or comparison across documents
- You need a recommendation with explicit evidence support
## Inputs I expect
Provide:
- Research objective
- Extracted evidence table or notes
- Optional comparison table
- Desired output type, such as:
- summary
- brief
- memo
- report
- gap analysis
- comparison matrix
- recommendation
## Workflow
1. Restate the question being answered
2. Group evidence by theme or sub-question
3. Identify:
- Supported conclusions
- Partial support
- Contradictions
- Missing evidence
4. Draft findings with explicit traceability
5. Separate:
- Facts from documents
- Interpretation
- Recommendations
6. Produce a final structured output fit for the requested audience
7. End with known limitations and review points
## Output modes
### A) Research Brief
Use for concise decision support.
Structure:
- Question
- Short answer
- Key findings
- Conflicting evidence
- Gaps
- Recommended next step
### B) Research Report
Use for fuller analytical output.
Structure:
- Objective
- Scope
- Method
- Findings by theme
- Evidence-backed conclusion
- Known gaps and limitations
- Appendix with source references
### C) Gap Analysis
Use when comparing required versus documented state.
Structure:
- Assessment topic
- Evidence found
- Gap
- Impact
- Confidence
- Review needed
## Traceability rule
For every substantive conclusion, include a source anchor such as:
- document name
- section or page
- extracted finding number if available
If traceability is weak, say so explicitly.
## Quality bar
- Conclusions must follow from the extracted evidence
- Contradictions must be surfaced, not hidden
- Distinguish "document says" from "my recommendation"
- State limits of the available corpus
- Prefer precise wording over polished vagueness
## Do not
- Do not introduce facts that were not extracted
- Do not overclaim certainty
- Do not bury disagreements between documents
- Do not produce recommendations without showing the evidence basis
- Do not omit limitations
## Companion skill sequence
Recommended sequence:
1. `document-triage`
2. `evidence-extraction`
3. `research-synthesis`
Use all three together for rigorous document-based research with clear traceability.