solo-history-manager

Records development history and decision context by phase and issue in Markdown files.

Updated Apr 23, 2026
One-click install
npx skills add https://github.com/cjrain-12505614/solo-forge-marketplace --skill solo-history-manager-cjrain-12505614
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: solo-history-manager
Source: https://github.com/cjrain-12505614/solo-forge-marketplace/tree/main/solo-forge-v1.2.0/skills/solo-history-manager
Command: npx skills add https://github.com/cjrain-12505614/solo-forge-marketplace --skill solo-history-manager-cjrain-12505614

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code tells you what a system does now, but not why it was built that way. Over time, the constraints, trade-offs, and stakeholder requests behind past decisions are forgotten, causing developers to repeat mistakes or undo intentional design choices. This Skill preserves the "why" of development in a structured history archive. ## Core Features & Use Cases - Phase-based history: Records each development phase's background, goals, architecture decisions, technical constraints, and known tech debt in phase-N.md files. - Request tracking: Captures stakeholder or issue-driven requests in requests/ files, separating what was implemented from remaining constraints and unimplemented reasons. - Timeline overview: Maintains a _timeline.md summarizing the overall development flow and major architecture decisions across phases. - Use Case: Before refactoring a module, ask why it was designed a certain way; the Skill surfaces the original issue, the trade-offs accepted at the time, and which constraints still apply. ## Quick Start Record the development history for this completed phase, including the background, key changes, and the reasons behind the architecture decisions.

Frequently Asked Questions about solo-history-manager

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

FAQPage Schema
How do I document why code was written a certain way?▼

Record the background, goals, and architecture decisions for each development phase in a phase-N.md file, and log stakeholder or issue requests separately. Focus on the reason for changes rather than describing what the code does.

What is the difference between a decision log and development history?▼

A decision log records what was decided, while development history records why the system evolved as it did, including constraints and trade-offs. This Skill complements decision trackers and lessons-learned logs by covering the context layer.

How do I track stakeholder requests that were only partially implemented?▼

Create a dated request file under the requests directory that separates what was implemented from remaining constraints, including the reasons anything was not reflected. Note the version and timing of what was applied.

When should I write development history entries?▼

Write a phase file when a development phase completes, a request file when a stakeholder or issue request is reflected, and update the timeline when major architecture decisions occur. Updating alongside regular status reports keeps context continuous.

Can development history replace reading the current code?▼

No. History explains why the code exists in its current form, while the code shows what it does. Both must be read together for accurate interpretation before making changes.