executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
brownfield-driftEnforces architecture boundaries defined in PLAN.md. Use when a PR crosses module/service boundaries, when the dev asks "are we following the architecture?", or as a scheduled architecture health check. Not for querying what a module does — use brownfield-chat for that.
Independent GitHub snapshot · Automated classification · Original documentation governs
wednesday-skills drift via Bash toolwednesday-skills drift --since <base-commit> to only report new violationswednesday-skills drift --rule <rule-name>If the project has no constraints block, add one to PLAN.md:
{
"boundaries": [
{
"rule": "frontend-never-imports-db",
"description": "Frontend components must never import DB layer directly",
"from": "src/app/**",
"to": "src/lib/db/**",
"type": "forbidden"
},
{
"rule": "no-circular-deps",
"description": "No circular dependencies anywhere",
"scope": "**",
"type": "no-cycle"
}
]
}
| Type | What it catches |
|---|---|
forbidden | Import from A → B that should never exist |
ownership | Logic pattern appearing outside its designated owner |
no-direct-import | Direct import between services that should use API |
no-cycle | Circular dependency between modules |
--since)wednesday-skills drift # full check
wednesday-skills drift --rule frontend-never-imports-db # single rule
wednesday-skills drift --since abc1234 # new drift only (for PR review)