arch3rPro
- 19 skills
- 0 followers
- 6 hours ago last updated
- ▌ Web · arch3rpro bundleRetrieve bounded public-web evidence through ArkSpace. Use for Web Search, pages related to a known URL, URL fetching, site mapping or crawling, schema-bound structured extraction, and implementation-oriented Code Context. Use a research workflow when the requested outcome is a synthesized report.
- ▌ Browser · arch3rproNavigate and interact with a website through an owned, bounded ArkSpace browser session. Use when a task requires dynamic page state, clicks, form filling, scrolling, pagination, or an accessibility snapshot rather than ordinary public-web retrieval.
- ▌ Monitor · arch3rproCreate and manage recurring Exa searches or Firecrawl page, crawl, and web-search monitors through ArkSpace. Use when the user wants scheduled change checks, webhook delivery, a monitor paused or resumed, an immediate check triggered, history inspected, or a persistent monitor deleted.
- ▌ Research · arch3rproProduce a bounded, cited synthesis across multiple public sources through ArkSpace. Use when the requested outcome is a research report, comparison, landscape, or decision-ready answer rather than source discovery or retrieval of known pages.
- ▌ Minimal Evidence Checks · arch3rpro bundleRun the smallest set of checks that covers an outgoing change before pushing, committing, or claiming checks pass — select evidence by the surface the diff touches, never reflexively run the full suite, and fix or explain a failure rather than pushing and hoping CI differs. Use before push, force-push, marking ready for review, or claiming checks pass.
- ▌ Event Contract Matrix · arch3rpro bundleMaintain an explicit matrix of which module dispatches each event and which modules listen — many-to-many, with deliberate bypass sites noted — so event contracts stay a single source of truth. Use in event-driven or pub/sub systems where events cross module boundaries.
- ▌ Documentation Placement · arch3rpro bundleDecide where documentation belongs so each fact has exactly one home — classify documents as tutorial or reference, place each fact in the tier that owns it and link everywhere else, and keep budgets as guardrails rather than reduction targets. Use when writing, moving, restructuring, or auditing documentation, or deciding where a fact should be documented.
- ▌ Extension Points And Seams · arch3rpro bundleDesign for swappable capabilities — when a capability may have multiple implementations or consumers, separate it into contract / implementation / consumer so they vary independently, and route new behavior through documented extension points instead of patching a core. Use when designing a new capability, deciding whether to split an interface, or adding behavior to an existing system. Out of scope (no seam needed) when a capability has a single fixed implementation and consumer.
- ▌ Responding To Review On A Stack · arch3rpro bundleRespond to code review across a dependent PR stack — fix on the PR that introduced the issue, propagate the fix up-stack, keep each review fix a distinct commit, lease-protect any rewrite, and re-audit threads, approvals, and checks after every rewrite. Use when review comments span several stacked PRs.
- ▌ Postmortem · arch3rpro bundleWrite a backward-looking failure record — executive summary, timeline, root cause, and guardrails — when a bug was subtle, systemic, and costly to rediscover. Use after a hard incident or regression, or when deciding whether one is owed. It records what broke and why it escaped; complement it with decision-records, which record forward-looking decisions.
- ▌ Code Review · arch3rpro bundleReview a change along two axes — Standards (does the code follow the repo's documented standards, plus a smell baseline?) and Spec (does it faithfully implement the originating issue/spec?) — run as parallel sub-agents and reported side by side, prioritizing correctness, lifecycle, and security over style. Use when reviewing a branch, PR, or work-in-progress change, or when asked to "review since X".
- ▌ Testing Tiers · arch3rpro bundleChoose the right test tier for a change and keep the suite meaningful — unit, integration, real-entry-path, end-to-end, and snapshot tiers; test the real entry path rather than a hand-built harness; verify the world rather than the component's self-report; prefer the real implementation over a mock; and treat line coverage as necessary, never sufficient. Use when writing, planning, or reviewing tests, deciding what a change needs to be tested, or when a suite is green but the product is broken.
- ▌ Decision Records · arch3rpro bundleRecord design decisions as Architecture Decision Records (ADRs) so the why survives — with a classification, a lifecycle, and a mandatory alternatives-considered section. Use when making or proposing a non-trivial design decision, when reviewing a change that affects architecture, contracts, processes, or formats, or when deciding whether to archive a past decision. Applies to any project that wants its decision rationale to outlive the people who made it.
- ▌ Pr History Hygiene · arch3rpro bundleKeep pull-request history deliberate and safe — split independent changes, rewrite with lease-protected force-push (never raw force), apply one kind label plus all material area labels, and land a stack of dependent PRs through the platform's native stack feature rather than manually merging and retargeting. Use when preparing, rewriting, labeling, merging, or stacking pull requests.
- ▌ Runtime Invariants · arch3rpro bundleAssert only authoritative state at runtime — authoritative event streams or mutable data, never service or method presence — with each check owned by the module it guards and failing loud at startup. Use when adding runtime invariant checks, or deciding what an invariant may assert. It complements testing-tiers, which picks the test tier.
- ▌ Module Layering · arch3rpro bundleKnow and enforce your module dependency graph — derive inter-module edges from the canonical dependency signal, catch circular dependencies, and enforce intended layering with tooling. Use when a codebase has many modules or packages and layering is a real concern.
- ▌ Prose Standard · arch3rpro bundleWrite prose that preserves every contract while deleting reasoning transcripts, repetition, and decoration — across comments, JSDoc, docs, prompts, diagnostics, and user-visible strings. Use when writing, reviewing, trimming, restoring, or auditing prose, or deciding where documentation or a comment is required. It owns two rules: preserve the complete proposition, and never let an authoring-session vantage leak into durable text.
- ▌ Code Conventions · arch3rpro bundleGeneral code conventions that keep a codebase predictable — reversible side effects, switching on discriminant tags, explicit-over-implicit at boundaries, configuration over hardcoded tunables, branded opaque ids, trusting types at typed boundaries, and honest empty catches. Use when writing, reviewing, or refactoring code in a typed language with an explicit boundary structure (services, plugins, modules, packages).
- ▌ Defensive Patterns · arch3rpro bundleDefensive-programming patterns to apply when writing or reviewing lifecycle, concurrency, subprocess, teardown, error-reporting, or untrusted-IO code. Use when a change touches async setup or teardown, callbacks, spawned processes, workers, event listeners, disposal, error aggregation, temp files, or anything receiving untrusted input — and when reviewing a PR that touches any of those.