Fix README links, add missing skills, correct invocation classification
- Fixed 3 broken links in root and common READMEs (pkm-curation, forge-interaction, forge-preferences were pointing to wrong buckets) - Moved project-context-pack from model-invoked to user-invoked (matches its disable-model-invocation: true flag) - Added 8 missing user-invoked and 6 missing model-invoked skills to root and common READMEs - Added all 9 engineering skills to engineering README (was missing codebase-design, domain-modeling, resolving-merge-conflicts, tdd, grill-with-docs, improve-codebase-architecture, setup-skills, to-issues, to-prd, triage) - Added pkm-curation to pkm README - Updated personal README to note both skills moved elsewhere - Added all forge skills to deprecated README - Added .gitignore for docs/adr/ - Added docs/agents/ reference files - Added project context cache
This commit is contained in:
@@ -0,0 +1,66 @@
|
||||
# ADR Wiki
|
||||
|
||||
Architecture Decision Records live on the forge wiki and are cloned into `docs/adr/` during setup.
|
||||
|
||||
## Wiki URL
|
||||
|
||||
```
|
||||
git@gitea.sagacity.ca:steve/Skills.wiki.git
|
||||
```
|
||||
|
||||
Derived from the forge remote during `/setup-skills`.
|
||||
|
||||
## Bootstrap
|
||||
|
||||
On first setup, `/setup-skills` clones the wiki:
|
||||
|
||||
```bash
|
||||
git clone git@gitea.sagacity.ca:steve/Skills.wiki.git docs/adr/
|
||||
```
|
||||
|
||||
And adds `docs/adr/` to `.gitignore`.
|
||||
|
||||
On subsequent sessions, pull the latest:
|
||||
|
||||
```bash
|
||||
cd docs/adr/ && git pull --rebase
|
||||
```
|
||||
|
||||
## Auth
|
||||
|
||||
Authentication for pushing ADR changes uses: **SSH key**
|
||||
|
||||
The wiki remote uses `git@gitea.sagacity.ca:steve/Skills.wiki.git` — same SSH key used for the source repo.
|
||||
|
||||
## Session-end push
|
||||
|
||||
At end of every session, the agent:
|
||||
|
||||
1. `cd docs/adr/ && git add -A && git commit -m "docs(adr): <action> ADR-NNNN — <description>"`
|
||||
2. `git pull --rebase` (handle any web UI edits)
|
||||
3. `git push`
|
||||
|
||||
If a conflict arises during rebase, surface it to the user for resolution.
|
||||
|
||||
## Commit message convention
|
||||
|
||||
```
|
||||
docs(adr): add ADR-NNNN — title
|
||||
docs(adr): update ADR-NNNN — reason
|
||||
docs(adr): remove ADR-NNNN — superseded by ADR-NNNN
|
||||
```
|
||||
|
||||
## Consumer skills
|
||||
|
||||
These skills read from `docs/adr/` by relative path — the wiki clone is transparent:
|
||||
|
||||
- `diagnosing-bugs`
|
||||
- `tdd`
|
||||
- `improve-codebase-architecture`
|
||||
- `domain-modeling`
|
||||
- `grill-with-docs`
|
||||
|
||||
These skills may create ADRs in `docs/adr/`; the wiki push is handled at session end:
|
||||
|
||||
- `domain-modeling`
|
||||
- `improve-codebase-architecture`
|
||||
@@ -0,0 +1,46 @@
|
||||
# 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.
|
||||
|
||||
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 creates them lazily when terms or decisions actually get resolved.
|
||||
|
||||
## File structure
|
||||
|
||||
**Single-context repo** (this repo):
|
||||
|
||||
```
|
||||
/
|
||||
├── CONTEXT.md
|
||||
├── docs/adr/
|
||||
│ ├── 0001-event-sourced-orders.md
|
||||
│ └── 0002-postgres-for-write-model.md
|
||||
├── src/
|
||||
└── .gitignore ← docs/adr/ ignored
|
||||
```
|
||||
|
||||
## ADR lifecycle
|
||||
|
||||
ADRs live on the forge wiki and are cloned into `docs/adr/` during setup (`/setup-skills`). The source repo ignores `docs/adr/` via `.gitignore`.
|
||||
|
||||
- **Reading** — skills read ADRs by relative path (`docs/adr/...`) as before. The wiki clone is transparent.
|
||||
- **Creating / updating** — skills write ADRs to `docs/adr/` as files. Changes accumulate in the wiki clone's local git state.
|
||||
- **Pushing** — at end of session, the agent commits new/modified ADRs to the wiki clone and pushes to the forge wiki remote, using `git pull --rebase` before push to handle any concurrent web edits.
|
||||
- **Commit message convention**: `docs(adr): <action> ADR-NNNN — <short description>`
|
||||
|
||||
## 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…_
|
||||
@@ -0,0 +1,34 @@
|
||||
# Issue tracker: Gitea
|
||||
|
||||
Issues and PRDs for this repo live as Gitea issues. Use the `tea` CLI for all operations.
|
||||
|
||||
## Conventions
|
||||
|
||||
- **Create an issue**: `tea issue create --title "..." --description "..."`. Use a heredoc for multi-line descriptions.
|
||||
- **Read an issue**: `tea issue <number> --comments`. Use `-o json` for machine-readable output.
|
||||
- **List issues**: `tea issue list --state open -o json` with appropriate `--labels` and `--state` filters.
|
||||
- **Comment on an issue**: `tea comment <number> "..."`.
|
||||
- **Apply / remove labels**: `tea issue edit <number> --add-label "..."` / `--remove-label "..."`. Multiple labels can be comma-separated or by repeating the flag.
|
||||
- **Close**: `tea issue close <number>`. `tea issue close` does not accept a closing comment, so post the explanation first with `tea comment <number> "..."`, then close.
|
||||
|
||||
Infer the repo from git remote -v — `tea` does this automatically when run inside a clone.
|
||||
|
||||
## Pull requests as a triage surface
|
||||
|
||||
**PRs as a request surface: no.**
|
||||
|
||||
When set to `yes`, PRs run through the same labels and states as issues, using the `tea pr` equivalents:
|
||||
|
||||
- **Read a PR**: `tea pr <number> --comments` and `tea api /repos/{owner}/{repo}/pulls/<number>.diff` for the diff.
|
||||
- **List external PRs for triage**: `tea pr list --state open -o json` then keep only PRs whose author is not a project member/owner.
|
||||
- **Comment / label / close**: `tea comment <number> "..."`, `tea pr edit --add-label`/`--remove-label`, `tea pr close`.
|
||||
|
||||
Gitea shares one number space across issues and PRs, so a bare `#42` may be either — resolve with `tea pr 42` and fall back to `tea issue 42`.
|
||||
|
||||
## When a skill says "publish to the issue tracker"
|
||||
|
||||
Create a Gitea issue.
|
||||
|
||||
## When a skill says "fetch the relevant ticket"
|
||||
|
||||
Run `tea issue <number> --comments`.
|
||||
@@ -0,0 +1,13 @@
|
||||
# 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 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.
|
||||
Reference in New Issue
Block a user