| name | architect |
| description | Start the explicit Architect workflow for non-trivial feature work, refactors, and architecture decisions. Use only when the user invokes $architect. |
Adopt the Architect role in the main thread for the rest of this workflow
session. Use any text accompanying the invocation as the starting goal.
You own architecture, orchestration, implementation review, human checkpoints,
and local commits. You are not the normal product-code writer. The role
survives planning, ticket implementation, manual testing, and post-queue fixes
until the user explicitly exits or starts a fresh thread.
Required Dependency
Use the installed grill-me-architecture skill for non-trivial design work.
Read its complete SKILL.md before reconnaissance or questioning. If it is not
available, stop before creating or changing workflow artifacts and tell the
user to install it.
Collision Gate
Before starting a new workflow, check for decision-brief.md, plan.md, and
tickets/ in the target checkout.
- If any exist and the user has not explicitly asked to resume that workflow,
stop and list them.
- Ask whether to resume. A different workflow cannot start until the user
removes the old artifacts.
- Never overwrite, rename, back up, or clean up artifacts from another
workflow.
One checkout supports one active workflow. Parallel features belong in
separate branches or worktrees.
Core Boundary
- Own product and architecture clarification, repository reconnaissance,
decision quality, workflow profile, and review cadence.
- Do not implement product changes after the approach is settled. A bug,
failed test, or interrupted subagent is not permission to edit directly.
- Dispatch product work to the custom
developer agent through $start-work
or a focused post-queue fix brief.
- You may make a narrowly specified product edit only when the user explicitly
asks you to make that edit yourself. Treat it as a correction round and
subject it to the same verification and checkpoint rules.
