DEV Community: Summonair

How i handle complex tasks with Claude Code

Summonair — Mon, 09 Mar 2026 20:13:54 +0000

Every big task I have that needs attention from several repos, I like to set up a fresh isolated folder for Claude with everything it needs. Searching, fetching, cloning the right repos every single time - it's repetitive and annoying. That's why I built claude-clone.

The Real Problem With Multi-Repo Work

When Claude Code opens a folder, it sees everything in it. Clone multiple repos into the same workspace and Claude understands how they all relate — your API and frontend, your shared lib and the services using it. The context quality jumps.

But nobody talks about the setup cost. You have to manually find each repo, clone it, and assemble the workspace every single time.

One Command Instead

claude-clone create my-feature

Choose your desired repos for the task:

That's it. It:

Fetches all your GitHub repos (org or personal)
Shows a searchable list, space to select
Clones everything you picked in parallel
Writes a CLAUDE.md describing the workspace
Launches Claude with full context across all repos

No config files to edit. No paths to remember. No repetitive setup.

Save Repo Groups as Presets

Working on the same stack repeatedly? Save it once:

claude-clone preset save backend
claude-clone create my-feature --preset backend

Works for Orgs and Personal Repos

claude-clone create my-feature --org acme   # org repos
claude-clone create my-feature              # your own repos
claude-clone open my-feature               # reopen later

Install

npm install -g claude-clone

Requirements: gh CLI authenticated, Claude Code in PATH.

Open source: github.com/Summonair/claude-clone

Agent build RPG style

Summonair — Sat, 24 Jan 2026 12:51:20 +0000

I built 𝗪𝗼𝗿𝗹𝗱 𝗼𝗳 𝗖𝗹𝗮𝘂𝗱𝗲𝗰𝗿𝗮𝗳𝘁 to replace 𝗮𝗴𝗲𝗻𝘁 𝗰𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻 𝗳𝗶𝗹𝗲𝘀 with something more visual (and honestly, more fun).

Instead of editing configs, you equip your Claude agent:
• Roles as helmets 🪖
• Behaviors as armor 🛡️
• Skills, constraints, formats, tools, context - each in its own slot
You drag & drop items, mix builds, track token budgets 💰, save loadouts, and export straight to ~/.claude/agents.

Each item is tokenized with GPT-Tokenizer and ranked by rarity ✨ according to its token cost.
Inspired by my favorite RPG games and their loadout systems.

https://github.com/Summonair/world-of-claudecraft

Resolving Storage Space Issues on AWS RDS Postgres

Summonair — Thu, 12 Sep 2024 15:59:52 +0000

As a devops engineer, maintaining optimal database performance is crucial. Recently, we encountered a persistent issue with our Postgres RDS instance: the free storage space was decreasing rapidly, and finding the root cause wasn't straightforward. This post outlines the investigation process, the routes we explored, and how we ultimately resolved the issue.

1. Temporary Files

One of the first things we checked was the use of temporary files. Typically, large temporary files can consume significant storage, especially when work_mem is set too low or when long-running queries abuse temp space. We ran the following query to check temporary files usage:

SELECT datname, temp_files AS "Temporary files", temp_bytes AS "Size of temporary files" 
FROM pg_stat_database;

However, in our case, this was ruled out early because our configuration uses a storage-optimized image. Temporary files were not written to the DB's EBS storage but to the local storage instead, so they were not contributing to the space issue on the database storage.

2. Dead Tuples

Next, we considered dead tuples, which can accumulate over time and bloat the database size. Dead tuples occur when rows are marked for deletion or updated, but the space they occupy isn’t immediately reclaimed. This can lead to bloat, where disk space is consumed by data that’s no longer needed but remains invisible to transactions. We checked the tables with the most dead tuples using:

SELECT relname, n_dead_tup 
FROM pg_stat_all_tables 
ORDER BY n_dead_tup DESC 
LIMIT 10;

Although we found a few million dead tuples, running a vacuum didn’t recover as much space as anticipated. This indicated that while dead tuples were present, they weren’t the main factor behind the excessive storage consumption

3. Orphaned Files

We also checked for orphaned files, which can occur if files remain in the database directory without corresponding objects pointing to them. This situation might happen if the instance runs out of storage or the engine crashes during operations like ALTER TABLE, VACUUM FULL, or CLUSTER. To check for orphaned files, we compared the database size occupied by files against the real size retrieved by summing the objects:

-- Size of the database occupied by files
SELECT pg_size_pretty(pg_database_size('DATABASE_NAME'));

-- Size of database retrieved by summing the objects (real size)
SELECT pg_size_pretty(SUM(pg_relation_size(oid))) 
FROM pg_class;

If a significant difference exists between these sizes, orphaned files might be using up storage space. In our case, the sizes were even, so orphaned files were not the reason.

4. Replication Slots

Replication slots are another common cause of storage bloat due to accumulating WAL (Write Ahead Logs) if they are not consumed properly.
To check replication slots, run:

SELECT * FROM pg_replication_slots;

However, upon checking, we confirmed that replication was active and working as intended

5. Log Files

The breakthrough came when we investigated log files. We discovered that our log files were consuming an enormous amount of space:

Log sizes over the past three days included 20GB, 18GB, 10GB, and 8GB files.

Our logging configuration was set to log queries that ran for a minimum of 1 second, including their bind parameters. This resulted in very large log entries, especially when complex queries with extensive parameters were executed frequently.

The Solution

To resolve the storage issue, we made the following adjustments:

Increased Minimum Run Time for Logging (log_min_duration_statement): We changed the minimum run time for logging queries from 1 second to 5 seconds. This reduced the number of logged queries significantly, focusing on longer-running, potentially more impactful queries.
Adjusted Log Retention Policy (rds.log_retention_period): We reduced the retention period of log files from the default 3 days to just 1 day. This change immediately helped in freeing up storage space by reducing the volume of retained log data.

Also worth mentioning is the log_parameter_max_length parameter which can limit the logged bind parameter.

These changes resulted in a significant reduction in the size of the log files, thereby freeing up the storage space and preventing further rapid consumption.

Conclusion

When faced with storage space issues in PostgreSQL RDS, it’s crucial to systematically investigate all possible sources of storage consumption. In our case, the logs were the unexpectedly large, but a strategic adjustment to logging parameters and retention policies helped us reclaim valuable storage space.