> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dotready.org/llms.txt
> Use this file to discover all available pages before exploring further.
# Ready Skill Modules: All Five Specialist Agent Guides
> Five specialist modules extend the Ready Skill Pack — each handles a focused domain and loads only when the product tree has a relevant gap to close.
The five Ready skill modules are specialist agent task guides that extend the entrypoint (`ready-skill.md`). The entrypoint routes; the modules execute. You never load all five at once — each module has a clear condition that tells the agent when to reach for it. Every module returns the same [worker output contract](/skills/overview#worker-output-contract), keeping orchestration predictable regardless of which modules ran.
## The five modules
**File:** `skills/modules/evidence-resource-review.md`
**Load when:** Evidence, samples, generated fixtures, public resources, or user-only information are missing or unverified.
Load this module for every non-trivial product tree, and specifically when any primitive, service, or flag depends on a sample, expected output, external data shape, or screenshot that has not been verified.
**Responsibilities:**
* Inventory every primitive, service, flag, and artifact that depends on a sample, resource, or expected output.
* Gather safe public resources — official docs, public datasets, open-source examples, published schemas, API specs — when they can answer a gap.
* Generate synthetic fixtures when product behavior can be proven without private or real user data.
* Ask the user for private or user-only material only when it materially changes the next stage.
* Store resources as artifact records or safe references, never as hidden chat memory.
* Record source, license or terms risk, retrieval date, privacy state, freshness, generation method, schema, and expected outputs for every resource.
**Sample categories to address:**
| Category | Purpose |
| --------------------------------------- | ------------------------------------------------- |
| Happy-path input | Normal case the coding agent should build toward |
| Expected output | Verifiable result for the happy-path input |
| Difficult edge case | Boundary or unusual input the product must handle |
| Failure or unavailable state | What happens when a dependency fails |
| Empty or first-run state | Initial experience before any data exists |
| Permission or access-denied state | What the user sees without required access |
| Stale, malformed, or conflicting source | Defensive case the product must survive |
| Proof-positive evidence | Sample that should close a flag |
| Proof-negative evidence | Sample that should NOT close a flag |
Keep sample purposes distinct: development samples help agents build locally, qualification samples prove correctness for review, and health samples support ongoing checks. One file can serve multiple purposes only when that does not hide coverage gaps.
**Completion check:** The module is complete when every build-critical primitive or flag has attached sample/resource artifacts, generated fixtures with expected outputs, public-source references with provenance, a precise user-only ask, or a blocked flag or question card explaining why the gap remains.
**File:** `skills/modules/access-readiness.md`
**Load when:** Accounts, credentials, environments, CLI logins, provider sessions, or service setup can block coding.
Load this module whenever a service, API key, OAuth app, provider session, database, deployment target, or CLI login is required for the next stage.
**Responsibilities:**
* Identify every service, account, credential, environment, permission, and CLI login needed for the next stage.
* Record service readiness as product truth — not as a private assumption in the agent's context.
* Create or request `.env.example` entries for variable names and non-secret setup hints.
* Direct the user to put real secrets in a safe, accessible location: untracked `.env.local`, OS keychain, 1Password, Vault, Supabase/Vercel/GitHub secret stores, provider-owned sessions, or another approved store accessible through a CLI or official SDK.
* Record only safe secret-location references: variable name, storage system, owner, required scope, setup status, and verification command.
* Create blocked flags when access is missing and coding would stall.
**Account readiness checklist fields:**
For each required service, capture all of the following:
```text theme={null}
- service name and environment
- account owner
- access status: ready | simulated | missing | blocked | not needed yet
- credential type and safe storage location
- required scopes or permissions
- setup steps the user must complete
- setup steps the agent can complete safely
- verification command or UI check
- fallback or simulation policy
- failure modes that coding agents should expect
```
**Safety rules — never break these:**
* Do not ask the user to paste raw secrets into chat.
* Do not commit tokens, cookies, private keys, API keys, OAuth secrets, database passwords, personal access tokens, or raw credential files.
* Do not store secrets in primitives, artifacts, samples, logs, screenshots, or generated work packages.
* If a credential is accidentally exposed, stop immediately and tell the user to rotate it.
**Completion check:** The module is complete when every required service has a readiness state, credential-location reference or blocked reason, setup path, verification check, and coding-agent-visible failure policy.
**File:** `skills/modules/design-artifact-readiness.md`
**Load when:** UI, workflow, copy, visual proof, component contracts, or design handoff can affect implementation.
Load this module when the product has a UI, user workflow, visual review surface, component contract, or customer-facing copy. Load it before any coding flag that touches interaction becomes claimable.
**Responsibilities:**
* Identify every intent, standard, service, and flag that depends on a visual or interaction decision.
* Gather existing designs, screenshots, mockups, prototypes, brand assets, design-system references, copy, and flow diagrams.
* Create low-fidelity mockups, HTML prototypes, component specs, or generated visual references when no useful design exists and the next stage needs one.
* Provide modular snippets or component contracts when they reduce ambiguity for coding agents.
* Mark prototype code as handoff reference unless the user explicitly makes it production source.
* Capture responsive behavior, loading states, empty states, error states, permission states, accessibility expectations, and content rules.
**Artifact storage locations:**
| Directory | What goes there |
| ------------ | ----------------------------------------------------------------------------------------- |
| `designs/` | Mockups, screenshots, visual references, diagrams, design handoff notes |
| `snippets/` | Component contracts, prototype code, copy blocks, state maps, reusable reference snippets |
| `resources/` | Design-system docs, public UI references, icon sources, external inspiration refs |
| `samples/` | UI state fixtures and expected outputs |
Record each design artifact's authority level: `target`, `reference`, `evidence`, `prototype`, `generated concept`, `stale`, or `superseded`. If a design conflicts with primitive truth, create a question card or primitive edit proposal — never silently blend the two.
**Design completeness checklist for claimable flags:**
```text theme={null}
□ Target user flow
□ Screen or component inventory
□ Primary, empty, loading, error, disabled, and permission states
□ Responsive behavior
□ Copy and labels
□ Asset and icon requirements
□ Accessibility requirements
□ Data displayed in each state
□ Interaction rules
□ Visual acceptance proof
□ Modular snippets or component contracts
```
**Completion check:** The module is complete when coding agents can see what should be built, what states must exist, which artifacts are authoritative, what is only reference, and what visual proof will be reviewed.
**File:** `skills/modules/coding-handoff-readiness.md`
**Load when:** A seed or delta flag may become claimable or a coding agent needs a work package.
Load this module before making any flag claimable. The product agent's job is to prepare the work package, not to become the coding agent.
**Responsibilities:**
* Convert product truth into coding-agent-ready flags and work packages without doing the implementation work itself.
* Ensure every claimable flag names scope, non-scope, dependencies, required standards, required services, required artifacts, setup needs, acceptance proof, and blocker policy.
* Ensure every required sample, resource, design, snippet, manifest, credential location, or environment setup reference is visible to the coding agent.
* Keep non-blocked seed flags non-ready until product leadership intentionally starts implementation.
* Allow blocked flags to be ready only when `blocked_by` prevents coding claims.
* Require Completion Proof before moving a flag to In Review or Closed.
**Work-package checklist — every claimable flag must include:**
```text theme={null}
□ Flag id and primitive branch
□ Intended product behavior
□ Scope and non-scope
□ User-facing and system-facing acceptance criteria
□ Required services and readiness state
□ Setup and verification commands
□ Required artifacts and sample ids
□ Design, snippet, or component references (when applicable)
□ Data shapes and expected outputs
□ Failure modes and edge cases
□ Relevant standards
□ Privacy, security, and authority limits
□ Completion Proof specification
□ How to report blockers and attach evidence
```
Do not prescribe internal file edits, function names, component structure, or migration strategy unless a standard, interface, architecture decision, or user instruction explicitly requires it. The coding environment chooses implementation strategy within the product, service, authority, and proof constraints you define.
**What not to do:**
* Do not make a flag claimable because the prose sounds clear while access, samples, designs, or proof are missing.
* Do not close flags based on coding-agent self-report alone — proof must pass review.
**Completion check:** The module is complete when a coding agent can claim the work, set up the environment, understand the target, implement within constraints, run proof, attach evidence, and know when to stop or report a blocker.
**File:** `skills/modules/perspective-review.md`
**Load when:** The tree needs psychological, physical, logical, evidence, design, or access challenge review.
Load this module before implementation handoff, after major discovery changes, or when confidence is low. The goal is to find missing truth before coding agents discover it by stalling or building the wrong thing.
**The six review perspectives:**
The psychological reviewer challenges motivation, trust, fear, desire, habit, and adoption barriers.
Key questions:
* What motivation, fear, or trust issue is missing from the tree?
* What emotional outcome does the user need to feel success?
* What would make the user reject the product even if the logic works correctly?
The physical reviewer challenges real-world context: devices, environment, time pressure, handoffs, manual steps, and operational constraints.
Key questions:
* What device, environment, or time constraint is missing?
* What must be true before, during, and after the product is used?
* What could go wrong because of physical or organizational reality?
The logic reviewer challenges rules, data shapes, state transitions, permissions, edge cases, and failure modes.
Key questions:
* What rules, data shapes, state transitions, or permissions are underspecified?
* What contradictions exist between premises, intents, standards, services, artifacts, and flags?
* What proof would catch a false-green implementation?
The evidence reviewer challenges sample completeness, provenance, and resource validity.
Key questions:
* What samples, expected outputs, public resources, or provenance are missing?
* Which facts are circular, stale, inferred, or unsupported?
* What can the agent gather safely, and what must the user provide?
The design reviewer challenges interface states, copy, assets, flows, and component contracts.
Key questions:
* What interface states, copy, assets, responsive behavior, or accessibility expectations are missing?
* Which design artifacts are authoritative versus illustrative?
* What visual proof should be required before the flag closes?
The access reviewer challenges accounts, credentials, environments, and work-package clarity.
Key questions:
* What account, credential, CLI login, or service readiness would stop coding?
* What work-package instruction is ambiguous or missing?
* Which flags should stay non-claimable until a blocker is resolved?
**Review output — each reviewer returns:**
```text theme={null}
- missing facts
- risky assumptions
- contradictions
- suggested cuts
- user-only asks
- safe agent-gatherable resources
- affected primitives, services, artifacts, or flags
- readiness recommendation: ready | draft | blocked | cut
```
**Completion check:** The review is complete when every material issue becomes one of: a primitive edit, an artifact or resource task, a service readiness update, a flag change, a question card, or an explicit cut from the next stage.
## Loading multiple modules
Load modules based on gaps, not ceremony. For small changes to an existing tree, you may need only one module. For substantial new product work, expect to run several.
**Common combinations:**
| Situation | Modules to load |
| ----------------------------------- | ------------------------------------------------------------ |
| New tree from scratch | Evidence review + Access readiness + Perspective review |
| UI feature heading to coding | Evidence review + Design artifact readiness + Coding handoff |
| Service integration | Access readiness + Coding handoff |
| Pre-handoff confidence check | Perspective review (all six roles) |
| Missing samples discovered mid-work | Evidence review only |
## Subagent strategy
For substantial Ready tree work, assign distinct perspectives to subagents instead of running the same review multiple times. Each subagent covers one perspective role and reports findings, risky assumptions, suggested cuts, and the exact primitives, artifacts, services, or flags affected.
Assign roles so each subagent has a different lens — psychological, physical, logic, evidence/resources, design, access/handoff. Running six identical general reviews wastes tokens and misses the coverage gaps that specialist framing catches.
The orchestrator collects all subagent outputs, resolves contradictions, and applies edits to the tree. Every issue must resolve into a primitive edit, artifact task, service readiness update, flag change, question card, or explicit cut — never a comment left in chat.