Observe requested behavior

SkillDev tools

Plans bounded manual or exploratory observation of requested product behavior when the developer explicitly requests manual testing, exploratory testing, or an active plan slice requires it. Covers web, CLI, API, desktop, or combined surfaces. Does not run proactively or replace required automated tests.

Use Observe requested behavior in Claude, ChatGPT or Ahel Desktop

Free. Sign in, add Observe requested behavior and connect your AI. About a minute.

Also: Claude Code · Cursor · Codex

Then ask your AI: use the Observe requested behavior skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Add Ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.

Observe requested behaviorStart free

What this skill tells your AI

The instructions your AI receives, as published by nerds-odd-e/doughnut in .agents/skills/dough-manual-testing/SKILL.md and read by Ahel’s review.

Use only on explicit developer request or plan-slice manual testing. No diagnosis, product repair, or unrequested tooling.

Mission

Resolve scope and time budget from the request: a feature, story set, recent deliveries, or change range. Recover current promises, examples, and constraints from this project's records or Git history, including deleted stories. Apply later decisions before older expectations; implementation, narration, and existing tests are not the oracle.

Identify in-scope externally observable surfaces, including non-web. Resolve URLs, accounts, startup, secrets, and tools from this project's guidance when needed; do not guess credentials.

If oracle, budget, or needed environment or access is missing, name it and stop; do not invent them.

A standalone session the developer accepts is a mission: admit it before setup or exploration, approach unselected, unless explicitly selected as one-shot work. Observation required by an active plan slice or story continues under that story. Admission changes none of the testing-only limits here.

Plan

Before acting, list coverage areas and journeys, risks or questions, and proportional split of preparation, breadth, selective depth, and surprise/confirmation reserve. Weight by importance and risk. Include each promised surface. Completing this plan is not acceptance.

Prepare

For a standalone session that needs a project checkout, first read and follow the shared exploration workspace lifecycle. Enter that lifecycle before checkout-bound setup and use its selected checkout throughout the session.

Choose the cheapest reliable route: existing setup, whole or partial automated journey, or temporary harness or test, including a setup-only feature scenario using existing steps. Skip setup when current state serves. Confirm state, session, and required services remain available for external observation; a finished batch run may not. Preserve isolation, cleanup, compatible-state reuse, and removal of owned temporary artifacts. Missing reuse is a possible improvement, not authority for permanent test/runner changes. If no supported route leaves a usable starting state, name it and stop.

Explore

Cover planned areas in breadth first with this project's tools. Spend depth on surprises and high-risk questions; reallocate remaining time, keeping confirmation reserve. Reuse sufficient automated evidence; do not replay deterministic checks or proven setup. If a needed tool or environment is unavailable, name it and stop.

Report

When planned coverage completes with no actionable findings or material uncertainty, report exactly Good. Otherwise report only discrepancies (expected versus actual plus evidence), unresolved expectations (not false fails), improvements (out-of-scope ideas, not failed acceptance), and material coverage gaps. Never report Good. when blocked or incomplete. Omit narration, speculation, and completion markers. Do not start repair, root-cause, or permanent test changes.

On normal completion, close or retain the workspace through the shared exploration workspace lifecycle. It owns which workspace is removed, safe cleanup, and exact retention when cleanup is unsafe. An admitted session, including one reporting Good., then follows finish the mission.

Signals

GitHub stars
49
Forks
72
Last commit
Oct 2026
Advanced
Item type
skill
Key
dough-manual-testing
Source
github.com/nerds-odd-e/doughnut