looply-new-session

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:

1. Read .looply/custom/session-links.json to inspect current sessions.
2. 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.
3. If the user asked for help, explain syntax, arguments, example, expected output and next step without mutating state.
4. Generate a unique session label if none provided (use a short timestamp-based suffix, e.g. session-<HHMM>).
5. 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.
6. Update the feature's workflow status file at .looply/custom/features/<feature-name>/workflow-status.md if it exists, noting the new session.
7. Output the exact $looply-auto-resume or $looply-resume command the user should paste in the new tab to resume the session.
8. Also suggest the CLI command looply sessions show <label> if the user prefers a CLI view.
9. Do not modify managed pack files. Write local state only under .looply/custom.
10. Respond in the same language as the user's input.
11. For existing projects, use the real local codebase as the primary source of truth and use context files only as accelerators.
12. Keep the response visually structured with clear Markdown section titles.
13. 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)