agentsclimarketplace

Project files

Skill marco-souza/skills/.agents/skills/project-files

Manage structured communication files (PLAN.md, TODO.md, SPEC.md, etc.) to coordinate work across agents and sessions. Use when starting complex tasks, delegating to subagents, or maintaining project state.From its SKILL.md

Install
npx -y skills add marco-souza/skills --skill project-files

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

7.7 KB, ~2.0k tokens by cl100k_base, as published. Nobody here has run it

Project Communication Files

Standard files for coordinating work across agents and sessions. These files serve as the single source of truth for project state.

Quick-Start

The 3 core files for agent coordination:

PLAN.md β€” Strategy

# Plan: <Project>
## Goal
One-line objective.
## Strategy
High-level approach.
## Phases
### Phase 1: <Name> [IN_PROGRESS]
- Objective: What this achieves
- Success criteria: How we know it's done

TODO.md β€” Tasks

# TODO
## Current Sprint
### In Progress
- [ ] agent: Task description
### Ready
- [ ] agent: Task description
### Blocked
- [ ] agent: Task (blocked by: X)

SESSION.md β€” Handoff

# Session: YYYY-MM-DD HH:MM
## Context
What we were working on.
## Current State
- PLAN phase: X, TODO items: Y, Blockers: None
## Next Actions
1. Complete X (assigned to: agent)
2. Start Y

File Overview

FilePurposeUpdated ByRead By
PLAN.mdHigh-level strategy and approachLead agentAll agents
TODO.mdCurrent tasks and queueWorking agentsAll agents
SPEC.mdTechnical requirements and designArchitect/plannerImplementation agents
DECISIONS.mdArchitecture decisions (ADRs)Any agentAll future agents
SESSION.mdSession context and handoffCurrent sessionNext session
STATUS.mdCurrent project stateAny agentStatus checks
CHANGELOG.mdCompleted work logWorking agentsReview agents

File Formats

PLAN.md

Strategic direction. Updated when approach changes.

# Plan: <Feature/Project Name>

## Goal
One-line objective.

## Strategy
High-level approach (2-3 paragraphs).

## Phases

### Phase 1: <Name> [IN_PROGRESS]
- Objective: What this phase achieves
- Success criteria: How we know it's done

### Phase 2: <Name> [PENDING]
- Objective: ...

## Constraints
- Must use X technology
- Must maintain Y compatibility

## Risks
- Risk: Mitigation strategy

State markers: [PENDING], [IN_PROGRESS], [COMPLETED], [BLOCKED]

TODO.md

Active work queue. Updated continuously.

# TODO

## Current Sprint

### In Progress
- [ ] <agent-name>: Task description (blocked by: X, ETA: Y)

### Ready
- [ ] <agent-name>: Task description (depends on: X)
- [ ] <agent-name>: Task description

### Blocked
- [ ] <agent-name>: Task description (blocked by: X, reason: Y)

## Backlog
- [ ] Future task

## Completed (Last 5)
- [x] <agent-name>: Task description (completed: DATE)

Assignment format: <agent-name>: <task> (e.g., architect: Design auth API)

SPEC.md

Technical specification. Updated during planning.

# SPEC: <Component/Feature>

## Overview
What this component does.

## Interface

### API/Exports
```typescript
function doThing(input: Input): Output

Types

interface Input { ... }
interface Output { ... }

Behavior

  • Given X, should Y
  • Error cases: Z

Dependencies

  • Requires: module-a
  • Used by: module-b

Open Questions

  • Question to resolve

### DECISIONS.md

Architecture Decision Records. Append-only.

```markdown
# Decisions

## ADR-001: <Title>

**Date:** YYYY-MM-DD  
**Status:** Proposed | Accepted | Deprecated | Superseded by ADR-XXX

### Context
What problem were we solving?

### Decision
What did we decide?

### Consequences
Positive:
- Benefit 1

Negative:
- Trade-off 1

ADR numbering: Sequential (ADR-001, ADR-002...)

SESSION.md

Session handoff. Updated at end of session.

# Session: YYYY-MM-DD HH:MM

## Context
What we were working on and why.

## Current State
- PLAN phase: X
- TODO items in progress: Y, Z
- Blockers: None | X

## Files Modified
- `src/auth/login.ts` - Added validation
- `tests/auth.test.ts` - Added tests

## Next Actions
1. Complete X (assigned to: agent-name)
2. Start Y (ready to go)

## Notes for Next Session
- Watch out for: potential issue
- Remember to: check Z

STATUS.md

Quick status dashboard. Updated as needed.

# Status

**Last Updated:** YYYY-MM-DD HH:MM  
**Current Phase:** Implementation  
**Overall Health:** 🟒 On Track | 🟑 At Risk | πŸ”΄ Blocked

## Progress
- [x] Planning complete
- [x] Design approved
- [ ] Implementation (60%)
- [ ] Testing
- [ ] Deployment

## Blockers
None.

## Recent Changes
- Change 1
- Change 2

CHANGELOG.md

Completed work history. Append-only.

# Changelog

## [Unreleased]

### Added
- Feature X implemented by @agent-name
- API endpoint Y added

### Fixed
- Bug Z resolved

## [DATE] - Release Name

### Added
- Initial implementation

Follows Keep a Changelog format.

Workflow Integration

Starting a Complex Task

# 1. Create PLAN.md with high-level strategy
cat > PLAN.md << 'EOF'
# Plan: User Authentication

## Goal
Implement secure JWT-based authentication.

## Strategy
...
EOF

# 2. Create TODO.md with initial tasks
cat > TODO.md << 'EOF'
# TODO

## Current Sprint

### Ready
- [ ] architect: Design auth API (SPEC.md)
- [ ] security: Review threat model
EOF

# 3. Create initial SPEC.md template
cat > SPEC.md << 'EOF'
# SPEC: Authentication API

## Overview
...
EOF

Delegating to Subagents

When using spawn-subagents or mixture-of-experts:

# Read context files before spawning
PLAN=$(cat PLAN.md)
TODO=$(cat TODO.md)
SPEC=$(cat SPEC.md)

# Spawn expert with full context
tmux send-keys -t subagent-architect \
  "pi -p 'Review PLAN.md, TODO.md, and SPEC.md. Then: $TASK' ..." C-m

Session Handoff

At end of session:

# 1. Update TODO.md - mark completed, move in-progress to ready
# 2. Update SESSION.md with current state
# 3. Update CHANGELOG.md with completed work
cat >> CHANGELOG.md << 'EOF'

### Added
- Implemented user login flow (SESSION.md for details)
EOF

Mixture of Experts Coordination

Use files to share context between experts:

# Pre-populate files for experts to read
for expert in architect security performance; do
  # Each expert reads PLAN/TODO/SPEC, writes to DECISIONS
  tmux send-keys -t "moe-$expert" \
    "cat PLAN.md SPEC.md | pi -p 'Review and add decisions to DECISIONS.md' ..." C-m
done

Best Practices

DOs

  • Update TODO.md in real-time β€” Mark tasks done as you complete them
  • Write SESSION.md before quitting β€” Future you will thank you
  • Keep SPEC.md precise β€” Ambiguity causes rework
  • Date all entries β€” Context decays over time
  • Use status markers β€” [IN_PROGRESS], [BLOCKED], [DONE]

DON'Ts

  • Don't duplicate information β€” Link to files instead of copying
  • Don't leave TODO.md stale β€” If it's wrong, it's harmful
  • Don't delete from CHANGELOG β€” Append-only history
  • Don't skip DECISIONS.md β€” You'll forget why you chose X

File Lifecycle

PLAN.md      β†’ Created at project start, updated when strategy shifts
TODO.md      β†’ Created with first tasks, updated continuously
SPEC.md      β†’ Created during design phase, refined during implementation
DECISIONS.md β†’ Created on first ADR, appended forever
SESSION.md   β†’ Created at session end, archived after next session starts
STATUS.md    β†’ Created when needed, kept current
CHANGELOG.md β†’ Created at project start, appended forever

Quick Commands

# Check current status
cat STATUS.md

# See what's in progress
grep -A 5 "In Progress" TODO.md

# View recent decisions
tail -50 DECISIONS.md

# Find previous session context
cat SESSION.md

# See what changed recently
tail -30 CHANGELOG.md

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most plan spec skills give in ~2.0k tokens

Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07

  • Ask one question at a timein 51 of 1099
  • Break plans into vertical slicesin 29 of 1099, across 11 files
  • Publish issues in dependency orderin 27 of 1099, across 9 files
  • Iterate until user approves the breakdownin 25 of 1099, across 7 files
  • Explore the repository to understand the codebase statein 24 of 1099, across 7 files
  • Use domain glossary vocabularyin 23 of 1099, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1099, across 5 files
  • Prefer AFK slices over HITLin 22 of 1099, across 7 files
  • Write a specification before writing any codein 22 of 1099, across 14 files
  • Write failing tests before implementation codein 22 of 1099, across 20 files
  • Ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
  • Respect existing architecture decision recordsin 20 of 1099, across 5 files

Said here and by no other author read

  • use communication files as single source of truth
  • update TODO.md in real-time
  • write SESSION.md before quitting
  • keep SPEC.md precise
  • date all entries
  • use status markers

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,861. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.