Run any Skill in Manus with one click

author-okf

Stars1

Forks0

UpdatedJune 14, 2026 at 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

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

smithdak

smithdak/dossier

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·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.

More from this repository

same 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.