Extract and Generalize Procedures

Overview

After completing a goal, extract reusable procedures and generalize them for storage in the library, enabling GOSM to learn from completed work.

Steps

Step 1: Review project phases

Go through each phase in COMPLETE_PLAN.md and identify:

What procedure was followed for each phase?
- Was it an existing library procedure?
- Was it ad-hoc / invented for this project?
- Was it adapted from something else?
Rate each procedure for extraction potential:
- Was it structured (clear steps) or intuitive?
- Could it apply to other projects?
- Did it produce good results?
Note any novel approaches:
- What was done differently than usual?
- What worked surprisingly well?
- What workarounds became standard practice?

Create candidate list with context for each.

Step 2: Review custom gates

Check the gates/ folder for custom or adapted gates:

Identify any gates created for this project:
- What checks were performed?
- Were they project-specific or general?
- Could they apply to other projects?
Note gates that were particularly valuable:
- Which gates caught real issues?
- Which gates would have helped earlier?
- Which gates could become standard?
Add valuable gates to candidate list

Gates often contain implicit procedures (the process of evaluation).

Step 3: Score candidates

For each candidate procedure or gate, score 1-5 on:

GENERALIZABILITY (weight: 0.3)

Could this apply to other projects?
5: Universal - applies across many domains
3: Moderate - applies within a domain
1: Specific - only this project type

VALUE (weight: 0.3)

How much effort does this save?
5: Major - saves days/weeks of work
3: Moderate - saves hours
1: Minor - saves minutes

COMPLETENESS (weight: 0.2)

How well is it documented?
5: Fully documented with examples
3: Key steps clear, some gaps
1: Mostly implicit knowledge

ABSTRACTION POTENTIAL (weight: 0.2)

Can specifics be removed without losing value?
5: Easy to parameterize
3: Some specifics can be abstracted
1: Heavily dependent on specifics

Calculate weighted average. Extract if >= 3.0

Step 4: Identify specific elements

For each procedure to extract, identify project-specific elements:

List all project-specific references:
- Named entities (people, products, companies)
- Domain-specific terminology
- Hardcoded values or thresholds
- Specific tools or technologies
Map specifics to parameter names:

Project-specific → Parameter

“atheism” → {topic} “philosophy” → {domain} “theist responses” → {counterposition} “10 interviews” → {sample_size} “3 weeks” → {duration}
Note which specifics are truly variable vs. essential:
- Some specifics are examples, not requirements
- Some are constraints that should remain

Step 5: Create parameters

Define formal parameters for the generalized procedure:

For each identified specific element, create parameter definition:

parameters:
  - name: topic
    description: "The subject being analyzed"
    type: string
    required: true
    example: "climate change"

  - name: domain
    description: "The field or area of focus"
    type: string
    required: false
    default: "general"

  - name: sample_size
    description: "Number of items to collect"
    type: integer
    required: false
    default: 10
    constraints:
      min: 5
      max: 100

Parameters should be:

Clearly named (what it represents)
Typed (string, integer, list, etc.)
Required or optional with defaults
Constrained where appropriate

Step 6: Generalize steps

Rewrite each step using parameters:

BEFORE (project-specific): “Research atheist philosophical arguments from academic sources”

AFTER (generalized): “Research arguments supporting {position} on {topic} from {source_type} sources”

Generalization principles:

Replace specific nouns with parameters
Keep action verbs unchanged
Preserve structure and sequence
Maintain clarity - generalized should be as clear as specific
Add notes for context where helpful

Check that generalized steps are still actionable:

Would someone know what to do?
Is it clear what the output should be?
Are there hidden dependencies?

Step 7: Document applicability

Define when this procedure should be used:

when_to_use:
  - "When creating persuasive content on any topic"
  - "When analyzing competing positions"
  - "When building argumentative documents"

when_not_to_use:
  - "For purely descriptive content"
  - "When positions are not in contention"
  - "For technical documentation"

applicability:
  domains:
    - "philosophical analysis"
    - "policy arguments"
    - "competitive analysis"

  goal_types:
    - "argumentative document"
    - "position paper"
    - "debate preparation"

  triggers:
    - "when asked to argue for a position"
    - "when comparing competing options"

Be specific enough to help with procedure discovery, but not so narrow that it’s rarely triggered.

Step 8: Add examples

Create 2-3 concrete instantiations showing the procedure in use:

examples:
  - name: "Climate policy analysis"
    context: "Analyzing carbon tax proposal"
    parameters:
      topic: "climate change policy"
      position: "carbon tax"
      counterposition: "market-only solutions"
      domain: "environmental economics"
    expected_output: "Position paper with counterargument analysis"

  - name: "Database selection"
    context: "Choosing database for new application"
    parameters:
      topic: "database selection"
      position: "PostgreSQL"
      counterposition: "MongoDB"
      domain: "software architecture"
    expected_output: "Technical comparison with recommendation"

Examples should:

Cover different domains to show generalizability
Include realistic parameter values
Show expected outputs
Be different from the source project

Step 9: Write to library

Create procedure file in library:

Determine correct location:
- library/procedures/extracted/{domain}/{procedure_id}.yaml
- Domain should match procedure’s primary domain
Use standard procedure template format with all sections:
- id, name, version, domain, description
- long_description
- tags
- when_to_use, when_not_to_use
- inputs, outputs
- steps (with id, name, action, inputs, outputs, verification)
- verification
- failure_modes
- examples
- gosm_integration

Add source attribution:

source:
  project: "{project_name}"
  extracted_date: "{date}"
  original_context: "{brief description}"

Validate YAML syntax before saving

Step 10: Update index

Add new procedure to library indexes:

Update library/INDEX.md:
- Add to “Extracted Procedures” section
- Include procedure ID, name, purpose, source
Update library/procedures/extracted/EXTRACTED_PROCEDURES_INDEX.md:
- Add entry with full details
Update domain-specific index if exists:
- E.g., library/procedures/extracted/{domain}/INDEX.md

Format for INDEX.md:

Procedure ID	Name	Purpose	Source
{id}	{name}	{purpose}	{source_project}

Step 11: Tag source project

Update the source project to record what was extracted:

Update project’s context.json or metadata:

{
  "extracted_procedures": [
    "{procedure_id_1}",
    "{procedure_id_2}"
  ],
  "extraction_date": "YYYY-MM-DD"
}

Update project’s LEARNINGS.md:
- Note which procedures were extracted
- Link to library locations
This creates traceability:
- Can find procedures by source project
- Can find projects that contributed to library

When to Use

After completing any project successfully
When novel approaches were developed during a project
When existing procedures were significantly adapted
During project retrospectives
When a repeatable pattern emerges across projects
When asked “how did you do that?” and realizing others could benefit
Before archiving a completed project
When noticing similar work being done repeatedly

Verification

Procedure is genuinely reusable (not just project-specific with placeholders)
Parameters are clearly defined with types and constraints
Steps are abstract but remain actionable
Applicability is well-defined and specific
Examples demonstrate usage across domains
Library location is correct for the domain
Index is updated in all relevant places
Source project is tagged for traceability

pcex - Extract and Generalize Procedures