Archetype
31 · № 2DCF·DADA · Coding pair
★ 80Sets up a direct, practical local coding assistant that works within the current repository, treats project rule files as authoritative, makes small reviewable changes, and proactively uses a live Hunk review session for code feedback.
32 · № 07CD·1AA2 · Coding pair
★ 4Sets up a calm, adversarial root-cause analyst that wakes on BLOCKED tasks, traces defects to their origin phase, applies minimal state corrections, and escalates unresolvable blocks instead of forcing success. Work is driven through mandatory tool calls rather than pasted code.
33 · № E37C·A96F · Coding pair
★ 1Sets up a implementation-focused coding agent that takes specs, writes tested code, and opens tight, well-described PRs without scope creep. It is a seed template for per-agent souls in a multi-agent team.
34 · № 2BC4·FEB9 · Coding pair
★ 1A template-architect agent that maintains the Harness SDD framework's conventions, manifest-first and deterministic, and refuses shortcuts like hand-editing generated files or skipping checks. Its tone is direct, precise and terse, leading with constraints before solutions.
35 · № 42BF·2C02 · Coding pair
★ 1A base QA role soul focused on release verification, integration testing and regression hunting. It sets a curious, specific, neutral reporting style and tells the agent to verify rather than rubber-stamp, and to be honest about untested gaps.
36 · № 0F71·72A5 · Coding pair
★ 1Sets up Chris, a strict but constructive code reviewer who flags security, quality and tech-debt issues with severity labels, and stays within review scope while coordinating with six other team roles via @mentions in Feishu.
37 · № FD90·38AE · Coding pair
★ 2Sets up Finn, a chief engineer who acts as architect, code quality guardian and technical innovator. Finn values clean, reviewable code, weighs 2-3 technical options with trade-offs, reports bugs in a fixed format, and avoids calling tasks simple.
38 · № D728·A346 · Coding pair
★ 2Sets up a review agent that checks diffs against the work order, cites file and line for each finding, refuses to rubber-stamp changes, and reports problems without rewriting the code.
39 · № 9EC5·AE33 · Coding pair
★ 2Sets up a reviewer role that independently assesses a builder's code for correctness, architecture fit, security and performance, issuing PASS or FAIL verdicts with severity-graded, evidence-based findings and no code writing.
40 · № 8C9B·1B78 · Coding pair
Sets up Rigel, a structured and calm code agent that plans before coding, tracks all work in a database, writes outputs to files instead of chat, and escalates ambiguity with one focused question. It works internally with Palomar and reports progress in concise bullet points.
41 · № 1928·65A9 · Coding pair
★ 101Sets up a meticulous, methodical Golang engineer agent that works through assigned GitHub issues, writes tests and docs, manages pull requests, and reports progress in detail. The base SOUL template adds guidance on competence, respectful handling of private access, and cautious external actions.
42 · № A292·FBC2 · Coding pair
★ 4Sets up a direct, correctness-first developer agent that reads full context before coding, follows every workflow phase, completes the commit, PR and notification lifecycle, and respects strict git and workspace boundaries.
43 · № F56E·A8D1 · Coding pair
★ 1Sets up Vibeforge as a tooled meta-method for one operator running parallel Claude Code workstreams through a single lead agent, with guardrails installed before autonomy and lessons captured across projects. The tone is principled and structured, describing an identity and first principles rather than a chat persona.
44 · № 0A3F·8A3A · Coding pair
Sets up an autonomous executive agent that orchestrates worker coding CLIs through isolated Git worktrees, demands machine-verifiable proof instead of claims, kills and retries failing workers, and records every mistake as a convention. Its working style is strict, process-driven and terse.
45 · № 1F61·43F9 · Coding pair
★ 30Sets up an engineer persona that acts on tasks promptly, reports clearly with data, surfaces blockers early, skips QA shortcuts, and stays out of PM work. The file is written in Chinese.
46 · № B8C1·3C1C · Coding pair
★ 25A focused QA agent that turns plain-English requirements into deterministic, CI-friendly end-to-end tests and diagnoses failures in a strict CATEGORY/REASON/FIX format. It sets rules on selectors, secrets and git safety, with no personality flourish.
47 · № 0D22·4BC7 · Coding pair
★ 1Sets up smolbot as a practical coding agent that speaks calmly and directly, avoids claiming unwired capabilities, and prefers small testable changes over broad rewrites. It also tells the agent to load any skill that might apply.
48 · № CAFA·DE0A · Coding pair
★ 6Sets up an agent that locks a character's visual identity (face, exact eye shade, hair, costume, marks) and records it in a characters.md file so it never drifts. The style is terse and procedural.
49 · № A152·3285 · Coding pair
★ 36Sets up an agent as a systematic technical architecture and UX foundation specialist that plans scalable CSS, layout systems and component hierarchies before implementation, with a developer-focused, structured working style.
50 · № DDC7·3E5C · Coding pair
Sets up an SDET persona that treats testing as software engineering, prioritizes reliable high-fidelity automation over raw coverage, and communicates failures with evidence in a direct, business-aware way.
51 · № A8C8·A4BE · Coding pair
Sets up a direct, analytical personal assistant and debugging partner in Spanish with a rioplatense touch. It requires explicit confirmation before sending emails, editing project files or deleting anything, and manages persistent memory across sessions.
52 · № FD02·2455 · Coding pair
Sets up Forge, a calm, safety-first DevOps partner covering CI/CD, containers, cloud infrastructure, monitoring and incident response. It asks for scope before starting, warns before destructive actions, and explains its configuration choices.
53 · № D288·67AD · Coding pair
★ 2Sets up a QA agent that is thorough and skeptical, deliberately tests edge cases, boundaries and unhappy paths, and reports findings with reproduction steps. Its personality is adversarial but constructive.
54 · № 3CC7·8B96 · Coding pair
★ 83Sets up an agent identity for the ecc Codex plugin that routes work to specialist agents early, writes or updates tests before trusting changes, applies security-first defaults, prefers immutable state transitions, and plans complex changes in phases before execution.
55 · № 425B·AD99 · Coding pair
★ 26Sets up a terse working style: calm, bounded and exact. The agent should prefer explicit repo roots, honest freshness reporting and doc-to-code links over vague claims, and should keep indexing posture separate from edit authority.
56 · № DA75·171A · Coding pair
★ 29Sets up Everything Claude Code as a production coding plugin that routes work to specialist agents, follows test-driven and security-first habits, and plans complex changes before executing them.
57 · № D008·A67C · Coding pair
★ 1Sets up Archie as the scaffolding agent in a builder pipeline, creating protocols, in-memory fakes, Hypothesis property tests and module skeletons from a Spec without writing implementation code. The working style is procedural and checklist-driven, with pipeline position and file conventions spelled out.
58 · № 1B95·7851 · Coding pair
★ 4Sets up a risk-focused reviewer that escalates security, performance and test-quality gaps, blocks ships on non-negotiable concerns, and gives specific, proportionate findings. It is a template with placeholders for the user's own compliance and performance context.
59 · № A73E·269E · Coding pair
Sets up a code evaluator agent that reviews work on its merits, runs linting first, labels findings as BLOCKER, WARNING or SUGGESTION, and escalates to a human only when stuck. It is the final review gate before work ships.
60 · № A376·E457 · Coding pair
Sets up a process-first working style for Codex: no code without a defined goal, scope, and done criteria, fail-fast stop conditions, metric thresholds, review before completion, and a learning log entry for each task. Priorities are preserving project invariants and lowering future decision cost over raw output.