workflow-memory

Separate WF-* metadata nodes from agent-output artifacts in native Markdown workflows.

Updated Mar 20, 2026
One-click install
npx skills add https://github.com/jfriisj/coding-agents --skill workflow-memory
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: workflow-memory
Source: https://github.com/jfriisj/coding-agents/tree/main/context-ligt-workflow/skills/workflow-memory
Command: npx skills add https://github.com/jfriisj/coding-agents --skill workflow-memory

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Relational memory workflow using strictly native file paths (no Obsidian/MCP overhead). Enforces Just-In-Time (JIT) context protection (Baseline vs. Append) and strict document lifecycle cleanup to prevent markdown bloat.

Core Features & Use Cases

  • Separates strategic metadata WF-* nodes from heavy execution artifacts agent-output/*
  • Uses canonical WF filename rules and epic subtree grouping to maintain a clean historical graph
  • Enforces lifecycle cleanup by moving completed artifacts to closed/ and preserving WF-* nodes for history

Quick Start

Create a native Markdown workflow graph with WF-* nodes and ensure agent-output artifacts are cleaned up automatically.

Frequently Asked Questions about workflow-memory

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent markdown bloat in workflow documentation?

Prevent markdown bloat in workflow documentation by separating strategic metadata WF-* nodes from heavy agent-output execution artifacts. This approach enforces Just-In-Time context protection and strict lifecycle cleanup by moving completed artifacts to closed directories.

What is JIT context isolation for markdown memory workflows?

JIT context isolation for markdown memory workflows is a mechanism that separates Baseline context from Append context. It ensures deterministic native memory by strictly managing how metadata and execution artifacts are loaded and appended during epic-driven projects.

How do I set up a native markdown workflow graph without external dependencies?

Set up a native markdown workflow graph by creating WF-* nodes and grouping them into epic subtrees. This method uses canonical filename rules to maintain a clean historical graph without requiring external tools like Obsidian or MCP.

Does this markdown memory workflow require Obsidian or MCP to operate?

No, this markdown memory workflow does not require Obsidian or MCP to operate. It uses strictly native file paths to coordinate deterministic relational memory without adding external software overhead to your project.

What is the best way to manage agent-output baselines in epic-driven projects?

The best way to manage agent-output baselines in epic-driven projects is to enforce strict document lifecycle cleanup. This involves preserving WF-* nodes for history while moving completed execution artifacts to a closed directory to maintain a navigable graph.

When should I move workflow artifacts to a closed directory?

You should move workflow artifacts to a closed directory during lifecycle cleanup after execution is complete. This action prevents markdown bloat while preserving the original WF-* strategic metadata nodes to maintain a navigable historical workflow graph.