progress
Internal skill for progress journal management. Other skills append to docs/arc/progress.md for cross-session context. Not invoked directly by users.
Best use case
progress is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Internal skill for progress journal management. Other skills append to docs/arc/progress.md for cross-session context. Not invoked directly by users.
Teams using progress should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/progress/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How progress Compares
| Feature / Agent | progress | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Internal skill for progress journal management. Other skills append to docs/arc/progress.md for cross-session context. Not invoked directly by users.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Progress Journal Internal patterns for maintaining cross-session context via `docs/arc/progress.md`. ## Journal Format **Location:** `docs/arc/progress.md` ```markdown # Progress Journal ## YYYY-MM-DD HH:MM — /arc:[command] **Task:** [Brief description] **Outcome:** [Complete / In Progress / Blocked] **Files:** [Key files created/modified] **Decisions:** - [Key decision 1] - [Key decision 2] **Next:** [What comes next, if any] --- ``` ## Appending Entries **All Arc skills should append to the progress journal on completion.** Use this pattern at the end of any skill: ```markdown <progress_append> After completing the skill's main work, append to the progress journal: **Entry format:** ## YYYY-MM-DD HH:MM — /arc:[skill-name] **Task:** [What was requested] **Outcome:** [Complete / In Progress / Blocked] **Files:** [Key files, comma-separated] **Decisions:** - [Decision 1] **Next:** [Suggested next step] --- </progress_append> ``` ## Reading Progress (For Context) **Skills that benefit from progress context should read recent entries first.** ```markdown <progress_context> **Use Read tool:** `docs/arc/progress.md` (first 50 lines) Look for: - Recent work on related features - Decisions that affect current work - In-progress items that might be continued </progress_context> ``` ## What Gets Logged | Skill | What to Log | |-------|-------------| | `/arc:ideate` | Feature designed, key decisions, approach chosen | | `/arc:implement` | Tasks completed, tasks remaining, blockers | | `/arc:testing` | Test results, coverage changes | | `/arc:review` | Plan reviewed, changes made | | `/arc:audit` | Audit completed, issue counts by severity | | `/arc:design` | UI designed, aesthetic direction | | `/arc:letsgo` | Deployment status, checklist progress | | `/arc:document` | Solution documented, category | | `/arc:commit` | What was committed, branch | ## What Doesn't Get Logged - `/arc:suggest` (read-only) - Linear issues (external system) - Failed/abandoned attempts (unless valuable context)
Related Skills
vision
Create or review a high-level vision document capturing project goals and purpose. Use when asked to "define the vision", "what is this project", "set goals", or when starting a new project that needs clarity on purpose and direction.
using-arc
Use when starting any conversation - establishes Arc's skill routing, instruction priority, and bootstrap rules
tidy
Clean up completed plans in docs/arc/plans/. Archives or deletes finished plans. Use when asked to "clean up plans", "tidy the docs", "archive old plans", or after completing implementation to remove stale planning documents.
testing
Comprehensive testing strategy. Creates test plans covering unit, integration, and E2E. Uses specialist agents for each test type. Supports vitest and Playwright with auth testing guidance for Clerk and WorkOS.
suggest
Opinionated recommendations for what to work on next based on Linear issues, tasks, and codebase. Use when asked "what should I work on", "what's next", "suggest priorities", or when starting a session and unsure where to begin.
seo
Deep SEO audit for web projects. Analyzes codebase for crawlability, indexability, on-page SEO, structured data, social previews, and technical foundations. Optionally runs Lighthouse and PageSpeed against a live URL. Reports findings with severity, offers direct fixes or /arc:detail plans. Use when asked to "audit SEO", "check SEO", "review SEO", or "is my site SEO-ready".
responsive
Audit and fix responsive/mobile issues across every page of a project, using browser screenshots at two breakpoints (375px mobile, 1440px desktop). Design-aware: reads existing design docs to preserve aesthetic intent, not just "make it fit." Use when asked to "make it responsive", "fix mobile", "responsive audit", or after building a desktop-first UI that needs mobile adaptation.
refactor
Discover architectural friction and propose structural refactors with competing interface designs. Focuses on deepening shallow modules, consolidating coupled code, and improving testability. Use when asked to "improve the architecture", "find refactoring opportunities", "deepen modules", "consolidate coupling", "make this more testable", or "find architectural friction".
prune-agents
Kill orphaned Claude subagent processes that didn't exit cleanly. Use when asked to "prune agents", "clean up agents", "kill orphaned processes", or when subagents accumulate from Task tool usage.
naming
Generate and validate project names. Reads codebase context, produces candidates using tech naming strategies, and checks domain + GitHub availability. Use when naming a new project, renaming, or validating an existing name.
letsgo
Production readiness checklist covering domains, SEO, security, and deployment. Use when asked to "ship it", "deploy to production", "go live", "launch", or when preparing a project for production deployment.
implement
Scope-aware implementation workflow with TDD and continuous quality checks. Use when asked to "implement this", "build this feature", "execute the plan", or after /arc:ideate has created a design doc. For small work it creates a lightweight inline plan; for larger work it creates or loads a full implementation plan and executes task-by-task with build agents.