Skip to main content
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, keeping orchestration predictable regardless of which modules ran.

​
The five modules

File: skills/modules/evidence-resource-review.mdLoad 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:
CategoryPurpose
Happy-path inputNormal case the coding agent should build toward
Expected outputVerifiable result for the happy-path input
Difficult edge caseBoundary or unusual input the product must handle
Failure or unavailable stateWhat happens when a dependency fails
Empty or first-run stateInitial experience before any data exists
Permission or access-denied stateWhat the user sees without required access
Stale, malformed, or conflicting sourceDefensive case the product must survive
Proof-positive evidenceSample that should close a flag
Proof-negative evidenceSample 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.mdLoad 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:
- 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.mdLoad 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:
DirectoryWhat 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:
□ 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.mdLoad 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:
□ 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.mdLoad 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?
Review output — each reviewer returns:
- 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:
SituationModules to load
New tree from scratchEvidence review + Access readiness + Perspective review
UI feature heading to codingEvidence review + Design artifact readiness + Coding handoff
Service integrationAccess readiness + Coding handoff
Pre-handoff confidence checkPerspective review (all six roles)
Missing samples discovered mid-workEvidence 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.