docs
Docs
Create and maintain project documentation in docs/ with a consistent, lightweight structure.
Outputs
Maintain these outputs:
docs/SUMMARY.md— documentation entry point (always regenerated)docs/architecture/— system design, infrastructure, component interactions, data flows, feature flows. Focus on how the system works, not file/code structure.docs/codebase/— file organization, directory structure, entry points, key modules and their responsibilities. Focus on where things live in the code.docs/code-standard/— coding conventions, naming rules, style guides, environment setup, custom rules and patterns the team follows. Focus on how to write code that fits in with the existing codebase, best practices, and team conventions, very important for maintaining consistency.docs/project-pdr/— product goals, use cases, business rules, constraints, and decision rationale. Nice to have many use case/requirements files
Also keep README.md aligned with current docs links and project summary.
Workflow
Step 1: Context Scan
More from buiducnhat/agent-skills
write-plan
Create detailed, execution-ready implementation plans for complex or high-risk changes without coding. Use when scope is large, requirements are mostly known, and work should be broken into validated phases before execution.
379execute-plan
Execute an approved implementation plan exactly and safely. Use when a plan already exists and work must be carried out phase-by-phase with verification checkpoints, status tracking, and final execution reporting.
378brainstorm
Collaborative discovery and design framing for ambiguous or high-risk work. Use when requirements are unclear, multiple approaches are possible, or you need to turn an idea into a validated design brief before planning or coding.
343quick-implement
Rapid implementation for small, low-risk, well-defined changes. Use when the task is narrow in scope, has clear acceptance criteria, and can be completed safely without a formal multi-phase plan.
332ask
Structured clarification and requirements gathering through focused dialogue. Use when a task is ambiguous, underspecified, or requires user input before any action can be taken. Do not plan or implement anything—only ask questions to collect the information needed.
193bootstrap
Initialize and scaffold a new project with structured requirements gathering. Use when starting a project from scratch, after running a framework initializer (npm init, create-next-app, etc.), or when an existing minimal project needs proper structure, documentation, and conventions. Triggers on: 'bootstrap project', 'start new project', 'scaffold project', 'initialize project', 'setup new project', or when the user wants to go from zero to a well-structured project foundation.
191