• Home
  • Technology
  • Gaming
  • Entertainment
  • World & Business
  • Science
  • Sports
  • AI
HomeTechnologyGamingEntertainmentWorld & BusinessScienceSportsAI
    • HomeTechnologyGamingEntertainmentWorld & BusinessScienceSportsAI
    • Home
    • Technology
    • Gaming
    • Entertainment
    • World & Business
    • Science
    • Sports
    • AI
    AI

    New /deslop-shared-libs skill aims to reduce code duplication

    A developer shared a review-only skill that starts with two weeks of commits and pull requests, looking for places where shared code could reduce duplication and improve reliability.

    SU
    1 Source, ,

    TLDR

    The creator says AI agents often write new code instead of building shared components, adding technical debt and slowing compile times. The /deslop-shared-libs instructions call for finding five opportunities to share code and recommending the best three. They prioritize actively changing areas and changes that would delete more code than they add. The skill is limited to recommendations—not editing code, opening issues or pull requests, or deploying.

    Combined views

    2.4K

    1 Source, first seen 14d ago

    Combined views

    2.4K

    1 Source, first seen 14d ago

    13 likes
    14d ago
    first seen 14d ago
    13 likes
    31 saves

    Sentiment

    Positive——Negative

    Summary

    Not enough discussion yet.

    No sentiment analysis available yet.

    31 saves

    Sentiment

    Positive——Negative

    Summary

    Not enough discussion yet.

    No sentiment analysis available yet.

    Today's Rank

    —

    Not ranked yet

    Today's Rank

    —

    Not ranked yet

    1 Source

    @Suhail--- name: deslop-shared-libs description: Find places where shared code could reduce duplication and improve reliability, starting with the past two weeks of commits and PRs. Use for /deslop-shared-libs, $deslop-shared-libs, or requests to find code worth sharing. Give recommendations without changing code. --- # Find code worth sharing Find five opportunities to share code, then recommend the best three. Focus on areas people are actively changing and changes that would delete more code than they add. ## Scope Review only. Do not edit code, install packages, open issues or PRs, or deploy. Follow any narrower scope the user gives. ## Start with recent work - Check the default branch's latest commit and choose a review commit. Review the past 14 days plus relevant current-branch work. State the commit and dates, and check candidate files against it if the checkout differs. Note any limits on access or history. Use a different time window if requested. - Read PRs opened, updated, or merged in that window using tools such as `gh`. Check the changed files and relevant diffs. Separate code changes from comment and bot noise, and count a merged PR and its commits as one effort. - Start where you see repeated fixes or similar code being added. Follow related callers and shared helpers, including older files. Frequent changes alone do not make something worth sharing. - Check whether PR code has merged and whether someone is already doing the proposed work. Verify findings against the source you reviewed. If history or PR access is missing, say so and use what is available; missing data does not mean an area is inactive. ## Look for useful shared code - Check existing libraries and helpers first. Reuse proven code where possible. - Cover the active areas in each language before ranking. Compare functions, types, schemas, and configuration, including copies with different names or formatting. Check the related files around each strong find for more copies. - For each of five ideas, show at least two places that could share code. Link to files, functions, and lines. Check that they need the same behavior; looking similar is not enough. - Describe the smallest useful helper and where it would live. Check whether callers can share it across languages, dependencies, and deployment setups. Preserve differences that callers need. - Explain how sharing would improve reliability. Point to tests or established use, and note missing coverage or how a shared bug could affect more callers. - Base estimates on named code blocks: what goes away, what replaces it, and what tests and integration work are needed. Show implementation savings and total savings separately; favor total reductions. Use ranges when uncertain. Exclude generated and third-party code; count moved code on both sides. ## Pick the best three - Set aside work already covered by an open or merged PR. Mention it separately; it does not count toward the five new ideas. - Favor code savings and reliability gains. Prefer recently changed areas when benefits are similar; explain any choice to focus on older code. - Favor changes that are easy to adopt and test, with a low risk of changing behavior. Prefer code already tested and used in several places. Avoid helpers with too many options or ones that tie unrelated components together. - Choose three and explain why the other two rank lower. Report fewer if the evidence does not support five ideas or three worthwhile recommendations. Say when a change might add more code than it removes. ## Output Keep explanations short and plain spoken. 1. Briefly state the dates, sources, and areas reviewed, including any gaps. 2. Compare up to five new ideas in a compact table: affected code, commit or PR links, estimated total lines removed, added, and saved, reliability benefit, and whether each made the top three. 3. Rank the best three. Link to the code, describe what to share, explain why it is useful now, and name the main risk or uncertainty. Briefly explain why the other two ranked lower and how recent activity affected the choice. Label estimates clearly. Stop after the recommendations.

    1 Source

    @Suhail--- name: deslop-shared-libs description: Find places where shared code could reduce duplication and improve reliability, starting with the past two weeks of commits and PRs. Use for /deslop-shared-libs, $deslop-shared-libs, or requests to find code worth sharing. Give recommendations without changing code. --- # Find code worth sharing Find five opportunities to share code, then recommend the best three. Focus on areas people are actively changing and changes that would delete more code than they add. ## Scope Review only. Do not edit code, install packages, open issues or PRs, or deploy. Follow any narrower scope the user gives. ## Start with recent work - Check the default branch's latest commit and choose a review commit. Review the past 14 days plus relevant current-branch work. State the commit and dates, and check candidate files against it if the checkout differs. Note any limits on access or history. Use a different time window if requested. - Read PRs opened, updated, or merged in that window using tools such as `gh`. Check the changed files and relevant diffs. Separate code changes from comment and bot noise, and count a merged PR and its commits as one effort. - Start where you see repeated fixes or similar code being added. Follow related callers and shared helpers, including older files. Frequent changes alone do not make something worth sharing. - Check whether PR code has merged and whether someone is already doing the proposed work. Verify findings against the source you reviewed. If history or PR access is missing, say so and use what is available; missing data does not mean an area is inactive. ## Look for useful shared code - Check existing libraries and helpers first. Reuse proven code where possible. - Cover the active areas in each language before ranking. Compare functions, types, schemas, and configuration, including copies with different names or formatting. Check the related files around each strong find for more copies. - For each of five ideas, show at least two places that could share code. Link to files, functions, and lines. Check that they need the same behavior; looking similar is not enough. - Describe the smallest useful helper and where it would live. Check whether callers can share it across languages, dependencies, and deployment setups. Preserve differences that callers need. - Explain how sharing would improve reliability. Point to tests or established use, and note missing coverage or how a shared bug could affect more callers. - Base estimates on named code blocks: what goes away, what replaces it, and what tests and integration work are needed. Show implementation savings and total savings separately; favor total reductions. Use ranges when uncertain. Exclude generated and third-party code; count moved code on both sides. ## Pick the best three - Set aside work already covered by an open or merged PR. Mention it separately; it does not count toward the five new ideas. - Favor code savings and reliability gains. Prefer recently changed areas when benefits are similar; explain any choice to focus on older code. - Favor changes that are easy to adopt and test, with a low risk of changing behavior. Prefer code already tested and used in several places. Avoid helpers with too many options or ones that tie unrelated components together. - Choose three and explain why the other two rank lower. Report fewer if the evidence does not support five ideas or three worthwhile recommendations. Say when a change might add more code than it removes. ## Output Keep explanations short and plain spoken. 1. Briefly state the dates, sources, and areas reviewed, including any gaps. 2. Compare up to five new ideas in a compact table: affected code, commit or PR links, estimated total lines removed, added, and saved, reliability benefit, and whether each made the top three. 3. Rank the best three. Link to the code, describe what to share, explain why it is useful now, and name the main risk or uncertainty. Briefly explain why the other two ranked lower and how recent activity affected the choice. Label estimates clearly. Stop after the recommendations.