@jaybeeuu/agent-cortex 1.38.1 → 1.39.0

package/skills/planning/request-refactor-plan/SKILL.md

@@ -1,73 +1,84 @@
 ---
 name: request-refactor-plan
-description: Create a detailed refactor plan with tiny commits via user interview, then file it as a bead. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.
+description: Create a detailed refactor plan via user interview, split into tiny commits, then file it as a bead. Use when planning a refactor, writing a refactoring RFC, or splitting a refactor into safe steps.
 ---
 
-This skill will be invoked when the user wants to create a refactor request. You should go through the steps below. You may skip steps if you don't consider them necessary.
+# Request Refactor Plan
 
-1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
+## When to use
 
-2. Explore the repo to verify their assertions and understand the current state of the codebase.
+- The user asks to "plan a refactor", "write a refactoring RFC", or "break this into safe incremental steps".
+- A refactor is too big or risky to execute without a commit-level plan.
+- You need a detailed, interview-derived implementation plan filed as a tracked task.
 
-3. Ask whether they have considered other options, and present other options to them.
+## When NOT to use
 
-4. Interview the user about the implementation. Be extremely detailed and thorough.
+- Trivial one-shot edits that need no plan — make the change directly.
+- Product- or feature-level planning — use `write-a-prd`.
+- A refactor plan already exists — file or execute it; do not re-plan.
+- An early-stage idea not ready for planning — record it with `record-idea`.
 
-5. Hammer out the exact scope of the implementation. Work out what you plan to change and what you plan not to change.
+## Workflow
 
-6. Look in the codebase to check for test coverage of this area of the codebase. If there is insufficient test coverage, ask the user what their plans for testing are.
-
-7. Break the implementation into a plan of tiny commits. Remember Martin Fowler's advice to "make each refactoring step as small as possible, so that you can always see the program working."
-
-8. Create a bead with the refactor plan. Invoke the `create-task` skill, passing:
+1. Interview the user for a long, detailed description of the problem and any potential solution ideas. Capture their words — the plan must encode the user's decisions, not your assumptions.
+2. Explore the repo to verify their assertions and understand the current state of the codebase. Codebases drift, so check rather than trust.
+3. Ask whether they have considered other options, and present alternatives yourself.
+4. Interview the user about the implementation in detail. Make every decision the plan needs now, while context is fresh.
+5. Hammer out the exact scope: what the plan will change and what it will not change.
+6. Check test coverage of the affected area. If coverage is insufficient, ask what the testing plans are.
+7. Break the implementation into a plan of tiny commits. Follow Martin Fowler: make each refactoring step as small as possible so you can always see the program working. Each commit must leave the codebase in a working state.
+8. Invoke the `create-task` skill to file the bead, passing:
    - **title**: a concise name for the refactor
-   - **description**: the refactor plan formatted using the template below
+   - **description**: the refactor plan formatted with the template in `FORMAT.md`
    - **priority**: P2
 
-   **Always use `create-task`** — never call `bd create` directly for tasks. `create-task` classifies the bead and expands AFK tasks into pipeline stage children that ralph can execute.
-
-<refactor-plan-template>
-
-## Problem Statement
-
-The problem that the developer is facing, from the developer's perspective.
-
-## Solution
-
-The solution to the problem, from the developer's perspective.
+   Always invoke `create-task` — never `bd create` directly. `create-task` classifies the bead and expands AFK tasks into pipeline stage beads for ralph.
 
-## Commits
+## Red Flags
 
-A LONG, detailed implementation plan. Write the plan in plain English, breaking down the implementation into the tiniest commits possible. Each commit should leave the codebase in a working state.
+- Skipping the interview because the request seems clear. The interview surfaces decisions only the user knows; a plan built on assumptions will not match reality.
+- Adding file paths or code snippets to the Decision Document. Implementation detail goes stale quickly and misdirects the executor.
+- Planning commits too big to verify in isolation. If a step cannot leave the program visibly working, split it further.
 
-## Decision Document
+## Common Rationalizations
 
-A list of implementation decisions that were made. This can include:
+| Rationalization | Rebuttal |
+|---|---|
+| "The user already told me what they want — the interview is unnecessary" | The interview collects decisions, not descriptions. Without it the plan is guesswork. |
+| "I know this codebase — exploring again is a waste" | Codebases drift. Verifying assertions is cheap and prevents planning against stale assumptions. |
+| "File paths in the decision doc make it more useful" | File paths go stale quickly. Keep decisions in the doc, paths out. |
+| "This refactor is small — one or two commits will do" | Each step stays as small as possible so you can always see the program working. Small commits also keep reviews tractable. |
 
-- The modules that will be built/modified
-- The interfaces of those modules that will be modified
-- Technical clarifications from the developer
-- Architectural decisions
-- Schema changes
-- API contracts
-- Specific interactions
+## Philosophy / rationale
 
-Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
+- **Interview-first.** The plan encodes the user's decisions, made while context is fresh, not the agent's guesses.
+- **Tiny commits.** Fowler's rule — each step as small as possible so you can always see the program working — makes regressions localisable and reviews tractable.
+- **Decisions without paths.** A document that names files ages overnight; one that names decisions survives the implementation.
 
-## Testing Decisions
+## Phase-gate checklist
 
-A list of testing decisions that were made. Include:
+- [ ] Phase 1 complete: problem and ideas captured, assertions verified in the repo.
+- [ ] Phase 2 complete: alternatives discussed, scope and testing plan agreed.
+- [ ] Phase 3 complete: commit plan written with every step leaving the codebase working.
+- [ ] Phase 4 complete: bead filed via `create-task` with priority P2.
 
-- A description of what makes a good test (only test external behavior, not implementation details)
-- Which modules will be tested
-- Prior art for the tests (i.e. similar types of tests in the codebase)
+## Cross-skill references
 
-## Out of Scope
+- `create-task` — files the plan bead and expands it into pipeline stages. Mandatory; never call `bd create` directly.
+- `write-a-prd` — product-level planning that is not a code refactor.
+- `record-idea` — early-stage refactor ideas not ready for a full plan.
 
-A description of the things that are out of scope for this refactor.
+## Examples
 
-## Further Notes (optional)
+Input: "I want to refactor how config validation is wired in this repo"
+Output: a P2 bead filed via `create-task` whose description follows the `FORMAT.md` template: Problem Statement, Solution, a commit-by-commit plan (each leaving the repo working), a Decision Document with decisions only, Testing Decisions, and Out of Scope.
 
-Any further notes about the refactor.
+## Verification checklist
 
-</refactor-plan-template>
+- [ ] Interview covered problem, solution ideas, alternatives, and implementation details.
+- [ ] User's assertions verified against the actual codebase; nothing assumed unverified.
+- [ ] Scope agreed: what will change and what will not.
+- [ ] Test coverage assessed; testing plan recorded when coverage is insufficient.
+- [ ] Commit plan written with every commit leaving the codebase working.
+- [ ] Decision Document contains decisions only — no file paths or code snippets.
+- [ ] Bead filed via `create-task` with concise title, `FORMAT.md`-formatted description, priority P2.

package/skills/planning/write-a-prd/FORMAT.md

@@ -0,0 +1,54 @@
+# PRD Template
+
+Render this template in full when completing step 5 of `write-a-prd`. Keep every section;
+omit a section only when the user agrees it does not apply.
+
+## Problem Statement
+
+The problem that the user is facing, from the user's perspective.
+
+## Solution
+
+The solution to the problem, from the user's perspective.
+
+## User Stories
+
+A LONG, numbered list of user stories. Each user story should be in the format of:
+
+1. As an <actor>, I want a <feature>, so that <benefit>
+
+<user-story-example>
+1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
+</user-story-example>
+
+This list of user stories should be extremely extensive and cover all aspects of the feature.
+
+## Implementation Decisions
+
+A list of implementation decisions that were made. This can include:
+
+- The modules that will be built/modified
+- The interfaces of those modules that will be modified
+- Technical clarifications from the developer
+- Architectural decisions
+- Schema changes
+- API contracts
+- Specific interactions
+
+Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
+
+## Testing Decisions
+
+A list of testing decisions that were made. Include:
+
+- A description of what makes a good test (only test external behavior, not implementation details)
+- Which modules will be tested
+- Prior art for the tests (i.e. similar types of tests in the codebase)
+
+## Out of Scope
+
+A description of the things that are out of scope for this PRD.
+
+## Further Notes
+
+Any further notes about the feature.

package/skills/planning/write-a-prd/SKILL.md

@@ -3,72 +3,73 @@ name: write-a-prd
 description: Create a PRD through user interview, codebase exploration, and module design, then file as a bead. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.
 ---
 
-This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary.
+# Write a PRD
 
-1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
+## When to use
 
-2. Explore the repo to verify their assertions and understand the current state of the codebase.
+- The user asks to "write a PRD", wants a "product requirements document", or says "plan a new feature".
+- A feature idea needs a written specification before implementation starts.
+- You need a durable record of the problem, solution, user stories, and key decisions.
 
-3. Interview the user relentlessly about every aspect of this plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
+## When NOT to use
 
-4. Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
+- The idea is not ready to build yet — use `record-idea` to capture it to the backlog.
+- The output targets a human team's external tracker — use `write-a-ticket`.
+- A PRD already exists and needs breaking into tasks — use `prd-to-tasks`.
+- The scope is a refactor needing a safe incremental plan — use `request-refactor-plan`.
 
-A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.
+## Workflow
 
-Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
+1. **Gather the problem statement.** Ask the user for a long, detailed description of the problem and any potential solution ideas. Ask one question at a time.
+2. **Explore the codebase.** Verify the user's assertions against the repo's current state. Explore instead of asking when the answer lives in code.
+3. **Interview relentlessly.** Walk down each branch of the design tree, resolving dependencies between decisions one by one, until the user's understanding and yours are identical. Every open question at this point becomes ambiguity in the PRD.
+4. **Sketch the modules.** List the major modules to build or modify, actively looking for deep modules — ones that encapsulate rich behaviour behind a simple, stable interface testable in isolation. Confirm the list with the user, plus which modules they want tests written for.
+5. **Write the PRD.** Render the template in `FORMAT.md` (Problem Statement, Solution, User Stories, Implementation Decisions, Testing Decisions, Out of Scope, Further Notes). Make the user-story list extremely extensive so it covers all aspects of the feature.
+6. **File the bead.** Create the epic with `bd create "<title>" --type epic --priority P1 --body-file -`, piping the rendered PRD to stdin, then run `classify-bead` (as a subagent, per its invocation instructions) to label it AFK or HITL.
 
-5. Once you have a complete understanding of the problem and solution, use the template below to write the PRD. Create a bead for it using `bd create` with type `epic` and priority P1, passing the rendered PRD template as the description.
+Run the steps in order. Skip a step only when the user confirms it is unnecessary (e.g. the codebase is already explored).
 
-<prd-template>
+## Red Flags
 
-## Problem Statement
+- Red flag: writing the PRD while an interview branch is still unresolved — each unanswered branch becomes a guess in the spec.
+- Red flag: accepting user assertions about the codebase without verifying them in the repo.
+- Red flag: a thin user-story list — a handful of stories usually means aspects of the feature were never discussed.
 
-The problem that the user is facing, from the user's perspective.
+## Common Rationalizations
 
-## Solution
+| Rationalization | Rebuttal |
+|---|---|
+| "I have enough context — the user is impatient" | Impatience is a signal to keep questions short, not to skip them. Unresolved branches surface later as rework. |
+| "The feature is simple, a few stories are enough" | An extensive story list is how hidden aspects of the feature surface; thin stories mean thin scope coverage. |
+| "I know this codebase, no need to explore" | Verification in the repo is cheap; a wrong assumption becomes a wrong PRD. |
 
-The solution to the problem, from the user's perspective.
+## Philosophy / rationale
 
-## User Stories
+- The PRD is the contract between intent and implementation; its quality caps everything downstream, so exhaust the interview before writing.
+- Deep modules beat shallow ones — in code and in the PRD's implementation decisions. Interfaces worth stating are stable ones.
 
-A LONG, numbered list of user stories. Each user story should be in the format of:
+## Phase-gate checklist
 
-1. As an <actor>, I want a <feature>, so that <benefit>
+- [ ] Gate 1 — shared understanding: every design-tree branch resolved and the user confirms the summary.
+- [ ] Gate 2 — modules agreed: the module list and test expectations match the user's model of the solution.
+- [ ] Gate 3 — PRD filed: the epic bead contains the rendered template and carries an implementation-type label.
 
-<user-story-example>
-1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
-</user-story-example>
+## Cross-skill references
 
-This list of user stories should be extremely extensive and cover all aspects of the feature.
+- Use `record-idea` when the idea is not yet ready to build.
+- Use `write-a-ticket` when the spec targets an external tracker rather than a bead.
+- Run `prd-to-tasks` on the filed epic to break the PRD into an executable backlog.
+- Run `classify-bead` on the new epic — the repo labels every new bead AFK or HITL.
 
-## Implementation Decisions
+## Examples
 
-A list of implementation decisions that were made. This can include:
+Input: "Write a PRD for adding scheduled exports to the reporting feature"
+Output: an epic bead whose description is the rendered PRD — problem, solution, extensive user stories, implementation and testing decisions, out-of-scope items, and further notes.
 
-- The modules that will be built/modified
-- The interfaces of those modules that will be modified
-- Technical clarifications from the developer
-- Architectural decisions
-- Schema changes
-- API contracts
-- Specific interactions
+## Verification checklist
 
-Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
-
-## Testing Decisions
-
-A list of testing decisions that were made. Include:
-
-- A description of what makes a good test (only test external behavior, not implementation details)
-- Which modules will be tested
-- Prior art for the tests (i.e. similar types of tests in the codebase)
-
-## Out of Scope
-
-A description of the things that are out of scope for this PRD.
-
-## Further Notes
-
-Any further notes about the feature.
-
-</prd-template>
+- [ ] Template in `FORMAT.md` rendered fully, with no placeholder sections.
+- [ ] Every user story follows "As an <actor>, I want <feature>, so that <benefit>".
+- [ ] Codebase assertions verified against the repo before writing.
+- [ ] Implementation Decisions contains no file paths or code snippets.
+- [ ] Epic bead filed with type `epic`, priority P1, the rendered PRD as description, and an implementation-type label applied.

package/skills/planning/write-a-ticket/SKILL.md

@@ -1,97 +1,112 @@
 ---
 name: write-a-ticket
-description: Write a well-structured ticket for an external issue tracker (e.g. Jira). Use when writing tickets intended for a human engineering audience — not for creating implementation tasks in a ralph/bd loop.
+description: Write a well-structured ticket for an external issue tracker (e.g. Jira) that an engineer can act on without follow-up questions. Use when asked to "write a ticket", "file this in Jira", or "create a work item" — not for creating implementation tasks in a ralph/bd loop.
+argument-hint: "The work to ticket: goal, epic/initiative, constraints, or paste a draft"
 ---
 
 # Write a Ticket
 
-Tickets are for skilled engineers. They should be able to pick one up, understand the context immediately, know where to start, and deliver the right outcome — without having to ask questions or wade through noise.
+## When to use
 
-**Write for clarity, not coverage.** A ticket is not a specification. Prefer one well-chosen sentence over three that say the same thing.
+- Asked to "write a ticket", "file this in Jira", or "create a work item".
+- Drafting an actionable work item for a human engineering audience in an external issue tracker (Jira, Linear, GitHub Issues).
+- Checking an existing ticket for clarity before it goes to the team.
 
----
-
-## Process
-
-### 1. Gather context
-
-Before drafting, confirm you have:
-- The goal of the work
-- Which epic, RFC, or initiative this belongs to (if any)
-- Any known constraints or decisions already made
-- Relevant code locations, schemas, or prior art
+## When NOT to use
 
-If anything is unclear, ask before writing.
+- Creating implementation tasks for the ralph/bd loop — those are beads executed by agents, not tickets read by engineers.
+- Writing a requirements document for a feature that is not yet actionable — run `write-a-prd` first and link the PRD from the ticket.
 
-### 2. Draft the ticket
+## Workflow
 
-Use the template below. Every section has a purpose — do not pad it, and do not omit a required section without good reason.
-
-### 3. Review against the checklist
-
-Before finalising, check:
-- [ ] Could a skilled engineer start this immediately with no follow-up questions?
-- [ ] Is every sentence earning its place? Remove anything that doesn't add information.
-- [ ] Are acceptance criteria verifiable, not vague?
-- [ ] Do technical notes point at the right things without over-prescribing the solution?
-
----
+1. **Gather context.** Confirm the goal of the work, the epic/RFC/initiative it belongs to (if any), known constraints or decisions, and relevant code locations, schemas, or prior art. Outcome: you can state the ticket's purpose in one sentence. If you cannot, ask before writing.
 
-## Template
+2. **Draft the ticket.** Work through the template below. Every section has a purpose — write it only if it earns its place, and never omit a required section without recording why.
 
 ```markdown
 ## Context
 
-<1–3 sentences. Set the scene: why does this work exist, what larger initiative is it part of?
-Link to the relevant epic, RFC, ADR, or prior ticket — don't duplicate their content here.>
+<1–3 sentences: why this work exists, and which epic/RFC/ADR it belongs to. Link to it — never copy-paste its content.>
 
 ## Description
 
-<What needs to be built or changed. Describe the outcome, not the implementation steps.
-Be specific about scope — what is in and what is explicitly out.>
+<What to build or change. Describe the outcome, not the implementation steps, and state scope explicitly — what is in and what is out.>
 
 ## Acceptance criteria
 
-- [ ] <Specific, verifiable criterion>
-- [ ] <Specific, verifiable criterion>
-- [ ] <Specific, verifiable criterion>
+- [ ] <Specific, independently verifiable criterion — e.g. "given X, the API returns Y">
+- [ ] <...>
 
 ## Technical notes
 
-<Links to relevant code, suggested request/response/document schemas, architectural decisions,
-or guidance the implementer should know. This is a pointer, not a design document —
-if a decision needs more space, it belongs in an ADR or RFC.>
+<Links to relevant code, agreed schemas, architectural decisions, or upstream constraints. A pointer, not a design document — decisions that need more space belong in an ADR or RFC.>
 
 ## Testing strategy
 
-<Optional. Agreed testing levels for this change: e.g. unit, integration, contract, E2E.
-Only include if there is something non-obvious to say.>
+<Optional. Only when testing needs are non-obvious or a level was agreed — unit, integration, contract, E2E. Omit when team defaults apply.>
 
 ## Monitoring strategy
 
-<Optional. How will this change be observed in production? e.g. new metrics, alerts, log events,
-dashboards, or feature flag rollout stages. Only include if the change has non-obvious observability
-requirements or a specific rollout approach was agreed.>
+<Optional. Only when the change adds metrics, alerts, log events, dashboards, or a phased rollout. Omit when there is no meaningful observability footprint.>
 
 ## Notes
 
-<Optional. Anything else that is genuinely useful and doesn't fit above.>
+<Optional. Genuinely useful details with no other home. If you reach for this often, restructure the ticket.>
 ```
 
----
+3. **Review against the checklist.** Work through the verification checklist below before finalising.
+
+## Red Flags
+
+- Writing implementation steps into the description — describe the outcome, not the how.
+- Acceptance criteria that cannot be verified: "works correctly", "is tested".
+- Copy-pasting context instead of linking to the epic, RFC, or ADR.
+- Padding sections with filler to look complete — a short, accurate ticket beats a padded one.
+- Omitting a required section without recording why.
+
+## Common Rationalizations
+
+| Rationalization | Rebuttal |
+|---|---|
+| "The engineer will figure it out" | Skilled engineers can — but questions are a blocked ticket. The ticket must stand alone. |
+| "More detail is safer" | Detail only helps if it informs the implementer. Every extra sentence is noise to skim. |
+| "We will verify acceptance criteria in review" | Unverifiable criteria cannot be checked. Write given/outcome pairs instead. |
+| "We will discuss the details in standup" | The ticket is the record. If it cannot stand alone, the discussion is lost. |
+
+## Philosophy / rationale
+
+- **Write for clarity, not coverage.** A ticket is not a specification. One well-chosen sentence beats three that say the same thing.
+- **Describe the outcome, not the implementation.** The ticket owns the what and why; the implementer owns the how.
+- **A ticket must stand alone.** Link, don't copy — readers who need the full rationale should open the linked document, not a paraphrase.
+
+## Cross-skill references
 
-## Guidance per section
+| When you need… | Use this skill |
+|---|---|
+| Tone, structure, and concision for human-facing writing | `style-comms` |
+| A requirements document that precedes the ticket | `write-a-prd` |
 
-**Context** — one job: explain *why*. A reader should understand the motivation without opening another tab. Link freely; copy-paste never.
+## Examples
 
-**Description** — describes *what*, not *how*. Avoid implementation steps. If scope boundaries matter, state them explicitly ("this ticket does not include X").
+### Vague vs verifiable acceptance criteria
 
-**Acceptance criteria** — must be independently verifiable. Avoid "works correctly" or "is tested". Prefer "given X, the API returns Y" or "the migration runs without errors on staging".
+| Instead of… | Write… |
+|---|---|
+| "The export feature works" | "Given exports enabled, selecting 'Export CSV' downloads `<account>-export-<date>.csv`" |
+| "Adds tests for the new endpoint" | "POST /v1/orders returns 201 with the created order for valid input and 422 with field errors for schema violations" |
 
-**Technical notes** — share what the implementer needs to know, not everything you know. Good candidates: a tricky code location, a schema that has already been agreed, a constraint from an upstream system. Bad candidates: a tutorial on the technology, decisions that haven't been made yet.
+### Context that links vs context that copies
 
-**Testing strategy** — omit if the team's default testing conventions apply. Include only when this ticket has unusual testing requirements or a specific agreement was reached.
+| Instead of… | Write… |
+|---|---|
+| Four paragraphs paraphrasing the ADR | "Follows ADR-014 (token refresh). This ticket adds only the retry path — see ADR link." |
 
-**Monitoring strategy** — omit if the change has no meaningful observability footprint. Include when the ticket introduces new metrics, requires new alerts, involves a phased rollout, or has an agreed approach to validating success in production.
+## Verification checklist
 
-**Notes** — a catch-all for genuinely relevant information that has no other home. If you're reaching for it often, the ticket probably needs restructuring.
+- [ ] Context explains why the work exists; the reader needs no other tab open
+- [ ] Description states the outcome, not implementation steps, and defines scope
+- [ ] Acceptance criteria are independently verifiable — no "works correctly" or "is tested"
+- [ ] Technical notes link to code or schemas without prescribing the solution
+- [ ] Testing/Monitoring/Notes present only when they add non-obvious information
+- [ ] Every sentence passes the "does this add information?" test
+- [ ] A skilled engineer can start immediately with zero follow-up questions

package/skills/productivity/handoff/SKILL.md

@@ -13,3 +13,15 @@ Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs,
 Redact any sensitive information, such as API keys, passwords, or personally identifiable information.
 
 If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.
+
+## Output a starter prompt
+
+As the last section of the document, include a `## Starter prompt` section containing a ready-to-paste prompt the user can give the next session. The prompt must:
+
+1. Point the new session at the handoff document itself by absolute path.
+2. State the focus of the next session in one or two sentences.
+3. Tell the new session to read the handoff first, then the referenced artifacts it needs, before acting.
+4. Ask the new session to clean up any provisional/test artifacts the handoff documents (e.g. prototype beads created during the session) unless the handoff says otherwise.
+5. Stay under ~150 words so it can be pasted verbatim as the first message.
+
+The point of the starter prompt is to give the next session a minimal-context start: everything it needs lives in the handoff document and the artifacts it references, so the first message can be short.