chore: scaffold Astro project and configure agent skills

Initial commit: Astro minimal template (Node >= 22.12), agent docs
(AGENTS.md/CLAUDE.md/QWEN.md), and docs/agents setup for the Gitea
issue tracker via the tea CLI, triage labels, and domain docs.
This commit is contained in:
2026-09-10 10:21:00 +02:00
commit 880e032ba1
17 changed files with 335 additions and 0 deletions
+27
View File
@@ -0,0 +1,27 @@
# build output
dist/
# generated types
.astro/
# dependencies
node_modules/
# logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
# environment variables
.env
.env.production
# macOS-specific files
.DS_Store
# jetbrains setting folder
.idea/
# agent session state
.qwen/
+8
View File
@@ -0,0 +1,8 @@
{
"mcpServers": {
"Astro docs": {
"type": "http",
"url": "https://mcp.docs.astro.build/mcp"
}
}
}
+4
View File
@@ -0,0 +1,4 @@
{
"recommendations": ["astro-build.astro-vscode"],
"unwantedRecommendations": []
}
+11
View File
@@ -0,0 +1,11 @@
{
"version": "0.2.0",
"configurations": [
{
"command": "./node_modules/.bin/astro dev",
"name": "Development server",
"request": "launch",
"type": "node-terminal"
}
]
}
+36
View File
@@ -0,0 +1,36 @@
## Development
When starting the dev server, use background mode:
```
astro dev --background
```
Manage the background server with `astro dev stop`, `astro dev status`, and `astro dev logs`.
## Documentation
Full documentation: https://docs.astro.build
Consult these guides before working on related tasks:
- [Adding pages, dynamic routes, or middleware](https://docs.astro.build/en/guides/routing/)
- [Working with Astro components](https://docs.astro.build/en/basics/astro-components/)
- [Using React, Vue, Svelte, or other framework components](https://docs.astro.build/en/guides/framework-components/)
- [Adding or managing content](https://docs.astro.build/en/guides/content-collections/)
- [Adding styles or using Tailwind](https://docs.astro.build/en/guides/styling/)
- [Supporting multiple languages](https://docs.astro.build/en/guides/internationalization/)
## Agent skills
### Issue tracker
Issues and specs live in the Gitea repo at `git.arthurerlich.de`, managed via the `tea` CLI. See `docs/agents/issue-tracker.md`.
### Triage labels
Default five-label vocabulary (needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix). See `docs/agents/triage-labels.md`.
### Domain docs
Single-context: `CONTEXT.md` + `docs/adr/` at the repo root. See `docs/agents/domain.md`.
Symlink
+1
View File
@@ -0,0 +1 @@
AGENTS.md
+27
View File
@@ -0,0 +1,27 @@
# QWEN.md
This file provides guidance to Qwen Code when working with code in this repository.
## Project Overview
`php-node-renderer-playground` is an **early-stage playground/experiment repository** with no source code yet. The working tree contains only this file and `.mcp.json`, and the git repository has no commits.
Based on the project name, the intended purpose is exploring **PHP and Node.js rendering** — e.g., how PHP and Node renderers can interoperate, share rendering logic, or be combined for server-side rendering. Nothing has been implemented yet; treat this repo as a blank slate.
## Tools & Configuration
- **`.mcp.json`** — Configures an MCP server for the **Astro docs** (`https://mcp.docs.astro.build/mcp`). The `mcp__Astro_docs__search_astro_docs_1e828ud` tool is available to search official Astro framework documentation. This suggests Astro (or a similar Node-based renderer) is a likely candidate for the rendering experiments. Use it when questions about Astro's rendering, SSR, or SSG behavior come up.
## Building and Running
No build, run, or test commands exist yet. The project has not been scaffolded.
- TODO: Once the stack is chosen (e.g., a PHP runtime + Node/Astro renderer), document the setup and key commands here (install, dev server, build, test).
- Until then, do not assume any toolchain (composer, npm, etc.) is present — verify against files in the repo before recommending commands.
## Development Conventions
No conventions established yet. When code is added:
- Follow the conventions of whichever frameworks are chosen (e.g., Astro conventions for any Node/SSR side; PSR-12 for PHP if PHP is introduced).
- Keep the playground nature in mind: this repo is for experiments, so prefer small, self-contained examples over full application scaffolding.
+43
View File
@@ -0,0 +1,43 @@
# Astro Starter Kit: Minimal
```sh
npm create astro@latest -- --template minimal
```
> 🧑‍🚀 **Seasoned astronaut?** Delete this file. Have fun!
## 🚀 Project Structure
Inside of your Astro project, you'll see the following folders and files:
```text
/
├── public/
├── src/
│ └── pages/
│ └── index.astro
└── package.json
```
Astro looks for `.astro` or `.md` files in the `src/pages/` directory. Each page is exposed as a route based on its file name.
There's nothing special about `src/components/`, but that's where we like to put any Astro/React/Vue/Svelte/Preact components.
Any static assets, like images, can be placed in the `public/` directory.
## 🧞 Commands
All commands are run from the root of the project, from a terminal:
| Command | Action |
| :------------------------ | :----------------------------------------------- |
| `npm install` | Installs dependencies |
| `npm run dev` | Starts local dev server at `localhost:4321` |
| `npm run build` | Build your production site to `./dist/` |
| `npm run preview` | Preview your build locally, before deploying |
| `npm run astro ...` | Run CLI commands like `astro add`, `astro check` |
| `npm run astro -- --help` | Get help using the Astro CLI |
## 👀 Want to learn more?
Feel free to check [our documentation](https://docs.astro.build) or jump into our [Discord server](https://astro.build/chat).
+5
View File
@@ -0,0 +1,5 @@
// @ts-check
import { defineConfig } from 'astro/config';
// https://astro.build/config
export default defineConfig({});
+51
View File
@@ -0,0 +1,51 @@
# Domain Docs
How the engineering skills should consume this repo's domain documentation when exploring the codebase.
## Before exploring, read these
- **`CONTEXT.md`** at the repo root, or
- **`CONTEXT-MAP.md`** at the repo root if it exists: it points at one `CONTEXT.md` per context. Read each one relevant to the topic.
- **`docs/adr/`**: read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `/domain-modeling` skill (reached via `/grill-with-docs` and `/improve-codebase-architecture`) creates them lazily when terms or decisions actually get resolved.
## File structure
Single-context repo (most repos):
```
/
├── CONTEXT.md
├── docs/adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
```
Multi-context repo (presence of `CONTEXT-MAP.md` at the root):
```
/
├── CONTEXT-MAP.md
├── docs/adr/ ← system-wide decisions
└── src/
├── ordering/
│ ├── CONTEXT.md
│ └── docs/adr/ ← context-specific decisions
└── billing/
├── CONTEXT.md
└── docs/adr/
```
## Use the glossary's vocabulary
When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
If the concept you need isn't in the glossary yet, that's a signal: either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `/domain-modeling`).
## Flag ADR conflicts
If your output contradicts an existing ADR, surface it explicitly rather than silently overriding:
> _Contradicts ADR-0007 (event-sourced orders), but worth reopening because…_
+56
View File
@@ -0,0 +1,56 @@
# Issue tracker: Gitea
Issues and specs for this repo live in the Gitea repository at
`https://git.arthurerlich.de/haylan/php-node-renderer-playground`. Use the `tea` CLI
(the official Gitea CLI, v0.15.1) for all operations.
`tea` infers the repository from the local git remote (`origin` → this repo), so
commands are run from the repo root without `-r`. Use `-o json` for machine-readable
output (e.g. `tea issues ls -o json`). If a command can't find a login, run
`tea login` first.
## Conventions
- **Create an issue**: `tea issues create -t "..." -d "..."` (add `-L "label, label"` for labels)
- **Read an issue**: `tea issues <n> --comments -o json`
- **List issues**: `tea issues ls -o json` (filters: `--state open|closed|all`, `--labels "..."`, `--keyword "..."`)
- **List issue comments**: `tea comments list <n>`
- **List labels**: `tea labels ls`
- **Comment on an issue**: `tea comments add <n> "..."`
- **Add / remove labels**: `tea issues edit <n> -L "label"` / `tea issues edit <n> --remove-labels "label"`
- **Assign a dev**: `tea issues edit <n> -a <username>`
- **Close**: `tea issues close <n>`
- **Reopen**: `tea issues reopen <n>`
Gitea shares one number space across issues and pull requests, so a bare `#42`
may be either: resolve with `tea pulls view <n>` (or `tea issues -K pulls <n>`) and
fall back to `tea issues <n>`.
## Pull requests as a triage surface
**PRs as a request surface: no.** _(Set to `yes` if this repo treats external PRs
as feature requests; `/triage` reads this flag.)_
When set to `yes`, PRs run through the same labels and states as issues, using the
`tea pulls` equivalents (`tea pulls ls`, `tea pulls view <n>`).
## When a skill says "publish to the issue tracker"
Create a Gitea issue in `haylan/php-node-renderer-playground` (`tea issues create`).
## When a skill says "fetch the relevant ticket"
Run `tea issues <n> --comments` for the referenced number.
## Wayfinding operations
Used by `/wayfinder`. The **map** is a single issue with **child** issues as tickets.
Gitea has no native sub-issues or issue-dependencies API, so links are recorded in
issue bodies.
- **Map**: a single issue labelled `wayfinder:map`, holding the Notes / Decisions-so-far / Fog body. Create with `tea issues create -t "..." -d "..." -L "wayfinder:map"`.
- **Child ticket**: an issue linked to the map via a task list in the map body, with `Part of #<map>` at the top of the child body. Labels: `wayfinder:<type>` (`research`/`prototype`/`grilling`/`task`). Once claimed, the ticket is assigned to the driving dev.
- **Blocking**: a `Blocked by: #<n>, #<n>` line near the top of the child body. A ticket is unblocked when every blocker is closed.
- **Frontier**: scan the map's open children (task list / `Part of`), drop any with an open blocker (per the `Blocked by` line) or an assignee; first in map order wins.
- **Claim**: assign the issue to the driving dev, the session's first write (`tea issues edit <n> -a <username>`).
- **Resolve**: comment the answer (`tea comments add <n> "..."`), close the issue (`tea issues close <n>`), then append a context pointer (gist + link) to the map's Decisions-so-far.
+15
View File
@@ -0,0 +1,15 @@
# Triage Labels
The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
| Label in mattpocock/skills | Label in our tracker | Meaning |
| -------------------------- | -------------------- | ---------------------------------------- |
| `needs-triage` | `needs-triage` | Maintainer needs to evaluate this issue |
| `needs-info` | `needs-info` | Waiting on reporter for more information |
| `ready-for-agent` | `ready-for-agent` | Fully specified, ready for an AFK agent |
| `ready-for-human` | `ready-for-human` | Requires human implementation |
| `wontfix` | `wontfix` | Will not be actioned |
When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
Edit the right-hand column to match whatever vocabulary you actually use.
+20
View File
@@ -0,0 +1,20 @@
{
"name": "site",
"type": "module",
"version": "0.0.1",
"engines": {
"node": ">=22.12.0"
},
"scripts": {
"dev": "astro dev",
"build": "astro build",
"preview": "astro preview",
"astro": "astro"
},
"dependencies": {
"astro": "^7.3.2"
},
"allowScripts": {
"esbuild": true
}
}
Binary file not shown.

After

Width:  |  Height:  |  Size: 655 B

+9
View File
@@ -0,0 +1,9 @@
<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 128 128">
<path d="M50.4 78.5a75.1 75.1 0 0 0-28.5 6.9l24.2-65.7c.7-2 1.9-3.2 3.4-3.2h29c1.5 0 2.7 1.2 3.4 3.2l24.2 65.7s-11.6-7-28.5-7L67 45.5c-.4-1.7-1.6-2.8-2.9-2.8-1.3 0-2.5 1.1-2.9 2.7L50.4 78.5Zm-1.1 28.2Zm-4.2-20.2c-2 6.6-.6 15.8 4.2 20.2a17.5 17.5 0 0 1 .2-.7 5.5 5.5 0 0 1 5.7-4.5c2.8.1 4.3 1.5 4.7 4.7.2 1.1.2 2.3.2 3.5v.4c0 2.7.7 5.2 2.2 7.4a13 13 0 0 0 5.7 4.9v-.3l-.2-.3c-1.8-5.6-.5-9.5 4.4-12.8l1.5-1a73 73 0 0 0 3.2-2.2 16 16 0 0 0 6.8-11.4c.3-2 .1-4-.6-6l-.8.6-1.6 1a37 37 0 0 1-22.4 2.7c-5-.7-9.7-2-13.2-6.2Z" />
<style>
path { fill: #000; }
@media (prefers-color-scheme: dark) {
path { fill: #FFF; }
}
</style>
</svg>

After

Width:  |  Height:  |  Size: 749 B

+17
View File
@@ -0,0 +1,17 @@
---
---
<html lang="en">
<head>
<meta charset="utf-8" />
<link rel="icon" type="image/svg+xml" href="/favicon.svg" />
<link rel="icon" href="/favicon.ico" />
<meta name="viewport" content="width=device-width" />
<meta name="generator" content={Astro.generator} />
<title>Astro</title>
</head>
<body>
<h1>Astro</h1>
</body>
</html>
+5
View File
@@ -0,0 +1,5 @@
{
"extends": "astro/tsconfigs/strict",
"include": [".astro/types.d.ts", "**/*"],
"exclude": ["dist"]
}