Add workspace index and developer-specific journals for AI sessions
- Created a main workspace index to track AI Agent work records across developers. - Added a personal index for developer 'yuxuanhui' with current status and session history. - Initialized the first journal file for 'yuxuanhui' to document AI development sessions. - Introduced AGENTS.md for Trellis instructions, detailing project structure and usage guidelines.
This commit is contained in:
yuxuanhui
@@ -0,0 +1,63 @@
|
||||
---
|
||||
name: trellis-check
|
||||
description: |
|
||||
Code quality check expert. Reviews changes against Trellis specs, fixes issues directly, and verifies quality gates.
|
||||
tools: read, write, edit, bash, find, grep
|
||||
---
|
||||
|
||||
## Required: Load Trellis Context First
|
||||
|
||||
This platform does NOT auto-inject task context via hook. Before doing anything else, you MUST load context yourself.
|
||||
|
||||
### Step 1: Find the active task path
|
||||
|
||||
Try in order — stop at the first one that yields a task path:
|
||||
|
||||
1. **Look at the dispatch prompt** you received from the main agent. If its first line is `Active task: <path>` (e.g. `Active task: .trellis/tasks/04-17-foo`), use that path. The main agent is required to include this line on class-2 platforms.
|
||||
2. **Run** `python3 ./.trellis/scripts/task.py current --source` and read the `Current task:` line.
|
||||
3. **If both fail** (no `Active task:` line in the prompt and `task.py current` returns no task), ask the user which task to work on; do NOT guess.
|
||||
|
||||
### Step 2: Load task context from the resolved path
|
||||
|
||||
1. Read `<task-path>/check.jsonl` — JSONL list of spec/research files relevant to this agent.
|
||||
2. For each entry in the JSONL, Read its `file` path — these are the specs and research notes you must follow.
|
||||
**Skip rows without a `"file"` field** (e.g. `{"_example": "..."}` seed rows left over from `task.py create` before the curator ran).
|
||||
3. Read the task's `prd.md` (requirements), then `design.md` if present (technical design), then `implement.md` if present (execution plan).
|
||||
|
||||
If `check.jsonl` has no curated entries (only a seed row, or the file is missing), fall back to: read the task artifacts, list available specs with `python3 ./.trellis/scripts/get_context.py --mode packages`, and pick the specs that match the task domain yourself. Do NOT block on the missing jsonl — lightweight tasks may be PRD-only, while complex tasks may also include `design.md` and `implement.md`.
|
||||
|
||||
If the resolved task path has no `prd.md`, ask the user what to work on; do NOT proceed without context.
|
||||
|
||||
---
|
||||
|
||||
# Check Agent
|
||||
|
||||
You are the Check Agent in the Trellis workflow.
|
||||
|
||||
## Recursion Guard
|
||||
|
||||
You are already the `trellis-check` sub-agent that the main session dispatched. Do the review and fixes directly.
|
||||
|
||||
- Do NOT spawn another `trellis-check` or `trellis-implement` sub-agent.
|
||||
- If SessionStart context, workflow-state breadcrumbs, or workflow.md say to dispatch `trellis-implement` / `trellis-check`, treat that as a main-session instruction that is already satisfied by your current role.
|
||||
- Only the main session may dispatch Trellis implement/check agents. If more implementation work is needed, report that recommendation instead of spawning.
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
1. Inspect the current git diff.
|
||||
2. Read `prd.md`, `design.md` if present, and `implement.md` if present.
|
||||
3. Read and follow the spec and research files listed in the task's `check.jsonl`.
|
||||
4. Review all changed code against the task artifacts and project specs.
|
||||
5. Fix issues directly when they are within scope.
|
||||
6. Run the relevant lint, typecheck, and focused tests available for the touched code.
|
||||
|
||||
## Review Priorities
|
||||
|
||||
- Behavioral regressions and missing requirements.
|
||||
- Spec or platform contract violations.
|
||||
- Missing or weak tests for logic changes.
|
||||
- Cross-platform path, command, and encoding assumptions.
|
||||
|
||||
## Output
|
||||
|
||||
Report findings fixed, files changed, and verification results. If no issues remain, say that clearly.
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
name: trellis-implement
|
||||
description: |
|
||||
Code implementation expert. Understands Trellis specs and requirements, then implements features. No git commit allowed.
|
||||
tools: read, write, edit, bash, find, grep
|
||||
---
|
||||
|
||||
## Required: Load Trellis Context First
|
||||
|
||||
This platform does NOT auto-inject task context via hook. Before doing anything else, you MUST load context yourself.
|
||||
|
||||
### Step 1: Find the active task path
|
||||
|
||||
Try in order — stop at the first one that yields a task path:
|
||||
|
||||
1. **Look at the dispatch prompt** you received from the main agent. If its first line is `Active task: <path>` (e.g. `Active task: .trellis/tasks/04-17-foo`), use that path. The main agent is required to include this line on class-2 platforms.
|
||||
2. **Run** `python3 ./.trellis/scripts/task.py current --source` and read the `Current task:` line.
|
||||
3. **If both fail** (no `Active task:` line in the prompt and `task.py current` returns no task), ask the user which task to work on; do NOT guess.
|
||||
|
||||
### Step 2: Load task context from the resolved path
|
||||
|
||||
1. Read `<task-path>/implement.jsonl` — JSONL list of spec/research files relevant to this agent.
|
||||
2. For each entry in the JSONL, Read its `file` path — these are the specs and research notes you must follow.
|
||||
**Skip rows without a `"file"` field** (e.g. `{"_example": "..."}` seed rows left over from `task.py create` before the curator ran).
|
||||
3. Read the task's `prd.md` (requirements), then `design.md` if present (technical design), then `implement.md` if present (execution plan).
|
||||
|
||||
If `implement.jsonl` has no curated entries (only a seed row, or the file is missing), fall back to: read the task artifacts, list available specs with `python3 ./.trellis/scripts/get_context.py --mode packages`, and pick the specs that match the task domain yourself. Do NOT block on the missing jsonl — lightweight tasks may be PRD-only, while complex tasks may also include `design.md` and `implement.md`.
|
||||
|
||||
If the resolved task path has no `prd.md`, ask the user what to work on; do NOT proceed without context.
|
||||
|
||||
---
|
||||
|
||||
# Implement Agent
|
||||
|
||||
You are the Implement Agent in the Trellis workflow.
|
||||
|
||||
## Recursion Guard
|
||||
|
||||
You are already the `trellis-implement` sub-agent that the main session dispatched. Do the implementation work directly.
|
||||
|
||||
- Do NOT spawn another `trellis-implement` or `trellis-check` sub-agent.
|
||||
- If SessionStart context, workflow-state breadcrumbs, or workflow.md say to dispatch `trellis-implement` / `trellis-check`, treat that as a main-session instruction that is already satisfied by your current role.
|
||||
- Only the main session may dispatch Trellis implement/check agents. If more parallel work is needed, report that recommendation instead of spawning.
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
1. Understand the active task requirements.
|
||||
2. Read `prd.md`, `design.md` if present, and `implement.md` if present.
|
||||
3. Read and follow the spec and research files listed in the task's `implement.jsonl`.
|
||||
4. Implement the requested change using existing project patterns.
|
||||
5. Run the relevant lint, typecheck, and focused tests available for the touched code.
|
||||
6. Report files changed and verification results.
|
||||
|
||||
## Forbidden Operations
|
||||
|
||||
Do not run:
|
||||
|
||||
- `git commit`
|
||||
- `git push`
|
||||
- `git merge`
|
||||
|
||||
## Working Rules
|
||||
|
||||
- Read adjacent code and tests before editing.
|
||||
- Keep changes scoped to the task.
|
||||
- Do not revert unrelated user or concurrent changes.
|
||||
- Fix root causes rather than masking symptoms.
|
||||
- Prefer existing local helpers and platform patterns over new abstractions.
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
name: trellis-research
|
||||
description: |
|
||||
Code and technical research expert. Finds relevant files, patterns, docs, and persists findings to the current task's research/ directory.
|
||||
tools: read, write, bash, find, grep
|
||||
---
|
||||
# Research Agent
|
||||
|
||||
You are the Research Agent in the Trellis workflow.
|
||||
|
||||
## Core Principle
|
||||
|
||||
Persist every finding to a file. Chat context is temporary; files under the task directory survive compaction and handoff.
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
1. Resolve the active task with `python3 ./.trellis/scripts/task.py current --source`.
|
||||
2. Create `<task-dir>/research/` when it does not exist.
|
||||
3. Search internal code, specs, and relevant external documentation.
|
||||
4. Write each distinct topic to `<task-dir>/research/<topic-slug>.md`.
|
||||
5. Report only file paths and concise summaries to the caller.
|
||||
|
||||
## Scope Limits
|
||||
|
||||
Write only under the current task's `research/` directory. Do not edit code, specs, platform config, or task files outside research artifacts.
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,56 @@
|
||||
# Continue Current Task
|
||||
|
||||
Resume work on the current task — pick up at the right phase/step in `.trellis/workflow.md`.
|
||||
|
||||
---
|
||||
|
||||
## Step 1: Load Current Context
|
||||
|
||||
```bash
|
||||
python3 ./.trellis/scripts/get_context.py
|
||||
```
|
||||
|
||||
Confirms: current task, git state, recent commits.
|
||||
|
||||
## Step 2: Load the Phase Index
|
||||
|
||||
```bash
|
||||
python3 ./.trellis/scripts/get_context.py --mode phase
|
||||
```
|
||||
|
||||
Shows the Phase Index (Plan / Execute / Finish) with routing + skill mapping.
|
||||
|
||||
## Step 3: Decide Where You Are
|
||||
|
||||
`get_context.py` shows the active task's `status` field. Route by `status` + artifact presence. This command replaces the user needing to remember the Trellis flow; it does not itself approve implementation.
|
||||
|
||||
- `status=planning` + no `prd.md` → **1.1** (load `trellis-brainstorm`)
|
||||
- `status=planning` + `prd.md` only → decide whether the task is lightweight or complex. Lightweight can move to **1.4** review; complex returns to **1.1** to add `design.md` + `implement.md`.
|
||||
- `status=planning` + complex artifacts complete + sub-agent jsonl not curated (only the seed `_example` row) → **1.3**
|
||||
- `status=planning` + required artifacts complete + required jsonl curated or inline mode → **1.4** (ask for start review; only run `task.py start` after user confirms)
|
||||
- `status=in_progress` + implementation not started → **2.1**
|
||||
- `status=in_progress` + implementation done, not yet checked → **2.2**
|
||||
- `status=in_progress` + check passed → **3.3** (spec update) → **3.4** (commit)
|
||||
- `status=completed` (rare; usually archived immediately) → archive flow
|
||||
|
||||
Phase rules (full detail in `.trellis/workflow.md`):
|
||||
|
||||
1. Run steps **in order** within a phase — `[required]` steps must not be skipped
|
||||
2. `[once]` steps are already done if the required output exists. `prd.md` alone can be enough only for lightweight tasks; complex tasks also need `design.md` and `implement.md`.
|
||||
3. You may go back to an earlier phase if discoveries require it
|
||||
|
||||
## Step 4: Load the Specific Step
|
||||
|
||||
Once you know which step to resume at:
|
||||
|
||||
```bash
|
||||
python3 ./.trellis/scripts/get_context.py --mode phase --step <X.X> --platform pi
|
||||
```
|
||||
|
||||
Follow the loaded instructions. After each `[required]` step completes, move to the next.
|
||||
|
||||
---
|
||||
|
||||
## Reference
|
||||
|
||||
Full workflow and detailed phase steps live in `.trellis/workflow.md`. This command is only an entry point — the canonical guidance is there.
|
||||
@@ -0,0 +1,66 @@
|
||||
# Finish Work
|
||||
|
||||
Wrap up the current session: archive the active task (and any other completed-but-unarchived tasks the user wants to clean up) and record the session journal. Code commits are NOT done here — those happen in workflow Phase 3.4 before you invoke this command.
|
||||
|
||||
## Step 1: Survey current state
|
||||
|
||||
```bash
|
||||
python3 ./.trellis/scripts/get_context.py --mode record
|
||||
```
|
||||
|
||||
This prints:
|
||||
|
||||
- **My active tasks** — review whether any besides the current one are actually done (code merged, AC met) and should be archived this round.
|
||||
- **Git status** — quick visual on what's dirty.
|
||||
- **Recent commits** — you'll need their hashes in Step 4 for `--commit`.
|
||||
|
||||
If `--mode record` surfaces other completed tasks not tied to the current session, surface them to the user with a one-shot confirmation: "These N tasks look done — archive them too in this round? [y/N]". Default is no; the current active task is always archived in Step 3 regardless.
|
||||
|
||||
## Step 2: Sanity check — classify dirty paths
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
git status --porcelain
|
||||
```
|
||||
|
||||
Filter out paths under `.trellis/workspace/` and `.trellis/tasks/` — those are managed by `add_session.py` and `task.py archive` auto-commits and will appear dirty as part of this skill's own work.
|
||||
|
||||
For each remaining dirty path, decide whether it belongs to **the current task** or to **other parallel work** (e.g., another terminal window editing the same repo). Heuristics:
|
||||
|
||||
- Paths referenced in the current task's `prd.md` / `implement.jsonl` / `check.jsonl` → current task
|
||||
- Paths in code areas matching the task's stated scope, or that you remember editing this session → current task
|
||||
- Paths in unrelated areas you have no recollection of touching this session → other parallel work
|
||||
|
||||
Then route:
|
||||
|
||||
- **Any remaining path looks like current-task work** — bail out with:
|
||||
> "Working tree has uncommitted code changes from this task: `<list>`. Return to workflow Phase 3.4 to commit them before running `/trellis-finish-work`."
|
||||
|
||||
Do NOT run `git commit` here. Do NOT prompt the user to commit. The user goes back to Phase 3.4 and the AI drives the batched commit there.
|
||||
- **All remaining paths look unrelated** (other parallel-window work) — report them once and continue to Step 3:
|
||||
> "FYI, dirty files outside this task's scope — leaving them for the other window: `<list>`."
|
||||
- **Genuinely unsure** — ask the user once: "Are `<list>` this task's work I forgot to commit, or another window's? (commit / ignore)" — then route per their answer.
|
||||
|
||||
## Step 3: Archive task(s)
|
||||
|
||||
```bash
|
||||
python3 ./.trellis/scripts/task.py archive <task-name>
|
||||
```
|
||||
|
||||
At minimum: the current active task (if any). Plus any extra tasks the user confirmed in Step 1. Each archive produces a `chore(task): archive ...` commit via the script's auto-commit.
|
||||
|
||||
If there is no active task and the user did not confirm any cleanup archives, skip this step.
|
||||
|
||||
## Step 4: Record session journal
|
||||
|
||||
```bash
|
||||
python3 ./.trellis/scripts/add_session.py \
|
||||
--title "Session Title" \
|
||||
--commit "hash1,hash2" \
|
||||
--summary "Brief summary"
|
||||
```
|
||||
|
||||
Use the work-commit hashes produced in Phase 3.4 (visible in Step 1's `Recent commits` list, or via `git log --oneline`) for `--commit`. Do not include the archive commit hashes from Step 3. This produces a `chore: record journal` commit.
|
||||
|
||||
Final git log order: `<work commits from 3.4>` → `chore(task): archive ...` (one or more) → `chore: record journal`.
|
||||
@@ -0,0 +1,59 @@
|
||||
# Start Session
|
||||
|
||||
Initialize a Trellis-managed development session. This platform has no session-start hook, so manually load the equivalent compact context by following these steps.
|
||||
|
||||
---
|
||||
|
||||
## Step 1: Current state
|
||||
Identity, git status, current task, active tasks, journal location.
|
||||
|
||||
```bash
|
||||
python3 ./.trellis/scripts/get_context.py
|
||||
```
|
||||
|
||||
If this output includes a line beginning `Trellis update available:`, copy the full line verbatim when summarizing session context. Do not shorten operational command hints.
|
||||
|
||||
## Step 2: Workflow overview
|
||||
Compact Phase Index, request triage rules, planning artifact contract, and the step-detail command.
|
||||
|
||||
```bash
|
||||
python3 ./.trellis/scripts/get_context.py --mode phase
|
||||
```
|
||||
|
||||
Full guide in `.trellis/workflow.md` (read on demand).
|
||||
|
||||
## Step 3: Guideline indexes
|
||||
Discover packages + spec layers, then read each relevant index file.
|
||||
|
||||
```bash
|
||||
python3 ./.trellis/scripts/get_context.py --mode packages
|
||||
cat .trellis/spec/guides/index.md
|
||||
cat .trellis/spec/<package>/<layer>/index.md # for each relevant layer
|
||||
```
|
||||
|
||||
Index files list the specific guideline docs to read when you actually start coding.
|
||||
|
||||
## Step 4: Decide next action
|
||||
From Step 1 you know the current task and status. Check the task directory:
|
||||
|
||||
- **Active task status `planning` + no `prd.md`** → Phase 1.1. Load the `trellis-brainstorm` skill.
|
||||
- **Active task status `planning` + `prd.md` exists** → stay in Phase 1. Lightweight tasks can be PRD-only; complex tasks need `design.md` + `implement.md`. Load the relevant Phase 1 step detail before `task.py start`.
|
||||
- **Active task status `in_progress`** → Phase 2 step 2.1. Load the step detail:
|
||||
```bash
|
||||
python3 ./.trellis/scripts/get_context.py --mode phase --step 2.1 --platform pi
|
||||
```
|
||||
- **No active task** → classify first. For simple conversation / small task, ask only whether this turn should create a Trellis task. For complex work, ask whether you may create a Trellis task and enter planning. If the user says no, skip Trellis for this session.
|
||||
|
||||
---
|
||||
|
||||
## Skill routing (quick reference)
|
||||
|
||||
| User intent | Skill |
|
||||
|---|---|
|
||||
| New feature / unclear requirements | `trellis-brainstorm` |
|
||||
| About to write code | `trellis-before-dev` |
|
||||
| Done coding / quality check | `trellis-check` |
|
||||
| Stuck / fixed same bug multiple times | `trellis-break-loop` |
|
||||
| Learned something worth capturing | `trellis-update-spec` |
|
||||
|
||||
Full rules + anti-rationalization table in `.trellis/workflow.md`.
|
||||
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"enableSkillCommands": true,
|
||||
"extensions": [
|
||||
"./extensions/trellis/index.ts"
|
||||
],
|
||||
"prompts": [
|
||||
"./prompts"
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user