Skip to content

example-workflow.md

Latest commit

 

History

History
200 lines (139 loc) · 5.85 KB

example-workflow.md

File metadata and controls

200 lines (139 loc) · 5.85 KB
Raw

Example Workflow

This example shows how KnowledgeOS turns one useful work update into maintained knowledge over time.

The goal is not to copy this exact project. The goal is to understand the flow:

raw update -> value check -> routing -> project memory -> daily log -> weekly synthesis -> current judgment

Scenario

A user is testing a small local-first habit tracker.

They send this to their agent:

Save to KnowledgeOS:
I started a small project to test a local-first habit tracker. The key decision is to keep data in plain Markdown before building any app UI. I want to validate whether the file format is useful before adding database sync or mobile features.

Step 1. Agent reads the operating context

Before writing, the agent reads:

MEMORY_RULES.md
CAPTURE_PROTOCOL.md
KNOWLEDGE_SCHEMA.md
config/taxonomy.yaml
INDEX.md

The agent checks:

  • Does this have long-term value?
  • Does it contain private or sensitive details?
  • Which semantic category does it belong to?
  • Is there already a related project or idea page?
  • Should this update an existing page or create a new one?

Step 2. Agent applies the value check

This update is worth saving because it contains:

  • a new project direction
  • a concrete product decision
  • a testable hypothesis
  • a constraint that future work should remember

It is not saved as a raw transcript. It is converted into structured project memory.

Step 3. Agent routes by taxonomy

The agent identifies the content as projects or ideas.

It reads config/taxonomy.yaml:

taxonomy:
  projects: "02-projects"
  ideas: "04-ideas"

Because the user said they started a project, the agent chooses:

02-projects/local-first-habit-tracker.md

If the project were still only a concept, it could start under:

04-ideas/local-first-habit-tracker.md

Step 4. Agent creates or updates project memory

The project file might look like this:

# Local-First Habit Tracker

## Project Summary
A small experiment to validate whether a habit tracker can begin as a local Markdown-based system before adding an app UI, database, sync, or mobile features.

## Current Status
Early validation.

## Current Judgment / Compiled Truth
The useful first test is not the interface. The useful first test is whether plain Markdown can represent habit data clearly enough to support review, editing, and later automation.

## Key Decisions
- Start with Markdown as the source of truth.
- Avoid database sync until the file format proves useful.
- Delay mobile features until the core capture/review loop works.

## Evidence Timeline
- YYYY-MM-DD: Started the project and chose a local-first Markdown data model as the first validation path.

## Open Questions
- What is the minimum habit record format?
- How should weekly habit review work?
- When does the system need an app UI instead of plain files?

## Next Actions
- Define the smallest useful habit entry template.
- Test one week of manual entries.
- Review whether Markdown is still readable after repeated use.

## Relations
- [[03-workflows/template]]
- [[05-learning/template]]

The exact links should point to real files in the user's vault. This starter example uses generic template links.

Step 5. Agent updates the daily log

The agent adds a short trace under the reviews path from config/taxonomy.yaml:

90-reviews/daily/YYYY-MM-DD.md

Example:

# YYYY-MM-DD Daily Capture Log

## Captures
- Added project memory for Local-First Habit Tracker: early validation of a Markdown-first habit data model before app UI or sync.

## Updated Files
- `02-projects/local-first-habit-tracker.md`

## Patterns
- Product validation should begin with the smallest durable representation before adding interface or infrastructure.

## Open Questions
- Does the Markdown format remain useful after one week of real entries?

Step 6. Weekly synthesis updates the current judgment

After several daily logs, a weekly review might notice:

  • the project has repeated evidence around file-format design
  • no UI work should start until the Markdown habit record is tested
  • the next bottleneck is review quality, not data entry

The weekly review could suggest updating the project page:

## Current Judgment / Compiled Truth
The project should continue as a file-format and review-loop experiment. Building an app UI now would hide the real question: whether the habit records are useful enough to review, edit, and automate as Markdown.

This is the core KnowledgeOS behavior: old notes are not just stored. They are maintained into current judgment.

Step 7. Maintenance audit keeps the vault healthy

A maintenance audit can later check:

  • Does the project file still have a clear current judgment?
  • Are there broken wikilinks?
  • Are there stale open questions?
  • Did the project outgrow projects and require a workflow or research note?
  • Are any private details accidentally included?

What this example demonstrates

This workflow demonstrates the reusable pattern:

  1. The user gives a messy but useful update.
  2. The agent decides whether it deserves persistence.
  3. The agent routes by semantic category from config/taxonomy.yaml.
  4. The agent updates durable project memory instead of dumping raw text.
  5. The daily log records the change.
  6. Weekly synthesis can later update the current judgment.
  7. Maintenance audits keep the system trustworthy.

Minimal prompt to reproduce this flow

Save this to KnowledgeOS if it has long-term value.

Before writing:
1. Read MEMORY_RULES.md, CAPTURE_PROTOCOL.md, KNOWLEDGE_SCHEMA.md, config/taxonomy.yaml, and INDEX.md.
2. Decide whether this is worth saving.
3. Remove private or sensitive details.
4. Search for related existing notes.
5. Update an existing page if possible.
6. Create a new page only if needed.
7. Update today's daily log.
8. Report what changed.

Content:
[PASTE UPDATE HERE]