← all publishers

Chrike

@chrike source repo

Report this profile Claim this profile

• 24 skills
• 0 followers
• 6 hours ago last updated

1. ▌
   Plan Work · chrike bundle

   Use for software implementation planning when the user asks for planning, an implementation plan, approach comparison, task breakdown, roadmap, step-by-step plan, or splitting a feature/refactor into clear implementation slices before the next safe implementation step, or when a requested software implementation has unresolved implementation approach, dependency-ordering, sequencing, migration, compatibility, rollout, or scope decisions that cannot be safely inferred. Do not use when the primary request is an architecture, ownership, interface, seam, or dependency-boundary decision; use design-codebase first when available, then return here for dependent rollout or sequencing planning. Do not use for PRD authoring, issue or tracker drafting/publication, durable multi-session decision-map workflows, ordinary code explanation, or implementation of an already-settled plan.
   0
   installs
2. ▌
   Idea Refine · chrike

   Use when the user explicitly asks to ideate, refine, explore alternatives, or converge on a product, feature, process, or solution concept before implementation planning. Do not use for ordinary vague implementation requests, one-question intent interviews, implementation plans, architecture or ownership decisions, PRD or issue drafting, or reliability review of an existing plan.
   0
   installs
3. ▌
   Decision Map · chrike

   Create, update, or resume a durable multi-session map of unresolved decisions and their dependencies. Use when the user clearly asks for a decision map, wants to track an open decision frontier across sessions, or wants to resume decision work by ticket. Do not use for ordinary implementation planning, one-session design comparison, progress summaries, handoff or checkpoint state, or direct execution of settled decisions.
   0
   installs
4. ▌
   Interview Me · chrike

   Use when the user explicitly asks for a one-question-at-a-time intent interview before planning or implementation, such as "interview me", "help me clarify what I actually want", or "grill me". Do not use for ordinary underspecified implementation requests, direct fixes, explanations, mechanical work, or reliability review of an existing decision.
   0
   installs
5. ▌
   Finish Branch · chrike

   Use when the user explicitly asks to commit changes, push a branch, prepare or create a new PR for a resolved branch, merge local branches, merge a named PR remotely, discard explicitly scoped Git working-tree changes, delete a named local or remote branch, remove a named worktree, or choose how to finish the current branch. Do not use to view or summarize an existing PR, review code, assess readiness or completion, answer read-only branch-status questions, explain Git, discard a non-Git idea, or write a generic PR template; use `review-and-finish` for review and completion verification when installed and available, otherwise leave that portion to the ordinary host workflow.
   0
   installs
6. ▌
   Test Strategy · chrike bundle

   Use when the primary problem is test design, explicit TDD, test-first or red-green-refactor work, test seams, regression coverage, mocks, assertions, fixtures, or timing and wait strategy, or when a requested change needs a non-obvious test level, seam, regression signal, or acceptance proof. Do not use for generic testing explanations, ordinary implementation, unresolved root-cause diagnosis, unresolved architecture or ownership/interface/dependency-boundary decisions, explicit review or feedback handling, or completed-work readiness review.
   0
   installs
7. ▌
   Agent Workflow · chrike bundle

   Use when the user explicitly asks to parallelize work, coordinate multiple agents, run parallel scouts, split work across independent owners, or coordinate multiple independent verifiers; first perform the orchestration fit check even when the correct result is to keep one owner. Also use when two or more genuinely independent subsystem or artifact slices, repeated per-item pipelines, orthogonal scout questions, or high-stakes candidate-and-review scopes require coordinated ownership and integration with material benefit over one owner. Own decomposition, assignment, evidence handoff, verification coordination, and integration. Do not use for one focused delegation or verifier, small independent tasks without an explicit orchestration request when coordination cost exceeds the benefit, coherent single-owner or shared-root work without an explicit orchestration request, capability-only parallelism, or work already owned by another orchestration layer.
   0
   installs
8. ▌
   Issue Workflow · chrike

   Use when the user clearly asks to create, publish, or update a tracker item; turn discussion into a PRD, explicit technical specification, issue draft, tracker-ready work item, or triage result; or modify tracker state such as status, labels, comments, or closure. Keep ordinary coding, planning, review, and repository-local work-item execution in their own flows.
   0
   installs
9. ▌
   Memory Handoff · chrike

   Creates or updates a compact handoff or checkpoint for a later session, and resumes work from a user-named or repository-standard handoff artifact. Use when the user explicitly asks to create or update a handoff or checkpoint, prepare one before context compaction, or resume from one. Do not use for ordinary progress summaries, long contexts without explicit handoff intent, or a direct request to run /compact without preparing a handoff.
   0
   installs
10. ▌
    Design Codebase · chrike bundle

    Use when the user asks to make or compare a codebase architecture decision involving module boundaries, ownership, interfaces, seams, adapters, domain language, or a throwaway prototype that answers a design question. Also use during implementation only when a non-obvious architecture, ownership, interface, or dependency-boundary decision blocks the next safe edit; a testability concern qualifies only when it demonstrates that kind of boundary pressure. Do not use for ordinary code explanation, straightforward implementation, general test design, flaky tests, mocks, regression coverage, or implementation of an already selected design.
    0
    installs
11. ▌
    Markdown Memory · chrike

    Use when the user clearly asks to record, update, prune, or consult project-governed Markdown reference lessons about repeated mistakes, corrections, or confirmed approaches that must be versioned, shared, reviewable, or otherwise tied to repository history. Do not use for automatically loaded CLAUDE.md or .claude/rules instructions, host auto memory, handoff state, or decision-frontier planning.
    0
    installs
12. ▌
    Skill Refactorer · chrike bundle

    Use when the user clearly asks to refactor, migrate, rewrite, de-duplicate, or clean up an existing coding-agent instruction artifact, such as a SKILL.md, Claude Code prompt, CLAUDE.md fragment, or equivalent agent configuration, while preserving its intended behavior and trigger boundary. Do not use for ordinary code refactors, code or document review, planning, general-purpose writing, translation, or ordinary prompt and copy editing.
    0
    installs
13. ▌
    Reliability Check · chrike

    Use when the user explicitly challenges the reliability of the agent's current or prior conclusion, evidence, source use, active stage, wrong direction, strategy or workflow drift, stale context, unsupported confidence, hallucination, guessing, source-vs-memory confusion, or example-vs-task confusion, or explicitly asks to reassess one of those concerns. Also use when the user says the agent used the wrong, missing, unread, or outdated source for its current or prior conclusion. Do not use for ordinary status questions, file-inventory questions, routine source-reading requests, general uncertainty, ordinary strategy or approach preference changes, or preventive stage reminders without a stated reliability concern.
    0
    installs
14. ▌
    Review And Finish · chrike bundle

    Use when the user explicitly asks to review code, assess or address review or PR feedback, verify whether completed software work is done, fixed, passing, or ready, or check a development artifact before sending or shipping. Also use before a done claim for completed changes affecting persisted data or migrations, authentication, authorization, permissions, public compatibility contracts, concurrency, transactions, or destructive behavior. Do not use for ordinary progress summaries, implementation-only requests, high-risk terminology without a completion claim, or an explicitly invoked bundled `/code-review`.
    0
    installs
15. ▌
    Context Engineering · chrike

    Use when the user explicitly asks to audit, pack, or configure the context for a task or project, or asks to investigate an observed context-specific quality problem such as invented APIs or ignored conventions. Do not use for ordinary source reading, new sessions, task switching, long conversations, generic uncertainty, reliability reassessment, handoff or compaction, planning, or ordinary implementation.
    0
    installs
16. ▌
    Shipping And Launch · chrike

    Use when the user explicitly asks to assess readiness for a concrete production release, launch, rollout, or rollback plan, or when an active owner identifies a release-specific production evidence gap. Do not use for ordinary implementation, generic review or done claims, repository CI definition, telemetry design, performance or security analysis, UI or test work, deployment execution, or authority pressure without a defined release question.
    0
    installs
17. ▌
    CI CD And Automation · chrike

    Use when the user explicitly asks to design, audit, or modify a repository-owned CI/CD or automation definition, quality-gate pipeline, build or deployment trigger, artifact or secret reference, or failure semantics, or when an active owner identifies a concrete pipeline-boundary risk. Do not use for ordinary tests, builds, linting, unknown CI failures, release readiness, deployment execution, branch protection or auto-merge changes, generic review, security or performance analysis, or existing tool availability alone.
    0
    installs
18. ▌
    Debug Systematically · chrike bundle

    Systematically diagnose unclear product behavior or root cause by building a feedback signal, testing one hypothesis at a time, and verifying the original symptom. Use for intermittent or flaky symptoms, cross-component failures, performance regressions, regressions after recent changes, or bugs that survived previous fixes. Do not use for obvious direct failures, primary test-design or wait-strategy problems, Claude Code runtime issues, unresolved architecture boundaries, or explicit review/readiness checks.
    0
    installs
19. ▌
    Security And Hardening · chrike

    Use when the user explicitly requests a security audit, threat model, or hardening analysis, or when an active owner identifies a concrete, non-trivial trust-boundary risk requiring security analysis. Do not use for security terminology alone, ordinary input validation, routine API or architecture work, generic review, test design, or branch work.
    0
    installs
20. ▌
    Frontend UI Engineering · chrike bundle

    Use when building or modifying a non-trivial user-facing interface where interaction semantics, keyboard or focus behavior, responsive behavior, design-system consistency, loading/error/empty states, or accessibility acceptance materially affects the outcome, or when the user explicitly asks for UI, accessibility, responsive, or interaction quality. Do not use for small label, text, class, or attribute edits, settled-plan execution, architecture or ownership decisions, test strategy, browser runtime evidence, or ordinary implementation.
    0
    installs
21. ▌
    Performance Optimization · chrike

    Runs a narrow, framework-neutral performance experiment. Use only when the request states a concrete performance goal or metric, provides a measured baseline or regression, identifies a bottleneck, or explicitly requests a performance audit or experiment. Do not use for vague speed requests, unknown slow paths or regressions, test design, architecture trade-offs, live browser evidence, generic review, existing tools alone, or automatic profiling and tool setup.
    0
    installs
22. ▌
    Browser Testing With Devtools · chrike

    Use only when the user explicitly requests live browser or DevTools evidence—such as DOM, console, network, screenshot, focus, accessibility, or runtime-performance observation—or when an active owner identifies a browser-only evidence gap. Requires an already configured and explicitly authorized browser/DevTools channel. Do not use merely because work targets a browser, is long, or a browser tool exists; do not use for UI design, test strategy, root-cause debugging, performance optimization, completion review, or host runtime/tool issues.
    0
    installs
23. ▌
    Observability And Instrumentation · chrike

    Use when the user explicitly asks to design, add, or audit persistent operational telemetry such as logs, metrics, traces, or alerts, or when an active owner identifies a concrete observability gap needed to answer an on-call question. Do not use for every production feature, ordinary logging, unknown active failures, measured performance work, generic review, launch readiness, or existing monitoring/tool availability alone.
    0
    installs
24. ▌
    Capability Harness · chrike bundle

    Apply a decision-first capability-harness pass to substantive work when a model may miss context, evidence, an observable check, or a materially different alternative. When the prompt hook selects a pre-action route, execute exactly that one route before material work and integrate its bounded result. Do not use for routine direct work, fixed pipelines, cosmetic variants, or work already owned by another controller.
    0
    installs