Inline links in post body instead of separate link button

.claude/guides/README.md

@@ -0,0 +1,7 @@
+# Guides
+
+Brief "How To" guides that explain both _what_ and _why_ for each topic. Aimed at students and anyone picking up this template for the first time. Each guide is ~100 lines — enough to understand the concept and get productive, not a reference manual.
+
+| Guide                                              | What it covers                                                                    |
+| -------------------------------------------------- | --------------------------------------------------------------------------------- |
+| [AI-Assisted Workflow](ai-assisted-workflow.md)     | Using Claude Code skills to plan iterations, create issues, branch, commit, and PR |

.claude/guides/ai-assisted-workflow.md

@@ -0,0 +1,69 @@
+# AI-Assisted Workflow Guide
+
+This guide walks you through using Claude Code and the skills in this repo to follow the team development workflow. Each section matches a phase of your iteration cycle.
+
+## Prerequisites
+
+- GitHub CLI authenticated: `gh auth login`
+- Claude Code installed and working
+- `docs/team-agreement.md` and `docs/product-requirements.md` are updated and committed to the repo
+
+## Step 1: Create GitHub Issues
+
+Ask Claude to turn the plan into issues:
+
+```plaintext
+> Read the iteration 1 plan and create GitHub issues for each requirement
+  and task. The team members are listed in docs/team-agreement.md.
+  Use the "Iteration 1" milestone.
+```
+
+Check GitHub to verify: correct labels, milestone, assignees, and acceptance criteria on each issue.
+
+## Step 2: Work on an Issue (Branch, Commit, PR)
+
+> **Note:** Before you can work on actual features, you need to scaffold your tech stack and update `README.md` and `CLAUDE.md` with your project's setup, commands, and architecture. Without this, Claude won't know how to generate code that fits your project.
+
+**Branch:** Pick an issue and create a branch:
+
+```plaintext
+> Create a branch for issue #3 (task: setup CI pipeline). I am <username>.
+```
+
+Claude creates a branch following the naming convention: `<username>/task/issue-3-setup-ci-pipeline`
+
+**Commit:** After making changes, commit with the issue reference:
+
+```plaintext
+> Commit my changes
+```
+
+**PR:** Push and open a pull request:
+
+```plaintext
+> /pr-workflow 3
+```
+
+Claude verifies the branch name, checks diff size, pushes, and creates a PR with `Closes #3` and the PR template filled in.
+
+## Step 3: Retrospective
+
+At the end of an iteration, create the retrospective issue:
+
+```plaintext
+> /retrospective 1
+```
+
+Claude creates a GitHub issue with the right labels (`task` + `retrospective`), milestone, and all team members assigned. The three sections (what went well, what didn't, lessons learned) are for the team to fill in — be specific and actionable.
+
+## What to Verify on GitHub
+
+After completing these steps, your repo should show:
+
+- **Milestone view** — all iteration issues in one place with open/closed status
+- **Issue list** — features and tasks with correct labels and assignees
+- **PR list** — PRs linked to issues with review status
+- **Commit history** — every commit references an issue number
+- **Branch list** — branches follow the naming convention
+
+The analytics scripts parse labels, branch names, and PR metadata. If conventions are not followed, your work won't be attributed to you.

.claude/rules/branch-naming.md

@@ -0,0 +1,20 @@
+# Branch Naming Convention
+
+When creating branches, ALWAYS follow this pattern:
+
+`<author>/<type>/issue-<number>-<short-description>`
+
+Where:
+
+- `author` is the GitHub username of the branch creator
+- `type` matches the issue label: `enhancement`, `bug`, or `task`
+- `number` is the GitHub issue number
+- `short-description` is 2-4 lowercase words separated by hyphens
+
+Examples:
+
+- `asmith/enhancement/issue-5-user-authentication`
+- `jdoe/bug/issue-12-fix-login-redirect`
+- `mchen/task/issue-3-setup-ci-pipeline`
+
+Never push directly to master. Always create a branch and open a PR.

.claude/rules/commit-conventions.md

@@ -0,0 +1,18 @@
+# Commit Conventions
+
+When creating commits:
+
+1. Reference the issue number in the commit message: `Add file validation (#12)`
+2. Use imperative mood in the subject line: "Add feature" not "Added feature"
+3. Keep the subject line under 72 characters
+
+Examples:
+
+- `Add login form component (#5)`
+- `Fix redirect loop on logout (#12)`
+- `Set up CI pipeline (#6)`
+
+Do not co-sign the commit! For example, do not end the commit with something like this:
+
+Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
+

.claude/rules/pr-conventions.md

@@ -0,0 +1,6 @@
+# Pull Request Conventions
+
+- Include `Closes #<number>` or `Fixes #<number>` in every PR body
+- Keep PRs under ~400 changed lines
+- Use merge commits only — never squash or rebase
+- See the `pr-workflow` skill for full details and the collaborative feature branch flow

.claude/skills/github-issues/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: github-issues
+description: Create and manage GitHub issues following project conventions. Use when creating issues, managing issue labels, assigning issues, setting up milestones, or asking about issue conventions and requirements.
+argument-hint: "issue title or number"
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - "Bash(gh issue *)"
+  - "Bash(gh api *)"
+  - "Bash(gh label *)"
+---
+
+# GitHub Issues Skill
+
+## Related Skills
+
+- `iteration-planning` — creates issues from the task breakdown
+- `pr-workflow` — PRs reference issues via `Closes #<number>`
+
+## Creating Issues
+
+Every issue must have:
+
+1. **Descriptive title** — clear and concise
+2. **Description** — what needs to be done and why
+3. **Acceptance criteria** — checklist of testable criteria
+4. **Label** — exactly one of: `enhancement`, `task`, or `bug`
+5. **Milestone** — the current iteration (e.g., "Iteration 1")
+6. **Assignees** — see ownership rules below
+
+## Labels
+
+The project uses these labels:
+
+- `enhancement` — new feature or request
+- `task` — development work that isn't a feature or bug
+- `bug` — something isn't working
+- `documentation` — improvements or additions to documentation
+- `retrospective` — added alongside `task` for retrospective issues
+
+If labels don't exist yet, create them:
+
+```bash
+gh label create enhancement --description "New feature or request" --color A2EEEF
+gh label create task --description "Development task" --color 1D76DB
+gh label create bug --description "Something isn't working" --color D73A4A
+gh label create retrospective --description "Iteration retrospective" --color FBCA04
+```
+
+## Milestones
+
+Milestones are named "Iteration 1" through "Iteration 4". Create them if they don't exist:
+
+```bash
+gh api repos/{owner}/{repo}/milestones -f title="Iteration 1"
+```
+
+## Issue Ownership
+
+- **Feature issues** — assign one owner + one supporting (up to three if the feature is large)
+- **Task and bug issues** — assign one person (optional supporting)
+- **Retrospective issues** — assign all team members
+
+If you contribute to an issue but aren't assigned, analytics won't attribute the work to you.
+
+## Creating Issues via CLI
+
+Read the matching template in `.github/ISSUE_TEMPLATE/` (feature.yml, task.yml, or bug.yml) and use its structure for the `--body`. Example:
+
+```bash
+gh issue create \
+  --title "Add search-by-title to items list endpoint" \
+  --label "enhancement" \
+  --milestone "Iteration 1" \
+  --assignee "owner,supporting" \
+  --body "## Description
+Add a query parameter to the items endpoint that filters by title.
+
+## Acceptance Criteria
+- [ ] Search is case-insensitive
+- [ ] Empty query returns all items
+- [ ] Tests added for all cases"
+```
+
+For task and bug issues, follow the same pattern using the corresponding template structure.
+
+## Rules
+
+- Only create issues for the **current** iteration — never for future ones
+- Use the GitHub issue templates (feature, task, or bug) when creating from the UI

.claude/skills/iteration-planning/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: iteration-planning
+description: Create and manage iteration plans. Use when starting a new iteration, writing an iteration plan, breaking down requirements into tasks, planning sprint work, or asking about iteration plan format and structure.
+argument-hint: "iteration number"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Grep
+  - Glob
+  - "Bash(gh issue *)"
+  - "Bash(gh api *)"
+---
+
+# Iteration Planning Skill
+
+## Related Skills
+
+- `github-issues` — create the issues from the task breakdown
+- `retrospective` — close out the iteration after work is done
+
+## Process
+
+1. Read the template at `docs/iteration-plan-template.md`
+2. Ask the user for the iteration number and requirements (or read from a PRD if available)
+3. **Draft** `docs/iteration-<number>-plan.md` with the 3 required sections:
+   - **Requirements & Acceptance Criteria** — each requirement gets a title, description, and testable acceptance criteria checklist
+   - **Coordination & Design Decisions** — architecture choices, API contracts, shared interfaces, responsibilities, dependencies
+   - **Task Breakdown** — table of tasks with type, assignee(s), and issue number
+4. **Ask the user to review the draft** — the team owns the final plan, not the AI. In particular:
+   - Are the acceptance criteria complete? Any edge cases missing?
+   - Do the coordination decisions (API contracts, schemas, shared interfaces) match what the team agreed on?
+   - Is the task breakdown realistic? Are assignments correct?
+5. Incorporate feedback and finalize the plan
+
+## Timeline
+
+- **Iteration plan due:** Tuesday 6 PM of Week 1
+- **Iteration work period:** remainder of Week 1 + Week 2
+- **Retrospective due:** Monday end-of-day after the iteration ends
+
+## Guidelines
+
+- Each requirement must have clear, testable acceptance criteria
+- Break requirements into issues that can be completed by 1-2 people
+- Follow issue ownership rules from the `github-issues` skill (not a fixed number of assignees)
+- Only create issues for the current iteration — never for future iterations
+- Apply the correct label to each issue: `enhancement`, `task`, or `bug`
+- Set the milestone to the current iteration (e.g., "Iteration 1")
+
+## After Planning
+
+Offer to create the GitHub issues from the task breakdown using the `github-issues` skill conventions:
+
+- Each issue gets a descriptive title, description, and acceptance criteria
+- Apply the correct label and milestone
+- Assign the correct team members

.claude/skills/pr-workflow/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: pr-workflow
+description: Create pull requests and manage the PR workflow. Use when creating a PR, reviewing PRs, managing feature branch merges, or asking about PR conventions, code review process, or the collaborative feature branch workflow.
+argument-hint: "PR or issue number"
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - "Bash(gh pr *)"
+  - "Bash(gh api *)"
+  - "Bash(git *)"
+---
+
+# PR Workflow Skill
+
+## Related Skills
+
+- `github-issues` — PRs must reference an issue via `Closes #<number>`
+- Branch naming rules: `.claude/rules/branch-naming.md`
+
+## Before Creating a PR
+
+1. **Verify branch naming** — must match `<author>/<type>/issue-<number>-<short-description>`
+2. **Check diff size** — warn if over ~400 changed lines and suggest splitting
+3. **Ensure commits reference the issue** — e.g., `Add validation (#12)`
+4. **Push the branch** to remote if not already pushed
+
+## Creating a PR
+
+Use the PR template (`.github/PULL_REQUEST_TEMPLATE.md`):
+
+```bash
+gh pr create \
+  --title "Short descriptive title" \
+  --body "## Summary
+
+Closes #<issue-number>
+
+## Changes
+
+- Change 1
+- Change 2
+
+## How to Test
+
+1. Step 1
+2. Step 2
+
+## Checklist
+
+- [x] PR is under ~400 changed lines
+- [x] Branch follows naming convention
+- [x] Commits reference the issue number
+- [ ] Tests pass
+- [ ] At least one teammate has been requested for review" \
+  --reviewer "teammate-username"
+```
+
+## Key Rules
+
+- Always include `Closes #<number>` or `Fixes #<number>` in the PR body
+- Target the `master` branch (or parent feature branch for sub-branches)
+- Request at least one teammate as reviewer
+- Use **merge commits only** — never squash or rebase
+- Delete the branch after merging
+
+## Collaborative Feature Branch Workflow
+
+When multiple people are actively coding the **same feature** in parallel:
+
+1. Feature owner creates a feature branch from `master`
+2. Each contributor creates a sub-branch off the feature branch
+3. Contributors open PRs targeting the feature branch (not master)
+4. Feature owner reviews and merges contributor PRs
+5. Each contributor is responsible for resolving conflicts in their own PR
+6. When complete, feature owner PRs the feature branch into `master`
+
+If only one person is implementing a feature, skip this — PR directly to `master`.
+
+See [reference.md](reference.md) for the git commands.