project-alignment
Project Alignment Skill
Patterns for maintaining alignment with PROJECT.md goals, scope, and constraints.
When This Skill Activates
- Validating feature alignment with PROJECT.md
- Assessing project scope
- Checking architectural constraints
- Keywords: "project", "alignment", "goals", "scope"
Core Concepts
Overview
This skill provides guidance on maintaining alignment with PROJECT.md. For detailed validation patterns, see the project-alignment-validation skill.
Key Topics:
- PROJECT.md structure and semantics
- Goal alignment validation
- Scope boundary checks
- Constraint adherence
See: project-alignment-validation skill for detailed validation patterns
Progressive Disclosure
This skill uses progressive disclosure to prevent context bloat:
- Index (this file): High-level concepts (<500 lines)
- Detailed patterns: See project-alignment-validation skill
Cross-References
Related Skills:
- project-alignment-validation - Detailed validation patterns
- semantic-validation - Semantic analysis patterns
Key Takeaways
- Always validate features against PROJECT.md goals
- Check scope boundaries before implementation
- Respect architectural constraints
- Refer to project-alignment-validation skill for detailed patterns
More from akaszubski/autonomous-dev
git-github
Git workflow and GitHub collaboration patterns including conventional commits, branch naming, PR workflow, and gh CLI usage. Use when creating commits, branches, or pull requests. TRIGGER when: git commit, branch, PR, pull request, merge, gh cli. DO NOT TRIGGER when: code implementation, testing, documentation without git operations.
26library-design-patterns
Two-tier design, progressive enhancement, non-blocking patterns, and security-first architecture for Python libraries. Use when creating or refactoring Python libraries. TRIGGER when: library design, module architecture, reusable component, two-tier. DO NOT TRIGGER when: simple scripts, config files, documentation-only changes.
26scientific-validation
Scientific method for validating claims with pre-registration, power analysis, statistical rigor, and Bayesian methods. Use when testing hypotheses, running experiments, or validating claims from papers. TRIGGER when: validate, hypothesis, experiment, backtest, evidence, statistical test. DO NOT TRIGGER when: routine coding, config changes, documentation, non-experimental tasks.
24state-management-patterns
JSON persistence, atomic writes, file locking, crash recovery, and state versioning patterns. Use when implementing stateful libraries or features requiring persistent state. TRIGGER when: state persistence, atomic write, file locking, crash recovery, checkpoint. DO NOT TRIGGER when: stateless utilities, pure functions, config reads, documentation.
22code-review
10-point code review checklist covering correctness, tests, error handling, type hints, naming, security, and performance. Use when reviewing PRs or evaluating code quality. TRIGGER when: code review, PR review, review checklist, code quality check. DO NOT TRIGGER when: writing new code, debugging, refactoring without review context.
22api-design
REST API design best practices covering versioning, error handling, pagination, and OpenAPI documentation. Use when designing or implementing REST APIs or HTTP endpoints. TRIGGER when: API design, REST endpoint, HTTP route, OpenAPI, swagger, pagination. DO NOT TRIGGER when: internal library code, CLI tools, non-HTTP interfaces.
22