Decisions

  • Which categories to use? → skills, agents, hooks, features, code
  • Subfolders per category or tags in frontmatter? → Subfolders chosen

User Tasks


Summary

Split proposals into typed categories so they’re easier to review and route.

Problem / Motivation

All proposals currently land in a flat vault/90_inbox/proposals/ folder. As the system grows, different types of proposals need different review approaches — a skill suggestion is quick to evaluate, a codebase architecture change needs deeper thought, and a CLAUDE.md update affects all future sessions. A flat list makes it hard to prioritize and batch-review.

Proposed Solution

Categorize proposals by type, either via subfolders or frontmatter tags. Each category has a clear scope and review expectation.

Candidate categories:

CategoryScopeExample
skillNew or improved slash command”Add a /health skill”
agentNew sub-agent definition”Create a vault-cleanup agent”
ruleNew or updated path-scoped rule”Add rules for 20_knowledge/“
hookNew hook script”Pre-commit hook for protected files”
claude-configCLAUDE.md, settings.json, or memory changes”Add tone rules to CLAUDE.md”
vaultVault structure, templates, dashboards”Reorganize 90_inbox/“
codebasesrc/ architecture, patterns, dependencies”Use dependency injection pattern”
workflowProcess changes, how we work”Change feature review flow”

Open Questions

1. Category List

Question: Which categories to use?

OptionDescription
A) All 8 aboveFull granularity from the start
B) Simplified (4)skill, config, vault, codebase — merge smaller ones
C) Start with tags onlyNo subfolders, just a category: field in frontmatter

Recommendation: Option C — least structural overhead, easy to recategorize later.

Decision: Simplified set — skills, agents, hooks, features, code.

2. Storage Approach

Question: Subfolders per category or tags in frontmatter?

OptionDescription
A) Frontmatter tagsKeep flat folder, add category: skill to frontmatter. Filter via search.
B) Subfoldersproposals/skill/, proposals/vault/, etc. Visual separation in Obsidian.
C) Prefix namingproposal-skill-xxx.md, proposal-vault-xxx.md. No folder change.

Recommendation: Option A — proposals are temporary (approve/reject/defer), so heavy folder structure isn’t worth it.

Decision: Option B (subfolders) — chosen for visual clarity and simpler routing logic.


Phase Overview

PhaseDescriptionStatus
Phase 1Add category field to proposal template and existing proposalsdone
Phase 2Update workflow docs and dashboard filteringdone

Phase 1: Categorize Proposals —

Goal: Add a category field to the proposal template and backfill existing proposals.

File / FeatureDetailsOwnerStatus
vault/_templates/proposal.mdAdd category: to frontmatteropus
Existing proposalsBackfill category on current proposalsopus

Phase 2: Workflow Integration —

Goal: Make categories visible in review workflow.

File / FeatureDetailsOwnerStatus
vault/00_system/docs/workflow.mdDocument category types in Proposals sectionopus
Review dashboardGroup proposals by category if usefulmv

Test

Manual tests

TestExpectedActualLast
pending-

AI-verified tests

ScenarioExpected behaviorVerification method

E2E tests

ScenarioAssertion

Integration tests

ComponentCoverage

Unit tests

ComponentTestsCoverage

History

DateEventDetails
2026-03-04CreatedBased on observation that flat proposal folder doesn’t scale
2026-03-12ImplementedSubfolder approach chosen (skills, agents, hooks, features, code). All docs updated.

References

  • FR-066 (Self-Improving System) — proposals are the output of self-improvement
  • FR-028 (Feature Workflow Automation) — automation could auto-categorize proposals