compound-engineering

Documents non-obvious bug fixes and engineering decisions as searchable markdown files in docs/solutions.

1|Updated Jul 18, 2025
One-click install
npx skills add https://github.com/gusgad/service-agent-by-sap --skill compound-engineering-gusgad
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: compound-engineering
Source: https://github.com/gusgad/service-agent-by-sap/tree/main/.agents/skills/compound-engineering
Command: npx skills add https://github.com/gusgad/service-agent-by-sap --skill compound-engineering-gusgad

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Hard-won debugging insights and design decisions evaporate when a work session ends, forcing every future session to re-investigate the same problems from scratch. This Skill captures those learnings as durable, searchable documentation so each unit of engineering work makes the next one easier. ## Core Features & Use Cases - Solution Capture: Writes one markdown file per learning to docs/solutions/<category>/ with a structured template covering problem, root cause, solution, and prevention. - Grounding Check: Searches docs/solutions/ with grep before investigating a bug, so already-solved problems are found instead of re-derived. - Capture Discipline: Defines clear rules for what to document (non-obvious root causes, durable decisions) versus what to skip (typos, unverified fixes, anything git history already covers). - Use Case: After spending hours tracing a multi-tenant database scoping bug, document the root cause and fix in docs/solutions/database-issues/ so the next session that hits a similar symptom finds the answer in minutes. ## Quick Start Document the root cause and fix for the bug we just solved as a new entry in docs/solutions so future sessions can find it.

Frequently Asked Questions about compound-engineering

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

FAQPage Schema
How do I document debugging solutions for future reference?▼

Write one markdown file per learning to docs/solutions/<category>/<slug>.md with sections for problem, root cause, solution, and prevention. Reference code with file:line links rather than pasted snippets so the documentation stays accurate as code changes.

What engineering decisions are worth documenting?▼

Document root causes that required real investigation and decisions between multiple viable approaches where the reasoning is not obvious from the code. Skip trivial fixes like typos, unverified work, and anything the code or tests already make clear.

How do I check if a bug is already documented before investigating?▼

Run grep -ril "<keyword>" docs/solutions/ to search existing entries before starting an investigation. If the directory does not exist yet, nothing has been captured and you can create it with the first entry.

When should I not write a solution document?▼

Do not document mid-investigation before the fix is verified, do not batch multiple unrelated learnings into one file, and do not duplicate an existing entry. Search docs/solutions first and update the existing document instead.

How do I keep engineering documentation findable across sessions?▼

Organize entries into flat browsable categories like build-errors, database-issues, and architecture-decisions, and add a short pointer to docs/solutions in the repository root instructions file such as CLAUDE.md or AGENTS.md.