agentleFS
aemerson-commitsaemerson-commits/shareable-skills/skills/propagate-feature/SKILL.md

propagate-feature

Skill1 starsChanged 8 months agoMITView on GitHub

Replicate features across projects with independent codebases — diff, adapt, apply. For cross-project propagation when projects have component copies instead of shared imports.

The file

Show its rules and text

We split this skill into the rules it gives an agent

21 rules. About 0 are common, 18 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈18

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When a feature is built in one project and needs to exist in another project that has its own component copies (not shared imports).

    line 8
  2. Distinctive:

    After modifying components that another project also has copies of

    line 12
  3. Distinctive:

    After adding a feature to one project that should exist in another

    line 13
  4. Very specific:

    When /audit-components flags drift between project copies

    line 14
  5. Distinctive:

    When user says "also add this to [other project]" or "propagate to [project]"

    line 15
  6. Distinctive:

    Wait for user approval on conflicts.

    line 76
  7. Distinctive:

    Verify env var names match target config

    line 87
  8. Distinctive:

    Do NOT touch source project files

    line 89
  9. Distinctive:

    If shared/ was also modified: build source project too

    line 95
  10. Distinctive:

    Verify propagated components have same props interface

    line 98
  11. Distinctive:

    Verify API endpoints handle same actions/params

    line 99
  12. Distinctive:

    Verify no broken imports in target project

    line 100
  13. Distinctive:

    Verify CSS additions don't collide with target's existing styles

    line 101
  14. Distinctive:

    Before modifying a component that exists in both projects:

    line 123
  15. Distinctive:

    Read the file in both projects

    line 124
  16. Very specific:

    Run diff -u target/src/path source/src/path to see divergence

    line 125
  17. Very specific:

    Always grep for class names in BOTH App.css AND component CSS files.

    line 135
  18. Distinctive:

    NEVER blindly copy entire files — always diff and apply hunks

    line 139
  19. Distinctive:

    NEVER overwrite target-specific adaptations (extra features, project-specific logic)

    line 140
  20. Distinctive:

    NEVER propagate without checking import path differences

    line 141
  21. Distinctive:

    If a component has diverged significantly (>50% different), flag for user decision rather than auto-merging

    line 142

≈ “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

Propagate Feature — Cross-Project Replication

When a feature is built in one project and needs to exist in another project that has its own component copies (not shared imports). The primary use case is when two projects share component structure but have diverged over time.

When to Use

  • After modifying components that another project also has copies of
  • After adding a feature to one project that should exist in another
  • When /audit-components flags drift between project copies
  • When user says "also add this to [other project]" or "propagate to [project]"

Arguments

  • --source=<project> (required: source project)
  • --target=<project> (required: target project)
  • --files=<glob> (optional: specific files to propagate)
  • --all — propagate all drifted files (uses diff to find them)

Phase 1: Drift Analysis (2 Parallel Agents, model: "opus")

Agent: Component Differ

Compare source and target component files.

For each file in the copy relationship:
1. Run diff between source and target versions
2. Classify each difference:
   - SOURCE_ONLY: Change exists only in source (needs propagation)
   - TARGET_ONLY: Change exists only in target (project-specific adaptation)
   - CONFLICT: Both sides changed the same area (needs manual resolution)
3. For SOURCE_ONLY changes: extract the specific hunks that need to apply

Output: Per-file diff report with classification

Agent: API Differ

Compare source and target API function files.

For each API file in the relationship:
1. Diff the files
2. Identify: new endpoints in source, modified endpoints, source-only logic
3. Check: does the target have different bindings, different env vars?
4. Flag any endpoint that references project-specific resources

Output: Per-file API diff with adaptation notes

Phase 2: Adaptation Plan (Main Agent)

Present the diff analysis to user:

## Propagation: {source} → {target}

### Files to Propagate
| File | Changes | Type | Risk |
|------|---------|------|------|
| ComponentA.jsx | +new feature panel | SOURCE_ONLY | Low |
| api-handler.js | +new endpoint guards | SOURCE_ONLY | Low |
| Dashboard.jsx | +customer filter | CONFLICT | Medium |

### Conflicts (need your input)
- Dashboard.jsx: Source added customer filter at line 45. Target has testing tab at same location. How to merge?

### Auto-Adaptations
- Import paths adjusted (project-relative)
- Binding names verified against target config

Wait for user approval on conflicts.

Phase 3: Apply (1 Worktree Agent, model: "opus")

Agent: Propagator (worktree)

For each approved file:

  1. SOURCE_ONLY changes: Apply the diff hunks to target file
  2. CONFLICT resolution: Apply user's chosen resolution
  3. Auto-adapt:
    • Adjust import paths for target project structure
    • Verify env var names match target config
    • Adjust CSS class prefixes if projects use different conventions
  4. Do NOT touch source project files

Phase 4: Verification (2 Parallel Agents, model: "opus")

Agent: Build Verifier

  • cd {target} && npm run lint && npm run build
  • If shared/ was also modified: build source project too

Agent: Consistency Checker

  • Verify propagated components have same props interface
  • Verify API endpoints handle same actions/params
  • Verify no broken imports in target project
  • Verify CSS additions don't collide with target's existing styles

Phase 5: Report

## Propagation Complete: {source} → {target}

### Files Modified
| File | Changes Applied |
|------|----------------|

### Remaining Drift (intentional)
| File | Target-Only Changes | Reason |
|------|-------------------|--------|

### Build Status
- {target}: PASS/FAIL
- {source}: PASS/FAIL (if modified)

Pre-Edit Divergence Check (MANDATORY)

Before modifying a component that exists in both projects:

  1. Read the file in both projects
  2. Run diff -u target/src/path source/src/path to see divergence
  3. Identical sections — safe to change in both
  4. Diverged sections — require project-specific edits

CSS File Mapping

Projects may store equivalent styles in different files:

  • Some projects use component-specific .css files (e.g., FeatureModal.css)
  • Others consolidate into App.css

Always grep for class names in BOTH App.css AND component CSS files.

Anti-Patterns

  • NEVER blindly copy entire files — always diff and apply hunks
  • NEVER overwrite target-specific adaptations (extra features, project-specific logic)
  • NEVER propagate without checking import path differences
  • If a component has diverged significantly (>50% different), flag for user decision rather than auto-merging

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.