How to instantiate a Punch website project in Asana

The two templates

Pick one. They're not designed to be used together — the detailed reference is for understanding the full process; the starter is for instantiating.

Task granularity — the "one chunk, one task" principle

Both templates follow the same granularity rule, so PMs (and anyone reading the project) can hold the shape of the engagement in their head without drowning in task volume.

What counts as a task: a contiguous block of work, owned by one person (or one tight pair), that produces a single coherent deliverable.

What does NOT get its own task: individual skill invocations within that work block. If the lead designer is running punch-project-init, then punch-token-export, then punch-component-export, then punch-rebind all in one sitting to set up the canonical fork, that's one task called "Set up canonical client fork," not four.

What stays separate even when sequential:

• Different people doing related work (writer's copy draft → designer's composition is two tasks, not one)
• Gates — they're checkpoints/meetings, not work tasks
• Pulse-check cycles — PM coordination work distinct from the gate itself
• Locks and sign-offs — single decisive actions that mark phase transitions
• Anything where dependency tracking actually matters — if you'd want to know whether the inner step is blocked, it's its own task

This is why the detailed reference is 45 tasks, not 100+. Atomizing per skill creates a task list nobody reads. Chunking by work block creates a task list that maps to how the team actually works.

How to use either template in Asana

1. Create a new Asana project for the client. Use the agency's standard project naming convention (e.g., "[Client] Website 2026").
2. Import the CSV. Asana → Project Settings → Import → CSV. Map the columns: Name → Task Name, Section → Section, Assignee → Assignee, Day Offset → Start Date (computed from kickoff), Dependencies → Dependencies, Notes → Description.
3. Set the kickoff date. The Day Offset column assumes T+0 = kickoff. Compute actual dates by adding the offset to your kickoff date.
4. Replace role brackets with real assignees. The CSV uses placeholders like [PM], [STRATEGIST], [LEAD CLIENT DESIGNER]. Find/replace with the actual people on this engagement.
5. Add per-project subtasks. If using the starter, expect to add 2–5 subtasks under each top-level task to capture client-specific work. The starter is the trunk; subtasks are the branches.
6. Verify gate dependencies hold. Each gate task depends on the work that precedes it. Don't move gates earlier than their dependencies allow.

The phase shape

Role bracket conventions

Both CSVs use bracketed placeholders for assignees so they work as templates. Replace with real names on instantiation. Conventions used:

Cowork-auto vs. human-owner distinction

Not every task needs a human owner from start to finish. Some tasks are Cowork-driven — a person triggers them, but Cowork does the work and produces an artifact. Others are human-owned — judgment, review, client interaction.

Rule of thumb when assigning:

The nine gates

The engagement is structured around nine gates — explicit checkpoints where work locks before the next phase begins — plus an informal post-launch retrospective within two weeks of launch.

What the task list captures

• Phase 4 added as a real, scheduled phase. Retrospective + candidate skill updates queue + terminology drift checks.
• punch-term-drift added at G6 (pre-launch) and Phase 4 (post-launch) as a safety net for catching stale terminology that drifted into the project during the engagement.
• punch-retrospective added as the formal mechanism for closing the learning loop.
• punch-page-content (deprecated) replaced with punch-web-copywriter where it appeared.
• punch-production-artist-qa added as a discrete per-batch task — previously implied, now explicit.
• Newspaper-greyscale wireframe baked in — the wireframe-config decision now covers three questions (bio treatment, FAQ pattern, logo / proof). Color mode is no longer asked.
• Nine gates, in order — G1 brief+sitemap, G2 theme pick (visual), G3 homepage, G4 wireframe sign-off, G5 per-batch QA, G6 client sign-off on The Build (static; unblocks migration), G7 pre-launch QA on the migrated site, G8 launch, G9 48-hour verify. Two QA passes: one on the static build before G6, one on the migrated site at G7.
• Notes column carries the skill detail — PMs can see which skill(s) produce each artifact without needing a separate task per skill. Makes debugging stalled tasks easier without inflating task count.
• Two scaffolds, one source of truth: the full task list (punch-website-asana-template.csv, 48 tasks, chunked by work block) is the reference; the starter (18 tasks, phase-level milestones) is what you import and expand. Both follow the same 9-gate sequence.

Where to go next

The two CSV templates and this guide are in the same folder:

For the rest of the process documentation: