Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

author-okf

Sterne1

Forks0

Aktualisiert14. Juni 2026 um 21:54

Author or extract atomic, OKF-compliant concept documents that conform to Dossier's knowledge model. Use whenever turning raw/clean source content (or a topic) into knowledge-base concepts — processes, workflows, roles, decisions, systems, policies, artifacts, terms. Produces one well-formed markdown+YAML file per concept, with full provenance and typed relationships.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

smithdak

smithdak/dossier

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name	author-okf
description	Author or extract atomic, OKF-compliant concept documents that conform to Dossier's knowledge model. Use whenever turning raw/clean source content (or a topic) into knowledge-base concepts — processes, workflows, roles, decisions, systems, policies, artifacts, terms. Produces one well-formed markdown+YAML file per concept, with full provenance and typed relationships.

Author OKF Concepts

Turn content into atomic, single-source-of-truth OKF concepts that conform to knowledge/model/index.md. Read the model first — it is the contract.

Procedure

Load the contract. Read knowledge/model/index.md for the concept types, base frontmatter schema, and the relationship vocabulary.
Identify the atoms. Break the source into the smallest concepts that can change independently. One concept = one file. If two facts can change separately, they are two files.
Type each atom. Assign a type (role · process · workflow · decision · system · policy · artifact · term, or concept fallback). Add a new type only with the knowledge-architect's blessing.
Write each file at knowledge/<area>/<slug>.md (or the client's KB root) with:
- Frontmatter: type (required), id (stable slug), title, description, plus resource, owner, status, confidence, source, tags, timestamp as available.
- Body: clear headings; the human-readable truth.
Wire relationships. Add typed edges in frontmatter (owner, uses, governed_by, steps, produces, relates_to, …) AND mirror the important ones as [[id]] links in the body. Same edge, two surfaces.
Stamp provenance. Every atom gets source (where it came from) and confidence (verified = grounded in a source · asserted = human judgment · inferred = LLM-derived). Never mark inferred content as verified.
Validate. Run verify-kb (or its checks) before declaring done.

Rules

Atomic. Single-source-of-truth. Link, don't copy.
Never fabricate. If a fact or rationale isn't in the source, omit it or write "not captured" — do not invent.
Stable ids. Slugs are permanent addresses; never recycle. Evolve via status/supersedes, not renaming.
Capture judgment. When the source reveals why something is done, write a decision concept — that's the IP.

Output

A set of OKF files, each independently readable (cat-able) and graph-parseable, plus a one-line summary of concepts created and any gaps you couldn't fill.

Mehr aus diesem Repository

gleiches Repository

verify-kb

smithdak/dossier

Audit an OKF knowledge base for integrity before it ships. Use to verify a generated/edited KB — checks OKF compliance, atomicity, link integrity, provenance/confidence, coverage gaps, and stale content. Produces a severity-ranked report; does not silently fix.

2026-06-211

adoption-readout

smithdak/dossier

Generate a client's L2 "adoption readout" — the Ladder (DEC-0052's wedge). From a provisioned client's served OKF, run the deterministic 4-axis scorer over their process/workflow atoms, then narrate a sequenced Now/Next/Later transformation roadmap and emit it as a sovereign OKF `artifact` in the CLIENT's own repo. Use after a client is ingested + served (KNOWLEDGE-BRIEF generated) to produce the post-diagnostic readout that lands the wedge ("we'll take you to where we already are") and opens the Agency conversation. Human-curated authoring; reads the client's OWN OKF, never perturbs Dossier's KB.

2026-06-201

docs-ia

smithdak/dossier

Architect a world-class, ATOMIC information architecture for a Dossier docs site — turn a flat OKF knowledge base into a navigable, scannable, readable reading experience whose structure is DERIVED FROM THE KNOWLEDGE GRAPH, never hand-maintained. Use when a docs surface is hard to navigate (giant flat sidebars, no section overviews, no wayfinding, every page a dead end), when onboarding a new client's KB to the docs, or when asked to improve docs IA / navigation / readability.

2026-06-191

generate-landing

smithdak/dossier

Generate a tailored client landing instance — a typed LandingContent module — from a provisioned client's OKF repo and tenant manifest. Use after a client is ingested and served (KNOWLEDGE-BRIEF generated) to produce a client-specific marketing landing that re-frames Dossier's universal messaging in the client's own vocabulary, with a hero artifact that is a REAL atom from the client's repo. Human-curated authoring, not a hosted runtime.

2026-06-181

github-markdown

smithdak/dossier

Wield the full power of GitHub-Flavored Markdown (GFM) and GitHub's rendering pipeline to design world-class documentation — alerts/admonitions, collapsible sections, tables, task lists, mermaid diagrams, math, footnotes, themed images, auto-anchors, and badges. Use whenever authoring a README, guide, or any markdown that renders on GitHub (and, with the noted caveats, on the Astro Starlight surface). The reference + procedure the documentation-engineer reaches for.

2026-06-141

ingest-client

smithdak/dossier

Run the ingestion sweep that pulls a new client's raw knowledge into Dossier — public website (Firecrawl), files (Unstructured), and Microsoft 365/SharePoint (Graph delta + Copilot connectors) — normalized to clean, provenance-stamped markdown ready for extraction. Use when onboarding a client or refreshing their sources.

2026-06-141

name	author-okf
description	Author or extract atomic, OKF-compliant concept documents that conform to Dossier's knowledge model. Use whenever turning raw/clean source content (or a topic) into knowledge-base concepts — processes, workflows, roles, decisions, systems, policies, artifacts, terms. Produces one well-formed markdown+YAML file per concept, with full provenance and typed relationships.

Author OKF Concepts

Turn content into atomic, single-source-of-truth OKF concepts that conform to knowledge/model/index.md. Read the model first — it is the contract.

Procedure

Load the contract. Read knowledge/model/index.md for the concept types, base frontmatter schema, and the relationship vocabulary.
Identify the atoms. Break the source into the smallest concepts that can change independently. One concept = one file. If two facts can change separately, they are two files.
Type each atom. Assign a type (role · process · workflow · decision · system · policy · artifact · term, or concept fallback). Add a new type only with the knowledge-architect's blessing.
Write each file at knowledge/<area>/<slug>.md (or the client's KB root) with:
- Frontmatter: type (required), id (stable slug), title, description, plus resource, owner, status, confidence, source, tags, timestamp as available.
- Body: clear headings; the human-readable truth.
Wire relationships. Add typed edges in frontmatter (owner, uses, governed_by, steps, produces, relates_to, …) AND mirror the important ones as [[id]] links in the body. Same edge, two surfaces.
Stamp provenance. Every atom gets source (where it came from) and confidence (verified = grounded in a source · asserted = human judgment · inferred = LLM-derived). Never mark inferred content as verified.
Validate. Run verify-kb (or its checks) before declaring done.

Rules

Atomic. Single-source-of-truth. Link, don't copy.
Never fabricate. If a fact or rationale isn't in the source, omit it or write "not captured" — do not invent.
Stable ids. Slugs are permanent addresses; never recycle. Evolve via status/supersedes, not renaming.
Capture judgment. When the source reveals why something is done, write a decision concept — that's the IP.

Output

A set of OKF files, each independently readable (cat-able) and graph-parseable, plus a one-line summary of concepts created and any gaps you couldn't fill.