agentsclimarketplace
Sign in

Architecture rescue

Skill quanpersie2001/pulse/skills/architecture-rescue

Repo-wide or subsystem-wide architecture hygiene pass that surfaces deepening opportunities, shallow modules, leaky seams, and ownership drift. Default mode is report-only: no bead creation or execution unless explicitly requested.From its SKILL.md

Install
npx -y skills add quanpersie2001/pulse --skill architecture-rescue

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.1 KB, 832 tokens by cl100k_base, as published. Nobody here has run it

Architecture Rescue

Use this skill when the user wants architecture cleanup that is broader than a single diff: repo-wide, subsystem-wide, or cross-module shape correction.

This skill is for analysis and proposal first. By default it is report-only.

What this is (and is not)

  • This skill: architecture rescue and hygiene across seams, ownership, interfaces, and module depth.
  • Not diff-scoped cleanup: this skill is for system shape, seams, and ownership, not for small behavior-preserving cleanup on a concrete diff.
  • Not normal planning: planning slices approved feature work into phases/stories/beads; architecture-rescue diagnoses architecture friction and proposes rescue candidates before planning.

Default mode

Default to report-only unless the user explicitly asks for planning/execution follow-through.

In report-only mode:

  • do not create beads
  • do not invoke pulse:planning
  • do not invoke pulse:executing
  • do not edit architecture artifacts unless the user asks

Inputs to read first

For the target scope (whole repo or named subsystem), read:

  1. project operating docs (CLAUDE.md, AGENTS.md, and nearby module docs)
  2. relevant history/<feature>/CONTEXT.md decisions when present
  3. .pulse/memory/* entries that apply to architecture constraints, incidents, or non-regression rules
  4. pulse:gitnexus and GitNexus context if available

If GitNexus is configured, prefer it for topology, process flow, and impact/breadth evidence before manual grep.

Architecture lens

Use consistent terms from references/LANGUAGE.md.

Look specifically for:

  1. Shallow modules: interface complexity close to implementation complexity
  2. Bloated interfaces: callers need to know too many invariants/orderings/error modes
  3. Leaky seams: cross-module coupling forces parallel edits or duplicated policy
  4. Ownership drift: responsibilities spread across multiple modules with unclear source of truth
  5. Deepening opportunities: ways to concentrate behavior behind smaller, clearer interfaces

Use the deletion test: if deleting a module merely moves complexity to callers, it was likely earning leverage; if it removes no real complexity, it was likely shallow or pass-through.

Process

1) Scope and map

  • Confirm scope: whole repo, bounded subsystem, or named execution flow.
  • Build a quick architecture map: modules, seams, owners, and flow handoffs.

2) Find rescue candidates

Generate a short list (3-7) of high-signal candidates with concrete evidence.

For each candidate capture:

  • Area/files
  • Current friction
  • Rescue move
  • Expected leverage/locality gain
  • Risk/coordination cost

3) Produce a report

Return a ranked architecture rescue report:

  1. Executive summary (what hurts most and why)
  2. Candidate list (ranked)
  3. Suggested rescue sequence (what to do first/second/later)
  4. Open questions that must be answered before execution

Do not generate implementation tasks unless asked.

Optional follow-through modes (explicit opt-in only)

Use only when the user explicitly requests them.

  • phase-shaping: hand off top approved candidate(s) to pulse:planning
  • execution-ready: after validating gate approval, proceed via pulse:swarming/pulse:executing

Before leaving report-only mode, restate the mode change and requested scope.

Output contract (report-only)

Provide concise output with:

  • scope analyzed
  • top rescue opportunities
  • rationale in leverage/locality terms
  • dependencies and risks
  • recommended first move

Keep recommendations specific, evidence-backed, and bounded to the requested scope.

References

What ships with it: 3 files

3.9 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most architecture codebase skills give in 832 tokens

Counted across 858 of the 1,304 authors here whose files we hold, read 2026-09-06

  • Apply the deletion test to identify shallow modulesin 32 of 858, across 31 files
  • Read domain glossary and ADRs before exploringin 22 of 858, across 19 files
  • Use Tailwind and Mermaid via CDN for reportsin 21 of 858, across 18 files
  • Document architecture decision recordsin 20 of 858, across 12 files
  • Offer to record ADRs for rejected candidatesin 17 of 858, across 14 files
  • Limit primary navigation to four to seven itemsin 17 of 858, across 7 files
  • Write HTML report to the system temp directoryin 17 of 858, across 14 files
  • Read product marketing context before asking questionsin 16 of 858, across 6 files
  • Use Mermaid graph TD for visual sitemapsin 15 of 858, across 5 files
  • Ensure every page has at least one internal linkin 15 of 858, across 5 files
  • Use ASCII tree format for page hierarchy draftsin 15 of 858, across 5 files
  • Enforce lowercase URLs with hyphensin 15 of 858, across 5 files

Said here and by no other author read

  • default to report-only mode
  • read project operating docs first
  • use consistent terminology from language references
  • map modules seams and ownership
  • generate three to seven high-signal rescue candidates
  • produce a ranked architecture rescue report

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.