open-dossier
SolidTurn any project folder into a source-driven knowledge dossier that compounds over time — ingest documents into traceable analyses, a living wiki, plans, actions and decisions. Use this skill whenever the user wants to process source documents (reports, transcripts, emails, decks, papers) into structured knowledge; asks to "ingest", "process" or "verwerk" a document, even a bare filename with no other context; wants a knowledge base, wiki or "second brain" for a project or client engagement; wants plans and action items derived from documents and traceable to their source; wants an existing pile of notes, summaries or already-processed documents restructured into a traceable knowledge base with an audit trail of where each fact came from; asks what a dossier knows ("query the dossier", "what do we know about X"); wants a briefing or one-page current-state synthesis of a case or file, especially when they need established fact separated from assumption or open question; or asks for a health check of the knowle
Install
Quality Score: 79/100
Skill Content
Details
- Author
- jpaarhuis
- Repository
- jpaarhuis/open-dossier
- Created
- 1 weeks ago
- Last Updated
- 5 days ago
- Language
- N/A
- License
- MIT
Bundled in these plugins
Similar Skills
Semantically similar based on skill content — not just same category
docforge
Design and generate a repository's documentation set — the docs/ tree, README and ARCHITECTURE, decision records (ADRs), a known-limitations register, a third-party dependency inventory, security policy, API error catalogs, data contracts and runbooks, AI-agent context files (AGENTS.md, CLAUDE.md, docs/agents/), plus audience overlays that speak to Business Analyst (BA) and Product Owner (PO) readers. Grounds every document in a knowledge-graph analysis of the actual source before writing, so nothing is invented, and stamps each document with git-hash provenance so staleness is decided by comparison, not by re-guessing. Host-neutral — works on any git host and never hardcodes one forge's paths, and checks for child repos (declared submodules or nested/vendored repos) before any multi-repo review. Use this skill whenever the user mentions documenting a repo or codebase, a docs folder, README or ARCHITECTURE files, ADRs or decision records, onboarding docs, runbooks, known limitations, dependency or licence inv
living-docs
Run a project's documentation as a living system — docs-first issues/PRDs, MADR-lite ADRs (supersede, never delete), Behavior Decision Records (BDRs), a project constitution, research artifacts, living Mermaid architecture diagrams, and semantic-index organization where every doc lands in exactly one place and indexes never drift. Use when setting up or maintaining project docs, writing an ADR/PRD/BDR/constitution/issue/research note, defining a term or acronym in the glossary, drawing or updating an architecture/flow/sequence diagram, splitting an oversized doc into an index, or enforcing the no-drift maintenance rule.
lore
Persistent project knowledge base so a new session resumes from recorded state instead of re-reading the whole codebase. Sets up and maintains docs/lore/ (STATE, ROADMAP, DECISIONS, LEARNINGS, JOURNAL): current status, phased progress path, why decisions were made, what was tried and failed, and dead ends not to retry. Use when: starting a new project or scaffolding its docs; beginning a session on a project that has docs/lore/ and you need context; finishing a task, fixing a bug, or making an architectural choice and the outcome should be recorded; the user says continue/resume, asks what the state is, asks to record a decision or lesson, or asks why something was done a certain way.