feat(isac): link skill chips to abilities
This commit is contained in:
@@ -1,5 +1,39 @@
|
||||
# Repository Instructions
|
||||
|
||||
## Parallel task execution
|
||||
|
||||
For substantial changes, use subagents as a standard practice when the work can
|
||||
be divided into concrete, independent tasks that provide real parallel progress.
|
||||
|
||||
1. Delegate bounded mechanical work to faster, lower-reasoning agents. Suitable
|
||||
tasks include focused code discovery, repetitive call-site updates,
|
||||
documentation, and isolated test coverage.
|
||||
2. Keep architecture, security-sensitive behavior, database migrations, shared
|
||||
data-model decisions, and complex debugging with a suitably capable agent.
|
||||
3. Assign explicit file or subsystem ownership before parallel edits. Avoid
|
||||
having multiple agents edit the same files unless their work is deliberately
|
||||
sequenced.
|
||||
4. Do not delegate tightly coupled work merely to increase agent count. Keep it
|
||||
with the primary agent when coordination would cost more than it saves.
|
||||
5. The primary agent remains responsible for integrating results, reviewing
|
||||
diffs, resolving cross-cutting concerns, and running the final required
|
||||
validation.
|
||||
6. Subagents must follow every repository rule that applies to their assigned
|
||||
work, including design-system maintenance, audit logging, and database
|
||||
preservation.
|
||||
|
||||
## Documentation prose
|
||||
|
||||
Use the `stop-slop` skill whenever an agent creates or changes project
|
||||
documentation. Apply its review to the complete affected document, including
|
||||
sections that the change did not introduce.
|
||||
|
||||
Preserve technical meaning, commands, paths, formulas, links, policy strength,
|
||||
and product terminology. Remove filler, vague claims, formulaic contrasts,
|
||||
manufactured emphasis, false agency, and repetition. Prefer active voice and
|
||||
specific subjects. Do not weaken terms such as `must`, `never`, or `always`
|
||||
when they express a real requirement.
|
||||
|
||||
## SHD design-system maintenance
|
||||
|
||||
Treat `docs/DESIGN_SYSTEM.md` and the shared tokens and patterns in `src/app.css`
|
||||
@@ -86,7 +120,7 @@ Follow these rules:
|
||||
`user_access`, `user_moderation`, `identity`, and `role_management`.
|
||||
Actions describe the exact event in namespaced past tense, such as
|
||||
`weapon.updated`, `attribute.archived`, or `moderation.blocked`.
|
||||
4. Capture relationship changes as well as the primary row. When an action
|
||||
4. Capture changes to the primary row and its relationships. When an action
|
||||
replaces permission sets, compatible brands, talents, effects, tiers, or
|
||||
other linked records, include the meaningful previous and resulting sets.
|
||||
5. Create audit records only after validation succeeds and the requested
|
||||
@@ -122,8 +156,8 @@ Treat embedded database files as persistent user data, not disposable build
|
||||
artifacts.
|
||||
|
||||
Before deleting, replacing, recreating, renaming, or destructively migrating a
|
||||
database—and before any major schema change—create a timestamped JSON backup
|
||||
with `npm run db:backup`.
|
||||
database, create a timestamped JSON backup with `npm run db:backup`. Create the
|
||||
same backup before any major schema change.
|
||||
|
||||
Database work must follow these rules:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user