OKF generator

Create an OKF bundle for my SaaS app.

First inspect the repository, product docs, database schema, analytics notes, and dashboards that are available to you. Then create an `okf/` folder that helps humans and AI agents understand the app's core commercial knowledge.

Use this folder structure as the starting point:

okf/
|-- index.md
|-- log.md
|-- metrics/monthly-recurring-revenue.md
|-- metrics/churn-rate.md
|-- tables/subscriptions.md
|-- dashboards/revenue-dashboard.md
`-- playbooks/revenue-review.md

Declare `okf_version: "0.2"` in the root index. For every non-reserved concept file, add YAML frontmatter with `type`, `title`, `description`, `resource`, `tags`, `generated`, and `sources` when source material exists. Use `Metric`, `Table`, `Dashboard`, and `Playbook` types where appropriate. Record the real producer in `generated.by` and the last meaningful change in `generated.at` as an ISO 8601 datetime with a UTC offset. Add `verified`, `status`, and `stale_after` only when the available evidence supports them.

Write concise Markdown bodies that explain the concept, where the source lives, how it is calculated or used, known caveats, and related files. Use standard Markdown links. Prefer bundle-relative links such as `/tables/subscriptions.md` for spec alignment, or use ordinary relative links consistently when the bundle must render without an OKF-aware resolver. Do not invent business rules, SQL logic, or dashboard behavior. If a fact is unknown, add it to `okf/log.md` under "Questions for maintainers".

When finished, summarize every file created and tell me how to validate the folder with the OKF validator.

Create an OKF bundle for my Laravel app.

Inspect the Laravel routes, controllers, models, policies, jobs, commands, migrations, config files, tests, and README files before writing. Create an `okf/` folder that explains the application as linked Open Knowledge Format concept files.

Use this folder structure as the starting point:

okf/
|-- index.md
|-- log.md
|-- routes/web.md
|-- routes/api-customers.md
|-- models/user.md
|-- policies/customer-policy.md
|-- jobs/sync-stripe-customer.md
`-- commands/rebuild-search-index.md

Declare `okf_version: "0.2"` in the root index. For every non-reserved concept file, add YAML frontmatter with `type`, `title`, `description`, `resource`, `tags`, `generated`, and `sources` when source material exists. Use types such as `Route`, `Model`, `Policy`, `Job`, `Command`, `Integration`, and `Workflow`. Record only real sources and producer identity. Add `verified`, `status`, and `stale_after` only when the repository supports those claims.

The Markdown body should explain what the concept does, the source files behind it, important dependencies, failure modes, permissions, related database tables, and related OKF files. Link related concepts with standard Markdown paths. Prefer bundle-relative links for spec alignment, or use ordinary relative links consistently when the bundle must render without an OKF-aware resolver. Do not guess hidden behavior. If the repository does not show something clearly, record the question in `okf/log.md`.

When finished, summarize the created OKF files and note any routes, jobs, or models that still need maintainer confirmation.

Create an OKF bundle for my WordPress site.

Inspect the theme, plugins, custom post types, taxonomies, ACF field groups, templates, shortcodes, editor patterns, and available documentation. Create an `okf/` folder that explains the site structure in Open Knowledge Format.

Use this folder structure as the starting point:

okf/
|-- index.md
|-- log.md
|-- post-types/product.md
|-- taxonomies/product-category.md
|-- acf/product-fields.md
|-- templates/single-product.md
`-- plugins/woocommerce.md

Declare `okf_version: "0.2"` in the root index. For every non-reserved concept file, add YAML frontmatter with `type`, `title`, `description`, `resource`, `tags`, `generated`, and `sources` when source material exists. Use types such as `PostType`, `Taxonomy`, `FieldGroup`, `Template`, `Plugin`, and `Workflow`. Do not invent sources, review events, usage counts, or owners.

Write Markdown that explains what each concept controls, where it is configured, which templates or plugins depend on it, how editors use it, and which related OKF files matter. Use standard Markdown links and choose one link form consistently. Do not invent plugin settings or editorial policies. Put unknowns in `okf/log.md` as maintainer questions.

When finished, summarize the files created and explain how to upload the `okf/` folder to the OKF validator.

Create an OKF bundle for my API docs.

Inspect the OpenAPI file, route definitions, controller code, SDK docs, examples, tests, authentication logic, and error handling. Create an `okf/` folder that makes the API understandable as linked Open Knowledge Format concept files.

Use this folder structure as the starting point:

okf/
|-- index.md
|-- log.md
|-- endpoints/create-customer.md
|-- endpoints/list-invoices.md
|-- schemas/customer.md
|-- errors/rate-limit.md
`-- auth/api-key-authentication.md

Declare `okf_version: "0.2"` in the root index. For every non-reserved concept file, add YAML frontmatter with `type`, `title`, `description`, `resource`, `tags`, `generated`, and `sources` when source material exists. Use types such as `Endpoint`, `Schema`, `Error`, `Authentication`, `RateLimit`, and `Workflow`. Do not invent sources, review events, usage counts, or owners.

Each Markdown body should explain the request, response, constraints, source route or spec location, relevant schemas, common errors, and related files. Link endpoints to schemas, auth rules, and errors with standard Markdown paths and choose one link form consistently. Do not invent parameters, status codes, or limits. Put missing details in `okf/log.md`.

When finished, provide a short summary of generated files and validation steps.

Create an OKF bundle for my data warehouse.

Inspect the warehouse schema, dbt models, SQL queries, metric definitions, BI dashboards, lineage docs, freshness checks, and data quality tests available to you. Create an `okf/` folder that explains the analytical system as linked Open Knowledge Format concept files.

Use this folder structure as the starting point:

okf/
|-- index.md
|-- log.md
|-- datasets/sales.md
|-- tables/orders.md
|-- tables/customers.md
|-- metrics/gross-revenue.md
|-- lineage/order-revenue-lineage.md
`-- dashboards/sales-performance.md

Declare `okf_version: "0.2"` in the root index. For every non-reserved concept file, add YAML frontmatter with `type`, `title`, `description`, `resource`, `tags`, `generated`, and `sources` when source material exists. Use types such as `Dataset`, `Table`, `Metric`, `Lineage`, `Dashboard`, and `QualityCheck`. Add verification and freshness fields only when owners, checks, and review deadlines are documented.

The Markdown body should state grain, owners if known, source tables, transformations, metric formulas, freshness expectations, caveats, and related OKF files. Use standard Markdown links and choose one link form consistently. Do not invent SQL, owners, freshness SLAs, or definitions. Put uncertain items in `okf/log.md`.

When finished, summarize the generated bundle and include validation instructions.

Create an OKF bundle for my company knowledge base.

Inspect the available docs, README files, runbooks, policies, decision records, team notes, and system documentation. Create an `okf/` folder that turns important organizational knowledge into linked Open Knowledge Format concept files.

Use this folder structure as the starting point:

okf/
|-- index.md
|-- log.md
|-- teams/support.md
|-- policies/refunds.md
|-- systems/billing.md
|-- playbooks/incident-response.md
`-- decisions/pricing-packaging.md

Declare `okf_version: "0.2"` in the root index. For every non-reserved concept file, add YAML frontmatter with `type`, `title`, `description`, `resource`, `tags`, `generated`, and `sources` when source material exists. Use types such as `Team`, `Policy`, `System`, `Playbook`, `Decision`, and `Process`. Do not invent sources, review events, usage counts, or owners.

Write practical Markdown bodies that define the concept, state where the source material came from, identify related systems or owners when visible, and link related OKF files. Do not invent internal policies, owners, or decisions. Add uncertain or missing details to `okf/log.md`.

When finished, summarize the generated files and list the highest-priority maintainer review questions.

Create an OKF bundle for my AI agent context.

Inspect the repository, product docs, tool docs, runbooks, policies, data definitions, API docs, and examples that the agent will need before acting. Create an `okf/` folder that gives the agent durable Open Knowledge Format context.

Use this folder structure as the starting point:

okf/
|-- index.md
|-- log.md
|-- systems/billing.md
|-- tools/stripe.md
|-- metrics/monthly-recurring-revenue.md
|-- playbooks/support-triage.md
`-- constraints/agent-safety-rules.md

Declare `okf_version: "0.2"` in the root index. For every non-reserved concept file, add YAML frontmatter with `type`, `title`, `description`, `resource`, `tags`, `generated`, and `sources` when source material exists. Use types such as `System`, `Tool`, `Metric`, `Playbook`, `Constraint`, and `Workflow`. Add verification and lifecycle fields only when a real person or process performed the check.

The Markdown body should explain what the agent must know, what source file or document supports it, which actions are allowed or risky, and which related files should be read next. Use standard Markdown links and choose one link form consistently. Do not invent tool permissions, safety rules, or business logic. Put unknowns in `okf/log.md`.

When finished, summarize the files created and recommend the first validation and maintainer review steps.