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.
In this repository51 other files it gives its agents.
- algorithmic-artSkill
- audit-componentsSkill
- canvas-designSkill
- cascade-orchestrationSkill
- consultSkill
- data-reconciliationSkill
- debug-collaborateSkill
- deep-root-causeSkill
- deploy-allSkill
- design-reverse-engineerSkill
- design-showcaseSkill
- docxSkill
- env-auditSkill
- evolveSkill
- frontend-designSkill
- full-stack-buildSkill
- full-stack-traceSkill
- gh-repo-reconSkill
- grill-meSkill
- handoffSkill
- html-slidesSkill
- insightSkill
- internal-commsSkill
- isolation-testSkill
- mcp-builderSkill
- model-selectionSkill
- pdfSkill
- persistent-issueSkill
- pre-merge-reviewSkill
- premise-auditSkill
- regression-bisectSkill
- research-gateSkill
- review-implSkill
- schema-checkSkill
- session-notesSkill
- skill-auditSkill
- skill-creatorSkill
- slack-gif-creatorSkill
- start-daySkill
- temporal-forensicsSkill
- theme-factorySkill
- throwaway-scriptSkill
- triage-ideasSkill
- verify-completeSkill
- webapp-testingSkill
- web-artifacts-builderSkill
- wisdomSkill
- worker-buildSkill
- worktree-guardSkill
- write-planSkill
- xlsxSkill
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
- Distinctive: line 8
When a feature is built in one project and needs to exist in another project that has its own component copies (not shared imports).
- Distinctive: line 12
After modifying components that another project also has copies of
- Distinctive: line 13
After adding a feature to one project that should exist in another
- Very specific: line 14
When /audit-components flags drift between project copies
- Distinctive: line 15
When user says "also add this to [other project]" or "propagate to [project]"
- Distinctive: line 76
Wait for user approval on conflicts.
- Distinctive: line 87
Verify env var names match target config
- Distinctive: line 89
Do NOT touch source project files
- Distinctive: line 95
If shared/ was also modified: build source project too
- Distinctive: line 98
Verify propagated components have same props interface
- Distinctive: line 99
Verify API endpoints handle same actions/params
- Distinctive: line 100
Verify no broken imports in target project
- Distinctive: line 101
Verify CSS additions don't collide with target's existing styles
- Distinctive: line 123
Before modifying a component that exists in both projects:
- Distinctive: line 124
Read the file in both projects
- Very specific: line 125
Run diff -u target/src/path source/src/path to see divergence
- Very specific: line 135
Always grep for class names in BOTH App.css AND component CSS files.
- Distinctive: line 139
NEVER blindly copy entire files — always diff and apply hunks
- Distinctive: line 140
NEVER overwrite target-specific adaptations (extra features, project-specific logic)
- Distinctive: line 141
NEVER propagate without checking import path differences
- Distinctive: line 142
If a component has diverged significantly (>50% different), flag for user decision rather than auto-merging
≈ “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.
Files
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-componentsflags 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 classificationAgent: 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 notesPhase 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 configWait for user approval on conflicts.
Phase 3: Apply (1 Worktree Agent, model: "opus")
Agent: Propagator (worktree)
For each approved file:
- SOURCE_ONLY changes: Apply the diff hunks to target file
- CONFLICT resolution: Apply user's chosen resolution
- 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
- 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:
- Read the file in both projects
- Run
diff -u target/src/path source/src/pathto see divergence - Identical sections — safe to change in both
- Diverged sections — require project-specific edits
CSS File Mapping
Projects may store equivalent styles in different files:
- Some projects use component-specific
.cssfiles (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
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
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.

