arch3rPro
UserGeneralized development-specification skills distilled from DeepSeek Harness's engineering conventions — defensive patterns, code conventions, testing tiers, prose standards, decision records, review and PR discipline.
Categories
Indexed Skills (36)
module-layering
Know 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.
event-contract-matrix
Maintain 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.
postmortem
Write 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.
responding-to-review-on-a-stack
Respond 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.
runtime-invariants
Assert 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.
code-conventions
General 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
Defensive-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.
extension-points-and-seams
Design 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.
documentation-placement
Decide 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.
prose-standard
Write 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-review
Review 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".
decision-records
Record 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.
minimal-evidence-checks
Run 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.
pr-history-hygiene
Keep 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.
testing-tiers
Choose 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.
arxiv-search
Use when searching arXiv papers by keyword, title, author, abstract, category, or arXiv ID through ArkSpace web_search routing.
drive-me
Diagnose personal execution friction and convert a vague, stalled, or over-scoped goal into one bounded next-action plan with explicit scope, non-goals, acceptance criteria, and a lightweight feedback loop. Use when the user asks for help restarting work, overcoming procrastination, choosing what to do next, reducing scope, validating an idea before building, or creating accountability around a personal/work/study goal. Do not use for ordinary project planning when the user already has clear requirements and only needs implementation details.
json-canvas
Create and edit JSON Canvas files (.canvas) with nodes, edges, groups, and connections. Use when working with .canvas files, creating visual canvases, mind maps, flowcharts, or when the user mentions Canvas files in Obsidian.
obsidian-bases
Create and edit Obsidian Bases (.base files) with views, filters, formulas, and summaries. Use when working with .base files, creating database-like views of notes, or when the user mentions Bases, table views, card views, filters, or formulas in Obsidian.
obsidian-kanban
Create and maintain Obsidian Kanban boards stored in Markdown, with a GTD-friendly workflow for capturing tasks, adding cards, organizing lists, and maintaining task details such as inline tags, Kanban date and time tokens, linked-note priority metadata, and subtasks. Use when working with Obsidian Kanban board files, when the user asks to add or manage cards, or when a lightweight task card should be upgraded into a linked note for more complex project tracking.
obsidian-markdown
Create and edit Obsidian Flavored Markdown with wikilinks, embeds, callouts, properties, and other Obsidian-specific syntax. Use when working with .md files in Obsidian, or when the user mentions wikilinks, callouts, frontmatter, tags, embeds, or Obsidian notes.
orchestrator
Route ArkSpace requests that need role, skill, provider, or web capability selection, including unclear or cross-domain tasks.
prd-create
Create or revise R&D-facing PRDs from product screenshots, prototypes, confirmed requirements, and review decisions. Keep the standard PRD document structure and preserve every functional-page field and field restriction; write clear workflows as a screenshot followed by concise requirements, and add branches, interaction constraints, or page flows only when they change implementation.
provider-manager
Use when configuring ArkSpace providers, fixing missing provider URLs or API keys, checking provider readiness, or setting up multiple API key rotation.
searxng-search
Use when querying a configured self-hosted SearXNG instance, the SearXNG Search API, or privacy-oriented metasearch through ArkSpace web_search routing.
skill-manager
Manage ArkSpace by creating skills, recording upstream sources, assigning roles, validating registries, and guiding mirror, adapted, local, and reference-only skill updates.
web-search
Use when discovering public sources from a query, searching papers via arXiv, using a privacy-oriented SearXNG instance, or finding pages semantically related to a known URL; optionally select Exa MCP, Exa, Tavily, Firecrawl, Jina, DuckDuckGo, Brave, SearXNG, or arXiv.
code-context
Use when implementation work needs externally grounded code examples, API syntax, framework setup, or library usage context.
defuddle
Extract clean markdown content from web pages using Defuddle CLI, removing clutter and navigation to save tokens. Use instead of WebFetch when the user provides a URL to read or analyze, for online documentation, articles, blog posts, or any standard web page. Do NOT use for URLs ending in .md — those are already markdown, use WebFetch directly.
obsidian-cli
Interact with Obsidian vaults using the Obsidian CLI to read, create, search, and manage notes, tasks, properties, and more. Also supports plugin and theme development with commands to reload plugins, run JavaScript, capture errors, take screenshots, and inspect the DOM. Use when the user asks to interact with their Obsidian vault, manage notes, search vault content, perform vault operations from the command line, or develop and debug Obsidian plugins and themes.
web-automation
Interact with public pages or manage recurring monitors for public web targets.
web-discover
Use when discovering public sources from a query or finding pages semantically related to a known URL; optionally select Exa, Tavily, or Firecrawl.
web-extract
Extract requested structured fields or schema from supplied public URL(s) with a natural-language goal.
web-fetch
Read supplied public URL(s) into readable content, metadata, or links; optionally select Exa, Tavily, or Firecrawl.
web-research
Synthesize a cited answer across multiple public sources; optionally select Exa or Tavily.
web-site
Discover or crawl a known public site; optionally select Tavily or Firecrawl.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.