agentleFS
Kastalien-ResearchKastalien-Research/thoughtbox/.agents/skills/workflows-compound/SKILL.md

workflows-compound

Skill64 starsChanged 4 months agoMITView on GitHub

Capture learnings from the workflow into reusable documentation. Stage 7 of the development workflow.

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 11 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If revision happened, it's also completed

    line 19
  2. Distinctive:

    If pre-conditions are not met, report what's missing and halt.

    line 21
  3. Distinctive:

    Read all workflow artifacts:

    line 27
  4. Very specific:

    If a reusable solution was produced, write it to docs/solutions/:

    line 60
  5. Distinctive:

    If significant patterns or discoveries should persist across sessions:

    line 89
  6. Distinctive:

    Check existing memory files for related entries

    line 91
  7. Distinctive:

    Update or add entries as appropriate

    line 92
  8. Distinctive:

    Do NOT capture every detail — focus on what's reusable

    line 132
  9. Distinctive:

    Do NOT write vague learnings like "testing is important" — be specific

    line 133
  10. Distinctive:

    Do NOT skip this stage because "nothing interesting happened" — every workflow teaches something

    line 134
  11. Distinctive:

    Do NOT write code — this is a documentation stage

    line 135
  12. Distinctive:

    Do NOT create solution docs for trivial changes — only for patterns worth reusing

    line 136

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Capture learnings from the current workflow: $ARGUMENTS

Purpose

You are executing Stage 7 (Compound) of the development workflow. Implementation is reviewed and revised. Your job is to extract reusable learnings from this workflow and persist them so future workflows benefit. You are NOT writing code — you are documenting what was learned.

Pre-Conditions

Before starting, verify:

  1. .workflow/state.json exists and currentStage is "compound"
  2. Review has passed (check stages.review.status is "completed")
  3. If revision happened, it's also completed

If pre-conditions are not met, report what's missing and halt.

Process

Step 1: Gather Evidence

Read all workflow artifacts:

  1. Workflow state: .workflow/state.json — timeline, iterations, stage notes
  2. Sub-agent summaries: .workflow/summaries/*.md — what was built
  3. Review report: .workflow/review-report.md — what was found
  4. Spec and ADR: The original design documents
  5. Git log: What actually changed
git log --oneline --since="$(jq -r .startedAt .workflow/state.json)" -- .

Step 2: Extract Learnings

Identify three categories of learnings:

Solutions — Reusable patterns for solving specific problems:

  • What problem was solved?
  • What approach worked?
  • What approach was tried and didn't work?
  • What would you do differently next time?

Discoveries — Things learned about the codebase or domain:

  • Unexpected behaviors encountered
  • Undocumented constraints discovered
  • Performance characteristics measured

Process — What worked or didn't in the workflow itself:

  • Which stages were smooth vs. painful?
  • Where did revision loops happen and why?
  • What spec assumptions were wrong?

Step 3: Write Solution Document

If a reusable solution was produced, write it to docs/solutions/:

# <Problem Title>

## Problem
[What problem this solves, in 2-3 sentences]

## Solution
[The approach that worked, with code references]

## Context
- Workflow: <id>
- Spec: <path>
- Date: <ISO date>

## Key Decisions
- [Decision 1]: [Why this choice was made]
- [Decision 2]: [Why this choice was made]

## What Didn't Work
- [Approach that was tried and abandoned, with brief explanation]

## Related
- [Links to specs, ADRs, or other solutions]

Step 4: Update Agent Memory

If significant patterns or discoveries should persist across sessions:

  1. Check existing memory files for related entries
  2. Update or add entries as appropriate
  3. Include fitness tags (HOT/WARM/COLD) per the DGM calibration rules

Step 5: Record and Handoff

  1. Update workflow state (.workflow/state.json):
    • Set stages.compound.status to "completed"
    • Set stages.compound.completedAt to current ISO timestamp
    • Set stages.compound.artifacts.solution to the solution doc path (if created)
    • Set currentStage to "reflection"
    • Update updatedAt
  2. Present the handoff:
    COMPOUND COMPLETE
    ==================
    
    Solutions captured: N
    Discoveries: N
    Process notes: N
    Solution doc: <path or "none — no reusable pattern identified">
    
    Next: Stage 8 - Reflection (/workflow-reflection)

What Makes a Good Learning

A learning is worth capturing if it meets ANY of these:

  • It would save >30 minutes if encountered again
  • It contradicts documentation or common assumptions
  • It reveals a non-obvious interaction between components
  • It's a pattern that applies beyond this specific feature

A learning is NOT worth capturing if:

  • It's specific to this feature with no broader applicability
  • It's already documented in the codebase or specs
  • It's a trivial fix that anyone would find quickly

Anti-Patterns

  • Do NOT capture every detail — focus on what's reusable
  • Do NOT write vague learnings like "testing is important" — be specific
  • Do NOT skip this stage because "nothing interesting happened" — every workflow teaches something
  • Do NOT write code — this is a documentation stage
  • Do NOT create solution docs for trivial changes — only for patterns worth reusing

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.