@vpxa/aikit 0.1.74 → 0.1.75

package/scaffold/_preview/skills/repo-access/references/platform-matrix.md

@@ -1,142 +0,0 @@
-# Platform Matrix
-
-Use this reference when a repository URL reveals the hosting platform and the skill needs platform-specific authentication or cloning guidance. Prefer platform CLI login flows or OS-backed credential helpers over raw PAT handling.
-
-## Platform Detection
-
-| URL Pattern | Platform | CLI Tool (optional) | Auth Command | No-CLI Alternative |
-|---|---|---|---|---|
-| `github.com` | GitHub | `gh` | `gh auth login` | PAT + `http` with `Authorization: token <PAT>` |
-| Any custom domain (e.g. `ghe.corp.com`, `github.corp.com`) | GitHub Enterprise | `gh` | `gh auth login --hostname <host>` | PAT + `http` against `<host>/api/v3` |
-| `gitlab.com` | GitLab | `glab` | `glab auth login` | PAT + `http` with `PRIVATE-TOKEN` header |
-| Self-hosted GitLab | GitLab Self-Managed | `glab` | `glab auth login --hostname <host>` | PAT + `http` with `PRIVATE-TOKEN` header |
-| `bitbucket.org` | Bitbucket Cloud | None | N/A | App password + `http` with `Authorization: Bearer` |
-| `dev.azure.com` or `*.visualstudio.com` | Azure DevOps | `az` + GCM | `az login` | PAT + `http` with Basic auth |
-| Gitea instances | Gitea | `tea` (optional) | `tea login add` | PAT + `http` with `Authorization: token` |
-| Unknown or custom domain | Ask user which platform | N/A | N/A | Probe `http` or ask before assuming generic Git |
-
-> **Note:** Platform CLIs (`gh`, `glab`, `az`, `tea`) are native binaries, not npm packages. Do NOT use `npx` to install them — it will fail or install unrelated/unofficial packages. When the CLI is unavailable, use the No-CLI Alternative column.
-
-## GitHub / GitHub Enterprise
-
-- CLI: `gh auth login` uses a browser or device code flow and can open the browser automatically.
-- GitHub Enterprise CLI: `gh auth login --hostname <host>`.
-- PAT creation: `https://github.com/settings/tokens` for classic tokens.
-- PAT creation: `https://github.com/settings/personal-access-tokens` for fine-grained tokens.
-- Minimum scopes: `repo` for classic PATs (NOTE: `repo` grants read and write — prefer fine-grained PATs with `Contents: Read` for read-only access).
-- Minimum scopes: `Contents: Read` for fine-grained PATs.
-- SSH: `git@github.com:owner/repo.git`.
-- Credential helper: `gh auth setup-git` configures Git to use the GitHub credential flow.
-- Note: Fine-grained PATs may not cover organization-level access or every repo path; classic PATs are still required for some org repos.
-- SAML SSO: PATs often require explicit org authorization from `https://github.com/settings/tokens` after creation.
-- Enterprise note: PAT URLs and token policy can vary by host; reuse the same auth pattern with the enterprise hostname and instance settings pages.
-- Enterprise detection: GHE instances use fully custom domains (e.g. `ghe.coxautoinc.com`, `github.acme.com`). If unsure, probe `https://<host>/api/v3` — a GitHub Enterprise instance returns a JSON response with `installed_version`. Use `gh auth login --hostname <host>` with any custom GHE domain.
-
-## GitLab / GitLab Self-Managed
-
-- CLI: `glab auth login` uses a browser-backed OAuth flow.
-- Self-managed CLI: `glab auth login --hostname <host>`.
-- PAT creation: `https://gitlab.com/-/user_settings/personal_access_tokens`.
-- Minimum scopes: `read_repository`.
-- SSH: `git@gitlab.com:owner/repo.git`.
-- Credential helper: `glab auth setup-git` configures Git credential handling.
-- Note: If 2FA is enabled, username/password Git auth is blocked; a PAT is mandatory for HTTPS auth.
-- Self-managed note: PAT URL is typically `https://<host>/-/user_settings/personal_access_tokens` unless the instance customizes settings paths.
-
-## Bitbucket Cloud
-
-- CLI: No official first-party CLI OAuth flow for repo auth.
-- PAT/App Password creation: `https://bitbucket.org/{workspace}/settings/app-passwords`.
-- Minimum permissions: `Repositories: Read`.
-- SSH: `git@bitbucket.org:owner/repo.git`.
-- Note: Bitbucket Cloud uses App Passwords rather than standard PAT terminology.
-- Note: HTTPS auth requires both the Bitbucket username and the app password, delivered through a credential helper or `GIT_ASKPASS` script — never embedded in the clone URL.
-
-## Azure DevOps
-
-- CLI: `az login` authenticates to Microsoft Entra ID; Git Credential Manager then handles Git credentials automatically.
-- PAT-based auth remains the fallback when Entra ID or GCM is unavailable.
-- PAT creation: `https://dev.azure.com/{org}/_usersSettings/tokens`.
-- Minimum scopes: `Code: Read`.
-- SSH: `git@ssh.dev.azure.com:v3/{org}/{project}/{repo}`.
-- Note: Microsoft Entra ID tokens are generally preferred over PATs in enterprise environments.
-- Credential helper: Git Credential Manager via `git-credential-manager configure`.
-- Legacy host note: Azure DevOps may also appear under `*.visualstudio.com` URLs.
-
-## Gitea / Forgejo
-
-- CLI: `tea login add` is available but optional and not universally installed.
-- PAT creation: `https://{host}/user/settings/applications`.
-- Minimum scopes: `repo`.
-- SSH: `git@{host}:owner/repo.git`.
-- Note: Forgejo commonly mirrors the same applications-token path and PAT model as Gitea.
-- Note: Some self-hosted instances rename scopes or disable API token creation, so confirm the instance policy if `repo` is rejected.
-
-## Generic Git (Self-Hosted)
-
-- Platform CLI: None assumed.
-- Auth path: Prefer SSH keys first, then PAT if the host documents HTTPS token auth.
-- PAT creation: Ask the user for the platform's PAT or application-token settings URL.
-- SSH: Use the host's documented SSH remote format; do not assume GitHub-style shortcuts if the server advertises a different pattern.
-
-## API File-Read Endpoints (for web-based code access)
-
-When agents need to read individual files without cloning, use these authenticated API endpoints.
-
-### GitHub / GitHub Enterprise
-
-```text
-# Read file contents (returns JSON with base64 content)
-GET https://api.github.com/repos/{owner}/{repo}/contents/{path}?ref={branch}
-Authorization: token <PAT>
-
-# GHE: replace api.github.com with <ghe-host>/api/v3
-GET https://<ghe-host>/api/v3/repos/{owner}/{repo}/contents/{path}?ref={branch}
-
-# Or use gh CLI (auto-authenticated):
-gh api repos/{owner}/{repo}/contents/{path}?ref={branch} --jq '.content' | base64 -d
-```
-
-### GitLab / GitLab Self-Managed
-
-```text
-# URL-encode the file path (/ becomes %2F)
-GET https://gitlab.com/api/v4/projects/{project-id}/repository/files/{url-encoded-path}/raw?ref={branch}
-PRIVATE-TOKEN: <PAT>
-
-# Or use project path instead of ID:
-GET https://gitlab.com/api/v4/projects/{url-encoded-namespace%2Fproject}/repository/files/{url-encoded-path}/raw?ref={branch}
-```
-
-### Azure DevOps
-
-```text
-GET https://dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/items?path={path}&api-version=7.0
-Authorization: Basic {base64(:PAT)}
-```
-
-### Bitbucket Cloud
-
-```text
-GET https://api.bitbucket.org/2.0/repositories/{workspace}/{repo}/src/{commit-or-branch}/{path}
-Authorization: Bearer <app-password-or-token>
-```
-- Note: Self-hosted products often customize auth policy, token names, and minimum scopes.
-
-## Safe Credential Delivery Patterns
-
-| Method | Command | Safety |
-|---|---|---|
-| Platform CLI | `gh auth login` / `glab auth login` | Best — handles credential storage |
-| Git Credential Manager | `git credential-manager configure` | Good — OS keychain storage |
-| Environment variable | `GH_TOKEN=xxx gh repo clone ...` | OK — ephemeral; safer than URL tokens but visible to same-user processes |
-| Git askpass | `GIT_ASKPASS=script git clone ...` | OK — no shell history exposure |
-| Inline in URL | `git clone https://token@host/...` | FORBIDDEN — leaks in history/logs |
-
-## Operational Notes
-
-- Prefer SSH when the user already has working keys and the host advertises a stable SSH remote format.
-- Prefer platform CLI login for GitHub and GitLab because it also wires Git credential storage.
-- Prefer Git Credential Manager for Azure DevOps and other HTTPS-heavy enterprise setups.
-- When recommending PAT creation, always suggest setting a short expiry (7-30 days for task-specific work). Prefer fine-grained or short-lived tokens.
-- Never recommend pasting tokens inline into clone URLs, scripts checked into the repo, or long-lived shell profiles.

package/scaffold/_preview/skills/requirements-clarity/SKILL.md

@@ -1,333 +0,0 @@
----
-name: requirements-clarity
-description: Clarify ambiguous requirements through focused dialogue before implementation. Use when requirements are unclear, features are complex (>2 days), or involve cross-team coordination. Ask two core questions - Why? (YAGNI check) and Simpler? (KISS check) - to ensure clarity before coding.
-metadata:
-  category: cross-cutting
-  domain: general
-  applicability: on-demand
-  inputs: [requirements]
-  outputs: [scored-requirements, clarifications]
-  relatedSkills: [brainstorming]
----
-
-# Requirements Clarity Skill
-
-## Description
-
-Automatically transforms vague requirements into actionable PRDs through systematic clarification with a 100-point scoring system.
-
-
-## Instructions
-
-When invoked, detect vague requirements:
-
-1. **Vague Feature Requests**
-   - User says: "add login feature", "implement payment", "create dashboard"
-   - Missing: How, with what technology, what constraints?
-
-2. **Missing Technical Context**
-   - No technology stack mentioned
-   - No integration points identified
-   - No performance/security constraints
-
-3. **Incomplete Specifications**
-   - No acceptance criteria
-   - No success metrics
-   - No edge cases considered
-   - No error handling mentioned
-
-4. **Ambiguous Scope**
-   - Unclear boundaries ("user management" - what exactly?)
-   - No distinction between MVP and future enhancements
-   - Missing "what's NOT included"
-
-**Do NOT activate when**:
-- Specific file paths mentioned (e.g., "auth.go:45")
-- Code snippets included
-- Existing functions/classes referenced
-- Bug fixes with clear reproduction steps
-
-## Core Principles
-
-1. **Systematic Questioning**
-   - Ask focused, specific questions
-   - One category at a time (2-3 questions per round)
-   - Build on previous answers
-   - Avoid overwhelming users
-
-2. **Quality-Driven Iteration**
-   - Continuously assess clarity score (0-100)
-   - Identify gaps systematically
-   - Iterate until ≥ 90 points
-   - Document all clarification rounds
-
-3. **Actionable Output**
-   - Generate concrete specifications
-   - Include measurable acceptance criteria
-   - Provide executable phases
-   - Enable direct implementation
-
-## Clarification Process
-
-### Step 1: Initial Requirement Analysis
-
-**Input**: User's requirement description
-
-**Tasks**:
-1. Parse and understand core requirement
-2. Generate feature name (kebab-case format)
-3. Determine document version (default `1.0` unless user specifies otherwise)
-4. Ensure `.spec/{feature_name}/` exists for PRD output
-5. Perform initial clarity assessment (0-100)
-
-**Assessment Rubric**:
-```
-Functional Clarity: /30 points
-- Clear inputs/outputs: 10 pts
-- User interaction defined: 10 pts
-- Success criteria stated: 10 pts
-
-Technical Specificity: /25 points
-- Technology stack mentioned: 8 pts
-- Integration points identified: 8 pts
-- Constraints specified: 9 pts
-
-
-If you present this rubric or a requirements scorecard to the user, use `present({ format: 'html' })` to display a rich dashboard when visual formatting would help.
-Implementation Completeness: /25 points
-- Edge cases considered: 8 pts
-- Error handling mentioned: 9 pts
-- Data validation specified: 8 pts
-
-Business Context: /20 points
-- Problem statement clear: 7 pts
-- Target users identified: 7 pts
-- Success metrics defined: 6 pts
-```
-
-**Initial Response Format**:
-```markdown
-I understand your requirement. Let me help you refine this specification.
-
-**Current Clarity Score**: X/100
-
-**Clear Aspects**:
-- [List what's clear]
-
-**Needs Clarification**:
-- [List gaps]
-
-Let me systematically clarify these points...
-```
-
-### Step 2: Gap Analysis
-
-Identify missing information across four dimensions:
-
-**1. Functional Scope**
-- What is the core functionality?
-- What are the boundaries?
-- What is out of scope?
-- What are edge cases?
-
-**2. User Interaction**
-- How do users interact?
-- What are the inputs?
-- What are the outputs?
-- What are success/failure scenarios?
-
-**3. Technical Constraints**
-- Performance requirements?
-- Compatibility requirements?
-- Security considerations?
-- Scalability needs?
-
-**4. Business Value**
-- What problem does this solve?
-- Who are the target users?
-- What are success metrics?
-- What is the priority?
-
-### Step 3: Interactive Clarification
-
-**Question Strategy**:
-1. Start with highest-impact gaps
-2. Ask 2-3 questions per round
-3. Build context progressively
-4. Use user's language
-5. Provide examples when helpful
-
-**Question Format**:
-```markdown
-I need to clarify the following points to complete the requirements document:
-
-1. **[Category]**: [Specific question]?
-   - For example: [Example if helpful]
-
-2. **[Category]**: [Specific question]?
-
-3. **[Category]**: [Specific question]?
-
-Please provide your answers, and I'll continue refining the PRD.
-```
-
-**After Each User Response**:
-1. Update clarity score
-2. Capture new information in the working PRD outline
-3. Identify remaining gaps
-4. If score < 90: Continue with next round of questions
-5. If score ≥ 90: Proceed to PRD generation
-
-**Score Update Format**:
-```markdown
-Thank you for the additional information!
-
-**Clarity Score Update**: X/100 → Y/100
-
-**New Clarified Content**:
-- [Summarize new information]
-
-**Remaining Points to Clarify**:
-- [List remaining gaps if score < 90]
-
-[If score < 90: Continue with next round of questions]
-[If score ≥ 90: "Perfect! I will now generate the complete PRD document..."]
-```
-
-### Step 4: PRD Generation
-
-Once clarity score ≥ 90, generate comprehensive PRD.
-
-**Output File**:
-
-1. **Final PRD**: `.spec/{feature_name}/requirements.md`
-
-Use `create_file` to save this file. Derive `{version}` from the document version recorded in the PRD (default `1.0`).
-
-## PRD Document Structure
-
-```markdown
-# {Feature Name} - Product Requirements Document (PRD)
-
-## Requirements Description
-
-### Background
-- **Business Problem**: [Describe the business problem to solve]
-- **Target Users**: [Target user groups]
-- **Value Proposition**: [Value this feature brings]
-
-### Feature Overview
-- **Core Features**: [List of main features]
-- **Feature Boundaries**: [What is and isn't included]
-- **User Scenarios**: [Typical usage scenarios]
-
-### Detailed Requirements
-- **Input/Output**: [Specific input/output specifications]
-- **User Interaction**: [User operation flow]
-- **Data Requirements**: [Data structures and validation rules]
-- **Edge Cases**: [Edge case handling]
-
-## Design Decisions
-
-### Technical Approach
-- **Architecture Choice**: [Technical architecture decisions and rationale]
-- **Key Components**: [List of main technical components]
-- **Data Storage**: [Data models and storage solutions]
-- **Interface Design**: [API/interface specifications]
-
-### Constraints
-- **Performance Requirements**: [Response time, throughput, etc.]
-- **Compatibility**: [System compatibility requirements]
-- **Security**: [Security considerations]
-- **Scalability**: [Future expansion considerations]
-
-### Risk Assessment
-- **Technical Risks**: [Potential technical risks and mitigation plans]
-- **Dependency Risks**: [External dependencies and alternatives]
-- **Schedule Risks**: [Timeline risks and response strategies]
-
-## Acceptance Criteria
-
-### Functional Acceptance
-- [ ] Feature 1: [Specific acceptance conditions]
-- [ ] Feature 2: [Specific acceptance conditions]
-- [ ] Feature 3: [Specific acceptance conditions]
-
-### Quality Standards
-- [ ] Code Quality: [Code standards and review requirements]
-- [ ] Test Coverage: [Testing requirements and coverage]
-- [ ] Performance Metrics: [Performance test pass criteria]
-- [ ] Security Review: [Security review requirements]
-
-### User Acceptance
-- [ ] User Experience: [UX acceptance criteria]
-- [ ] Documentation: [Documentation delivery requirements]
-- [ ] Training Materials: [If needed, training material requirements]
-
-## Execution Phases
-
-### Phase 1: Preparation
-**Goal**: Environment preparation and technical validation
-- [ ] Task 1: [Specific task description]
-- [ ] Task 2: [Specific task description]
-- **Deliverables**: [Phase deliverables]
-- **Time**: [Estimated time]
-
-### Phase 2: Core Development
-**Goal**: Implement core functionality
-- [ ] Task 1: [Specific task description]
-- [ ] Task 2: [Specific task description]
-- **Deliverables**: [Phase deliverables]
-- **Time**: [Estimated time]
-
-### Phase 3: Integration & Testing
-**Goal**: Integration and quality assurance
-- [ ] Task 1: [Specific task description]
-- [ ] Task 2: [Specific task description]
-- **Deliverables**: [Phase deliverables]
-- **Time**: [Estimated time]
-
-### Phase 4: Deployment
-**Goal**: Release and monitoring
-- [ ] Task 1: [Specific task description]
-- [ ] Task 2: [Specific task description]
-- **Deliverables**: [Phase deliverables]
-- **Time**: [Estimated time]
-
----
-
-**Document Version**: 1.0
-**Created**: {timestamp}
-**Clarification Rounds**: {clarification_rounds}
-**Quality Score**: {quality_score}/100
-```
-
-## Behavioral Guidelines
-
-### DO
-- Ask specific, targeted questions
-- Build on previous answers
-- Provide examples to guide users
-- Maintain conversational tone
-- Summarize clarification rounds within the PRD
-- Use clear, professional English
-- Generate concrete specifications
-- Stay in clarification mode until score ≥ 90
-
-### DON'T
-- Ask all questions at once
-- Make assumptions without confirmation
-- Generate PRD before 90+ score
-- Skip any required sections
-- Use vague or abstract language
-- Proceed without user responses
-- Exit skill mode prematurely
-
-## Success Criteria
-
-- Clarity score ≥ 90/100
-- All PRD sections complete with substance
-- Acceptance criteria checklistable (using `- [ ]` format)
-- Execution phases actionable with concrete tasks
-- User approves final PRD
-- Ready for development handoff

package/scaffold/_preview/skills/session-handoff/SKILL.md

@@ -1,199 +0,0 @@
----
-name: session-handoff
-description: "Creates comprehensive handoff documents for seamless AI agent session transfers. Triggered when: (1) user requests handoff/memory/context save, (2) context window approaches capacity, (3) major task milestone completed, (4) work session ending, (5) user says 'save state', 'create handoff', 'I need to pause', 'context is getting full', (6) resuming work with 'load handoff', 'resume from', 'continue where we left off'. Proactively suggests handoffs after substantial work (multiple file edits, complex debugging, architecture decisions). Solves long-running agent context exhaustion by enabling fresh agents to continue with zero ambiguity."
-metadata:
-  category: cross-cutting
-  domain: general
-  applicability: always
-  inputs: [session-state, decisions]
-  outputs: [handoff-document]
-  requires: [aikit]
-  relatedSkills: [lesson-learned]
----
-
-# Handoff
-
-Creates comprehensive handoff documents that enable fresh AI agents to seamlessly continue work with zero ambiguity. Solves the long-running agent context exhaustion problem.
-
-## Mode Selection
-
-Determine which mode applies:
-
-**Creating a handoff?** User wants to save current state, pause work, or context is getting full.
-- Follow: CREATE Workflow below
-
-**Resuming from a handoff?** User wants to continue previous work, load context, or mentions an existing handoff.
-- Follow: RESUME Workflow below
-
-**Proactive suggestion?** After substantial work (5+ file edits, complex debugging, major decisions), suggest:
-> "We've made significant progress. Consider creating a handoff document to preserve this context for future sessions. Say 'create handoff' when ready."
-
-> **aikit Integration:** If the project uses the aikit MCP server, complement file-based handoffs with `remember({ title: "Session checkpoint: ...", content: "...", category: "conventions" })` to persist key decisions in the knowledge base. Use `search({ query: "SESSION CHECKPOINT" })` at session start to retrieve past checkpoints.
-
-## CREATE Workflow
-
-### Step 1: Generate Scaffold
-
-Run the smart scaffold script to create a pre-filled handoff document:
-
-```bash
-node scripts/create_handoff.js [task-slug]
-```
-
-Example: `node scripts/create_handoff.js implementing-user-auth`
-
-**For continuation handoffs** (linking to previous work):
-```bash
-node scripts/create_handoff.js "auth-part-2" --continues-from 2024-01-15-auth.md
-```
-
-The script will:
-- Create `.handoffs/` directory if needed
-- Generate timestamped filename
-- Pre-fill: timestamp, project path, git branch, recent commits, modified files
-- Add handoff chain links if continuing from previous
-- Output file path for editing
-
-### Step 2: Complete the Handoff Document
-
-Open the generated file and fill in all `[TODO: ...]` sections. Prioritize these sections:
-
-1. **Current State Summary** - What's happening right now
-2. **Important Context** - Critical info the next agent MUST know
-3. **Immediate Next Steps** - Clear, actionable first steps
-4. **Decisions Made** - Choices with rationale (not just outcomes)
-
-Use the template structure in [references/handoff-template.md](references/handoff-template.md) for guidance.
-
-### Step 3: Validate the Handoff
-
-Run the validation script to check completeness and security:
-
-```bash
-node scripts/validate_handoff.js <handoff-file>
-```
-
-The validator checks:
-- [ ] No `[TODO: ...]` placeholders remaining
-- [ ] Required sections present and populated
-- [ ] No potential secrets detected (API keys, passwords, tokens)
-- [ ] Referenced files exist
-- [ ] Quality score (0-100)
-
-**Do not finalize a handoff with secrets detected or score below 70.**
-
-### Step 4: Confirm Handoff
-
-Report to user:
-- Handoff file location
-- Validation score and any warnings
-- Summary of captured context
-- First action item for next session
-
-## RESUME Workflow
-
-### Step 1: Find Available Handoffs
-
-List handoffs in the current project:
-
-```bash
-node scripts/list_handoffs.js
-```
-
-This shows all handoffs with dates, titles, and completion status.
-
-### Step 2: Check Staleness
-
-Before loading, check how current the handoff is:
-
-```bash
-node scripts/check_staleness.js <handoff-file>
-```
-
-Staleness levels:
-- **FRESH**: Safe to resume - minimal changes since handoff
-- **SLIGHTLY_STALE**: Review changes, then resume
-- **STALE**: Verify context carefully before resuming
-- **VERY_STALE**: Consider creating a fresh handoff
-
-The script checks:
-- Time since handoff was created
-- Git commits since handoff
-- Files changed since handoff
-- Branch divergence
-- Missing referenced files
-
-### Step 3: Load the Handoff
-
-Read the relevant handoff document completely before taking any action.
-
-If handoff is part of a chain (has "Continues from" link), also read the linked previous handoff for full context.
-
-### Step 4: Verify Context
-
-Follow the checklist in [references/resume-checklist.md](references/resume-checklist.md):
-
-1. Verify project directory and git branch match
-2. Check if blockers have been resolved
-3. Validate assumptions still hold
-4. Review modified files for conflicts
-5. Check environment state
-
-### Step 5: Begin Work
-
-Start with "Immediate Next Steps" item #1 from the handoff document.
-
-Reference these sections as you work:
-- "Critical Files" for important locations
-- "Key Patterns Discovered" for conventions to follow
-- "Potential Gotchas" to avoid known issues
-
-### Step 6: Update or Chain Handoffs
-
-As you work:
-- Mark completed items in "Pending Work"
-- Add new discoveries to relevant sections
-- For long sessions: create a new handoff with `--continues-from` to chain them
-
-## Handoff Chaining
-
-For long-running projects, chain handoffs together to maintain context lineage:
-
-```
-handoff-1.md (initial work)
-    ↓
-handoff-2.md --continues-from handoff-1.md
-    ↓
-handoff-3.md --continues-from handoff-2.md
-```
-
-Each handoff in the chain:
-- Links to its predecessor
-- Can mark older handoffs as superseded
-- Provides context breadcrumbs for new agents
-
-When resuming from a chain, read the most recent handoff first, then reference predecessors as needed.
-
-## Storage Location
-
-Handoffs are stored in: `.handoffs/`
-
-Naming convention: `YYYY-MM-DD-HHMMSS-[slug].md`
-
-Example: `2024-01-15-143022-implementing-auth.md`
-
-## Resources
-
-### scripts/
-
-| Script | Purpose |
-|--------|---------|
-| `create_handoff.js [slug] [--continues-from <file>]` | Generate new handoff with smart scaffolding |
-| `list_handoffs.js [path]` | List available handoffs in a project |
-| `validate_handoff.js <file>` | Check completeness, quality, and security |
-| `check_staleness.js <file>` | Assess if handoff context is still current |
-
-### references/
-
-- [handoff-template.md](references/handoff-template.md) - Complete template structure with guidance
-- [resume-checklist.md](references/resume-checklist.md) - Verification checklist for resuming agents