# Readiness and Blockers ## What this is Readiness checks explain whether a Protege is safe to save, test, or publish. Blockers are setup issues Hookshot™ finds before a Protege can run reliably. ## When to use it Use this page when a Protege cannot be published, cannot run automatically, or shows setup warnings after a Builder plan is accepted. ## Blockers you may see ### Complete basics The Protege needs a clear name and description. Fix it by adding enough context that a teammate can understand what the Protege owns. ### Add behavior instructions The Protege needs clear run-time rules. Fix it by describing what the Protege should decide, what it should produce, and what it should avoid. ### Connect required services One or more required integrations are not connected or need repair. Fix it by opening the integration and completing the connection or reconnection flow. ### Connect trigger services The Protege has a trigger, but the service that provides the trigger is not connected. Fix it by connecting the source integration before expecting automatic runs. ### Finish trigger setup The trigger is connected but still needs configuration, such as a project, repo, channel, team, or other provider-specific field. Fix it by filling the required trigger input in setup or Integrations. ### Waiting for first webhook event The trigger is registered, but Hookshot has not received the first matching event yet. Fix it by sending a known-safe event from the connected app, then checking Event Feed. ### Add a schedule The Protege is schedule-only but has no enabled schedule. Fix it by adding at least one schedule with the intended cron and timezone. ## Access checks ### Trigger Access Trigger Access controls what can start the Protege. Review it when: * No event appears in Event Feed * The wrong event starts the Protege * The Protege is skipped or unevaluated ### Tool Access Tool Access controls what the Protege can do after it starts. Review it when: * A run cannot complete the expected action * The plan includes a tool you did not intend to allow * The Protege writes to an external system {% hint style="warning" %} Tool Access deserves extra review for workflows that post messages, create issues, update tasks, or otherwise change another system. {% endhint %} ## How to verify You are ready to test when: * Required services are connected * Required trigger fields are complete * Schedule-only Proteges have a schedule * Tool Access matches the intended action * Event Feed can show the incoming event or scheduled run * Audit can show the resulting run ## Common failures * Connecting an app but not completing trigger setup * Adding tools before confirming the Protege needs them * Waiting in Audit for a run when no event has arrived * Publishing a schedule-only Protege without a schedule * Ignoring waiting webhook states during first setup ## Next step * [Create a Protege](/create-a-protege.md) * [Integrations overview](/integrations.md) * [Troubleshooting](/event-feed/troubleshooting.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://gitbook.tryprotege.com/create-a-protege/readiness-and-blockers.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.