sakibcc/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add documentation for the three-stage development workflow and CLI management strategy; create a new notes file for additional insights.

Browse Source
This commit is contained in:
yuxuanhui
2026-08-03 16:17:16 +08:00
parent 91861565bb
commit 6e0c5c35fc
14 changed files with 3122 additions and 61 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AI-RD-Workflow/40-workflows/trellis-matt/EN/AGENTS.md
+4 -3
View File
@@ -49,18 +49,19 @@ Handle the following directly without creating a Trellis task:
- Trellis manages only task state, planning artifacts, research, checkpoints, cross-session recovery, and archiving.
- Matt provides only the engineering method for the current phase. Keep exactly one method owner per phase.
- Do not use `trellis-brainstorm` in Phase 1. The main session first drafts task artifacts from evidence, then reviews the spec with `grill-with-docs`.
- Do not use `trellis-brainstorm` in Phase 1. The main session first drafts task artifacts from evidence. Review a normal task's spec with `grill-with-docs`; for an approved Feishu-bound Spec/Ticket set, verify source-snapshot equivalence and use `grill-with-docs` only for decision-bearing task-local deltas.
- Do not use the native `trellis-implement` in Phase 2. The `trellis-matt-implement` sub-agent executes the recorded `standard|tdd` mode; if the agent is unavailable, the main session falls back using the same mode.
- Follow the project's `.trellis/workflow.md` for detailed phases, breadcrumbs, recovery, and archive commands.
- Do not create a task for simple work. If the project has no `.trellis/`, do not initialize it unless the user explicitly asks for durable records or initialization.
## Planning Method
- A Trellis task's `prd.md` and conditional `design.md` and `implement.md` are the task-level source of truth for the spec.
- A Trellis task's `prd.md` and conditional `design.md` and `implement.md` are the task-level source of truth for an unbound task. For a Feishu-bound task, approved Wiki/Base artifacts remain the business source while Trellis stores an execution snapshot and task-local planning.
- Initial planning artifacts should come from evidence in code, tests, configuration, documentation, and task history.
- Every Trellis implementation task records `Implementation Mode: standard|tdd` under `Testing Strategy` in `prd.md`; `standard` is the default.
- Record `tdd` when the user requests `/tdd`, test-first, red-green-refactor, or integration tests, or when the reviewed spec explicitly requires TDD, and confirm public test seams before execution.
- Use `grill-with-docs` to review product, scope, UX, compatibility, risk, acceptance, and key design decisions one by one.
- When there is no approved external Spec, use `grill-with-docs` to review product, scope, UX, compatibility, risk, acceptance, and key design decisions one by one.
- If a Feishu-bound snapshot matches the approved sources and adds no decision, perform only a mechanical consistency check. Review only task-local compatibility, migration, rollout/rollback, security, or sequencing deltas. If planning changes product requirements, acceptance, Ticket identity, or blocker semantics, revise and re-approve the owning Feishu artifact first.
- Ask one question at a time. Investigate environmental facts first and ask the user only for decisions that genuinely belong to them.
- After each answer is confirmed, immediately synchronize it back to the owning Trellis artifact.
- `CONTEXT.md` stores only durable domain terminology. ADRs store only decisions that are hard to reverse, counterintuitive, and based on a real tradeoff; they must not duplicate the task spec.