Use one fictional feature throughout: LOGIN-01, an email-and-password login. Its requirements are deliberately small. You can inspect whether the agent follows them without building an entire application.

R1: An active, verified account with correct credentials
    opens the account home page.
R2: A wrong password shows "Email or password is incorrect."
    No authenticated session is created.
R3: An empty email or password shows a required-field message.
    The form is not submitted.

Unspecified: lockout threshold and session lifetime.

The deliverable is test-cases/login.md: test cases linked to R1–R3, plus an explicit list of unresolved questions. The agent writes a plan. It does not implement login, execute tests, or certify the feature as secure. Those are separate jobs with different evidence requirements.

For repeated instructions in the main conversation, a skill may be enough. A subagent adds a separate context and a defined tool set. Here, the combination lets a dedicated QA worker apply the same test-design procedure each time.[1][2]

Start with a narrow job whose mistakes you can recognize.A confident report with invented requirements has failed the contract.

Save the complete definition below. Claude Code reads the YAML configuration and uses the Markdown body as the custom prompt. The skills list preloads the named skill’s full content.[1]

---
name: login-qa
description: >-
  Creates a test plan from supplied login requirements.
  Use when a user asks for login test cases or a login coverage review.
tools: Read, Grep, Glob, Write
model: inherit
skills:
  - login-test-design
---

You design test cases for an email-and-password login feature.
Use the requirements supplied in the delegated task, including
any explicitly named source files. Follow login-test-design.

Write the report to test-cases/login.md. If it already exists,
read it first and replace it only when this task requests an update.
Do not modify application code or execute tests.

Treat missing or conflicting requirements as open questions.
Do not turn assumptions or remembered policies into facts.

Return the report path and a short summary of coverage and gaps.
If writing is denied, report the blocker; never claim a file exists
without a successful write.

name and description are required; the other fields shown are choices for this example. model: inherit follows the parent’s model. A role sentence provides context, but the observable instructions do the real specification work: what to read, what to produce, and when to report a blocker.[1]

Supply LOGIN-01 when you invoke the agent. An ordinary subagent receives a delegated task rather than your entire conversation. Text such as {USER_INPUT} is not a documented agent-file substitution mechanism. Skills have their own documented argument syntax, including $ARGUMENTS.[1][2]

Create the folder and save this as SKILL.md. Here, user-invocable: false hides the standalone slash command while keeping the skill available to Claude. It can still be preloaded by the agent.[2]

---
name: login-test-design
description: >-
  Designs traceable test cases for email-and-password login
  requirements, including missing policy questions.
user-invocable: false
---

# Login Test Design

## 1. Read
Extract the supplied requirement IDs and their exact behaviors.
If IDs are absent, assign local R1, R2, ... labels and quote each
requirement under its label. Separate missing details and conflicts.

## 2. Design
Cover each stated requirement with an independently checkable case.
Consider success, rejection, and input boundaries where supported.
Keep additional security suggestions separate from required behavior.
Never invent lockout thresholds, timings, or API responses.
Use synthetic accounts; never include real credentials.

## 3. Deliver
Produce Markdown with these headings:
# Login Test Plan
## Requirements
## Test Cases
## Open Questions

For each test case use:
### TC-001 — Descriptive title
- Requirement: source ID
- Preconditions: exact starting state
- Steps: numbered actions
- Expected result: observable behavior from the requirement

Use consecutive IDs: TC-001, TC-002, ...
Include a coverage line mapping each requirement ID to case IDs.
If a requirement lacks an expected behavior, mark it blocked in
Open Questions instead of inventing a result. Write "None" when
there are no open questions. Do not report tests as executed.

## Example case for R2
### TC-002 — Reject a wrong password
- Requirement: R2
- Preconditions: An active, verified synthetic account exists.
- Steps:
  1. Enter its email and an incorrect password.
  2. Submit the login form.
- Expected result: Show "Email or password is incorrect."
  and create no authenticated session.

The three phases organize this particular job. They are an editorial choice, not a required skill architecture. The example case resolves a practical ambiguity: a rejection test checks both the message and the absence of a session. A generic “login fails” would leave too much room for interpretation.

The agent owns the destination and overall scope; the skill owns the procedure and case fields. If your team later changes the report format, edit the skill. Avoid copying the entire procedure into both files, where the two versions can quietly diverge.

The prompt asks the agent to stay within test planning. The agent’s tools field limits available tool categories. Claude Code’s permission rules govern whether an attempted operation may run. A sentence saying “write only this report” is an instruction, not a filesystem boundary.[1][3]

Inspect /permissions for your first run. If you want to pre-approve the report path, merge this entry into the existing .claude/settings.local.json. Preserve any other settings. The leading slash here anchors to the primary working directory; start Claude Code at the project root.[3]

{
  "permissions": {
    "allow": [
      "Edit(/test-cases/login.md)"
    ]
  }
}

Edit(path) rules cover built-in file modification, including the Write tool. Current documentation says path-scoped Write(path) rules are ignored. This allow entry pre-approves the report; it does not deny other paths. Other operations still depend on the active mode and remaining rules.[3]

A skill’s allowed-tools also grants approval rather than defining an exclusive tool set. Leave it out of this skill; the agent already declares the needed tools. Avoid broad shell or MCP approvals simply because a generic template includes them.[2]

Run the baseline first. Later, add memory: project to the agent’s YAML if it should retain project conventions. Claude Code manages notes under .claude/agent-memory/login-qa/. This adds saved context; it does not retrain model weights.[1][4]

Add this instruction to the agent body alongside that configuration:

Consult memory for confirmed project conventions, then verify them
against current requirements. Save stable report conventions with
a source pointer. Do not save credentials, ticket-specific details,
or guessed policies. Current explicit requirements take precedence.

“We label requirements R1, R2…” may be reusable. “Lock accounts after five attempts” is not reusable evidence unless a current policy establishes it. Store where a convention came from, and revisit it when that source changes.

Memory startup includes the first 200 lines or 25KB of MEMORY.md, whichever comes first. Enabling memory also adds Read, Write, and Edit tools; disabling auto memory disables this feature. Recheck access when you enable it.[1]

Start a fresh Claude Code session in your project root and submit this request. It supplies the feature directly, without relying on earlier conversation context.

Use the login-qa agent to create test-cases/login.md for LOGIN-01.
Do not execute tests or change application code.

R1: An active, verified account with correct credentials opens
    the account home page.
R2: A wrong password shows "Email or password is incorrect."
    No authenticated session is created.
R3: An empty email or password shows a required-field message.
    The form is not submitted.

The lockout threshold and session lifetime are unspecified.

Inspect the delegation and resulting file. R1 needs a successful sign-in case. R2 needs a rejection case with both stated outcomes. R3 needs coverage for each empty field. Every case must contain the required fields, and the coverage line must connect cases to requirements. Lockout and session lifetime should remain open questions.

Then repeat with controlled changes. The following are suggested checks, not results from an executed agent run. Inspect repository changes after each run as well as the text of the report.

When something fails, inspect the layer responsible. A missing agent calls for a discovery check. A missing procedure calls for checking the skill name and file. An invented policy calls for a better evidence rule and another run with incomplete input. An unauthorized write calls for examining permission enforcement.

Current Claude Code supports creating agent files directly. If the agent is not detected, restart the session and check its frontmatter and location. The older /agents creation wizard was removed in version 2.1.198. Renaming a specialist to a “neutral” name is not a general fix for ignored instructions.[1]

Keep LOGIN-01 and its altered versions as repeatable review inputs. After changing a prompt, skill, model, or permission, rerun the cases that exercise that change. A clean Markdown file tells you the output is readable. Requirement coverage, honest unknowns, and observed tool behavior tell you whether the worker is useful.

Your first agent is ready to reuse when its work is easy to verify.Keep the job small. Preserve the evidence. Expand its responsibilities only when you can test the new behavior.