Skip to main content
The basic project template (examples/example/) provides the starting point for all Longshot projects. It includes all required specification and operational documents with placeholders and guidance.

Template Structure

The template includes six core markdown files:
examples/example/
├── SPEC.md           # Product requirements and acceptance criteria
├── AGENTS.md         # Agent execution policies and conventions  
├── README.md         # Quick start and setup guide
├── RUNBOOK.md        # Operational procedures and recovery
├── DECISIONS.md      # Architecture decision log
├── ENTRY_POINT.md    # Document ownership matrix
└── INSTRUCTIONS.md   # Local notes (not copied to new projects)

Document Templates

SPEC.md - Project Specification

The authoritative source for product requirements, success criteria, and scope. Key Sections:
## Product Statement
2-4 sentences: what you are building, for whom, and the primary use case

## Success Criteria (Ranked)
1. Highest-priority outcome with measurable target
2. Second-priority outcome with measurable target  
3. Third-priority outcome with measurable target

### Hard Limits
- Time budget: e.g. 8 hours
- Resource budget: e.g. <= 2 CPU cores, <= 2 GB RAM
- External services: e.g. no paid APIs
- Runtime mode: e.g. must run offline

## Acceptance Tests (Runnable, Objective)
- `exact command` results in `exact expected output/behavior`
- `manual flow with clear pass condition`

## Scope Model
### Must Have (3-7)
- Capability spine items

### Nice to Have (3-7)  
- Optional enhancements

### Out of Scope
- Tempting but intentionally excluded items
Document Ownership:
  • Type: User input to swarm
  • Created by: User before run
  • Updated by: User is primary editor; agents propose edits but cannot change intent without approval

AGENTS.md - Repository Conventions

Defines how agents should execute work in the repository. Key Sections:
## Scope Discipline
- Derive tasks from SPEC.md boundaries and acceptance tests
- Prefer small, merge-safe changes

## Code Style  
- Follow existing naming and patterns
- Avoid placeholders and TODO stubs
- Keep functions small with explicit types

## Dependencies
- Allowed: list allowed runtime/test deps
- Banned: dependencies not allowed without approval

## Testing Policy
- Run targeted tests before completion
- Run all acceptance tests before handoff
- Never delete tests to hide failures

## Commit Expectations
- Focused commits mapping to acceptance tests
- Message format: e.g. feat(scope): summary
Document Ownership:
  • Type: User input to swarm
  • Created by: User before run
  • Updated by: User primarily; agents propose updates when constraints unclear

README.md - Quick Start Guide

Living documentation for setting up and running the project from a clean machine. Template Structure:
# <project-name>

## Quick Start (Clean Machine)
1. <install prerequisite 1>
2. <install prerequisite 2>  
3. <setup command>
4. <run command>

## Verify
- <acceptance command 1>
- <acceptance command 2>

## Demo Flow
1. <step 1>
2. <step 2>
3. <expected visible result>
Document Ownership:
  • Type: Agent-maintained living artifact
  • Created by: Template bootstrap before run
  • Updated by: Agent during implementation; user may edit anytime

RUNBOOK.md - Operational Guide

Procedures for running, monitoring, and recovering the system. Template Structure:
## Operating Modes
- Local dev: <command>
- Swarm run: <command>  
- Recovery run: <command>

## Monitoring
- Key logs: <path or command>
- Key metrics: <what to watch>
- Failure signals: <degradation indicators>

## Recovery Procedures
### Restart Orchestrator
1. <step>
2. <step>
3. <verification>

### Resource Ceiling Behavior  
- CPU cap response: <expected behavior>
- Memory cap response: <expected behavior>
Document Ownership:
  • Type: Agent-maintained living artifact
  • Created by: Template bootstrap
  • Updated by: Agent as procedures evolve

DECISIONS.md - Architecture Decision Log

Short-form architecture decisions with rationale. Entry Format:
### <decision-id-or-title>
- Date: YYYY-MM-DD
- Decision: <what was chosen>
- Why: <rationale>  
- Alternatives considered: <brief list>
- Status: active | replaced
Document Ownership:
  • Type: Agent-maintained living artifact
  • Created by: Template bootstrap
  • Updated by: Agent when architecture choices are made

ENTRY_POINT.md - Document Ownership Matrix

Defines who owns and updates each document. Purpose:
  • Clarify ownership boundaries
  • Set update expectations
  • Guide agents on when to propose vs. directly update

Using the Template

Step 1: Copy Template Files

# Create new project directory
mkdir -p target-repo/my-project

# Copy all template files except INSTRUCTIONS.md
cp examples/example/ENTRY_POINT.md target-repo/my-project/
cp examples/example/SPEC.md target-repo/my-project/
cp examples/example/AGENTS.md target-repo/my-project/
cp examples/example/README.md target-repo/my-project/
cp examples/example/RUNBOOK.md target-repo/my-project/
cp examples/example/DECISIONS.md target-repo/my-project/
Do NOT copy INSTRUCTIONS.md - this file is for local development notes only and should not be part of the project contract.

Step 2: Collect Project Information

Gather these inputs before filling templates: Product Basics:
  • Project name
  • 2-4 sentence high-level description
  • Target user
  • Primary workflow
Success Definition:
  • Top 3 ranked success criteria
  • Hard limits (time, cost, resources)
  • Acceptance test commands
  • Manual demo flow
Architecture:
  • Repo topology (single app, monorepo, services)
  • Required boundaries (UI/API/worker/storage)
  • Allowed dependencies
  • Banned dependencies
Scope Control:
  • Must-have capabilities (3-7)
  • Nice-to-have capabilities (3-7)
  • Explicit out-of-scope items (3+ minimum)

Step 3: Fill Templates

1

Complete SPEC.md

Fill all sections with specific requirements. Remove all placeholder text (<...>). Ensure acceptance tests are runnable commands with exact expected outputs.
2

Complete AGENTS.md

Define concrete policies for dependencies, testing, commits, and code style. No vague guidelines - make them enforceable.
3

Bootstrap README.md

Write exact setup commands that work from a clean machine. Test them yourself before running swarm.
4

Bootstrap RUNBOOK.md

Define initial operating modes and monitoring approach. Agents will expand this during execution.
5

Initialize DECISIONS.md

Add at least one initial architecture decision if you’ve made technology choices.
6

Verify ENTRY_POINT.md

Confirm the ownership matrix matches your project policy.

Step 4: Validate Completeness

Quality Gates:
# Check for remaining placeholders
rg -n "<.*>|TODO|TBD" target-repo/my-project/*.md
This should return zero results. Manual Checklist:
  • SPEC.md has concrete acceptance tests with exact commands
  • SPEC.md includes must-have, nice-to-have, and out-of-scope
  • AGENTS.md has specific allowed/banned dependency lists
  • README.md setup commands can run on a clean machine
  • RUNBOOK.md has at least basic restart procedure
  • DECISIONS.md has at least one decision (if applicable)
  • No placeholder text (<...>) remains in any file

Step 5: Launch Swarm

Once templates are complete and validated:
# Set target repository path
export TARGET_REPO_PATH=target-repo/my-project

# Run Longshot
npm start

Template Philosophy

Small Required Sections

Every template section exists for a reason:
  • Product Statement: Forces clarity on what and why
  • Success Criteria (Ranked): Prevents scope creep and enables prioritization
  • Hard Limits: Sets non-negotiable constraints
  • Acceptance Tests: Provides objective completion criteria
  • Scope Model: Explicit boundaries prevent mission drift

No Placeholders in Production

The bootstrap process requires removing ALL placeholder text before swarm execution. This ensures:
  • Agents work from concrete requirements, not assumptions
  • Users make decisions upfront instead of mid-execution
  • Quality gates are enforceable and objective

Living Documentation

Three documents evolve during execution:
  • README.md - Kept current with actual setup/run procedures
  • RUNBOOK.md - Expanded as operational needs emerge
  • DECISIONS.md - Grows as architecture choices are made
Two documents remain user-owned:
  • SPEC.md - Agents propose changes but user approves
  • AGENTS.md - Agents can request clarification but user decides policy

Example: Creating a Web Scraper Project

Initial Input

Project: web-scraper
Description: A CLI tool that scrapes product prices from e-commerce sites 
             and saves them to a SQLite database for trend analysis.

Filled SPEC.md Excerpt

## Product Statement
A command-line web scraper that monitors product prices across multiple 
e-commerce sites. Users provide URLs via a config file, the scraper runs 
on a schedule, and price history is stored in SQLite for analysis and alerts.

## Success Criteria (Ranked)  
1. Successfully scrape and store prices from 3 target sites (Amazon, eBay, 
   Walmart) with 95%+ success rate
2. Detect price changes and log alerts when drops exceed 10%
3. Complete scrape cycle for 100 products in under 5 minutes

### Hard Limits
- Time budget: 8 hours
- Resource budget: <= 1 CPU core, <= 512 MB RAM
- External services: No paid APIs (free proxy rotation acceptable)
- Runtime mode: Must run offline after initial install

## Acceptance Tests
- `npm start -- --config test-urls.json` completes with exit code 0
- `sqlite3 prices.db "SELECT COUNT(*) FROM price_history"` returns > 0  
- Manually verify: scrape Amazon product, change price in test mock, 
  re-scrape, confirm new price recorded

Filled AGENTS.md Excerpt

## Dependencies
- Allowed: `puppeteer`, `cheerio`, `better-sqlite3`, `node-cron`, `zod`
- Banned: Paid services, Playwright (Puppeteer sufficient), heavy ORMs 
  (use raw SQL with sqlite3)

## Testing Policy  
- Every scraper module has unit test with mocked HTTP responses
- Run `npm test` before every commit
- Run full acceptance test suite before handoff

Common Pitfalls

Vague Acceptance Tests❌ Bad: “The app should work correctly”✅ Good: “npm test exits with code 0 and coverage > 80%”
Unbounded ScopeAlways include Out of Scope section. This prevents feature creep:
### Out of Scope
- User authentication (single-user CLI tool)
- Real-time monitoring (scheduled runs sufficient)  
- Web dashboard (CLI output only)
Ignored Quality GatesDon’t skip the placeholder validation step. Remaining <...> tokens will confuse agents and lead to incorrect assumptions.

Next Steps

Decagon Assistant Example

See a complete real-world project using this template

Project Structure

Learn how Longshot organizes and executes projects

Bootstrap Guide

Detailed bootstrap workflow and quality gates

Swarm Execution

Understand how agents use these documents during execution

Build docs developers (and LLMs) love