원클릭으로 Manus에서 모든 스킬 실행

author-okf

스타1

포크0

업데이트2026년 6월 14일 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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

smithdak

smithdak/dossier

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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.

이 저장소의 다른 Skills

같은 저장소

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.