| name | looply-new-session |
| description | Use to open a new session tab for a feature. Registers the session in session-links.json and provides the resume command for the new tab. |
Use this skill when the user explicitly invokes $looply-new-session, asks to run /looply:new-session, or requests a new session tab for a feature.
Workflow phase: none.
Category: navigation.
Quick usage:
$looply-new-session <feature-name> [session-label]
Primary references:- Session links: ../../../../.looply/custom/session-links.json
- Session context: ../../../../.looply/custom/session-context.md
- Context index: ../../../../.looply/state/context-index.md
- Project context: ../../../../.looply/custom/project-context.md
- Managed pack: ../../../../.looply/managed/packs/software-delivery-suite
- Custom overrides: ../../../../.looply/custom
Usage:
- Explicit mention:
$looply-new-session
- Workflow alias to honor:
/looply:new-session and $looply-new-session depending on host
- Syntax in OpenCode:
$looply-new-session <feature-name> [session-label]
Example:
- $looply-new-session pix-webhook-retry backend-afternoon
- $looply-new-session auth-refresh
When to use:
- The user wants to open a new terminal tab to work on a feature in parallel.
- The user needs a fresh session bound to a specific feature with an optional label.
- The user wants to register a concurrent session for a feature already in progress.
Curated example guidance:
- ICL mode:
on
- Use examples only for style, structure and quality calibration.
- Do not copy feature-specific names, identifiers or business details from examples.
- No example was selected for this workflow.
Execution rules:
- Read
.looply/custom/session-links.json to inspect current sessions.
- If
<feature-name> does not exist as a feature directory under .looply/custom/features/, suggest running $looply-idea-to-prd <feature-name> or $looply-workflow-status <feature-name> first.
- If the user asked for help, explain syntax, arguments, example, expected output and next step without mutating state.
- Generate a unique session label if none provided (use a short timestamp-based suffix, e.g.
session-<HHMM>).
- Add the new session entry to
session-links.json using the real data model (label, feature, lastCommand, lastUpdatedAt). Use looply sessions link <label> <feature> or write directly.
- Update the feature's workflow status file at
.looply/custom/features/<feature-name>/workflow-status.md if it exists, noting the new session.
- Output the exact
$looply-auto-resume or $looply-resume command the user should paste in the new tab to resume the session.
- Also suggest the CLI command
looply sessions show <label> if the user prefers a CLI view.
- Do not modify managed pack files. Write local state only under
.looply/custom.
- Respond in the same language as the user's input.
- For existing projects, use the real local codebase as the primary source of truth and use context files only as accelerators.
- Keep the response visually structured with clear Markdown section titles.
- Do not use emojis.
Composed Agent Context
The sections below were pre-composed by looply from agent context_slots.
Constraints
- Do not implement feature code directly
- Do not modify managed pack files
- Do not create or delete features without explicit user confirmation
Escalation
- Escalate missing feature context to
$looply-workflow-status
- Escalate feature creation to
$looply-idea-to-prd
Project Rules
project-conventions
Project Conventions
Purpose
Define project-level conventions for collaboration that agents must follow when interacting with version control, pull requests and releases.
Rules
- Follow the project's established branching strategy.
- Write clear, descriptive commit messages.
- PRs must include a summary of changes and link to the relevant story.
- Do not commit generated files or build artifacts.
- Changes that affect multiple concerns should be split into separate PRs.
Examples
- Good commit:
feat: add retry logic to payment processing
- Bad commit:
fix stuff
Enforcement
- Branch protection rules enforce review requirements.
- CI checks run on every PR.
- Commit message convention enforced via hooks or CI.
Arguments:
- feature-name: short identifier of the feature to open a session for (required)
- session-label: optional label to identify this session among parallel sessions (optional, auto-generated if omitted)
